Sorry for the delay in my answer, I saved a copy of the partition before I restored from backup, but it took me a while to cobble a machine together to access it on.
/opt/zimbra/db/data/mail.err
Code:
080219 22:08:00 mysqld started
080219 22:08:00 [Warning] Changed limits: max_open_files: 1024 max_connections: 16 table_cache: 499
080219 22:08:01 InnoDB: Started; log sequence number 1 3397511598
080219 22:08:01 [Note] /opt/zimbra/mysql/libexec/mysqld: ready for connections.
Version: '5.0.45-log' socket: '/opt/zimbra/db/mysql.sock' port: 7306 Source distribution
InnoDB: Error: the size of single-table tablespace file ./mailbox192/tombstone.ibd
InnoDB: is only 0 4096, should be at least 65536!
080219 22:13:24InnoDB: Assertion failure in thread 2489510832 in file fil0fil.c line 564
InnoDB: Failing assertion: 0
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
080219 22:13:24 - mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=8388600
read_buffer_size=1044480
max_used_connections=1
max_connections=16
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 40895 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x93d1ac0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0x9462abe8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8176361
0x836e9c4
0x836f081
0x8379c26
0x8350dc9
0x8345f86
0x8303e47
0x830434a
0x82bcf07
0x82c3242
0x824f1c0
0x8241139
0x81c8672
0x81bd83d
0x81c1138
0x81c1b12
0x81c1e4f
0x818ce8d
0x8196567
0x8196bab
0x81981ed
0x8198cea
0xb7f31341
0xb7e614ee
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x93e7980 = SELECT 192, sequence, date, ids
INTO OUTFILE '/tmp/migrate20060911-17014-mbox192-tombstone.dat'
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n'
FROM mailbox192.tombstone
thd->thread_id=10
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
Number of processes running now: 0
080219 22:13:24 mysqld restarted
080219 22:13:24 [Warning] Changed limits: max_open_files: 1024 max_connections: 16 table_cache: 499
080219 22:13:24 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
080219 22:13:26 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 1 3496228619.
InnoDB: Doing recovery: scanned up to log sequence number 1 3501471232
InnoDB: Doing recovery: scanned up to log sequence number 1 3506714112
InnoDB: Doing recovery: scanned up to log sequence number 1 3511956992
InnoDB: Doing recovery: scanned up to log sequence number 1 3517199872
InnoDB: Doing recovery: scanned up to log sequence number 1 3522442752
InnoDB: Doing recovery: scanned up to log sequence number 1 3527685632
InnoDB: Doing recovery: scanned up to log sequence number 1 3532928512
InnoDB: Doing recovery: scanned up to log sequence number 1 3538171392
InnoDB: Doing recovery: scanned up to log sequence number 1 3543414272
InnoDB: Doing recovery: scanned up to log sequence number 1 3548657152
InnoDB: Doing recovery: scanned up to log sequence number 1 3553900032
InnoDB: Doing recovery: scanned up to log sequence number 1 3559142912
InnoDB: Doing recovery: scanned up to log sequence number 1 3564385792
InnoDB: Doing recovery: scanned up to log sequence number 1 3569628672
InnoDB: Doing recovery: scanned up to log sequence number 1 3574871552
InnoDB: Doing recovery: scanned up to log sequence number 1 3580114432
InnoDB: Doing recovery: scanned up to log sequence number 1 3585357312
InnoDB: Doing recovery: scanned up to log sequence number 1 3590600192
InnoDB: Doing recovery: scanned up to log sequence number 1 3595843072
InnoDB: Doing recovery: scanned up to log sequence number 1 3601085952
InnoDB: Doing recovery: scanned up to log sequence number 1 3606328832
InnoDB: Doing recovery: scanned up to log sequence number 1 3611571712
InnoDB: Doing recovery: scanned up to log sequence number 1 3616814592
InnoDB: Doing recovery: scanned up to log sequence number 1 3622057472
InnoDB: Doing recovery: scanned up to log sequence number 1 3627300352
InnoDB: Doing recovery: scanned up to log sequence number 1 3632543232
InnoDB: Doing recovery: scanned up to log sequence number 1 3637786112
InnoDB: Doing recovery: scanned up to log sequence number 1 3643028992
InnoDB: Doing recovery: scanned up to log sequence number 1 3648271872
InnoDB: Doing recovery: scanned up to log sequence number 1 3653480327
080219 22:13:52 InnoDB: Error: table 'mailbox192/tombstone'
InnoDB: in InnoDB data dictionary has tablespace id 775,
InnoDB: but tablespace with that id or name does not exist. Have
InnoDB: you deleted or moved .ibd files?
InnoDB: This may also be a table created with CREATE TEMPORARY TABLE
InnoDB: whose .ibd and .frm files MySQL automatically removed, but the
InnoDB: table still exists in the InnoDB internal data dictionary.
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting.html
InnoDB: for how to resolve the issue.
080219 22:13:52 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
080219 22:14:37 InnoDB: Started; log sequence number 1 3653480327
080219 22:14:37 [Note] /opt/zimbra/mysql/libexec/mysqld: ready for connections.
Version: '5.0.45-log' socket: '/opt/zimbra/db/mysql.sock' port: 7306 Source distribution
080219 23:49:51 [Note] /opt/zimbra/mysql/libexec/mysqld: Normal shutdown
080219 23:49:51 InnoDB: Starting shutdown...
080219 23:49:52 InnoDB: Shutdown completed; log sequence number 1 3653549307
080219 23:49:52 [Note] /opt/zimbra/mysql/libexec/mysqld: Shutdown complete
080219 23:49:52 mysqld ended
080220 00:29:59 mysqld started
080220 0:30:00 [Warning] Changed limits: max_open_files: 1024 max_connections: 16 table_cache: 499
080220 0:30:04 InnoDB: Started; log sequence number 1 3653549307
080220 0:30:05 [Note] /opt/zimbra/mysql/libexec/mysqld: ready for connections.
Version: '5.0.45-log' socket: '/opt/zimbra/db/mysql.sock' port: 7306 Source distribution
080220 0:30:11 [Note] /opt/zimbra/mysql/libexec/mysqld: Normal shutdown
080220 0:30:11 InnoDB: Starting shutdown...