будет mysql гарантировать двоичный журнал (журнал бина) записать событие Table_map / событие Write_rows / событие Xid атомарно? - PullRequest
Новая
       11

будет mysql гарантировать двоичный журнал (журнал бина) записать событие Table_map / событие Write_rows / событие Xid атомарно?

0 голосов
/ 15 апреля 2019

попробуйте использовать журнал bin для чтения инкрементных данных, но вставьте / обновите / удалите только события записи идентификатора таблицы, в то время как идентификатор таблицы является записью в событии Table_map до этих измененных событий. то есть события insert / update / delete и событие Table_map атомарно записываются в двоичный журнал, так что определенное имя таблицы измененных событий можно узнать с помощью очень близкого предыдущего события Table_map?

если нет, как получить имя таблицы для определенных событий вставки / обновления / удаления с идентификатором таблицы?

1 Ответ

0 голосов
/ 02 мая 2019

@ BillKarwin после того, как я прочел другой проект: maxwell (https://github.com/zendesk/maxwell) ответ - да, mysql транзакционно записывает события вставки / обновления / удаления, где их окружают begin (тип события = Query) и COMMIT (тип события = Xid).

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

в самом начале, я получаю полные данные с помощью следующих действий: 

flush tables tableA, tableB, tableC WITH READ LOCK; 
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION WITH CONSISTENT SNAPSHOT;
show master status;
//record binlog filename and position
UNLOCK TABLES;
//read complete data
commit;

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

каждый раз после этого я начинаю читать binlog из записи о положении в последний раз и с осторожностью получаю интересующие меня данные, чтобы позаботиться об упомянутом выше угловом случае, поскольку незакрытые события могут откатываться сервером mysql.

после чтения binlog, запишите позицию текущего чтения для следующей итерации.

@ BillKarwin, спасибо за помощь

...