LINUX.ORG.RU

Как узнать точную причину падения контейнера с MariaDB?

 , , , ,


0

2

Есть контейнер с базой, есть бэкапы, сделанные, xtrabackup. Бэкапы тестовых баз спокойно восстанавливаются. Бэкап продакшена не хочет. После остановки контейнера он больше не запускается. Есть еще такое дело: в бэкапах тестовых баз нет файлов вида *.cfg, а в проде есть. Может быть из-за этого и что в этих файлах может быть важного? Свмый главный вопрос - как посмотреть с какой ошибкой падает?

конфиг:

host=127.0.0.1
user=root
port=3308
password=PaSsWoRd
database_dir=/path/to/db
encryption_key=/path/to/key
dbsake_path=/path/to/dbsake
restart_mysql=docker restart 10.1.23-mariadb

скрипт восстановления: https://pastebin.com/cyFRehZs

может я что не учел?

★★★★★

Последнее исправление: Qwentor (всего исправлений: 4)

может я что не учел?

Да, ты не учёл, что НИКОГДА НЕ ИСПОЛЬЗУЙТЕ DOCKER ДЛЯ СУБД.

anonymous
()

Тебе нужно пальцем указать на команду вывода логов контейнера, как запустить контейнер в интерактивном режиме и самому посмотреть детальнее или что?

Deleted
()
Ответ на: комментарий от Deleted

docker logs 10.1.23-mariadb
выдает кучу такого:

2018-03-03 17:45:20 140421864060864 [ERROR] InnoDB: Trying to do i/o to a tablespace which exists without .ibd data file. i/o type 10, space id 38, page no 0, i/o length 16384 bytes
2018-03-03 17:45:20 140421864060864 [ERROR] InnoDB: Trying to access tablespace [space=38: page=0] but the tablespace does not exist or is just being dropped.
2018-03-03 17:45:20 140421864060864 [ERROR] InnoDB: tablespace id is 38 in the data dictionary but in file ./database/order.ibd it is 2193!


А потом сыпется такое:
Server version: 10.1.23-MariaDB-1~jessie
key_buffer_size=134217728
read_buffer_size=2097152
max_used_connections=0
max_threads=102
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 759834 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x48400
mysqld(my_print_stacktrace+0x2e)[0x7fb682e9285e]
mysqld(handle_fatal_signal+0x2fd)[0x7fb6829cbc7d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf890)[0x7fb681ff3890]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fb6800e3067]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fb6800e4448]
mysqld(+0x70f527)[0x7fb682b33527]
mysqld(+0x85e8f3)[0x7fb682c828f3]
mysqld(+0x8baeaf)[0x7fb682cdeeaf]
mysqld(+0x8c3934)[0x7fb682ce7934]
mysqld(+0x8a4ace)[0x7fb682cc8ace]
mysqld(+0x7f4598)[0x7fb682c18598]
mysqld(+0x713aee)[0x7fb682b37aee]
mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x64)[0x7fb6829cdfb4]
mysqld(+0x42f71a)[0x7fb68285371a]
mysqld(_Z11plugin_initPiPPci+0x8aa)[0x7fb682854e6a]
mysqld(+0x38b68e)[0x7fb6827af68e]
mysqld(_Z11mysqld_mainiPPc+0x1ad1)[0x7fb6827b2fc1]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fb6800cfb45]
mysqld(+0x38315d)[0x7fb6827a715d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Fatal signal 11 while backtracing

Qwentor ★★★★★
() автор топика
Ответ на: комментарий от firstep

ну, прод не в контейнере. В контейнере тестовая. Т.к. предположил, что тестить надо на той же версии БД, а на этих серверах они разные установлены, т.е. это _вторая_ mysql на данном сервере

Qwentor ★★★★★
() автор топика
Ответ на: комментарий от anonymous

НИКОГДА НЕ ИСПОЛЬЗУЙТЕ DOCKER ДЛЯ СУБД.

НИКОГДА НЕ ХРАНИТЕ ДАННЫЕ В DOCKER. СУБД в докер можно и местами нужно.

dib2 ★★★★★
()
Ответ на: комментарий от dib2

Это не прод. Прод без докера. Данные даже здесь в volume

Qwentor ★★★★★
() автор топика

Все, разобрался. Причиной оказалась таблица order, название которой совпадает с оператором MySQL и то что я не брал в косые кавычки названия таблиц в скрипте восстановления.

Qwentor ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.