Звичайна реплікація MySQL асинхронна: джерело комітить транзакцію, відповідає клієнту «готово» і лише потім репліки забирають зміни. Якщо джерело загинуло одразу після коміту, остання транзакція могла ще не дійти до жодної репліки. Після перемикання на репліку ці транзакції втрачено, хоча застосунок отримав підтвердження: замовлення «оформлене», гроші «списані».
Напівсинхронна реплікація: джерело перед підтвердженням клієнту чекає, доки хоча б одна репліка підтвердить, що отримала транзакцію й записала її у свій журнал ретрансляції (relay log). Не застосувала - лише отримала й зберегла.
-- на джерелі
INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
SET PERSIST rpl_semi_sync_source_enabled = ON;
SET PERSIST rpl_semi_sync_source_timeout = 1000; -- мс
-- на репліці
INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
SET PERSIST rpl_semi_sync_replica_enabled = ON;
Точка очікування rpl_semi_sync_source_wait_point:
AFTER_SYNC(за замовчуванням, «без втрат») - джерело записує транзакцію в бінарний журнал, чекає підтвердження репліки, і лише потім комітить у рушії. Інші клієнти не побачать транзакцію на джерелі раніше, ніж вона буде на репліці;AFTER_COMMIT- коміт у рушії, потім очікування. Інші сесії можуть побачити дані, які потім пропадуть при перемиканні.
Головне застереження - тайм-аут. Якщо репліки не відповідають довше за rpl_semi_sync_source_timeout (за замовчуванням 10 секунд), джерело тихо переходить в асинхронний режим і продовжує працювати. Гарантія зникає саме тоді, коли щось пішло не так. Це треба моніторити:
SHOW GLOBAL STATUS LIKE 'Rpl_semi_sync_source_status'; -- ON / OFF
SHOW GLOBAL STATUS LIKE 'Rpl_semi_sync_source_no_tx'; -- коміти без підтвердження
Ціна: кожен коміт чекає на мережевий обмін з реплікою. У межах одного дата-центру - долі мілісекунди; між регіонами - десятки мілісекунд на кожну транзакцію.
Налаштування для надійності:
- щонайменше дві напівсинхронні репліки, щоб відмова однієї не перемикала джерело в асинхронний режим;
rpl_semi_sync_source_wait_for_replica_count- скільки підтверджень чекати;- автоматичне перемикання (Orchestrator, MySQL Router з InnoDB Cluster) має обирати як нове джерело саме репліку, що має всі підтверджені транзакції.
Від чого не захищає: від логічних помилок (DELETE без WHERE теж реплікується), і не робить читання з репліки свіжим - транзакцію отримано, але ще не обов'язково застосовано. Для справді синхронної реплікації з консенсусом - Group Replication.