Назад | Перейти на главную страницу

Репликация MySQL - быстро растущие журналы бункеров ретрансляции

Всем доброго утра,

У меня сегодня утром действительно странная ситуация, очень похожая на якобы исправленную ошибку MySQL.

http://bugs.mysql.com/bug.php?id=28421

Журналы моей релейной корзины быстро заполняются бесконечным циклом мусора, сделанного из такого рода вещей.

#121018  5:40:04 server id 101  end_log_pos 15598207
#Append_block: file_id: 2244  block_len: 8192
# at 15598352
#121018  5:40:04 server id 101  end_log_pos 15606422
#Append_block: file_id: 2244  block_len: 8192
# at 15606567

...

# at 7163731
#121018  5:38:39 server id 101  end_log_pos 7171801
#Append_block: file_id: 2243  block_len: 8192
WARNING: Ignoring Append_block as there is no Create_file event for file_id: 2243
# at 7171946
#121018  5:38:39 server id 101  end_log_pos 7180016
#Append_block: file_id: 2243  block_len: 8192
WARNING: Ignoring Append_block as there is no Create_file event for file_id: 2243

Эти файлы журналов увеличиваются до 1 ГБ примерно за минуту, а затем снова запускаются.

Эти большие файлы чередуются с 1 или 2 файлами меньшего размера.

/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#121023  9:43:05 server id 100  end_log_pos 106         Start: binlog v 4, server v 5.1.61-log created 121023  9:43:05
BINLOG '
mViGUA9kAAAAZgAAAGoAAAAAAAQANS4xLjYxLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC
'/*!*/;
# at 106
#121023  9:43:05 server id 100  end_log_pos 156         Rotate to mysqld-relay-bin.000003  pos: 4
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

Мы запускаем настройку репликации мастер-мастер с проблемным сервером, на котором запущен mysql 5.1.61. Другой стабильный на данный момент сервер работает под управлением 5.1.58.

Есть ли у кого-нибудь идеи, как решить эту проблему и, кроме того, что могло вызвать это?

После пары часов лихорадочного поиска, очистки, сброса и т. Д. Кажется, что старый добрый способ выключить его и снова включить - это решение. Не совсем цикл включения, а полный сброс ведомых + мастеров.

slave stop;
reset master;
reset slave;
slave start;

Я сделал это на каждом из главных / подчиненных, так что все подчиненные были остановлены перед перезапуском каждого из мастеров перед перезапуском каждого из подчиненных.

Я надеюсь, что это поможет кому-то другому, в этой ситуации мало что известно.