May 11th, 2017

Как обычно, очередные грабли, на сей раз – в MySQL

На бэкапном MySQL сервере slave отвалился с очень странной ошибкой, с которой я раньше не встречался:
Could not execute Update_rows event on table foobar.nodes; Can't find record in 'nodes', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log live-master.001765, end_log_pos 13453210
Попробовал перезапустить slave, та же ошибка вылезает. Покопался в базе, а там никаких event’ов вовсе не зарегистрировано. Посмотрел в master, там тоже нету.

Классический способ STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE; в данном случае не подходил, ибо в этой бэкапной базе нужно иметь в точности то же самое, что и в основной. А если часть операторов пропустить, то что-нибудь может подпортиться.

Самое противное, что непонятно, какой оператор эту ошибку вызвал. Обычно-то он явно указывается, а тут нету — сам ищи, что там за ключ не нашёлся, и каким образом он использовался..
Попробовал сдампить log-файл на master’е mysqlbinlog’ом, а там фигня какая-то: виднеются операторы типа SET TIMESTAMP=1494413401, BEGIN, COMMIT,, а в какой записи этот timestamp SET — фиг знает, сам угадай.. Но виднеются какие-то куски BINLOG в base64. Попробовал сдампить ещё раз с --base64-output=decode-rows, так эти куски пропали, а подробности операторов так и не появились.

Ну, как водится, эти грабли мне тоже удалось обойти. Нашёл нужную опцию -vv для mysqlbinlog’а, и тогда в дампе появились подробности, хотя и не про сами операторы, но хотя бы про записи, над которыми эти операторы выполнялись:

Collapse )

Оригинал этой записи в личном блоге.

(comment count unavailable | Комментировать в Dreamwidth)