После переполнения диска на хостинге полетел MySql – повреждена база данных, как восстановить?

Question

[Maксим Волков]

После некоторых изменений на сайте, стал расти кэш, перестали удалятся созданные при автоматическом резервном копировании файлы backup копий сайта. В результате, в связи с нехваткой места, лёг VPS сервер.

Очистил кеш, удалил устаревшие резервные копии. В настоящее время на сервер занято около 60% дискового пространства, однако сайт перестал работать должным образом, периодически отваливается MySql.
При обращении к сайту, сайт иногда открывается, но чаще показывает ошибку:

[Bitrix\Main\DB\ConnectionException] 
Mysql connect error [localhost]: (2002) Connection refused (400)
/home/bitrix/ext_www/my-site.ru/bitrix/modules/main/lib/db/mysqliconnection.php:82
#0: Bitrix\Main\DB\MysqliConnection->connectInternal()
	/home/bitrix/ext_www/my-site.ru/bitrix/modules/main/lib/data/connection.php:53
#1: Bitrix\Main\Data\Connection->getResource()
----------

Админ - панель битрикса открывается, однако воспользоваться инструментами: оптимизировать исправить таблицы базы, сделать резервную копию не получается – получаю MySQL Query Error!
Согласно логам /var/log/mysql/error.log – проблема в таблице: b_stat_session_data,

2022-08-16T03:33:08.491425Z 2 [ERROR] InnoDB: Corruption of an index tree: table `dbpechi-tula`.`b_stat_session_data` index `PRIMARY`, father ptr page no 409142, child page no 409143
PHYSICAL RECORD: n_fields 8; compact format;

Фрагмент Log - файла

2022-08-16T03:33:07.971669Z 0 [Note] InnoDB: Apply batch completed
2022-08-16T03:33:08.241907Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2022-08-16T03:33:08.241956Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-08-16T03:33:08.242010Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-08-16T03:33:08.248809Z 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-08-16T03:33:08.249891Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
2022-08-16T03:33:08.249907Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
2022-08-16T03:33:08.250307Z 0 [Note] InnoDB: Waiting for purge to start
2022-08-16T03:33:08.300668Z 0 [Note] InnoDB: Percona XtraDB (www.percona.com) 5.7.38-41 started; log sequence number 113670717229
2022-08-16T03:33:08.301090Z 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2022-08-16T03:33:08.301229Z 0 [Note] Plugin 'FEDERATED' is disabled.
2022-08-16T03:33:08.314768Z 0 [Note] InnoDB: Buffer pool(s) load completed at 220816 3:33:08
2022-08-16T03:33:08.316059Z 0 [Note] Found ca.pem, server-cert.pem and server-key.pem in data directory. Trying to enable SSL support using them.
2022-08-16T03:33:08.316100Z 0 [Note] Skipping generation of SSL certificates as certificate files are present in data directory.
2022-08-16T03:33:08.316108Z 0 [Warning] A deprecated TLS version TLSv1 is enabled. Please use TLSv1.2 or higher.
2022-08-16T03:33:08.316112Z 0 [Warning] A deprecated TLS version TLSv1.1 is enabled. Please use TLSv1.2 or higher.
2022-08-16T03:33:08.320614Z 0 [Warning] CA certificate ca.pem is self signed.
2022-08-16T03:33:08.323466Z 0 [Note] Skipping generation of RSA key pair as key files are present in data directory.
2022-08-16T03:33:08.323930Z 0 [Note] Server hostname (bind-address): '*'; port: 3306
2022-08-16T03:33:08.323989Z 0 [Note] IPv6 is available.
2022-08-16T03:33:08.324007Z 0 [Note] - '::' resolves to '::';
2022-08-16T03:33:08.324035Z 0 [Note] Server socket created on IP: '::'.
2022-08-16T03:33:08.384098Z 0 [Note] Event Scheduler: Loaded 0 events
2022-08-16T03:33:08.384347Z 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.7.38-41' socket: '/var/lib/mysqld/mysqld.sock' port: 3306 Percona Server (GPL), Release 41, Revision da46e5474f9
2022-08-16T03:33:08.491425Z 2 [ERROR] InnoDB: Corruption of an index tree: table `dbpechi-tula`.`b_stat_session_data` index `PRIMARY`, father ptr page no 409142, child page no 409143
PHYSICAL RECORD: n_fields 8; compact format; info bits 0
0: len 4; hex 8057bcb5; asc W ;;
1: len 6; hex 0000101ab29e; asc ;;
2: len 7; hex 67000002cc02cc; asc g ;;
3: len 5; hex 99ad76f1cf; asc v ;;
4: len 5; hex 99ad76f1e4; asc v ;;
5: len 30; hex 343636323632623335316264363038623866613834623661346337383662; asc 466262b351bd608b8fa84b6a4c786b; (total 32 bytes);
6: len 4; hex 805511b3; asc U ;;
7: len 30; hex 613a33333a7b733a383a227265666572657231223b4e3b733a383a227265; asc a:33:{s:8:"referer1";N;s:8:"re; (total 1402 bytes);
2022-08-16T03:33:08.491764Z 2 [Note] InnoDB: n_owned: 0; heap_no: 12; next rec: 129
PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 4; hex 8057bcaa; asc W ;;
1: len 4; hex 00063e36; asc >6;;
2022-08-16T03:33:08.491803Z 2 [Note] InnoDB: n_owned: 0; heap_no: 480; next rec: 112
2022-08-16T03:33:08.491808Z 2 [ERROR] [FATAL] InnoDB: You should dump + drop + reimport the table to fix the corruption. If the crash happens at database startup. Please refer to dev.mysql.com/doc/refman/5.7/en/forcing-innodb-rec... for information about forcing recovery. Then dump + drop + reimport.
2022-08-16 03:33:08 0x7f37ecc45700 InnoDB: Assertion failure in thread 139878172219136 in file ut0ut.cc line 924
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to 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: dev.mysql.com/doc/refman/5.7/en/forcing-innodb-rec...
InnoDB: about forcing recovery.
03:33:08 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.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
Please help us make Percona Server better by reporting any
bugs at https://bugs.percona.com/

key_buffer_size=25165824
read_buffer_size=131072
max_used_connections=1
max_threads=36
thread_count=1
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 172928 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

MySql – после перезапуска MySql – сервер активен,


Однако при попытке посмотреть содержание проблемной таблицы получаю ошибку: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysqld/mysqld.cock' (111):


Файл - /var/lib/mysqld/mysqld.cock присутствует, имеет доступ (0777) для пользователей БД.

Как восстановить сломанную базу данных?
Какие есть способы в решении указанной проблемы?

К сожалению, удалил последние сохранённые резервные копии, и крайне необходимо восстановить текущую базу данных, с последними изменениями.

Comments

[Melkij]

Прежде чем что-то делать - остановите базу, скопируйте целиком весь data dir в безопасное место.

[ERROR] [FATAL] InnoDB: You should dump + drop + reimport the table to fix the corruption.

А так, база вполне прямым языком советует как поступить

[Maксим Волков]

Melkij, Благодарю за совет. Пробовал, к сожалению не получилось.
Создал Дамп базы, и попытался развернуть на локальном хостинге копию сайта. Однако после экспорта данных - получаю битую базу данных - MySQL Query Error!

Да и сам, полученный дамп подозрительно большого размера, что не удивительно, проблемная таблица b_stat_session_data занимает почти 5 гигов.

[Melkij]

Сделайте каноничным mysqldump и смотрите реальную ошибку. Невнятное MySQL Query Error - это разговор ни о чём.
а 5гб табличка - это не много.

[Дмитрий]

Мне кажется если это каким то боком относится к сессиям, то можно просто создать пустую таблицу аналогичной структуры

[Maксим Волков]

Melkij, Sorry... Каноничный mysqldump - это что? Можно чуть подробнее? Гугл сразу не дает ответа что это такое.

[Дмитрий]

https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html

[Maксим Волков]

Дмитрий, Благодарю!
Так и есть! Сработало.
Действительно - в таблице b_stat_session_data - содержатся данные статистики о предыдущих посещениях сайта, в моем случае, не самая важная информация для работы интернет-магазина.
Создал дамп базы с исключением битой таблицы b_stat_session_data ,
Развернул свежую версию БУС и отдельно сделал дамп чистой таблицы базы данных b_stat_session_data
На локальном сервере создал базу и импортировал полученные данные из двух фалов дампов.

Все работает! Еще раз благодарю за идею!

Answer 1

[Maксим Волков]

Проблема решена путем восстановления MySql баз данных из файлов с перезапуском mysql c опцией innodb_force_recovery.
Если коротко, то процесс восстановления InnoDB базы данных происходит так :

1. Останавливаем mysql сервер.
2. В файл /root/my.cnf вносим параметр innodb_force_recovery = 1
3. Запускаем mysql сервер
4. В случае успешного запуска сервера, создаем дамп баз данных;
5. Удаляем из файла /root/my.cnf вносим параметр innodb_force_recovery
6. Удаляем поврежденную базу данных
7. Перезапускаем mysql сервер.
8. Восстанавливаем базу данных из полученного дампа

Боле детально, с подробными пояснениями и примерами можно посмотреть тут: восстановление MySql базы данных.

Answer 2

[Alexey_Neonov]

Попробуйте это:

Необходимо остановить MySQL сервер (если таблица ничем не используется, то можно не останавливать):
sudo service mysql stop

Перейдем в директорию с базой:
cd /var/lib/mysql/"директория базы"

Выполним команду восстановления указанной таблицы:
myisamchk -r -o -f -v phistory

По завершению, если останавливали MySQL сервер, то запустим его:
sudo service mysql start