Выйти из системы

Сменить пользователя

Репликация данных в различных СУБД

Для того, чтобы обеспечить сохранность баз данных, необходимо, чтобы на другой локации находилась копия, которая синхронизируется с основной. В различных системах управления БД, таких как MySQL, Microsoft SQL Server, PostgreSQL, Oracle – технология называется по-разному.

Термин «репликация» пришёл в ИТ из генетики. С биологической точки зрения обозначает процесс удвоения ДНК — необходимый момент при делении клетки.

Тем не менее, репликация ДНК имеет лишь отдалённое сходство с репликацией БД. Репликация БД — механизм синхронизации нескольких баз данных. В первую очередь, технологию используют на возможный случай возникновения аварийной ситуации – чтобы исключить или минимизировать потери данных и обеспечить непрерывность работы бизнес-критичных сервисов. Во-вторых, в реплику возможно направить ресурсоёмкие отчёты, что снимает нагрузку с основной базы.

Репликация vs Резервная копия

Технологии отличаются временем готовности к запуску и стратегией применения.

Предположим, произошла авария, для развёртывания резервной копии требуется время. Для больших баз, например, крупной торговой сети – это может занять несколько дней. Из-за простоя бизнес несёт финансовые и репутационные потери.

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

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

Технология репликации бывает:

– синхронной

– асинхронной

Рассмотрим разницу между 2 типами.

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

Механизм синхронной репликации

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

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

Преимущества

– Данные в копиях идентичны

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

Недостатки

– Замедляется работа основного приложения, так как возникает задержка при передаче данных на резервный сервер

– Не предназначена для работы на больших расстояниях из-за увеличения времени отклика в канале связи

– Значительно дороже других форм репликации

Где используется

В большинстве случаев синхронная репликация используется, когда требования бизнеса не допускают любой потери данных – кассы, банки, e-commerce и т.д.

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

Синхронная и асинхронная репликация баз данных – на что обратить внимание?, изображение №2

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

Преимущества

– Расстояние: асинхронная репликация предназначена для работы на больших расстояниях.

– Устойчивость: асинхронная репликация переносит некоторые ухудшения связи, поскольку процесс не происходит в режиме реального времени.

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

Недостатки

– Временная задержка между хранением на основной и удаленной локациях.

– Риски
В случае аварии или сбоя, данные, которые не были скопированы, будут потеряны, а данные во вторичном хранилище будут отставать от основной БД на то количество, которое не было передано.

Когда используется асинхронная репликация

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

– Когда требования бизнеса позволяют потерять некоторое количество данных.

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

– Когда стоимость синхронной репликации превышает потери от простоя.

Этапы внедрения технологий репликации

  1. Выбор архитектуры решения. Определить, какие блоки будут подлежать репликации, какую роль выполнять, геолокацию. Назначить наблюдателя за кластером, с которого будут выполняться реплики.
  2. Расчет чистой приведенной стоимости (Net Present Value, NPV). Выбор наиболее быстрого варианта решения. Сбор предположительно самого долгого варианта. Тестовый стенд – проверка одного из элементов технологии или всего продукта в уменьшенном масштабе
  3. Запуск тестовой среды – копия основной базы, проверка времени задержки, генерация нагрузки и т.д.
  4. Запуск технологии. Постоянное наблюдение за основным кластером.

На что обратить внимание при выборе?

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

Важно учитывать следующие параметры:

– Задержка в канале (растёт с увеличением длины канала и его загруженности)

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

– Требования бизнеса, определение конкретной цели – ответ на вопросы: какова максимальная длительность простоя критически важных приложений? Какое количество данных может потерять бизнес? Какова стоимость простоя и потерь?

– Исходя из второго пункта – стоимость технологии. Для бизнеса бессмысленно внедрять ту или иную форму репликации, если стоимость её обслуживания превышает прогнозируемые потери.

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

“Опытным путем выявили – резервная копия применяется при возможности простоя более 4 часов. От 1 часа до 4 – репликация. Менее 1 часа – кластеризация, асинхронная технология, и при высоких требованиях к непрерывности — синхронная.
Если мы видим, что у компании высокопроизводительное приложение, которое не терпит простоя и не может допустить потери ни одной транзакции – например, банки, операционные, e-commerce – мы внедряем синхронную репликацию”

– Черепанов Игорь Георгиевич, руководитель отдела проектов Cortel.