16.3.8. Полусинхронная Репликация

16.3.8.1. Полусинхронная Репликация Административный Интерфейс
16.3.8.2. Полусинхронная Установка Репликации и Конфигурация
16.3.8.3. Полусинхронный Контроль Репликации

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

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

Полусинхронная репликация может использоваться в качестве альтернативы асинхронной репликации:

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

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

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

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

Чтобы понять, что означает "полу" в "полусинхронной репликации", сравните ее с асинхронной и полностью синхронной репликацией:

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

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

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

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