Назад | Перейти на главную страницу

Таблицы MySQL аварийно завершают работу

Это одна из многих случайных таблиц, которые могут быть повреждены. Есть идеи, почему и что может вызвать это?

Как мне предотвратить сбой таблиц MySQL и сбой MySQL?

Repairing USR_wp537

USR_wp537.rev_commentmeta                     OK
USR_wp537.rev_comments                        OK
USR_wp537.rev_links                           OK
USR_wp537.rev_options                         OK
USR_wp537.rev_postmeta                        OK
USR_wp537.rev_posts
Error    : Incorrect key file for table './USR_wp537/rev_posts'; try to repair it
Error    : Incorrect key file for table 'rev_posts'; try to repair it
error    : Corrupt
USR_wp537.rev_term_relationships              OK
USR_wp537.rev_term_taxonomy                   OK
USR_wp537.rev_terms                           OK
USR_wp537.rev_usermeta                        OK
USR_wp537.rev_users      

В конце концов, единственный способ исправить это - сделать mysql> REPAIR TABLE <tbl> USE_FRM;

Это тоже mysql 5.5

наверх - 20:17:11 вверх 4 дня, 8:57, 1 пользователь, средняя загрузка: 0,41, 0,37, 0,36 Задачи: всего 204, 1 запущен, 203 спит, 0 остановлен, 0 зомби Cpu0: 11,0% us, 0,3% sy, 0,0% ni, 88,7% id, 0,0% wa, 0,0% hi, 0,0% si, 0,0% st Cpu1: 5,0% us, 1,0% sy, 0,0% ni, 93,4% id, 0,0% wa, 0,0% hi , 0,7% si, 0,0% st Cpu2: 10,4% us, 0,7% sy, 0,0% ni, 89,0% id, 0,0% wa, 0,0% hi, 0,0% si, 0,0% st Cpu3: 1,3% us, 0,3% sy , 0,0% ni, 98,0% id, 0,0% wa, 0,0% hi, 0,3% si, 0,0% st Mem: всего 16288440k, использовано 15292940k, 995500k свободно, 1398928k буферов Swap: всего 8191992k, использовано 0k, 8191992k свободно, 9351404k кэшировано

my.cnf

[mysqld]
core-file
default-storage-engine=MyISAM
local-infile=0
symbolic-links=0
skip-networking
max_connections = 500
max_user_connections = 40
key_buffer = 500M
myisam_sort_buffer_size = 32M
join_buffer_size = 256M
read_buffer_size = 2M
sort_buffer_size = 2M
read_rnd_buffer_size = 2M
table_cache = 1024
thread_cache_size = 16K
wait_timeout = 20
connect_timeout = 10
tmp_table_size = 256M
max_heap_table_size = 256M
max_allowed_packet = 160M
max_connect_errors = 10
query_cache_limit = 1M
query_cache_size = 64M
query_cache_type = 1
low_priority_updates=1
concurrent_insert=ALWAYS
log-error=/var/log/mysql/error.log
myisam_repair_threads=4
[mysqld_safe]
core-file-size = unlimited
open_files_limit = 8192
log-error=/var/log/mysql/error.log

[mysqldump]
quick
max_allowed_packet = 512M

[myisamchk]
key_buffer = 64M
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M

EDIT: похоже, MySQL по какой-то причине перезапустился?

130131 20:30:59 [ERROR] Got an error from thread_id=817995, /builddir/build/BUILD/mysql-5.5.28/mysql-5.5.28/storage/myisam/mi_write.c:223
130131 20:30:59 [ERROR] MySQL thread id 817998, OS thread handle 0x7f8589e2a700, query id 24842525 localhost ahmad_wp Waiting for table level lock
SELECT option_value FROM wp_options WHERE option_name = 'widget_momizat-posts-images' LIMIT 1
130131 20:30:59 [ERROR] MySQL thread id 817995, OS thread handle 0x7f858692f700, query id 24842524 localhost ahmad_wp update
INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`) VALUES ('rewrite_rules', 'a:91:{s:27:\"typename/([0-9]{4})/(.+)/?$\";s:30:\"index.php?typename=$matches[2]\";s:47:\"category/(.+?)/feed/(feed|rdf|rss|rss2|atom)/?$\";s:52:\"index.php?category_name=$matches[1]&feed=$matches[2]\";s:42:\"category/(.+?)/(feed|rdf|rss|rss2|atom)/?$\";s:52:\"index.php?category_name=$matches[1]&feed=$matches[2]\";s:35:\"category/(.+?)/page/?([0-9]{1,})/?$\";s:53:\"index.php?category_name=$matches[1]&paged=$matches[2]\";s:17:\"category/(.+?)/?$\";s:35:\"index.php?category_name=$matches[1]\";s:44:\"tag/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$\";s:42:\"index.php?tag=$matches[1]&feed=$matches[2]\";s:39:\"tag/([^/]+)/(feed|rdf|rss|rss2|atom)/?$\";s:42:\"index.php?tag=$matches[1]&feed=$matches[2]\";s:32:\"tag/([^/]+)/page/?([0-9]{1,})/?$\";s:43:\"index.php?tag=$matches[1]&paged=$matches[2]\";s:14:\"tag/([^/]+)/?$\";s:25:
    130131 20:33:42 mysqld_safe Number of processes running now: 0
    130131 20:33:42 mysqld_safe mysqld restarted
    130131 20:33:42 [Note] libgovernor.so found
    130131 20:33:42 [Note] All governors functions found too
    130131 20:33:42 [ERROR] Governor not connected
    130131 20:33:42 [Note] All governors lve functions found too
    130131 20:33:42 [Note] Plugin 'FEDERATED' is disabled.
    130131 20:33:42 InnoDB: The InnoDB memory heap is disabled
    130131 20:33:42 InnoDB: Mutexes and rw_locks use GCC atomic builtins
    130131 20:33:42 InnoDB: Compressed tables use zlib 1.2.3
    130131 20:33:42 InnoDB: Using Linux native AIO
    130131 20:33:42 InnoDB: Initializing buffer pool, size = 128.0M
    130131 20:33:42 InnoDB: Completed initialization of buffer pool
    130131 20:33:42 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!
    130131 20:33:42  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...
    130131 20:33:42  InnoDB: Waiting for the background threads to start
    130131 20:33:43 InnoDB: 1.1.8 started; log sequence number 5726524860
    130131 20:33:43 [Note] Event Scheduler: Loaded 1 event
    130131 20:33:43 [Note] /usr/sbin/mysqld: ready for connections.
    Version: '5.5.28-cll-lve'  socket: '/var/lib/mysql/mysql.sock'  port: 0  MySQL Community Server (GPL)

РЕДАКТИРОВАТЬ: жесткие диски чистые

РЕДАКТИРОВАТЬ: использование mcelog для проверки ОЗУ

РЕДАКТИРОВАТЬ: для проверки наличия проблем в сообщениях использовалось следующее

  902  fgrep -i seg /var/log/messages
  903  fgrep -i mce /var/log/messages
  904  tail /var/log/mysql/error.log
  906  smartctl --all /dev/sda
  907  smartctl -t short /dev/sda
  908  tail /var/log/mysql/error.log
  910  smartctl --all /dev/sda
  911  fgrep -i i/o /var/log/messages
  912  fgrep -i i/o /var/log/messages*
  913  fgrep -i sda /var/log/messages*
  914  fgrep -i sense /var/log/messages*
  915  egrep 'sda.*Error' sense /var/log/messages*
  916  egrep -h 'sda.*Error' sense /var/log/messages*
  917  egrep -h 'sda.*Error' /var/log/messages*

df /tmp
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda5              4031680     97304   3729576   3% /tmp

Вопреки распространенному мнению, таблицы MySQL не дают сбоев просто так. Сбои часто связаны с высокой загрузкой или слишком большим количеством строк. Вот дерьмо.

Если у вас произошел сбой таблиц, значит, существует основная проблема с сервером, такая как плохая память или плохой жесткий диск. Это также может быть ошибка сервера MySQL, но это очень маловероятно. Если вы являетесь клиентом веб-хостинга, вы ничего не можете сделать, кроме как заставить свой хост решить основную проблему.

Мы видели это, когда на диске для временных таблиц не хватало места из-за плохо написанных соединений. Временные таблицы временные, поэтому их сложно поймать на месте.

Есть ли у вас что-нибудь интересное внутри журнала сообщений (обычно / var / log / messages). Здесь могли быть видны проблемы с диском или памятью ...

Когда мы уже говорим о дисках, мне пришлось заменить очень много дисков ... (даже серия Enterprise не является пуленепробиваемой)