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

Question

[Вячеслав Грачунов]

Есть контейнер с базой, есть бэкапы, сделанные, 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

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

Comments

[Антон Швец]

если че, обычно контейнеры все в логи пишут, которые можно посмотреть по docker logs

[Вячеслав Грачунов]

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!

Потом

2018-03-03 18:32:45 140313627678656 [ERROR] InnoDB: Unable to read tablespace 12 page no 0 into the buffer pool after 100 attempts The most probable cause of this error may be that the table has been corrupted. You can try to fix this problem by using innodb_force_recovery. Please see http://dev.mysql.com/doc/refman/5.6/en/ for more details. Aborting...

И в конце:

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)[0x7f9d4f85085e]
mysqld(handle_fatal_signal+0x2fd)[0x7f9d4f389c7d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf890)[0x7f9d4e9b1890]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f9d4caa1067]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f9d4caa2448]
mysqld(+0x70f527)[0x7f9d4f4f1527]
mysqld(+0x85e8f3)[0x7f9d4f6408f3]
mysqld(+0x8baeaf)[0x7f9d4f69ceaf]
mysqld(+0x8c3934)[0x7f9d4f6a5934]
mysqld(+0x8a4ace)[0x7f9d4f686ace]
mysqld(+0x7f4598)[0x7f9d4f5d6598]
mysqld(+0x713aee)[0x7f9d4f4f5aee]
mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x64)[0x7f9d4f38bfb4]
mysqld(+0x42f71a)[0x7f9d4f21171a]
mysqld(_Z11plugin_initPiPPci+0x8aa)[0x7f9d4f212e6a]
mysqld(+0x38b68e)[0x7f9d4f16d68e]
mysqld(_Z11mysqld_mainiPPc+0x1ad1)[0x7f9d4f170fc1]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f9d4ca8db45]
mysqld(+0x38315d)[0x7f9d4f16515d]
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

Answer 1

[Вячеслав Грачунов]

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