#mysql #configuration #mariadb
#mysql #конфигурация #mariadb
Вопрос:
MariaDB 10.4.6 (Windows)
binlog_format = СТРОКА
Мой двоичный журнал взрывается. С нескольких дней у меня в нем много таких записей:
#201005 9:35:11 server id 14020 end_log_pos 262175992 CRC32 0xce45fdf1 Update_rows: table id 433 flags: STMT_END_F
BINLOG '
r8x6XxPENgAAewAAACY/nw8AALEBAAAAAAEAE215c3FsbW9uaXRvcl9lbmdpbmUAGm1pc19teXNx
bF9pbnN0YW5jZXNfc3RhdHVzABYBDxL AgICDw8DCQkBCQ8BAg8ICA8SEDIAAP4DCgAeAPoAFABQ
wwAAoBOICLzi ...
с действительно большим количеством строк. Я находил такие большие записи несколько раз в секунду. Теперь каждые 6 минут создается новый 250MB-binlog-файл (до этого это было каждые несколько часов).
Недавно я изменил формат binlog_format с стандартного (СМЕШАННОГО) на ROW . Вот и все.
В чем причина такого поведения, для какой цели предназначены эти записи? И что я могу сделать, чтобы подавить эти нечитаемые записи?
Ответ №1:
Скорее всего, причина в том, что у вас относительно мало операторов, которые изменяют большое количество строк. Включите общий журнал (или медленный журнал с long_query_time=0), и вы будете записывать все инструкции, которые выполняет сервер. Это должно помочь вам найти запросы, которые ведут себя таким образом.
Двоичный журнал на основе инструкций хранит инструкции, которые изменяют данные. Существуют крайние случаи, для которых это не является детерминированным. Двоичный журнал на основе строк хранит все строки, которые были изменены. Если у вас есть один оператор, который изменяет каждую строку в большой таблице, вся таблица попадет в двоичный журнал дважды (исходная строка и новая строка хранятся в двоичном журнале на основе строк — полная старая строка для сопоставления и полная строка замены).
Вы ничего не можете сделать, чтобы изменить это поведение, такова природа работы двоичного журнала на основе строк. Единственное, что вы можете сделать, чтобы уменьшить требования к пространству, это поместить двоичные журналы в сжатую файловую систему или сократить период их хранения.
Комментарии:
1. Привет, Гордан, большое спасибо за ваше полезное объяснение! Проблема должна заключаться не в том, что оператор изменяет много строк, а в обновлении только одной строки, но в этой таблице есть столбец, содержащий текст большего размера (около 40.000 символов). Я не изменяю этот текст в ОБНОВЛЕНИИ, но другие значения в этой строке, и теперь я понимаю, что вся строка, по-видимому, записывается (дважды, спасибо за этот совет) в двоичный журнал. Но примерно с тройкой символов (представленных в результате mysqlbinlog). И да, я делаю много изменений в этой таблице.
2. Еще одна проблема, кстати, заключается в написании инструкции UPDATE над областью «BINLOG» в журнале. Я могу найти точное утверждение, которое я выполнил, но без последнего символа. Когда мое утверждение заканчивается «ГДЕ id = 170», я нахожу в журнале «ГДЕ id = 17». Каждый раз. Странно. Но, я думаю, это другая тема.
3. Это может быть проблемой рендеринга символов в Windows. Посмотрите на файл с помощью шестнадцатеричного редактора и посмотрите, действительно ли запрос завершен, но символ, который завершает строку, отображается таким образом, что кажется, что он поглощает предыдущий символ.