Мариадб грузится, но вылетает через пару минут. Произошло после восстановления сервера из «снимка» - PullRequest
Новая
       26

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

1 голос
/ 09 марта 2019

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

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

Запуск 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

и CHECK TABLE 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-database , который вернулся с «OK»

  • Попробовал исправление, указанное здесь https://stackoverflow.com/a/3322930/8644833 после запуска Mariadb с mysqld_safe --skip-grant-tables

Я не очень хорошо разбираюсь в mysql, поэтому я просто ищу решение, которое поможет мне снова заработать и не потерять слишком много данных. Я бы не отказался выполнить чистую установку Mariadb и настроить новую базу данных Wordpress, но я не совсем уверен, как сделать резервную копию всех моих данных, чтобы мне не пришлось перестраивать все мои сайты. Похоже, это должно быть возможно, так как все сайты работают нормально, пока не вылетит 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 status 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 log: 

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

Ответы [ 2 ]

0 голосов
/ 11 марта 2019

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

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

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

0 голосов
/ 09 марта 2019

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

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

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

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

Затем я переустановил Mariadb 

# apt-get install mariadb-server

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

Вышеперечисленные шаги не сработали

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

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

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

...