Помимо встроенной асинхронной репликации, MySQL 9.2 поддерживает интерфейс полусинхронной репликации, реализованный плагинами. В этом разделе обсуждается, что такое полусинхронная репликация и как она работает. Следующие разделы описывают административный интерфейс полусинхронной репликации и способы ее установки, настройки и мониторинга.

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

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

Полусинхронная репликация находится между асинхронной и полностью синхронной репликацией. Источник ожидает, пока по крайней мере одна реплика получит и запишет события (необходимое количество реплик настраивается), а затем подтверждает транзакцию. Источник не ждет подтверждения от всех реплик, и ему требуется только подтверждение от реплик, а не то, что события полностью выполнены и подтверждены на стороне реплики. Таким образом, полусинхронная репликация гарантирует, что если источник выходит из строя, все транзакции, которые он подтвердил, были переданы по крайней мере одной реплике.

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

По сравнению с полностью синхронной репликацией полусинхронная репликация быстрее, поскольку ее можно настроить так, чтобы сбалансировать требования к целостности данных (число реплик, подтверждающих получение транзакции) со скоростью подтверждений, которые медленнее из-за необходимости ожидания реплик.

Влияние на производительность полусинхронной репликации по сравнению с асинхронной репликацией — это компромисс для повышения целостности данных. Время замедления как минимум равно времени обмена TCP/IP для отправки подтверждения в реплику и ожидания подтверждения получения репликой. Это означает, что полусинхронная репликация лучше всего работает для близко расположенных серверов, обменивающихся данными по быстрым сетям, и хуже всего — для удаленных серверов, обменивающихся данными по медленным сетям. Полусинхронная репликация также устанавливает ограничение скорости для загруженных сессий, ограничивая скорость отправки событий двоичного журнала с источника на реплику. Когда один пользователь слишком занят, это замедляет работу, что может быть полезно в некоторых ситуациях развертывания.

Полусинхронная репликация между источником и его репликами работает следующим образом:

Пока источник заблокирован (ожидая подтверждения от реплики), он не возвращается к сессии, которая выполнила транзакцию. По окончании блокировки источник возвращается к сессии, которая затем может продолжить выполнение других операторов. В этот момент транзакция подтверждена на стороне источника, и получение ее событий было подтверждено по крайней мере одной репликой. Количество подтверждений от реплик, которое должен получить источник за транзакцию перед возвратом к сессии, настраивается и по умолчанию равно одному подтверждению (см. Раздел 19.4.10.2, «Настройка полусинхронной репликации»).

Блокировка также происходит после отката, записываемого в двоичный журнал, который происходит при отмене транзакции, изменяющей не транзакционные таблицы. Отменённая транзакция регистрируется, даже если она не оказывает никакого эффекта для транзакционных таблиц, потому что изменения в не транзакционных таблицах не могут быть отменены и должны быть отправлены репликам.

Для операторов, которые не выполняются в контексте транзакции (то есть, когда транзакция не была начата с START TRANSACTION или SET autocommit = 0), автоматическое подтверждение включено и каждый оператор неявно подтверждается. При полусинхронной репликации источник блокируется для каждого такого оператора, как и для явного подтверждения транзакции.

По умолчанию источник ожидает подтверждения от реплики о получении транзакции после синхронизации двоичного журнала на диск, но перед подтверждением транзакции в хранилище данных. В качестве альтернативы, вы можете настроить источник таким образом, чтобы он ожидал подтверждения от реплики после подтверждения транзакции в хранилище данных, используя системную переменную rpl_semi_sync_source_wait_point. Эта настройка влияет на характеристики репликации и данные, которые клиенты могут видеть на источнике. Дополнительную информацию см. в Разделе 19.4.10.2, «Настройка полусинхронной репликации».

Вы можете улучшить производительность полусинхронной репликации, включив системные переменные replication_sender_observe_commit_only, которые ограничивают обратные вызовы, и replication_optimize_for_static_plugin_config, которые добавляют общие блокировки и избегают ненужных приобретений блокировок. Эти параметры помогают по мере увеличения количества реплик, поскольку конкуренция за блокировки может замедлить производительность. Серверы-источники полусинхронной репликации также могут извлечь выгоду из включения этих системных переменных, поскольку они используют те же механизмы блокировки, что и реплики.