LINUX.ORG.RU

Крашатся таблицы в базе данных

 , ,


0

1

Есть база данных Mariadb 10.5.8, в ней несколько однотипных таблиц MyISAM такого вида:

    id    Primary	int(10)		    UNSIGNED AUTO_INCREMENT
    txt   Index     varchar(255)	utf8_general_ci
    tr	            varchar(255)	utf8_general_ci

В эти таблицы достаточно активно идёт запись и чтение данных. И вот сегодня утром уже не в первый раз столкнулся с тем, что несколько таблиц выдают, что они crashed и нуждаются в repaired.

    Table 'trans_it' is marked as crashed and should be repaired

Кликаю в phpmyadmin для этой таблицы «Repair table» на что мне выдаёт:

    manager.trans_it	repair	info	Wrong bytesec:   0-  0-  0 at 4837060; Skipped
    manager.trans_it	repair	status	OK

И таблица вроде начинает работать, но затем ситуация может повториться снова. Ещё заметил, что после восстановления MAX(id) и COUNT(id) стали различаться.

    SELECT MAX(`id`),COUNT(`id`) FROM `trans_it`

Выдаёт:

    MAX(`id`)      COUNT(`id`)
        75940            75926

Не очень давно обновлял Mariadb с 5.5.68 до 10.5.8 (Обновлял через mysqldump, а затем импортировал новый дамп в свежеустановленную БД). Сервер Centos 7.9 c 32 GB RAM Все таблицы в БД только типа MyISAM (таблиц InnoDB нет). Вот конфиг my.cnf

    [mysqld]
    
    bind-address = 127.0.0.1
    log_error = /var/log/mariadb/mysqld.error.log
    general_log_file    	= /var/log/mariadb/general.log
    general_log         	= 0
    slow_query_log      = 1
    slow_query_log_file = /var/log/mariadb/slow_queries.log
    long_query_time     = 1
    
    max_connections = 3984
    key_buffer_size = 6000M
    query_cache_size = 128M
    query_cache_limit = 2M
    read_buffer_size = 16M
    join_buffer_size = 16M

Перед крашем таблиц в логах обнаружил такие записи:

    2021-01-03 10:49:58 4 [Note] Detected table cache mutex contention at instance 1: 70% waits. Additional table cache instance activated. Number of instances after activation: 2.
    2021-01-03 10:49:58 5 [Note] Detected table cache mutex contention at instance 2: 36% waits. Additional table cache instance activated. Number of instances after activation: 3.
    2021-01-03 10:49:58 7 [Note] Detected table cache mutex contention at instance 2: 43% waits. Additional table cache instance activated. Number of instances after activation: 4.
    2021-01-03 10:49:59 9 [ERROR] mariadbd: Table './manager/domains' is marked as crashed and should be repaired
    2021-01-03 10:49:59 53 [ERROR] mariadbd: Table './manager/trans_de' is marked as crashed and should be repaired

И крашится таблицы начинают по моим ощущениям, когда возрастает нагрузка на БД. Собственно, вопрос в том, почему это возникает и как с этим бороться? Может в настройках что-то донастроить нужно?

https://serverfault.com/questions/923473/mariadb-mysql-table-marked-as-crashe...

Есть мнение что OOM-киллер отстреливает бекенд. Звучит логично: рост нагрузки, дополнительный кеш, рост потребления RAM.

Ну а

Ещё заметил, что после восстановления MAX(id) и COUNT(id) стали различаться.

Это тоже логично, myisam нетранщакционален и без лога, т.ч. отстрел ему болезнен

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

Сегодня ситуация повторилась, утром сервер работал отлично, час назад нагрузка стала расти. Load average перевалил за 50. Думаю, надо бэкап БД сделать. БД размером около 4 GB. Начал делать бэкап через mysqldump и сервер во время него умер. Просто связь оборвалась и всё. Смотрел в лог ошибок mariadb - там никаких сообщений об ошибке - связь просто оборвалась и всё. Так что проблема не в mariadb. Вот вывод команды dmesg -T, посмотрите пожалуйста, возможно кто-то найдёт причину.

вывод команды dmesg -T на pastebin

Например вызывают вопросы вот такие сообщения


[Mon Jan  4 11:58:42 2021] random: systemd: uninitialized urandom read (16 bytes read)
[Mon Jan  4 11:58:42 2021] systemd[1]: Initializing machine ID from random generator.
[Mon Jan  4 11:58:42 2021] random: systemd-cryptse: uninitialized urandom read (16 bytes read)
[Mon Jan  4 11:58:42 2021] random: systemd: uninitialized urandom read (16 bytes read)
[Mon Jan  4 11:58:42 2021] random: systemd: uninitialized urandom read (16 bytes read)
[Mon Jan  4 11:58:42 2021] random: systemd: uninitialized urandom read (16 bytes read)
[Mon Jan  4 11:58:42 2021] random: systemd: uninitialized urandom read (16 bytes read)
[Mon Jan  4 11:58:42 2021] random: systemd: uninitialized urandom read (16 bytes read)

О чём они могут говорить? И как выяснить был ли OOM-killer? Вывод dmesg -T не содержит ни слова «OOM» ни «killer»

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

Почитал про OOM-killer - врядли это он. Перед падением сервера у меня остался вывод команды top из putty.

[root@server1 ~]# top
top - 11:21:52 up 18:05,  1 user,  load average: 53.36, 25.40, 12.88
Tasks: 433 total,  18 running, 415 sleeping,   0 stopped,   0 zombie
%Cpu(s): 37.8 us, 23.1 sy,  0.0 ni, 21.3 id, 15.4 wa,  0.0 hi,  2.3 si,  0.0 st
KiB Mem : 32624820 total,  6168488 free,  5011796 used, 21444536 buff/cache
KiB Swap: 16759804 total, 16759804 free,        0 used. 27185516 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 1508 mysql     20   0 9781104   2.2g  16248 S  24.8  6.9 214:27.98 mariadbd
 2848 apache    20   0  531044  20016  10764 D   2.9  0.1   2:05.03 php-fpm
...

Видно, что за несколько минут до падения в системе ещё куча доступной RAM. На винчестере тоже куча места - там более 1.5TB свободно. (2 винта по 2TB в RAID 1)

Но факт - значительное увеличение нагрузки на сервер - и сервер внезапно умирает (помогает потом только перезагрузка сервера из панели управления хостера).

Возможно ключ к падениям кроется в выводе: вывод команды dmesg -T на pastebin

manolls ()
Ограничение на отправку комментариев: только для зарегистрированных пользователей