Репликация
Поддержание копий базы данных на нескольких серверах: если основной сервер выйдет из строя, работу продолжит копия.
Репликация — непрерывное копирование данных с одного сервера базы данных на другие. Основной сервер принимает изменения, а реплики получают их и хранят такую же копию данных. Если основной сервер выйдет из строя, одну из реплик назначают основной, и система продолжает работать. Кроме того, на реплики можно направлять запросы на чтение и тем самым разгружать основной сервер.
Основная схема: ведущий и ведомые
Чаще всего используют схему с одним ведущим сервером (primary) и несколькими репликами. Все записи идут на ведущий, а он передает изменения репликам — обычно в виде журнала изменений, того же, который обеспечивает долговечность транзакций в ACID. Реплики применяют журнал и остаются точной копией ведущего.
Синхронная и асинхронная репликация
| Синхронная | Асинхронная | |
|---|---|---|
| Когда подтверждается запись | После того, как ее получила реплика | Сразу, реплика догоняет позже |
| Риск потери при аварии | Нет | Последние секунды изменений |
| Скорость записи | Ниже: ожидание реплики | Выше |
Для финансовых систем важные изменения подтверждают синхронно хотя бы на одной реплике, а остальные реплики обновляют асинхронно.
Задержка реплик
Асинхронная реплика отстает от ведущего — обычно на миллисекунды, под нагрузкой на секунды. Отсюда классическая ошибка: пользователь сохранил данные, приложение тут же прочитало их с реплики — и показало старую версию. Поэтому то, что пользователь только что изменил, читают с ведущего сервера, а с реплик берут отчеты и справочные данные.
Виды репликации
- Физическая — копируется все хранилище целиком, побайтно. Просто и надежно, реплика полностью совпадает с ведущим.
- Логическая — передаются изменения отдельных таблиц. Позволяет переносить часть данных, обновлять версию СУБД без простоя и передавать данные в другие системы. В PostgreSQL есть оба вида.
- Несколько ведущих (multi-master) — запись возможна на любой узел, но приходится разрешать конфликты одновременных изменений; используется реже.
Репликация — не резервная копия
Если кто-то по ошибке удалит таблицу, удаление мгновенно повторится на всех репликах. Поэтому помимо репликации нужны резервные копии с возможностью восстановления на нужный момент времени. Репликацию сочетают с шардингом для больших объемов, а переключение на реплику при аварии автоматизируют — от этого напрямую зависит, какое SLA по доступности система может обещать.