Несколько таблиц все еще не синхронизированы после запуска mk-table-sync

У меня есть 1 хозяин и 2 раба. Я использую MySQL 5.1.42 на всех серверах. Я пытаюсь использовать mk-table-checkum для проверки того, что их данные синхронизированы, но я получаю неожиданные результаты на одном из ведомых устройств.

Сначала я генерирую контрольные суммы на мастере следующим образом:

mk-table-checksum h=localhost --databases MYDB --tables {$table_list} --replicate=MYDB.mk_checksum --chunk-size=10M

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

Затем, чтобы убедиться, что контрольные суммы совпадают, я запускаю это на мастере:

mk-table-checksum --databases MYDB --replicate=IRC.mk_checksum --replicate-check 1 h=localhost,u=maatkit,p=xxxx

Если есть какие-либо различия, я чиню рабов следующим образом:

mk-table-sync --execute --verbose --replicate IRC.mk_checksum h=localhost,u=maatkit,p=xxxx

Сделав все это, я восстановил обоих ведомых с помощью mk-table-sync. Тем не менее, каждый раз, когда я запускаю эту последовательность (после того, как все уже восстановлено), один ведомый полностью синхронизирован, но у одного ведомого всегда есть несколько таблиц, не синхронизированных. Я на 99,999% уверен, что данные на ведомых устройствах совпадают, поскольку я все исправил, и таблицы даже не обновлялись на главном сервере между запусками сценария контрольной суммы. Что может привести к тому, что несколько таблиц будут всегда не синхронизированы только на одном из ведомых устройств? Я застрял. Вот вывод:

Differences on h=x.x.x.x,p=...,u=maatkit  

DB TBL CHUNK CNT_DIFF CRC_DIFF BOUNDARIES
IRC продукт 10 0 1 product_id > = 147377 И product_id <162085
IRC post_order_survey 0 0 1 1 = 1
IRC mk_heartbeat 0 0 1 1 = 1
IRC mailing_list 0 0 1 1 = 1
IRC honey_pot_log 0 0 1 1 = 1
IRC продукт 12 0 1 product_id > = 176793 И product_id <191501
IRC продукт 18 0 1 product_id > = 265041
IRC заказывает 26 0 1 order_id > = 694472
IRC orders_product 6 0 1 op_id > = 935375