Базы данных Sql повреждаются после каждого резервного копирования

У меня проблема с моим unix-сервером. Это началось неделю назад. Через день после резервного копирования (раньше у меня было 3 файла резервных копий) я посетил веб-сайт на сервере, но он не работал. Я перезапустил сервер, и он, казалось, работал нормально, за исключением службы mysql. Мои попытки перезапустить его не увенчались успехом. Затем я решил, что это из-за того, что сервер был заполнен, поэтому я удалил одну из резервных копий, очистил место, и служба mysql успешно перезапустилась. Затем я понял, что таблицы в одной из баз данных (таблицы MYIsam) были повреждены. Поэтому я восстановил их с помощью команды myisamchk через ssh, и все заработало нормально. Однако уже на следующий день я проснулся, они снова были повреждены (несмотря на то, что mysql работал нормально), и на этот раз на сервере не было проблем с дисковым пространством. Я снова их ремонтировал. На следующий день произошло то же самое; и на этот раз таблицы innodb, которые были частью другой базы данных, также были повреждены. Я их тоже исправил, так что теперь все работает хорошо, но я думаю, что то же самое произойдет после сегодняшнего резервного копирования.

Я не могу идентифицировать проблему и не знаю, в какие журналы смотреть, чтобы понять проблему. Кто-нибудь может мне помочь? Большое спасибо заранее.


mysql sql-server backup innodb myisam
person eylul    schedule 30.11.2015    source источник
comment
Какой метод вы используете для резервного копирования?   -  person Sasha Pachev    schedule 30.11.2015
comment
Я делаю это через новую систему резервного копирования whm, устаревшая на данный момент отключена. Я использую сжатые параметры и получаю резервные копии баз данных sql только для каждой учетной записи. Сведения о сервере следующие: CENTOS 6.7 x86_64 xenpv — сервер WHM 11.52.1 (сборка 2). Вам нужна дополнительная информация?   -  person eylul    schedule 30.11.2015
comment
Видите ли вы что-нибудь интересное в журнале ошибок MySQL? Чтобы найти расположение журнала: stackoverflow.com/questions/33700660/   -  person Sasha Pachev    schedule 30.11.2015
comment
Нет, сегодняшний лог начинается, например, так: 151130 0:15:08 [ERROR] /usr/sbin/mysqld: Table './eximstats/smtp' is marked as crashed and last (automatic?) repair failed 151130 0:15:08 [ERROR] /usr/sbin/mysqld: Table './eximstats/smtp' is marked as crashed and last (automatic?) repair failed 151130 0:30:02 [ERROR] /usr/sbin/mysqld: Table './eximstats/failures' is marked as crashed and last (automatic?) repair failed 151130 0:30:02 [ERROR] /usr/sbin/mysqld: Table './eximstats/sends' is marked as crashed and last (automatic?) repair failed @sasha-pachev   -  person eylul    schedule 30.11.2015
comment
Кстати, журнал ошибок огромен, около 25 МБ ... Думаю, это слишком много для файла журнала.   -  person eylul    schedule 30.11.2015
comment
запустите это как root из командной строки: grep -i signal $(readlink /proc/$(pidof mysqld)/fd/2) . Находит что-нибудь?   -  person Sasha Pachev    schedule 30.11.2015
comment
Я запускаю команду, но она ничего не показывает, она не дает мне выходного сообщения.   -  person eylul    schedule 30.11.2015
comment
Также grep sacrifice /var/log/syslog /var/log/messages - есть подозрение, что mysqld убивается OOM killer при резервном копировании системы из-за нехватки памяти.   -  person Sasha Pachev    schedule 30.11.2015
comment
В каталоге журналов нет папок системного журнала и сообщений, поэтому команда выдает ошибку. Так ты думаешь это опять из-за нехватки свободного места на сервере? @SashaPachev   -  person eylul    schedule 30.11.2015

Ответы (3)


arrow_upward
0
arrow_downward

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

Найдите файл my.cnf. На моем CentOs он находится в /etc/my.cnf. Он будет иметь настройку конфигурации для местоположения журнала ошибок.

person Reenactor Rob    schedule 30.11.2015
comment
Файл my.cnf на самом деле довольно пуст... Я нашел и проверил журнал ошибок, но он просто начинает говорить, что база данных xxxxx повреждена, и автоматическое восстановление не удалось... Содержание файла cnf приведено ниже. [mysqld] innodb_file_per_table=1 max_allowed_packet=268435456 open_files_limit=10000 default-storage-engine=MyISAM - person eylul; 30.11.2015

arrow_upward
0
arrow_downward

Мой самый сильный подозреваемый - это OOM kill ядром или какая-то другая проблема, возникающая в результате запуска системы из-за нехватки памяти. Попробуй это:

  • Запустите top на сервере и нажмите M для сортировки по памяти, чтобы самый большой пользователь памяти был вверху.
  • обратите внимание на pid из mysqld
  • вручную выполните резервное копирование, наблюдая значение столбца RES в выводе top (размер резидентной памяти)
  • после завершения резервного копирования посмотрите, изменились ли pid из mysqld

Если pid изменился (имеется в виду перезагрузка), и вы увидели, что объем памяти mysqld занимает что-то сравнимое с общим объемом системной памяти, то мое подозрение верно, и нам нужно понизить некоторые настройки в my.cnf, чтобы он используйте меньше памяти, например key_buffer_size и innodb_buffer_pool_size.

РЕДАКТИРОВАТЬ. Из опубликованного вами журнала есть дополнительные проблемы, хотя неясно, как они могут способствовать повреждению таблицы. Похоже, что ваш сервер работает с --skip-innodb, и ваш сценарий резервного копирования не может справиться с отсутствием InnoDB механизма хранения, который печатает сообщения об ошибках исключения, но, тем не менее, продолжает работать. Он также пытается выполнить ремонт, который терпит неудачу из-за отсутствия системных привилегий (ошибка 1 — операция не разрешена). Вполне возможно, что обнаружение этих ошибок вызывает некоторую ошибочную логику в вашем сценарии резервного копирования, которая приводит к повреждению таблиц.

На этом этапе я бы рекомендовал отключить резервное копирование MySQL с помощью инструмента cPanel и использовать mysqldump или какое-либо другое решение (например, Xtrabackup (https://www.percona.com/doc/percona-xtrabackup/2.3/index.html)) из задания cron.

EDIT2 - по результатам теста. Резервное копирование вручную не приводит к нехватке памяти и не приводит к сбою сервера. Жюри все еще отсутствует на автоматическом.

person Sasha Pachev    schedule 30.11.2015
comment
Хорошо, позвольте мне попробовать это сейчас. Я обновлю здесь, как только это будет сделано. Большое спасибо заранее. - person eylul; 30.11.2015
comment
Между прочим... Это вчерашний резервный журнал. Видите ли вы что-нибудь, что может вызвать проблему? Я подумал, может быть, это может помочь. textuploader.com/5xafm - person eylul; 30.11.2015
comment
Итак, судя по логам, резервное копирование завершено... Интересно, базы в этот раз не испортились? Кроме того, mysql pid остается прежним, это нормально? Обычно он использует около 56 МБ RES, во время резервного копирования он увеличился (около 88 МБ), но ничего не повреждается. Интересно, произойдет ли это с автоматическим резервным копированием сегодня вечером. Между прочим, я запустил резервную копию со следующим кодом: /scripts/cpbackup --force С нетерпением жду ваших комментариев по этому поводу и еще раз большое спасибо за ваше время и усилия. @sashapachev - person eylul; 01.12.2015
comment
Большое спасибо за вашу помощь. Интересно, что автоматическое резервное копирование вчера запустилось без проблем. Я проверю, работает ли это сегодня вечером и обновлю здесь. Как вы думаете, я должен также исправить эту проблему с пропуском innodb? - person eylul; 02.12.2015
comment
Это зависит от того, почему вы поставили skip-innodb в конфиг для начала. Если для mysqld очень важно быть легким и не создавать случайно таблицы InnoDB, используйте другое решение для резервного копирования. Если нет, просто удалите skip-innodb из my.cnf и перезапустите MySQL. - person Sasha Pachev; 02.12.2015

arrow_upward
0
arrow_downward

  • Не убивайте mysqld; выключите его изящно.

  • Переключиться с MyISAM на InnoDB; последний не страдает от этой «ошибки».

person Rick James    schedule 01.12.2015