Что такое репликация базы данных?
Репликация БД – это процесс синхронизации данных в режиме реального времени между несколькими серверами БД. Репликация позволяет распределить нагрузку на серверы, обеспечить отказоустойчивость и повысить доступность данных.
Для чего нужна репликация?
Основная цель репликации БД — обеспечить согласованность (консистентность) данных между репликами (серверами БД). В процессе репликации все изменения, вносимые в основную БД (мастер), автоматически передаются на реплики. Для примера возьмём БД 1С, развёрнутую на Postgres Pro для 1С. В большинстве случаев, инсталляция сервера 1С представляет из себя один физический сервер, на котором разворачивается как сам сервер приложений 1С, так и СУБД. В случае выхода из строя такого сервера или дискового массива, данные будут утеряны. В случае когда настроена репликация, все данные гарантированно сохранятся.
Как работает репликация?
Репликация может быть организована с помощью репликационных логов, триггеров или других механизмов. Когда данные изменяются на мастере, эти изменения реплицируются на реплики, чтобы они оставались согласованными.
Режимы репликации БД могут быть различными. В режиме мастер-мастер изменения могут быть внесены как на мастере, так и на реплике, и они будут синхронизированы между собой. В режиме мастер-реплика изменения вносятся только на мастере и реплицируются на реплики. В каскадной репликации изменения передаются по цепочке от одной реплики к другой. Наиболее часто используемым режимом является мастер-реплика, основной задачей которого является сохранность и актуальность данных БД. В рассмотренном выше примере используется именно такой режим.
Чем репликация отличается от резервной корпии (бекапа)?
Репликация БД имеет ряд преимуществ по отношению к резервным копиям. Она позволяет увеличить производительность системы, так как запросы могут быть распределены между несколькими серверами. Это особенно полезно в случае большой нагрузки на БД. Репликация также обеспечивает отказоустойчивость, так как при сбое одного сервера данные остаются доступными на других серверах. Кроме того, репликация позволяет проводить обслуживание и обновления БД, а так-же съём резервных копий без прерывания работы системы, что невозможно в случае использования классического резервного копирования.
В то-же время, репликация БД имеет некоторые ограничения и сложности. К примеру, синхронизация данных между мастером и репликами в некоторых СУБД может занимать некоторое время, что может привести к небольшой задержке в доступе к данным на репликах, впрочем, это утверждение касается не всех СУБД и не всех режимов работы. Кроме того, при наличии нескольких реплик возникает проблема конфликтов изменений, которые могут возникнуть, если данные изменяются одновременно на разных серверах.
Однако основным отличием репликации от классического резервного копирования являются индексы RTO и RPO.
Что такое RPO и RTO?
Показатель точки восстановления (RPO — Recovery Point Objective) и показатель времени восстановления (RTO — Recovery Time Objective) — это два важных показателя, используемых для определения требований к резервному копированию и восстановлению данных.
RPO определяет максимальный допустимый промежуток времени между моментом последней резервной копии данных и моментом сбоя системы. Другими словами, RPO указывает, насколько старые могут быть восстановленные данные. Например, если RPO составляет 1 час, то после сбоя системы можно восстановить данные, которые были сохранены не позднее, чем за 1 час до сбоя. В случае использования классического резервного копирования, данный индекс может составлять как дни, так и недели (или месяцы). Таким образом, в случае сбоя в работе БД, данные получиться восстановить на момент последней резервной копии. В случае работающей репликации, этот индекс будет составлять секунды, в редких случаях – минуты. Однако это зависит как от СУБД, так и от режима и настроек её работы. Как показывает практика, в случае правильной конфигурации репликации, индекс RPO равняется нулю.
RTO определяет максимальное время, необходимое для восстановления системы после сбоя. Он указывает на период времени, в течение которого система должна быть недоступна. Например, если RTO составляет 4 часа, то система должна быть полностью восстановлена и функционировать в течение 4 часов после сбоя. Как и в случае с RPO, рассмотрим данный индекс сперва для классического резервного копирования.
Если по неким причинам, сервер БД перестал работать, сперва необходимо его восстановить, что занимает определённое время, как правило от нескольких часов, до нескольких дней и только потом восстановить резервную копию, что тоже занимает определённое время. Таким образом, при использовании классического резервного копирования, восстановление работы системы может занять до нескольких дней, а в случае выхода из строя физического сервера, возможно и дольше.
Теперь рассмотрим аналогичную аварию в условиях использования репликации. Так как данные БД реплики актуальны на момент сбоя, всё что нужно – это переключить реплику в режим мастера и изменить настройки приложения использующего данную БД. Впрочем, если инфраструктура настроена правильно и приложение использует для доступа к БД DNS-имя сервера БД, то такие изменения вносятся только в пределах DNS-сервера. Таким образом, для восстановления работы приложения понадобится от силы несколько минут. В рассмотренном выше примере с 1С сервером, индекс RTO как правило составляет 10-15 минут.
Рассмотрев оба метода организации сохранности данных, очевидно преимущество репликации перед обычными резервными копиями, что к слову, не отменяет последнего. В системах с репликацией БД, резервные копии всегда снимаются с реплики а не с мастера, так как процесс резервного копирования БД, зачастую требует монопольного режима использования БД, блокировок транзакций и в итоге необходимости остановки приложения.
Так-же важно отметить, что RPO и RTO должны быть определены на основе требований бизнеса и уровня критичности данных. Критические системы и данные могут требовать более низких значений RPO и RTO, чтобы минимизировать потери данных и время простоя системы. Некритические системы могут иметь более высокие значения RPO и RTO.
Как правильно организовать репликацию?
В зависимости от приложения, его организации и требований к нему, способы организации могут быть разными. Реплик может быть несколько, как с дополнительными резервными копиями, так и без них, однако есть очевидные аспекты, так или иначе влияющие на безопасность и функциональность в любом из сценариев.
– Размещение реплики. Размещать основную БД (мастер) и её реплику в пределах одной площадки (стойки) не всегда хорошо. В пользу такого подхода говорит стабильная сетевая связность, чего требуют некоторые СУБД, однако в случае непредвиденных ситуаций, вызванных факторами непреодолимой силы, есть все шансы потерять как мастер, так и реплику. Поэтому зачастую, реплики распределены географически. В вышеприведенном примере, с сервером 1С, допускается репликация БД даже через сеть Интернет, с распределением как по разным городам, так и разным странам. Такие услуги часто оказывают аутсорсинговые компании, как в режиме SaaS, так и в режиме PaaS. Впрочем, такая форма как SaaS, требует гораздо меньших вложений, что положительно влияет на стоимость владения системой.
– Выбор СУБД. Не все СУБД позволяют организовать репликацию, соответствующую требованиям Заказчика. Поэтому перед тем как разворачивать систему или её последующее резервирование, стоит проконсультироваться с профессионалами в данной сфере.
– Конфигурация СУБД. Если сервер БД и/или его реплика настроены неправильно, то возможны случаи низкой производительности БД или неконсистентности данных. К сожалению, не всегда получается настроить репликацию с первого раза и навсегда. На корректность работы влияет масса факторов, таких как постоянная пиковая и усреднённая нагрузка, стабильность и пропускная способность сетевого канала между серверами и пр. Все эти случаи требуют круглосуточного мониторинга всех серверов БД.