Как обычно, очередные грабли, на сей раз - в 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’а, и тогда в дампе появились подробности, хотя и не про сами операторы, но хотя бы про записи, над которыми эти операторы выполнялись:
### UPDATE `foobar`.`nodes` ### WHERE ### @1=345 /* INT meta=0 nullable=0 is_null=0 */ ### @2=2 /* INT meta=0 nullable=0 is_null=0 */ ### @3=0 /* INT meta=0 nullable=0 is_null=0 */ ### @4='string1' /* VARSTRING(192) meta=192 nullable=0 is_null=0 */ ### @5='string2' /* VARSTRING(192) meta=192 nullable=0 is_null=0 */ ### @6='string3' /* VARSTRING(96) meta=96 nullable=0 is_null=0 */ ### @7='' /* VARSTRING(192) meta=192 nullable=0 is_null=0 */ ### @8=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @9=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @10=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @11=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @12=1469704055 /* INT meta=0 nullable=0 is_null=0 */ ### @13=1489490052 /* INT meta=0 nullable=0 is_null=0 */ ### @14=1494410253 /* INT meta=0 nullable=0 is_null=0 */ ### @15=-1 /* INT meta=0 nullable=0 is_null=0 */ ### SET ### @1=345 /* INT meta=0 nullable=0 is_null=0 */ ### @2=2 /* INT meta=0 nullable=0 is_null=0 */ ### @3=0 /* INT meta=0 nullable=0 is_null=0 */ ### @4='string1' /* VARSTRING(192) meta=192 nullable=0 is_null=0 */ ### @5='string2' /* VARSTRING(192) meta=192 nullable=0 is_null=0 */ ### @6='string3' /* VARSTRING(96) meta=96 nullable=0 is_null=0 */ ### @7='' /* VARSTRING(192) meta=192 nullable=0 is_null=0 */ ### @8=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @9=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @10=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @11=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */ ### @12=1469704055 /* INT meta=0 nullable=0 is_null=0 */ ### @13=1489490052 /* INT meta=0 nullable=0 is_null=0 */ ### @14=1494413401 /* INT meta=0 nullable=0 is_null=0 */ ### @15=-1 /* INT meta=0 nullable=0 is_null=0 */
Посмотрел структуру таблицы, @1 - это id, первичный ключ. Поискал запись с таким id, а её нету.. Ни в slave, ни в master. Ну, видать, из master’а её потом удалили, а в slave придётся добавить, чтоб этот UPDATE сработал. Добавил её руками, перезапустил slave, заработало! Но через некоторое время вылезла аналогичная ошибка. Поискал в дампе, опять там меняли запись, которой тут нету. Добавил и её, перезапустил slave, и так далее. Короче, всего пришлось добавить штук 10 записей в паре таблиц, хотя потом их все всё равно удалили. Ну зато slave больше не ругается, нормально работает.
Но вот как эти записи пропали в slave, когда в master’е их ещё только подправляли - так и осталось загадкой. Видать, кто-то руками удалил, но кто, когда, как, и главное - зачем, выяснить не удалось.
Оригинал этой записи в личном блоге.
(
| Комментировать в Dreamwidth)