Недавно я загрузил большую (~ 5 ГБ) базу данных из SQLdump в базу данных локального сервера MySQL. Загрузился нормально после пары попыток, и первоначально я мог запросить без проблем, хотя запросы занимали ~ 1,5 минуты (что не идеально, но хорошо).
Теперь, однако, запросы выпадают через пару секунд с
ERROR 2013 (HY000): Lost connection to MySQL server during query
и у меня даже был
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Это очень странно, потому что он работал нормально в течение первого часа или около того (оба через mysql-workbench и через стандартный интерфейс командной строки).
Я уже поднял max_allowed_packet размер в my.conf до 64 МБ, но это не имеет никакого влияния. Есть идеи? Я на Ubuntu 12.04 (ядро 3.3.6-030306).
UGH. Так что это похоже на ошибку или, возможно, на аппаратный сбой. error.log показывает загрузку hex, затем
p c -> y;
InnoDB: End of page dump
130509 18:25:51 InnoDB: Page checksum 3880653435, prior-to-4.0.14-form checksum 3737975691
InnoDB: stored checksum 386314462, prior-to-4.0.14-form stored checksum 3737975691
InnoDB: Page lsn 4 759090297, low 4 bytes of lsn at page end 759090297
InnoDB: Page number (if stored to page already) 240815,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an update undo log page
InnoDB: Page may be an index page where index id is 208
InnoDB: (index "PRIMARY" of table "chembl_15"."compound_structures")
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 240815.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
130509 18:25:51
InnoDB: Assertion failure in thread 139737190622976 in file buf0buf.c line 3629
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
23:25:51 UTC - mysqld got signal 6 ;
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=16777216
read_buffer_size=131072
max_used_connections=2
max_threads=151
thread_count=2
connection_count=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346682 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7f172cfd87b9]
/usr/sbin/mysqld(handle_fatal_signal+0x483)[0x7f172ce9e8f3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f172bbebcb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7f172b257425]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7f172b25ab8b]
/usr/sbin/mysqld(+0x5f2b81)[0x7f172d075b81]
/usr/sbin/mysqld(+0x620cc9)[0x7f172d0a3cc9]
/usr/sbin/mysqld(+0x5ad1c0)[0x7f172d0301c0]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f172bbe3e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f172b314ccd]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
130509 18:25:51 [Note] Plugin 'FEDERATED' is disabled.
130509 18:25:51 InnoDB: The InnoDB memory heap is disabled
130509 18:25:51 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130509 18:25:51 InnoDB: Compressed tables use zlib 1.2.3.4
130509 18:25:51 InnoDB: Initializing buffer pool, size = 128.0M
130509 18:25:52 InnoDB: Completed initialization of buffer pool
130509 18:25:52 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130509 18:25:52 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...
130509 18:25:52 InnoDB: Waiting for the background threads to start
130509 18:25:53 InnoDB: 5.5.31 started; log sequence number 21293128389
130509 18:25:53 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
130509 18:25:53 [Note] - '127.0.0.1' resolves to '127.0.0.1';
130509 18:25:53 [Note] Server socket created on IP: '127.0.0.1'.
130509 18:25:53 [Note] Event Scheduler: Loaded 0 events
130509 18:25:53 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.31-0ubuntu0.12.04.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 240815.
InnoDB: You may have to recover from a backup.
130509 18:27:15 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex
Какие-нибудь мысли :-(
Ответы:
Так что я понятия не имею, что вызвало это, но кажется, что линия
Был на месте - я перезагрузил свою систему и теперь могу запросить снова без сбоев. Интересно, связано ли это с тем, что после загружая базу данных, я установил MySQL-workbench, хотя он все еще работал в течение часа или около того после этого.
Одна вещь, которая может иметь отношение к делу - моя ОС работает на SSD объемом всего 20 ГБ, а папка данных MySQL - на жестком диске (~ 750 ГБ). Интересно, была ли какая-то проблема с кешем, вызванная этим разделением (не должно быть, но кто знает).
ОБНОВИТЬ
Три дня спустя и никаких коррупций пока нет ...
источник
У меня было что-то вроде этого, и в моем случае перезагрузка виртуальной машины, которая запускает базу данных, исправила проблему, а перезапуск mysql - нет. Насколько я понимаю, это указывает на ошибку ОЗУ.
Если бы сами жесткие диски были отключены и перезапущены, как при перезагрузке хост-среды нашей виртуальной машины, это оставило бы больше возможностей в отношении аппаратных сбоев в дисковой системе и ее кэширования, и
Я не думал спрашивать о ECC Ram, когда я ввел сервер в эксплуатацию, о чем я сейчас сожалею. Тем не менее, наш хостинг-провайдер рад поменять оперативную память на новые модули DIMM.
Если перезагрузка сервера не решит проблему, то, скорее всего, это не будет ошибка ОЗУ.
источник