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

Репликация 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, которая добавляет общие блокировки и избегает ненужных приобретений блокировок. Эти настройки помогают при увеличении количества реплик, поскольку конкуренция за блокировки может снизить производительность. Серверы источника полусинхронной репликации также могут получить выгоду от включения этих системных переменных, поскольку они используют те же механизмы блокировки, что и реплики.