16.3.9 Semisynchronous Replication — MySQL 5.7

16.3.9 Полусинхронная репликация

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

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

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

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

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

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

Важно

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

Если вашей целью является реализация отказоустойчивой топологии репликации, где все серверы получают одинаковые транзакции в одном и том же порядке, а сервер, выходящий из строя, может присоединиться к группе и быть обновлён автоматически, вы можете использовать Group Replication для достижения этой цели. Для получения информации см. Главу 17, Group Replication.

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

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

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

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

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

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

Системная переменная rpl_semi_sync_master_wait_point управляет моментом, в котором источник полусинхронной репликации ожидает подтверждения реплики о получении транзакции перед возвращением статуса клиенту, который выполнил транзакцию. Разрешены следующие значения:

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

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

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

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

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