Репликация данных в различных СУБД
Для того, чтобы обеспечить сохранность баз данных, необходимо, чтобы на другой локации находилась копия, которая синхронизируется с основной. В различных системах управления БД, таких как MySQL, Microsoft SQL Server, PostgreSQL, Oracle – технология называется по-разному.
Термин «репликация» пришёл в ИТ из генетики. С биологической точки зрения обозначает процесс удвоения ДНК — необходимый момент при делении клетки.
Тем не менее, репликация ДНК имеет лишь отдалённое сходство с репликацией БД. Репликация БД — механизм синхронизации нескольких баз данных. В первую очередь, технологию используют на возможный случай возникновения аварийной ситуации – чтобы исключить или минимизировать потери данных и обеспечить непрерывность работы бизнес-критичных сервисов. Во-вторых, в реплику возможно направить ресурсоёмкие отчёты, что снимает нагрузку с основной базы.
Репликация vs Резервная копия
Технологии отличаются временем готовности к запуску и стратегией применения.
Предположим, произошла авария, для развёртывания резервной копии требуется время. Для больших баз, например, крупной торговой сети – это может занять несколько дней. Из-за простоя бизнес несёт финансовые и репутационные потери.
В той же ситуации переключение с основной базы на реплику займёт 1-3 минуты. Приложение продолжает работать, простой и потеря данных – минимальные.
Наиболее грамотный вариант – использование двух технологий в тандеме. Репликацию – для обеспечения непрерывности работы приложения в случае аварии, бэкап – для сохранения целостности и доступности данных, если они повредились из-за поломки дисков, на которых они хранятся, атаки вируса-шифровальщика или других непредвиденных ситуаций.
Технология репликации бывает:
– синхронной
– асинхронной
Рассмотрим разницу между 2 типами.
Синхронная репликация
Это процесс дублирования данных в реальном времени через сеть – локальную или глобальную – таким образом, чтобы существовало несколько актуальных копий.
Это возможно благодаря алгоритму работы технологии – запись делается одновременно в разные локации. Операция не завершится, пока данные не будут записаны и сохранены на другие копии. При этом оборудование, серверы, хранилища на точках также полностью идентичны для того, чтобы при переходе реплика могла справиться с той же нагрузкой, что и основная база.
Преимущества
– Данные в копиях идентичны
– Высокая доступность. В случае отказа основной базы данных, переключение на реплику происходит достаточно быстро (в пределах минуты), поскольку реплики продолжают работу и содержат актуальные данные
Недостатки
– Замедляется работа основного приложения, так как возникает задержка при передаче данных на резервный сервер
– Не предназначена для работы на больших расстояниях из-за увеличения времени отклика в канале связи
– Значительно дороже других форм репликации
Где используется
В большинстве случаев синхронная репликация используется, когда требования бизнеса не допускают любой потери данных – кассы, банки, e-commerce и т.д.
Асинхронная репликация
Продукты, использующие асинхронную репликацию, дублируют данные в реплику после того, как они записаны в основное хранилище, поэтому копия всегда отстаёт от основной БД.
Преимущества
– Расстояние: асинхронная репликация предназначена для работы на больших расстояниях.
– Устойчивость: асинхронная репликация переносит некоторые ухудшения связи, поскольку процесс не происходит в режиме реального времени.
– Цена: стоимость асинхронной репликация, как правило, гораздо ниже, чем синхронной, так как не требует такой большой пропускной способности и скорости в канале.
Недостатки
– Временная задержка между хранением на основной и удаленной локациях.
– Риски
В случае аварии или сбоя, данные, которые не были скопированы, будут потеряны, а данные во вторичном хранилище будут отставать от основной БД на то количество, которое не было передано.
Когда используется асинхронная репликация
– Когда внедрение синхронной технологии невозможно ввиду большой задержки в канале, которая усиливается пропорционально увеличению длины канала и его загруженности.
– Когда требования бизнеса позволяют потерять некоторое количество данных.
– При работе с базами данных, когда в случае сбоя на основном сервере, на развёртывание резервной копии требуется время, превышающее допустимое для бизнеса.
– Когда стоимость синхронной репликации превышает потери от простоя.
Этапы внедрения технологий репликации
- Выбор архитектуры решения. Определить, какие блоки будут подлежать репликации, какую роль выполнять, геолокацию. Назначить наблюдателя за кластером, с которого будут выполняться реплики.
- Расчет чистой приведенной стоимости (Net Present Value, NPV). Выбор наиболее быстрого варианта решения. Сбор предположительно самого долгого варианта. Тестовый стенд – проверка одного из элементов технологии или всего продукта в уменьшенном масштабе
- Запуск тестовой среды – копия основной базы, проверка времени задержки, генерация нагрузки и т.д.
- Запуск технологии. Постоянное наблюдение за основным кластером.
На что обратить внимание при выборе?
На сегодняшний день, технология репликации баз данных распространена повсеместно. С точки зрения бизнеса, в случае аварии зачастую необходимо работать без простоев и минимизировать риск потери данных.
Важно учитывать следующие параметры:
– Задержка в канале (растёт с увеличением длины канала и его загруженности)
Ключевой аспект. Внедрить технологию синхронной репликации без ощутимых задержек технически затруднительно на канале протяженностью более 100 км.
– Требования бизнеса, определение конкретной цели – ответ на вопросы: какова максимальная длительность простоя критически важных приложений? Какое количество данных может потерять бизнес? Какова стоимость простоя и потерь?
– Исходя из второго пункта – стоимость технологии. Для бизнеса бессмысленно внедрять ту или иную форму репликации, если стоимость её обслуживания превышает прогнозируемые потери.
Чтобы обеспечить непрерывную работу бизнес-приложений и минимизировать риски потерь данных, всё больше компаний обращаются к сервисной модели. Поставщик услуг учитывает все перечисленные критерии и подбирает оптимальное решение для резервирования инфраструктуры. Чтобы получить индивидуальный расчет — просто напишите нам.
“Опытным путем выявили – резервная копия применяется при возможности простоя более 4 часов. От 1 часа до 4 – репликация. Менее 1 часа – кластеризация, асинхронная технология, и при высоких требованиях к непрерывности — синхронная.
Если мы видим, что у компании высокопроизводительное приложение, которое не терпит простоя и не может допустить потери ни одной транзакции – например, банки, операционные, e-commerce – мы внедряем синхронную репликацию”– Черепанов Игорь Георгиевич, руководитель отдела проектов Cortel.