Мариадб загружается, но через пару минут вылетает. Произошло после восстановления сервера из снимка

У меня есть VPS (Ubuntu Server 18.04), размещенный на OVH. Они предлагают снимки состояния, которые должны иметь возможность откатить VPS к предыдущему состоянию. Я никогда раньше не пользовался этой функцией. Но вчера вечером я сделал снимок, прежде чем начал возиться с BTCpay. Я по-королевски провалил эту установку, поэтому я решил вернуться к моментальному снимку.

Теперь моя установка Mariadb работает некорректно. Единственное, что размещено на сервере, - это мультисайт Wordpress. Если я перезагружаю сервер (или запускаю Mariadb с помощью systemctl), он загружается, и я могу получить доступ ко всем своим сайтам WordPress и панели администратора. Но через пару минут Мариадб вылетает.

Запуск mysqld_safe --skip-grant-tables выводит:

190308 15:10:20 mysqld_safe Logging to syslog.
190308 15:10:20 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

Это запускает Wordpress, но, очевидно, не является безопасным решением.

Это единственные ошибки, которые появляются в /var/log/mysql/error.log, но есть только одна запись, и они не повторяются каждый раз при сбое Mariadb:

2019-03-08 13:08:24 139897840925824 [ERROR] mysqld: Table './mysql/db' is marked as crashed and should be repaired
2019-03-08 13:08:24 139897840925824 [ERROR] mysql.db: 1 client is using or hasn't closed the table properly

и ПРОВЕРИТЬ ТАБЛИЦУ mysql.db; выводит:

+----------+-------+----------+----------+
| Table    | Op    | Msg_type | Msg_text |
+----------+-------+----------+----------+
| mysql.db | check | status   | OK       |
+----------+-------+----------+----------+
1 row in set (0.00 sec)

На данный момент я предпринял следующие шаги:

  • Чтобы использовать mysqldump для базы данных wordpress, которую я установил для своей многосайтовой установки Wordpress.

  • Запустите # mysqlcheck --all-databases, который вернул все с 'OK'

  • Пробовал исправление, указанное здесь https://stackoverflow.com/questions/226172/how-do-i-repair-an-innodb-table после запуска Mariadb с помощью mysqld_safe --skip-grant-tables

Я не очень хорошо разбираюсь в mysql, поэтому я просто ищу решение, которое поможет мне снова заработать, не теряя слишком много данных. Я бы не возражал выполнить чистую установку Mariadb и настроить новую базу данных Wordpress, но я не совсем уверен, как сделать резервную копию всех моих данных, чтобы мне не пришлось перестраивать все мои сайты. < / strong> Похоже, это должно быть возможно, поскольку все сайты работают нормально, пока Mariadb не выйдет из строя.

Вот вся другая соответствующая информация, которая у меня есть:

dmesg:

[  108.430534] audit: type=1400 audit(1552073977.631:19): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  108.534100] audit: type=1400 audit(1552073977.739:20): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  108.634399] audit: type=1400 audit(1552073977.839:21): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  108.734779] audit: type=1400 audit(1552073977.939:22): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  108.835027] audit: type=1400 audit(1552073978.039:23): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w"denied_mask="w" fsuid=111 ouid=0
[  108.935311] audit: type=1400 audit(1552073978.139:24): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  109.035562] audit: type=1400 audit(1552073978.235:25): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  109.136162] audit: type=1400 audit(1552073978.339:26): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  110.038191] audit: type=1400 audit(1552073979.243:27): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  110.040919] audit: type=1400 audit(1552073979.243:28): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0

статус systemctl mariadb.service:

    ● mariadb.service - MariaDB 10.1.38 database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
   Active: failed (Result: timeout) since Fri 2019-03-08 14:39:39 EST; 14min ago
     Docs: man:mysqld(8)
           https://mariadb.com/kb/en/library/systemd/
  Process: 939 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 839 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
  Process: 809 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 770 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
 Main PID: 939 (code=exited, status=0/SUCCESS)

Mar 08 14:38:08 mydomain.com systemd[1]: Starting MariaDB 10.1.38 database server...
Mar 08 14:38:09 mydomain.com mysqld[939]: 2019-03-08 14:38:09 140251492867200 [Note] /usr/sbin/mysqld (mysqld 10.1.38-MariaDB-0ubuntu0.18.04.1) starting as process 939 ...
Mar 08 14:39:37 mydomain.com systemd[1]: mariadb.service: Start operation timed out. Terminating.
Mar 08 14:39:39 mydomain.com systemd[1]: mariadb.service: Failed with result 'timeout'.
Mar 08 14:39:39 mydomain.com systemd[1]: Failed to start MariaDB 10.1.38 database server.

журнал mysql:

2019-03-08 14:59:39 140597857991808 [Note] InnoDB: innodb_empty_free_list_algor
ithm has been changed to legacy because of small buffer pool size. In order to 
use backoff, increase buffer pool at least up to 20MB.

2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Using mutexes to ref count b
uffer pool pages
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: The InnoDB memory heap is disabled
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Compressed tables use zlib 1.2.11
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Using Linux native AIO
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Using SSE crc32 instructions
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Completed initialization of buffer pool
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Highest supported file format is Barracuda.
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: 128 rollback segment(s) are active.
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Waiting for purge to start
2019-03-08 14:59:39 140597857991808 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.42-84.2 started; log sequence number 446057526
2019-03-08 14:59:39 140597857991808 [Note] Plugin 'FEEDBACK' is disabled.
2019-03-08 14:59:39 140597201463040 [Note] InnoDB: Dumping buffer pool(s) not yet started
2019-03-08 14:59:39 140597857991808 [Note] Server socket created on IP: '127.0.0.1'.
2019-03-08 14:59:39 140597857991808 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.1.38-MariaDB-0ubuntu0.18.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Ubuntu 18.04
2019-03-08 15:01:09 140597856737024 [Note] /usr/sbin/mysqld: Normal shutdown
2019-03-08 15:01:09 140597856737024 [Note] Event Scheduler: Purging the queue. 0 events
2019-03-08 15:01:09 140597251774208 [Note] InnoDB: FTS optimize thread exiting.
2019-03-08 15:01:09 140597856737024 [Note] InnoDB: Starting shutdown...
2019-03-08 15:01:09 140597856737024 [Note] InnoDB: Waiting for page_cleaner to finish flushing of buffer pool
2019-03-08 15:01:11 140597856737024 [Note] InnoDB: Shutdown completed; log sequence number 446281568
2019-03-08 15:01:11 140597856737024 [Note] /usr/sbin/mysqld: Shutdown complete

mysql ubuntu wordpress vps mariadb
person Phillip Brantley    schedule 08.03.2019    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Если бы мог, я бы прокомментировал, но решил, что это слишком важно, чтобы просто пропустить.

Моментальные снимки сервера и резервные копии базы данных - это разные вещи. Проблема в том, что моментальный снимок может захватить сервер базы данных в середине чего-то; если вы позже перезапустите систему на основе снимка, сервер базы данных может быть сбит с толку. Скорее всего, потребовалось несколько минут, чтобы осознать скрытую несогласованность и сбой. Предположительно, переустановка косвенно запустила более агрессивную, чем обычно, очистку, которая устранила несоответствие. Чтобы узнать подробности и подтвердить мои предположения, вы можете попробовать https://dba.stackexchange.com/.

В будущем, возможно, будет лучше делать регулярные резервные копии базы данных в дополнение к снимкам состояния системы. Также может сработать перевод WordPress в режим только для чтения (что непросто, но есть плагин) во время создания снимка. (Хотя было бы разумно спросить, сработает ли это.)

person Loren Rosen    schedule 11.03.2019

arrow_upward
0
arrow_downward

Я до сих пор не знаю, в чем была основная причина этой проблемы, но удаление и повторная установка Mariadb устранили проблему.

В частности, я сделал:

# apt-get remove --purge mariadb-server
# apt-get autoremove --purge
# apt-get autoclean

При появлении запроса я решил сохранить существующие базы данных.

Потом переустановил Мариадб

# apt-get install mariadb-server

И после этого все заработало и мне не нужно было восстанавливать никакие базы.

Вышеуказанные шаги не сработали

После выполнения вышеизложенного все будет работать нормально, пока система не будет перезагружена или пока не будет перезапущен mariadb-server. Тогда снова возникнет исходная проблема, и сервер mariadb выйдет из строя после нормальной работы в течение минуты или около того.

Я до сих пор не знаю, в чем проблема. Я знаю, что восстановление из снимка - это то, что вызвало проблему, но я не знаю, почему и каким образом Mariadb ломался. Я даже попытался удалить mariadb-server и все базы данных, но когда он был переустановлен, у меня возникла та же проблема.

Я устал искать проблему, поэтому я сбросил базу данных wordpress, удалил mariadb-server и все базы данных и установил mysql-server. Это устранило проблему.

person Phillip Brantley    schedule 09.03.2019