Асинхронная репликация
Асинхронная репликация позволяет синхронизировать данные между базами данных YDB почти в реальном времени. Также она может быть использована для миграции данных между базами данных с минимальным простоем работающих с ними приложений. Базы данных могут располагаться как в одном кластере YDB, так и на разных.
Принцип работы
Асинхронная репликация реализована поверх Change Data Capture и оперирует логическими данными. Схема процесса репликации:
Как следует из схемы выше, в асинхронной репликации участвуют две базы:
- Источник — база данных с исходными объектами.
- Приёмник — база данных, в которой будут созданы экземпляр асинхронной репликации и объекты-реплики.
Процесс асинхронной репликации состоит из следующих стадий:
Инициализация
Инициализация асинхронной репликации состоит из:
- Создания экземпляра асинхронной репликации в приемнике с помощью выражения CREATE ASYNC REPLICATION.
- Установки соединения с источником. Для соединения с источником приемник использует параметры подключения, указанные при создании экземпляра асинхронной репликации.
Примечание
Пользователь, от имени которого производится подключение к источнику, должен обладать следующими правами:
- просмотр объектов схемы и содержимого каталогов;
- создание, изменение, удаление и чтение потоков изменений.
- Для заданного набора исходных объектов автоматически создаются:
- потоки изменений (в источнике);
- объекты-реплики (в приемнике).
Примечание
Объекты-реплики создаются от имени пользователя, создавшего экземпляр асинхронной репликации.
Репликация первоначальных данных
Первоначальные данные исходных таблиц отгружаются в потоки изменений с использованием первоначального сканирования. В это время в приемнике запускаются читатели, которые записывают прочитанные данные в объекты-реплики.
Прогресс первоначального сканирования можно получить из описания экземпляра асинхронной репликации.
Синхронизация с помощью резервного копирования и восстановления
При INITIAL_SCAN = FALSE первоначальные данные переносятся серверными операциями резервного копирования в S3 и восстановления из S3. Этот способ позволяет использовать механизм резервного копирования для переноса большого объёма данных.
Репликация создаётся в состоянии PAUSED и подготавливает потоки изменений без первоначального сканирования. После готовности всех потоков пользователь создаёт резервную копию исходных таблиц и восстанавливает их в приёмнике. Пока идёт перенос, изменения источника накапливаются в потоках. Целевые таблицы на этом этапе не подключены к репликации.
После завершения восстановления пользователь переводит репликацию в STANDBY с помощью ALTER ASYNC REPLICATION. Приёмник проверяет схемы восстановленных таблиц, подключает их как объекты-реплики и начинает применять накопленные изменения. Подключённые таблицы становятся доступны только для чтения.
Для полноты данных потоки изменений должны быть готовы до создания резервной копии, а накопленные записи должны оставаться доступными до подтверждения их обработки. Период доступности задаётся параметром AVAILABILITY_PERIOD. Пошаговая процедура и проверки приведены в руководстве по первоначальной синхронизации с помощью резервного копирования и восстановления.
Выбор способа первоначальной синхронизации
Оба способа требуют чтения исходных данных и записи в приёмник. Дополнительные затраты различаются:
| Затраты | Первоначальное сканирование | Резервное копирование и восстановление |
|---|---|---|
| Обработка данных | Каждая исходная строка сериализуется в CDC-сообщение, записывается в поток, читается и применяется в приёмнике | Данные выгружаются и загружаются серверными операциями; через CDC передаются только изменения |
| Временное хранение | Первоначальные данные и изменения хранятся в потоках с учётом периода доступности | Требуются согласованная копия таблиц в источнике и резервная копия в S3; в потоках хранятся изменения с учётом периода доступности |
| Передача по сети | Первоначальные данные передаются из потоков изменений источника в приёмник | Данные передаются из источника в S3, затем из S3 в приёмник; сжатие выгрузки позволяет уменьшить объём передачи |
| Настройка и эксплуатация | Синхронизация запускается автоматически при создании репликации | Требуются S3-хранилище, отдельные операции резервного копирования и восстановления, проверка их завершения и запуск репликации |
Первоначальное сканирование проще в настройке и подходит для небольших объёмов данных. Для больших объёмов резервное копирование и восстановление позволяют сократить затраты на обработку первоначальных данных через CDC, но требуют дополнительного хранения и операций с S3. Итоговые затраты и длительность зависят от объёма данных, интенсивности изменений, ресурсов кластеров, сжатия и условий использования S3.
Репликация изменений
После завершения первоначального сканирования читатели получают только данные об изменениях и записывают их в объекты-реплики.
Для каждого изменения известно время его возникновения (). В то же время читатели отслеживают время получения изменения (). Таким образом, отставание репликации может быть вычислено по формуле:
Отставание репликации также можно получить из описания экземпляра асинхронной репликации с параметром --stats. При остановке читателя, потере его сессии или отсутствии свежего отчёта в течение 60 секунд значение отставания становится недоступным. Отсутствие значения означает, что отставание неизвестно, а не равно нулю.
Хранение изменений в источнике
Параметр AVAILABILITY_PERIOD определяет, как долго потоки изменений сохраняют сообщения, обработку которых репликация ещё не подтвердила. Он задаётся при создании репликации и не может быть изменён с помощью ALTER ASYNC REPLICATION.
По умолчанию используется значение 'UNLIMITED': неподтверждённые сообщения сохраняются до подтверждения их обработки. Для ограничения периода доступности укажите положительный интервал, например Interval('PT48H').
При любом выбранном периоде доступности сообщения в топике удаляются практически сразу после подтверждения их обработки читателем, чтобы освобождать место в источнике и сокращать затраты на хранение уже обработанных изменений. Параметр AVAILABILITY_PERIOD защищает от удаления только неподтверждённые сообщения.
| Условие | Без ограничения: 'UNLIMITED' |
Конечный период: например, Interval('PT48H') |
|---|---|---|
| Длительная остановка или отставание | Неподтверждённые сообщения сохраняются независимо от их возраста | По истечении заданного периода неподтверждённые сообщения могут быть удалены |
| Расход места в источнике | Объём накопленных сообщений может расти всё время, пока репликация не подтверждает обработку | Возраст удерживаемых для репликации сообщений ограничен заданным периодом |
| Первоначальный перенос через резервную копию | Нет ограничения по возрасту накопленных изменений; необходимо обеспечить место для их хранения | Экспорт, импорт и обработка накопленных изменений должны укладываться в выбранный период |
| Что контролировать | Свободное место в источнике и отставание репликации | Отставание репликации и запас времени до истечения периода доступности |
Период доступности относится к возрасту сообщений, а не к длительности текущего простоя. Состояние PAUSED не останавливает отсчёт этого периода. Если нужные сообщения уже удалены, для восстановления полноты данных потребуется повторная первоначальная синхронизация.
При 'UNLIMITED' используется важный читатель, а при конечном периоде — читатель с заданным временем доступности сообщений. Благодаря этому неподтверждённые сообщения могут храниться дольше времени хранения сообщений в топике.
Ограничения
-
Набор исходных объектов задается при создании экземпляра асинхронной репликации и не может быть изменен.
-
В качестве исходных объектов поддерживаются:
- строковые таблицы, в том числе с синхронными вторичными индексами, включая уникальные (кроме векторных);
- директории — будут реплицироваться все строковые таблицы, содержащиеся в них (включая содержимое поддиректорий) на момент создания экземпляра асинхронной репликации.
-
Во время работы асинхронной репликации в исходных таблицах блокируется возможность изменения состава столбцов.
-
Во время работы асинхронной репликации объекты-реплики доступны только для чтения.
Обработка ошибок в процессе асинхронной репликации
В процессе асинхронной репликации возможно возникновение разных классов ошибок:
- Временные сбои. Например, транспортные ошибки, перегрузка системы и т.д. Запросы будут повторяться до успешного выполнения.
- Критичные ошибки. Например, ошибки прав доступа, ошибки схемы и т.д. Процесс репликации будет остановлен, и в описании экземпляра репликации будет указан текст ошибки.
Важно
Подробнее про классы ошибок и политики их обработки см. в разделе Обработка ошибок.
Уровни согласованности реплицируемых данных
Согласованность данных уровня строк
Механизм Change Data Capture, используемый для асинхронной репликации, гарантирует, что изменения по одному и тому же первичному ключу доставляются в том же порядке, в котором они происходили в источнике. Таким образом обеспечивается согласованность данных уровня строк.
Данные, записанные в объекты-реплики в этом режиме, сразу становятся доступными для чтения.
Глобальная согласованность данных
При выполнении транзакций в источнике могут быть атомарно изменены несколько строк таблицы или, более того, строки в разных партициях таблиц(ы). Глобальная согласованность данных в приемнике подразумевает сохранение свойства атомарности — изменения "проявляются" (становятся доступными для чтения) согласованно.
Для обеспечения глобальной согласованности данных необходимо создавать потоки изменений с включенными барьерами. Между барьерами данные буферизируются непосредственно на партициях объектов-реплик. При получении очередной порции барьеров от всех топиков записанные изменения фиксируются и становятся доступными для чтения. При этом данные в приемнике оказываются согласованными на момент времени, указанном в барьере. Если считать, что в источнике барьеры создаются каждые 10 секунд (значение по умолчанию), то в нормальном режиме приемник коммитит и публикует набор изменений от источника также каждые 10 секунд.
Периодичность фиксации изменений
По умолчанию изменения фиксируются (коммитятся) не чаще, чем раз в 10 секунд. Периодичность фиксации изменений можно переопределить, указав опцию COMMIT_INTERVAL при создании экземпляра асинхронной репликации.
Примечание
Периодичность фиксации изменений напрямую влияет на периодичность выгрузки барьеров в потоки изменений — значения параметров синхронизированы. Таким образом, обычно, изменения фиксируются с той же частотой, с которой в потоках изменений появляются барьеры. Однако, в некоторых случаях, например, в случае неравномерной нагрузки между таблицами, барьеры в потоках изменений могут появляться с существенной разницей во времени, что приведёт к увеличению периодичности фиксации изменений. Отставание можно получить из описания экземпляра асинхронной репликации.
Завершение асинхронной репликации
Завершение асинхронной репликации может быть конечной целью процедуры миграции данных из одной базы данных в другую. В таком случае клиент останавливает пишущую нагрузку в источнике, дожидается нулевого отставания репликации и завершает её. При завершении объекты-реплики становятся доступными как для чтения, так и для записи. После этого можно переключить нагрузку с источника на приемник и завершить процедуру миграции.
Перед завершением получите актуальное значение отставания с помощью scheme describe --stats. Если значение недоступно, дождитесь возобновления отчётов: отсутствие значения или ранее показанный ноль не подтверждают, что все изменения перенесены.
Примечание
Завершённый процесс асинхронной репликации не может быть возобновлён.
Важно
На данный момент поддерживается только принудительное завершение асинхронной репликации, при котором не производится никаких дополнительных проверок (на согласованность данных, на отставание и т.д.).
Для завершения асинхронной репликации используйте выражение ALTER ASYNC REPLICATION.
Удаление асинхронной репликации
При удалении асинхронной репликации:
- В исходных таблицах удаляются потоки изменений.
- В исходных таблицах разблокируется возможность изменения состава столбцов.
- Опционально могут быть удалены все объекты-реплики.
- Удаляется экземпляр асинхронной репликации.
Важно
Если удалить асинхронную репликацию без предварительного завершения и не удалять объекты-реплики, то они останутся доступными только для чтения.
Для удаления асинхронной репликации используйте выражение DROP ASYNC REPLICATION.