12. Репликация

12.1. Особенности репликации

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

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

Элемент репликации представляет собой запись в таблице, любые изменения которой передаются на резервные сервера. Также передаются и контекстные изменения, а именно соединения и транзакции, в которых происходит изменение записи. Таким образом, основными событиями репликации являются:

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

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

В процессе работы репликации возможны конфликты. Конфликтом считается обнаруженное несоответствие между данными на основном и резервном серверах. Примерами конфликтов являются:

наличие строки в реплике при попытке ее вставки;
отсутствие строки в реплике при ее изменении или удалении;
наличие транзакции при попытке её запуска;
отсутствие транзакции при её завершении.

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

12.2. Режимы репликации

Существует два основных режима работы репликации: синхронный и асинхронный. В первом случае при наступлении события репликации в мастер-базе, оно должно быть также выполнено на всех слейв-базах для того, чтобы событие считалось завершенным. Логически это означает, что существует лишь одна версия данных. Основной недостаток синхронной репликации – она создаёт дополнительную задержку в работе мастера, т.к. СУБД должна дождаться ответа от реплики, чтобы считать операцию завершенной.

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

Рассмотрим подробнее принципы работы и особенности разных режимов репликации.

Синхронная репликация

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

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

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

Асинхронная репликация

Асинхронная репликация также использует буферизацию событий репликации, но не посылает содержимое буфера на слейв, а пишет его в журнал репликации. Он представляет собой набор бинарных файлов (сегментов журнала) фиксированного размера, хранящихся в директории, заданной в конфигурации репликации. СУБД сбрасывает буферы с событиями репликации в текущий (активный) сегмент до тех пор, пока он не будет заполнен. После этого отдельный поток выполняет архивацию сегмента с помощью внешней команды. По окончании архивации сегмент считается свободным и может снова использоваться для записи событий репликации.

В данной модели существует четыре возможных состояния сегментов журнала:

USED – сегмент в данный момент используется. В конкретный момент времени он единственный. Когда сегмент достигает заданного размера, он считается заполненным и запись в него прекращается. То же самое происходит при простое сегмента в течении минуты.
FULL – сегмент заполнен и ждет архивации. Ей занимается отдельный поток, который оповещается с помощью семафора. Также возможна ручная архивация с помощью утилиты rdblogmgr.
ARCH – сегмент в процессе архивации.
FREE – помечается после архивации, как возможный к использованию. Как только сегмент USED переходит в состояние FULL, ищутся сегменты в состоянии FREE, чтобы использовать их снова. Если такие не найдены, создается новый.

Cегменты журнала могут быть применены вручную утилитой rdblogmgr.

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

Сегменты регулярно ротируются. Этот процесс контролируется либо максимальным размером сегмента, либо таймаутом, оба порога настраиваются. Как только активный сегмент достигает порогового значения, он помечается как «полный», и запись переключается на следующий доступный сегмент. Полные сегменты архивируются и затем повторно используются для последующих записей. Архивирование в основном означает копирование сегмента с целью передачи его на хост реплики и применения там. Копирование может быть выполнено самим сервером РЕД Базы Данных или, альтернативно, указанной пользователем командой.

Со стороны реплики сегменты журнала применяются в порядке последовательности репликации. Сервер РЕД Базы Данных периодически сканирует новые сегменты, появляющиеся в настроенном каталоге. Как только следующий сегмент найден, он реплицируется. Состояние репликации хранится в локальном файле с именем {UUID} (для каждого источника репликации) и содержит следующие маркеры: последняя последовательность сегментов (LSS), самая старая последовательность сегментов (OSS) и список активных транзакций, запущенных между OSS и LSS. LSS означает последний реплицированный сегмент. OSS означает сегмент, который начал самую раннюю транзакцию, которая не была завершена во время обработки LSS. Эти маркеры управляют двумя вещами: какой сегмент должен быть реплицирован следующим и когда файлы сегмента можно безопасно удалить. Сегменты с номерами между OSS и LSS сохраняются для воспроизведения журнала после отключения репликатора от базы данных реплики (например, из-за ошибки репликации или времени простоя). Если нет ожидающих активных транзакций и LSS был обработан без ошибок, все сегменты включая LSS удаляются. В случае любой критической ошибки репликация временно приостанавливается и повторяется после истечения времени ожидания.

Применение журнала к реплике выполняется сервером репликации. В случае Суперсервера или Суперклассика, это отдельный поток в запущенной СУБД. Он читает архивные сегменты из указанного каталога и применяет их к БД. Если в системе установлен и работает классик, то сервер репликации запускается отдельным процессом суперклассика с ключом -R.

Адаптивная репликация

Примечание

Адаптивная репликация доступна только в промышленной редакции. Подробнее различия функционала редакций описаны в разделе Редакции СУБД РЕД База Данных 5.0.

Адаптивная репликация объединяет в себе два описанных выше режима. Основным преимуществом этого режима является то, что мастер-база остаётся доступной на протяжении всего процесса репликации.

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

Примечание

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

Для возобновления синхронной репликации необходимо, чтобы данные на слейве были актуальны. Проверка актуальности данных производится при попытке отправить синхронный репликационный пакет. Если разрыв между мастером и слейвом достигает количества журналов, которое меньше или равно backoff_lag, то плагин репликации запустит механизм восстановления синхронизации. Плагин репликации будет замедлять процесс коммита в мастере на initial_backoff_delay миллисекунд. Если журналы применились, но данные на слейве всё ещё не актуальны, то задержка будет увеличена в backoff_factor раз. Так с каждой попыткой синхронизации время задержки будет расти в backoff_factor раз до достижения max_backoff_delay. Задержка будет выполняться, пока данные на слейве не станут актуальными. или пока разница в журналах между мастером и репликой не превысит backoff_lag.

12.3. Отчет об ошибках

Все ошибки и предупреждения репликации (например, обнаруженные конфликты) записываются в файл replication.log, хранящийся в корневом каталоге установки РЕД Базы Данных. Этот файл также может содержать подробное описание операций, выполняемых репликатором.

12.4. Настройка системы репликации

Файл конфигурации

Для настройки системы репликации используется файл replication.conf, находящийся в корневом каталоге СУБД. Файл настраивается как на стороне мастер сервера, так и на стороне слейва. Все параметры настройки содержатся в блоке database{ ... }, и по умолчанию закомментированы. Настройки можно проводить глобально сразу для всех баз данных и отдельно для каждой базы данных.

Примечание

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

database = /your/db.fdb
{ ... }

Первое слово в строке внутри блока, начинающейся не с символа комментария, считается названием параметра. Справа от имени параметра, после символа равенства, указывается значение параметра.

Параметры настройки на мастере

plugin

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

plugin =

buffer_size

Указывает размер буфера операций на мастер-базе, при достижении которого он будет отправлен на слейв-базы или записан в журнал. Этот параметр не влияет на такие операции, как commit или rollback; при выполнении этих операций буфер отправляется немедленно и ожидается подтверждение от всех удачного исполнения.

buffer_size = 1048576 # 1MB

include_filter

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

include_filter = (W$|ORD$)%

exclude_filter

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

exclude_filter = (TEMP$|LOG$)%|(SYS_DB_LOG)

exclude_without_pk

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

exclude_without_pk = true

log_errors

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

log_errors = true

report_errors

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

report_errors = false

disable_on_error

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

disable_on_error = false

journal_directory (только для асинхронного режима)

Задание этого параметра включает асинхронную репликацию и говорит серверу начать создавать сегменты журнала. Данный параметр указывает на каталог для хранения файлов журнала репликации.

journal_directory = /your/db/chlog

journal_file_prefix (только для асинхронного режима)

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

journal_file_prefix = warehouse_log

journal_segment_size (только для асинхронного режима)

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

journal_segment_size = 16777216 # 16MB

journal_segment_count (только для асинхронного режима)

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

journal_segment_count = 8

journal_group_flush_delay (только для асинхронного режима)

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

journal_group_flush_delay = 30

journal_archive_directory (только для асинхронного режима)

Данный параметр определяет директорию, куда будут архивироваться сегменты журнала. Для этого значения определена переменная $(archivepathname) (см. ниже).

journal_archive_directory = /temp/archive_logs

journal_archive_command (только для асинхронного режима)

Программа, которая выполняется, когда некоторый сегмент репликации становится полным и нуждается в архивировании. Архивирование выполняется путем копирования сегментов из journal_directory в journal_archive_directory. Сервер РЕД Базы Данных сам копирует эти сегменты. Можно задать команду архивирования самостоятельно. Эта программа должна возвращать ноль, только если архивирование успешно выполнено. Например, должен вернуться не ноль, если целевой архив уже существует.

Доступны специальные предопределенные переменные:

$ (filename) - имя файла (без пути) сегмента, который нужно заархивировать;
$ (pathname) - полный путь к файлу сегмента, который нужно заархивировать.

Равен journal_directory + $(filename);
$ (archivepathname) - полный путь к файлу заархивированного сегмента.

Равен journal_archive_directory + $(filename).

journal_archive_command = "test ! -f $(archivepathname) && cp $(pathname)
$(archivepathname)"

journal_archive_command = "copy $(pathname) $(archivepathname)"

Пользовательское архивирование позволяет использовать любую shell команду (включая скрипты / пакетные файлы) для доставки сегментов на сторону реплики. Она может использовать сжатие, FTP или что-либо еще доступное на сервере. Реальная реализация доставки зависит от администратора баз данных, РЕД База Данных просто создает сегменты на стороне ведущей базы и ожидает, что они появятся на стороне реплики.

journal_archive_timeout (только для асинхронного режима)

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

Это позволяет минимизировать разрыв репликации, если база данных редко изменяется. Значение 0 означает отсутствие промежуточного архивирования, т.е. сегменты архивируются только после достижения их максимального размера (определяется journal_segment_size).

Используется только для асинхронного режима. По умолчанию значение параметра равно 60.

journal_archive_timeout = 60

sync_replica (только для синхронного режима)

Задание этого параметра включает синхронную репликацию. Он указывает на базу данных реплики.

Значение параметра можно указывать в двух форматах. В первом варианте значение указывается одной строкой и есть ограничение на использование символа @ в имени пользователя и пароле:

sync_replica = [<пользователь>:<пароль>@]<адрес сервера>:<путь к БД>

Во втором варианте sync_replica определяется в виде подсекции:

sync_replica = <адрес сервера>:<путь к БД>
{
   username[_env | _file] = {<имя пользователя> | <переменная окружения> | <путь к файлу>}
   password[_env | _file] = {<пароль> | <переменная окружения> | <путь к файлу>}
}

При использовании суффикса _env значение будет взято из заданной переменной окружения.

Если РЕД База Данных запущена как сервис, то передать переменные окружения нужно одним из следующих способов:

Задать переменную окружения в файле сервиса:
1. Укажите переменную окружения в секции [Service] файла firebird.service в формате: Environment=<переменная окружения>=<значение>.
2. Примените изменения в настройках службы командой systemctl daemon-reload.
3. Перезапустите сервис командой systemctl restart firebird.
Предупреждение

После обновления СУБД настройки вернутся к значениям по умолчанию.
Задать переменную окружения в отдельном файле:
1. Создайте файл /etc/systemd/system/firebird.service.d/override.conf.
2. Укажите переменную окружения в секции [Service] в формате: Environment=<переменная окружения>=<значение>.
3. Примените изменения в настройках службы командой systemctl daemon-reload.
4. Перезапустите сервис командой systemctl restart firebird.
Задать путь к файлу с переменными окружения в файле сервиса:
1. В секции [Service] файла firebird.service определите путь к файлу, из которого необходимо читать переменные окружения, указав EnvironmentFile=<путь к файлу>.
2. В указанном файле задайте переменные окружения в формате <переменная окружения>=<значение>.
3. Примените изменения в настройках службы командой systemctl daemon-reload.
4. Перезапустите сервис командой systemctl restart firebird.

При использовании суффикса _file значение будет взято из первой строки определённого файла. Можно указывать как абсолютный, так и относительный путь (относительно корневого каталога инсталляции РЕД Базы Данных). Если такого файла не существует, либо файл пустой, то в лог будут записаны следующие ошибки:

"<replica> specifies missing file: <...>/replicaton_pass" -- файл не найден
"<replica> specifies empty file: <...>/replication_pass" -- файл пустой

В архитектурах SuperServer и SuperClassic подключение к базе данных реплики происходит при первом соединении пользователя с мастером. А отключение происходит, когда последний пользователь отсоединяется от базы данных мастера.

В архитектуре Classic каждый серверный процесс сохраняет свое собственное активное соединение с базой данных реплики.

sync_reconnect_timeout (только для синхронного режима)

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

По умолчанию имеет значение 60.

sync_reconnect_timeout = 60

auto_resync (только для адаптивного режима)

Примечание

Только для промышленной редакции.

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

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

По умолчанию выключено (значение false).

auto_resync = false

backoff_lag (только для адаптивного режима)

Примечание