Не запускается mysql (сайт на 1С-Битрикс Управление сайтом). Похоже, повреждена база. Как можно её восстановить?

Question

[Walker2000]

Не запускается сайт, не стартует mysql. Сообщение о том, что БД не запустилась выводится на любой странице кроме основной (она грузится).

[Bitrix\Main\DB\ConnectionException]
Mysql connect error [127.0.0.1]: (2002) Connection refused (400)
/home/bitrix/www/bitrix/modules/main/lib/db/mysqliconnection.php:82
#0: Bitrix\Main\DB\MysqliConnection->connectInternal()
/home/bitrix/www/bitrix/modules/main/lib/data/connection.php:53
#1: Bitrix\Main\Data\Connection->getResource()
/home/bitrix/www/bitrix/modules/main/lib/db/mysqlisqlhelper.php:21
#2: Bitrix\Main\DB\MysqliSqlHelper->forSql(string)
/home/bitrix/www/bitrix/modules/main/lib/config/option.php:193
#3: Bitrix\Main\Config\Option::load(string)
/home/bitrix/www/bitrix/modules/main/lib/config/option.php:38
#4: Bitrix\Main\Config\Option::get(string, string, string)
/home/bitrix/www/bitrix/modules/main/lib/httprequest.php:394
#5: Bitrix\Main\HttpRequest->prepareCookie(array)
/home/bitrix/www/bitrix/modules/main/lib/httprequest.php:71
#6: Bitrix\Main\HttpRequest->__construct(object, array, array, array, array)
/home/bitrix/www/bitrix/modules/main/lib/httpapplication.php:49
#7: Bitrix\Main\HttpApplication->initializeContext(array)
/home/bitrix/www/bitrix/modules/main/lib/application.php:130
#8: Bitrix\Main\Application->initializeExtendedKernel(array)
/home/bitrix/www/bitrix/modules/main/include.php:21
#9: require_once(string)
/home/bitrix/www/bitrix/modules/main/include/prolog_before.php:14
#10: require_once(string)
/home/bitrix/www/bitrix/modules/main/include/prolog.php:10
#11: require_once(string)
/home/bitrix/www/bitrix/header.php:1
#12: require(string)
/home/bitrix/www/catalog/index.php:2
#13: include_once(string)
/home/bitrix/www/bitrix/modules/main/include/urlrewrite.php:160
#14: include_once(string)
/home/bitrix/www/bitrix/urlrewrite.php:2

В файле /var/log/mysql/error.log следующие сообщения:

2021-12-28T04:42:48.871067Z 0 [Warning] Changed limits: max_open_files: 5000 (requested 16238)
2021-12-28T04:42:48.871323Z 0 [Warning] Changed limits: table_open_cache: 2477 (requested 8096)
2021-12-28T04:42:49.064840Z 0 [Warning] 'NO_AUTO_CREATE_USER' sql mode was not set.
2021-12-28T04:42:49.066759Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.33-36) starting as process 1615 ...
2021-12-28T04:42:49.072036Z 0 [Note] InnoDB: PUNCH HOLE support available
2021-12-28T04:42:49.072080Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2021-12-28T04:42:49.072089Z 0 [Note] InnoDB: Uses event mutexes
2021-12-28T04:42:49.072096Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2021-12-28T04:42:49.072104Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.7
2021-12-28T04:42:49.072111Z 0 [Note] InnoDB: Using Linux native AIO
2021-12-28T04:42:49.072380Z 0 [Note] InnoDB: Number of pools: 1
2021-12-28T04:42:49.072522Z 0 [Note] InnoDB: Using CPU crc32 instructions
2021-12-28T04:42:49.074495Z 0 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
2021-12-28T04:42:49.085615Z 0 [Note] InnoDB: Completed initialization of buffer pool
2021-12-28T04:42:49.089702Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2021-12-28T04:42:49.101559Z 0 [Note] InnoDB: Recovering partial pages from the parallel doublewrite buffer at /var/lib/mysql/xb_doublewrite
2021-12-28T04:42:49.105272Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2021-12-28T04:42:49.108314Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 4280861412938
2021-12-28T04:42:49.129319Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 4280862209170
2021-12-28T04:42:49.129579Z 0 [Note] InnoDB: Database was not shutdown normally!
2021-12-28T04:42:49.129592Z 0 [Note] InnoDB: Starting crash recovery.
2021-12-28T04:42:49.142699Z 0 [Note] InnoDB: Created parallel doublewrite buffer at /var/lib/mysql/xb_doublewrite, size 3932160 bytes
2021-12-28T04:42:49.147707Z 0 [ERROR] InnoDB: Trying to access page number 4294967295 in space 0, space name innodb_system, which is outside the tablespace bounds. Byte offset 0, len 16384, i/o type read. If you get this error at mysqld startup, please check that your my.cnf matches the ibdata files that you have in the MySQL server.
2021-12-28T04:42:49.147735Z 0 [ERROR] InnoDB: Server exits.

В чем может быть проблема? HELP!!!

Comments

[Дмитрий]

Работал и перестал? Или это перенесли сайт?

[Walker2000]

Сначала закончилось место на VPS (причина тоже непонятна) потом вывалился сайт в Mysql connect error [127.0.0.1]: (2002) Connection refused (400). Место освободили, не помогло. Восстановили из бэкапа образ сайта, тоже не помогло.

[Alexey Dmitriev]

Там Innodb - ищите специалиста, раз сами не понимаете. Объяснять сложно, нужно играться с удалением логов транзакций, с копиями и оригиналом - может с чем то запустится

[Alexey Dmitriev]

Walker2000, причина как раз понятна. Отсутствие системного администратора, поддерживающего VPS?

[Walker2000]

Причина понятна. Но нужно решение.

[Ярослав Александров]

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

[Walker2000]

Автоматические бэкапы сайта целиком делались. Но дамп базы данных при этом отдельно не сохранялся. Провайдер Рег.ру.

Answer 1

[Walker2000]

Вот ответ от хостера, который в итоге сработал.

MySQL не запускается из-за того, что после восстановления бэкапа были побиты таблицы.

Добавили следующую строку:
innodb_force-recovery=6
После чего запустили службу MySQL.

Сделали дамп базы сайта:
[root@5-63-157-200 ~]# mysqldump --events --routines --triggers sitemanager > sitemanager.sql
[root@5-63-157-200 ~]# ls -lha /root/sitemanager.sql
-rw-r--r-- 1 root root 298M Dec 28 04:38 /root/sitemanager.sql

Но для корректной работы необходимо сделать реинициализацию innodb, после чего восстановление базы из дампа. Мы можем вам помочь, произвести реинициализию на основе платного почасового администрирования. Либо вы можете сделать это самостоятельно.

Если у вас имеется дамп базы данных, снятый до того, как вы произвели восстановление, то лучше после реинициализации innodb восстановить базу из того дампа.

Если же нет, то можно произвести восстановление из дампа /root/sitemanager.sql.

Answer 2

[pcdesign]

У меня было такое. И я на всякий случай сохранил себе такой алгоритм действий:

1) Добавляем в my.cnf следующие строки

port = 8881

innodb_force_recovery=3

innodb_purge_threads=0

2) Запускаем

systemctl start mysql

3) В дожидаемся, что все восстановлено:

171229 14:10:41 InnoDB: Page checksum 2138135319 (32bit_calc: 1915668989), prior-to-4.0.14-form checksum 3309214847
InnoDB: stored checksum 2658474647, prior-to-4.0.14-form stored checksum 3309214847
InnoDB: Page lsn 0 2312264, low 4 bytes of lsn at page end 2312264
InnoDB: Page number (if stored to page already) 0,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a file space header page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 0.
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 dev.mysql.com/doc/refman/5.5/en/forcing-innodb-rec...
InnoDB: about forcing recovery.
171229 14:10:41 InnoDB: Waiting for the background threads to start
171229 14:10:42 Percona XtraDB (www.percona.com) 5.5.52-MariaDB-38.3 started; log sequence number 2313740
171229 14:10:42 InnoDB: !!! innodb_force_recovery is set to 3 !!!
171229 14:10:42 [Note] Plugin 'FEEDBACK' is disabled.
171229 14:10:42 [Note] Server socket created on IP: '0.0.0.0'.
171229 14:10:43 [Note] Event Scheduler: Loaded 0 events
171229 14:10:43 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.56-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 8881 MariaDB Server

4) Делаем дамп Всех баз данных.

5) Удаляем базы drop database ...

6) Останавливаем
systemctl stop mysql

7) Удаляем в /var/lib/mysql/
aria_log.00000001 aria_log_control ibdata1 ib_logfile0 ib_logfile1

8) Удаляем строки из my.cnf, которые были добавлены.

9) Перезагружаемся, создаем новую (старую) базу данных и ресторимся из дампа

P.S. Но вообще - это тревожный звоночек. Может что-то не так с диском или памятью.
Имеет смысл вообще перебросить базу на другую машину.

Comments

[Walker2000]

Сайт лежит на VPS REG.RU. Думаете с железом проблема?

[pcdesign]

Walker2000, У меня тоже это случалось всегда на виртуалках.
Виртуалки ведь крутятся на обычных железках.

[Walker2000]

Большое спасибо за предложение. Если не найду специалиста (сам опасаюсь ковырять), воспользуюсь вашим алгоритмом.

[pcdesign]

Walker2000, да, не за что. Вы можете остановится на пункте 4. Когда вы сделаете дампы, то эти дампы вы можете попробовать развернуть где угодно. Хоть на локальном компе. И убедится, что все работает.
Страшно начинается с пункта 5.

Answer 3

[Rsa97]

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

Comments

[Walker2000]

База отдельно не сохранялась. Сохранялся сайт целиком. База там лежит в /var/lib/mysql/.

[Rsa97]

Walker2000, Базу можно сохранять копированием файлов только при остановленном сервере MySQL. Иначе не гарантируется внутренняя целостность, что вы и видите.
Для штатного сохранения есть mysqldump.

[Walker2000]

Увы.

[Walker2000]

Rsa97, недосмотр нашего бывшего администратора, похоже. Он порекомендовал делать бэкапы средствами хостера. Но про важность делать параллельно дамп базы данных не упомянул.