Синхронная репликация¶
В данном разделе описан механизм синхронной репликации в Picodata
Общие сведения¶
Понятие репликации имеет несколько определений в Picodata, о чём написано в нашем глоссарии. В данном случае речь идёт о синхронизации данных между инстансами внутри репликасета. Необходимость репликации вызвана тем, что изменения (такие как DML-операции) в шардированных таблицах изначально происходят только на лидере репликасета (мастер-реплике) и требуют отдельной синхронизации с остальными репликами для поддержания консистентности данных.
Режим репликации в Picodata является настройкой на уровне тиров, поскольку тир является логической сущностью для хранения данных с одинаковыми требованиями к долговечности и отказоустойчивости. Например, возможна топология кластера, в которую будут входить два тира: один для высококритичных данных с более высоким фактором репликации и синхронным режимом, и второй, с меньшим фактором репликации и асинхронным режимом.
См. также:
Принцип работы¶
Синхронная репликация подразумевает, что запись в таблицу возвращает
управление пользователю только тогда, когда эта операция была
подтверждена кворумом репликасета (подтверждение происходит после
попадания записи в WAL-журнал инстанса). Кворум определяется по
формуле RF / 2 + 1, где RF (replication factor) — фактор
репликации для тира.
Использование синхронной репликации означает, что успешно выполненная (и вернувшая управление) операция записи гарантирует сохранность данных даже при отказе одного или нескольких узлов при условии, что кворум внутри репликасета сохранён. Например, при факторе репликации равному трём после подтверждения транзакции кворумом (двумя узлами) при выходе из строя любого одного узла в репликасете останется узел, сохранивший записанные данные.
При использовании синхронной репликации существенно повышается надёжность данных в СУБД за счёт некоторого снижения скорости их обновления (за счёт ожидания подтверждения операции от реплик).
Второй способ репликации — асинхронный — обладает противоположными свойствами: высокой скоростью записи данных за счет отсутствия необходимости ожидать подтверждения с реплик. Скорость выше в разы или даже в десятки раз по пропускной способности (TPS), а задержка (latency) сетевых операций при этом ниже на 0,5-5 мс, в зависимости от конкретной конфигурации и топологии кластера СУБД.
Для пользователя это означает, что управление после операции записи возвращается до подтверждения операции репликами. В асинхронном режиме на лидере репликасета при постоянном потоке операций записи может накапливаться набор неподтверждённых репликами операций. В случае отказа лидера неподтверждённые операции могут быть потеряны если лидера не получится ввести в строй. При попытке ввести в строй старого лидера возможен конфликт репликации: например, новый лидер закоммитит операцию, конфликтующую с данными из неподтверждённого набора на старом лидере.
Синхронный режим исключает описанные проблемы.
Применимость¶
Синхронная репликация в Picodata работает только для шардированных (пользовательских) таблиц и включается один раз при первоначальном развёртывании кластера.
Синхронная репликация не используется для глобальных таблиц и не применима
к системным таблицам (с префиксом _pico), которые обновляются
глобально с помощью алгоритма Raft. Операции над глобальными таблицами всегда
требуют подтверждения кворумом узлов.
См. также:
Конфигурация¶
По умолчанию в Picodata используется асинхронная репликация. Синхронный режим следует явно включить в файле конфигурации перед первым запуском кластера.
Поведение при отказах¶
Кворум синхронной репликации равен RF / 2 + 1. Если число живых
инстансов в репликасете меньше кворума, то идущие в этот репликасет
операции записи не подтверждаются.
При потере кворума репликасет автоматически переводится в режим read-only и обслуживает в нормальном режиме только читающие транзакции (DQL). Для пишущих транзакций (DML/DDL) действуют следующие ограничения:
- транзакции, которые уже попали в журнал лидера до перевода репликасета режим в read-only: зависнут, пользователь получит ошибку по таймауту, но транзакция может подтвердиться позже при восстановлении кворума.
- транзакции, пришедшие на репликасет после его перевода в режим read-only: будут прерваны с ошибкой.
Примечание
Не рекомендуется использовать синхронную
репликацию в сочетании с чётным фактором репликации (RF). При
небольших значениях RF (2) репликасет теряет возможность
выполнять операции записи при отказе любого одного инстанса.
Примечание
На текущий момент не предусмотрен автоматический процесс восстановления репликасета, в котором потерян кворум. Восстановить кворум можно только вручную, используя следующие настройки реплик:
replication_synchro_quorum(кворум синхронной репликации — может помочь его временное уменьшение),replication_synchro_timeout(таймаут подтверждения транзакций при синхронной репликации) — может помочь его временное уменьшение,read_only(флаг, отвечающий за доступность реплики на запись) — может помочь, если нужно принудительно сделать реплику доступной только для чтения.