Рейтинг:0

Mysql постоянно пишет в binlog, быстро используя место на диске

флаг in
jla

Мой сервер Ubuntu начал выполнять большое количество операций ввода-вывода. На сервере есть несколько веб-сайтов WordPress, но они получают максимум несколько десятков просмотров в день. За пару дней было использовано 30 ГБ дискового пространства.

Проверка йотоп

Бег йотоп показал, что mysql постоянно пишет на диск. Типичный вывод был таким:

Всего DISK READ: 0,00 Б/с | Общая скорость записи на диск: 390,38 тыс./с
Текущее чтение с диска: 0,00 Б/с | Текущая скорость записи на диск: 664,80 К/с
    TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND                                                                        
    298 be/3 root 0,00 Б/с 0,00 Б/с 0,00 % 4,79 % [jbd2/vda1-8]
    981 be/4 mysql 0,00 Б/с 0,00 Б/с 0,00 % 0,55 % mysqld [ib_log_flush]
    960 be/4 mysql 0,00 Б/с 0,00 Б/с 0,00 % 0,42 % mysqld [ib_io_wr-1]
  63310 be/4 mysql 0,00 Б/с 30,92 К/с 0,00 % 0,17 % mysqld [соединение]
  62908 be/4 mysql 0,00 Б/с 34,79 К/с 0,00 % 0,09 % mysqld [соединение]
  64165 be/4 mysql 0,00 Б/с 34,79 К/с 0,00 % 0,07 % mysqld [соединение]
    964 be/4 mysql 0,00 Б/с 185,52 К/с 0,00 % 0,05 % mysqld [ib_pg_flush_co]
    983 be/4 mysql 0,00 Б/с 100,49 К/с 0,00 % 0,00 % mysqld [ib_log_writer]
  71067 be/4 www-data 0,00 Б/с 3,87 К/с 0,00 % 0,00 % apache2 -k start

Действительно, проверка в /var/lib/mysql каталог показал сотни файлов binlog общим размером около 30 ГБ. Временные метки указывали, что mysql записывает в бинарные журналы со скоростью, близкой к 1 ГБ в час, без каких-либо признаков замедления.

Проверка процессов mysql

Бег mysql -p -e "показать список процессов" просмотр процессов mysql ничего не показал.

+--------+------+-----------+------+---------+---- --+-------+----+
| Идентификатор | Пользователь | Хост | дб | Команда | Время | состояние | Информация |
+--------+------+-----------+------+---------+---- --+-------+----+
| 627525 | корень | локальный | НУЛЕВОЙ | Запрос | 0 | инициировать | показать список процессов |
+--------+------+-----------+------+---------+---- --+-------+----+

Проверка файлов binlog

С использованием mysqlbinlog просмотр файлов binlog показал, что они заполнены каким-то хэшем. Типичный файл выглядел так:

# Правильный термин псевдо_реплика_режим, но мы используем этот псевдоним совместимости
# чтобы оператор можно было использовать на серверах версии 8.0.24 и старше.
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# в 4
#220515 4:09:54 идентификатор сервера 1 end_log_pos 126 CRC32 0x070b8f09 Запуск: binlog v 4, сервер v 8.0.29-0ubuntu0.20.04.3 создан 220515 4:09:54
БИНЛОГ '
En2AYg8BAAAAegAAAH4AAAAAAAQAOC4wLjI5LTB1YnVudHUwLjIwLjA0LjMAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEwANAAgAAAAABAAEAAAAYgAEGggAAAAICAgCAAAACgoKKioAEjQA
CigAAQmPCwc=
'/*!*/;
# в 126
#220515 4:09:54 идентификатор сервера 1 end_log_pos 157 CRC32 0x433aa4c9 Предыдущие GTID
# [пустой]
# в 157
#220515 4:09:54 идентификатор сервера 1 end_log_pos 236 CRC32 0x671d08bc Anonymous_GTID last_committed=0 sequence_number=1 rbr_only=yes original_committed_timestamp=1652587794635604imimum_commit_timestamp=1652587794635604transaction_length=1652587794635604transaction_2
/*!50718 УСТАНОВИТЬ УРОВЕНЬ ИЗОЛЯЦИИ ТРАНЗАКЦИИ READ COMMITTED*//*!*/;
# original_commit_timestamp=1652587794635604 (2022-05-15 04:09:54.635604 UTC)
# немедленно_commit_timestamp=1652587794635604 (2022-05-15 04:09:54.635604 UTC)
/*!80001 SET @@session.original_commit_timestamp=1652587794635604*//*!*/;
/*!80014 SET @@session.original_server_version=80029*//*!*/;
/*!80014 SET @@session.immediate_server_version=80029*//*!*/;
SET @@SESSION.GTID_NEXT= 'АНОНИМНЫЙ'/*!*/;
# в 236
#220515 4:09:54 идентификатор сервера 1 end_log_pos 334 CRC32 0x71a6c06f Запрос thread_id=614826 exec_time=0 error_code=0
УСТАНОВИТЬ TIMESTAMP=1652587794/*!*/;
SET @@session.pseudo_thread_id=614826/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
НАБОР @@session.sql_mode=1149239296/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=246,@@session.collation_connection=246,@@session.collation_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
НАЧИНАТЬ
/*!*/;
# на 334
#220515 4:09:54 идентификатор сервера 1 end_log_pos 415 CRC32 0x6976a620 Table_map: `wordpress-jessjohn`.`wp_options` сопоставлен с номером 81
# на 415
#220515 4:09:54 идентификатор сервера 1 end_log_pos 14218 CRC32 0x8cd2158b Update_rows: идентификатор таблицы 81 флаги: STMT_END_F

БИНЛОГ '
En2AYhMBAAAAUQAAAJ8BAAAAAFEAAAAAAAAEndvcmRwcmVzcy1qZXNzam9obgAKd3Bfb3B0aW9u
cwAECA/8DwX8AgRQAAABAYACAfYgpnZp
En2AYh8BAAAA6zUAAIo3AAAAAFEAAAAAAAEAAgAE//8AHQAAAAAAAAANAHJld3JpdGVfcnVsZXMA
AAAAA3llcwAdAAAAAAAAAA0AcmV3cml0ZV9ydWxlc4c1AABhOjE0MDp7czoxMToiXndwLWpzb24v
PyQiO3M6MjI6ImluZGV4LnBocD9yZXN0X3JvdXRlPS8iO3M6MTQ6Il53cC1qc29uLyguKik/Ijtz
OjMzOiJpbmRleC5waHA/cmVzdF9yb3V0ZT0vJG1hdGNoZXNbMV0iO3M6MjE6Il5pbmRleC5waHAv
d3AtanNvbi8/JCI7czoyMjoiaW5kZXgucGhwP3Jlc3Rfcm91dGU9LyI7czoyNDoiXmluZGV4LnBo
cC93cC1qc29uLyguKik/IjtzOjMzOiJpbmRleC5waHA/cmVzdF9yb3V0ZT0vJG1hdGNoZXNbMV0i
O3M6MTc6Il53cC1zaXRlbWFwXC54bWwkIjtzOjIzOiJpbmRleC5waHA/c2l0ZW1hcD1pbmRleCI7

...245 строк этого...

dD0kbWF0Y2hlc1sxXSZjcGFnZT0kbWF0Y2hlc1syXSI7czoyMjoiW14vXSsvKFteL10rKS9lbWJl
ZC8/JCI7czo0MzoiaW5kZXgucGhwP2F0dGFjaG1lbnQ9JG1hdGNoZXNbMV0mZW1iZWQ9dHJ1ZSI7
fQN5ZXOLFdKM
'/*!*/;
# в 14218
#220515 4:09:54 идентификатор сервера 1 end_log_pos 14249 CRC32 0x322d3658 Xid = 18716628
СОВЕРШИТЬ/*!*/;
# в 14249
#220515 4:09:54 идентификатор сервера 1 end_log_pos 14329 CRC32 0xc4b6c15a Anonymous_GTID last_committed=1 sequence_number=2 rbr_only=yes original_committed_timestamp=1652587794702570 немедленно_commit_timestamp=165258779470251001 transaction_4=4
/*!50718 УСТАНОВИТЬ УРОВЕНЬ ИЗОЛЯЦИИ ТРАНЗАКЦИИ READ COMMITTED*//*!*/;
# original_commit_timestamp=1652587794702570 (2022-05-15 04:09:54.702570 UTC)
# немедленно_commit_timestamp=1652587794702570 (2022-05-15 04:09:54.702570 UTC)
/*!80001 SET @@session.original_commit_timestamp=1652587794702570*//*!*/;
/*!80014 SET @@session.original_server_version=80029*//*!*/;
/*!80014 SET @@session.immediate_server_version=80029*//*!*/;
SET @@SESSION.GTID_NEXT= 'АНОНИМНЫЙ'/*!*/;
# в 14329
#220515 4:09:54 идентификатор сервера 1 end_log_pos 14427 CRC32 0x1328bf8c Запрос thread_id=614825 exec_time=0 error_code=0
УСТАНОВИТЬ TIMESTAMP=1652587794/*!*/;
НАЧИНАТЬ
/*!*/;
# в 14427
#220515 4:09:54 идентификатор сервера 1 end_log_pos 14507 CRC32 0x64436ee3 Table_map: `wordpress-jessjohn`.`wp_usermeta` сопоставлен с номером 95
# в 14507
#220515 4:09:54 идентификатор сервера 1 end_log_pos 114362 CRC32 0xec16092b Update_rows: идентификатор таблицы 95 флаги: STMT_END_F

БИНЛОГ '
En2AYhMBAAAAUAAAAKs4AAAAAF8AAAAAAAAEndvcmRwcmVzcy1qZXNzam9obgALd3BfdXNlcm1l
dGEABAGID/wD/AMEDAEBwAIB9uNuQ2Q=
En2AYh8BAAAAD4YBALq+AQAAAF8AAAAAAAAAAgAE//8ANwAAAAAAAAABAAAAAAAAAAAA4Ac2Vzc2lv

... и так далее для >200 строк

Что вызывает все эти журналы?

Я не очень хорошо знаком с ведением журнала mysql, поэтому не знаю, куда идти дальше. Я полагаю, что быстрым решением было бы просто отключить регистрацию. Я не понимаю, что говорят файлы binlog или что может быть причиной того, что так много логируется.

Wilson Hauck avatar
флаг jp
Запрос дополнительной информации, пожалуйста. Размер оперативной памяти, количество ядер, какие-либо устройства SSD или NVME на хост-сервере MySQL? Опубликуйте на pastebin.com и поделитесь ссылками. Из вашего корня входа SSH текстовые результаты: A) SELECT COUNT(*) FROM information_schema.tables; B) ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС; минимум через 24 часа UPTIME C) ПОКАЗАТЬ ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ; D) ПОКАЗАТЬ ПОЛНЫЙ СПИСОК ПРОЦЕССОВ; И очень полезная информация об ОС, включая - htop ИЛИ top для наиболее активных приложений, ulimit -a для списка ограничений, iostat -xm 5 3 для IOPS по устройству и количеству ядер / процессоров, для анализа настройки бинарного журнала сервера для предоставления предложений.
флаг ua
У вас есть реплика? Каков его "server_id"?
Рейтинг:1
флаг in

Бинлоги в MySQL используются для репликации между мастером и подчиненными. Если вы не используете такую ​​архитектуру, вы можете отключить ее, выполнив следующее:

УСТАНОВИТЬ sql_log_bin = 0;

Если у вас есть такая структура, вы можете удалить старые (уже реплицированные) записи с помощью команды, например:

ОЧИСТИТЬ БИНАРНЫЕ ЖУРНАЛЫ ДО '2019-04-02 22:46:26';

или же

ОЧИСТИТЬ БИНАРНЫЕ ЖУРНАЛЫ В 'mysql-bin.010';

Для получения дополнительной информации вы можете использовать этот ответ.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.