таблица, толстая (innodb), размером в 90 G. Мы решили, что было бы неплохо ее скопировать для выполнения на ней тестового ALTER. Для этого мы решили использовать SELECT INSERT, но вот что-то в этот момент мы очень ступили и вызвали эту радость на мастер сервере... и занялись своими делами. В какой-то момент, все слейвы начали естественно все это дело реплицировать и seconds behind master ушел в космос. В это момент мы вспомнили и поняли что натворили и кильнули в мелкой панике запрос на мастере... Но... это не убило данный запрос на слейвах, они устойчиво продолжали выполнять данную позицию из релей бин лог. Тут пришла мысль просто скипнуть это, для этого мы выполнили stop slave и выставили скип с шагом - 1 (просто для теста даже). Что нас ожидало? То чего я прежде не видел и не знал слейв выдал ошибку вида:
Got fatal error 1236 from master when reading data from binary log: 'log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master;
Почитав быстро статью многоуважаемого Петра Зайцева, я понял, что мы в ж..е. Тут интересный факт, которого я и не знал. Оказывается бинлог на мастер сервере, может превышать заданный в настройках размер. При выставленном ограничении в 500Mb (после чего запись идет в следующий лог) бинлог файл на мастере, на момент того страшного запроса вырос до
43G ./mysql-bin.017832
Я если честно до конца не понимаю как это возможно и почему это возможно, но понял также что вероятно даже если я проскипаю релей логи до нужной позиции, то скорее всего я что-то все же потеряю в данных.
Что я сделал? Единственное что я мог на тот момент - накатил вновь все слейвы с нуля...
Я был бы рад , если кто-то мне укажет на мои ошибки и скажет где я был не прав и как на самом деле можно было-бы поступить.
Версия MySQL (5.7.21-21-3.stretch)
по-моему очевидный факт, что размер может быть больше лимита, твой insert into select это одна транзакция, которая не может быть разбита на несколько бинлог файлов
Обсуждают сегодня