Репликация баз данных

Репликация баз данных

Под репликацией баз данных понимается процесс синхронизации информации в нескольких копиях одной базы данных. При этом копии могут находиться на разных серверах.

При репликации база данных копируется на другую машину, но копия и оригинал работают одновременно. Фактически пользователи работают с двумя отдельными базами данных, внося в них новую информацию. В определенные моменты времени, в зависимости от типа технологии, данные синхронизируются между собой. Таким образом, получается создавать несколько независимых и актуальных копий одной БД.

Технология позволяет минимизировать или полностью исключить потерю информации. Если одна БД будет безвозвратно утеряна, ее можно восстановить из любой копии.

Как работает технология репликации

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

• Главная СУБД (Master Database) — это оригинал. Имеет доступ ко всей информации в соответствии со всеми уровнями запросов.
• Подчиненная СУБД (Slave Database) — копия или реплика главной СУБД. Ее функциональность может отличаться от оригинальной.

Взаимодействие между элементами происходит благодаря системе управления распределенными базами данных — DBMS. В зависимости от конфигурации и настройки процесс реплицирования будет осуществляться массово или отдельными узлами, в режиме реального времени или по расписанию.

Конкретный алгоритм функционирования и репликации СУБД будет зависеть от важности информации, ее количества, масштаба и доступных вычислительных мощностей.

Типы репликации данных

Технология репликации достаточно гибкая и может быть настроена под конкретную задачу. Основное разделение идет по трем принципам:

• Способ синхронизации данных.
• Способ передачи данных.
  
• Тип серверной архитектуры.
  

Первый подразумевает под собой алгоритм или правило, по которому данные синхронизируются между оригиналом и репликами. В SQL-сервере используются три основных типа:

• Транзакционная — любые изменения в оригинале фиксируются и доставляются в реплики. Обновление информации происходит практически моментально.
• Репликация моментальных снимков — данные обновляются периодически. В определенные моменты времени делается снимок базы данных, который накладывается на реплики. Это один из самых простых способов. Его большим преимуществом является периодичность, то есть он не несет постоянной нагрузки на систему.
  
• Слияние — является промежуточным вариантом между транзакционным способом и репликацией моментальных снимков. Метод отслеживает изменения, фиксирует и периодически передает их. Если за отслеживаемый период было внесено всего два изменения, то именно они будут переданы. Это намного быстрее и проще, чем обновлять всю таблицу.
  
• Одноранговая — изменения согласуются на уровне транзакций и передаются между несколькими копиями СУБД. Все процессы происходят практически в режиме реального времени. Возможно небольшое запаздывание.
  
• Двунаправленная — технология позволяет двум серверам обмениваться данными между собой.
  

По способу передачи данных выделяют:

• Асинхронную репликацию — после записи в оригинал информация дублируется в реплику. Такой механизм подразумевает, что копия всегда отстает от главной СУБД. Главное преимущество заключается в простоте развертывания и инертности к увеличению расстояния канала передачи данных.
• Синхронную репликацию — данные дублируются в реальном времени. Это позволяет иметь несколько актуальных копий, поэтому полная потеря данных практически невозможна. Способ требует высоких вычислительных мощностей, так как несет постоянную нагрузку на основное приложение.
  
• Полусинхронная репликация — компромисс между вышеописанными способами. Все изменения фиксируются локально. При этом изменения поступают на реплики, но не обновляют значения моментально.
  
• Физическая репликация — мастер передает на реплику журнальные записи. Реплика применяет их к своим файлам данных. Все процессы носят чисто «механический» характер. Поэтому это возможно только для одинаковых платформ, в которых есть двоичная совместимость.
  
• Логическая журнальная репликация — является более «умным» методом, чем физическое копирование. Кроме журнальных записей на реплику поступает информация высокого уровня. Она позволяет декодировать журнальную информацию для внесения изменений в целевые таблицы.
  

По типу серверной архитектуры бывают:

• Однолидерные — реплики считывают данные с одного сервера. Стандартная структура.
• Многолидерные — реплики считывают данные с нескольких серверов. Актуальна для рассредоточенной структуры.
  
• Без лидеров — любой сервер служит моделью для реплик. Максимально гибкая структура. Но могут возникнуть проблемы с синхронизацией данных.
  

Ключевые отличия репликации от резервного копирования

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

При репликации создается точная реплика виртуальной машины. Далее реплика поддерживается в актуальном состоянии с помощью синхронизации данных.

Если при работе с СУБД произошла авария, которая привела к полной потере данных, то возможны два исхода:

• При наличии резервной копии можно восстановить БД. При этом актуальность будет зависеть от того, как давно сделан бэкап. Также сам процесс развертывания может занять приличное время, которое зависит от масштабности.
• При репликации данных нужно лишь переключиться с главной БД на реплику. При этом реплика получает статус Master. Весь процесс занимает несколько минут.

Поэтому главным отличием между репликацией и бэкапом выступает время аварийного развертывания. Из других различий следует отметить:

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

Основными преимуществами бэкапа являются:

• Простота интеграции.
• Полная изоляция от угроз: вирусы, хакерские атаки и т.д.
  
• Низкая стоимость.
  

Главными достоинствами репликации баз данных выступают:

• Возможность быстрого аварийного восстановления.
• Для восстановления доступны максимально актуальные копии БД.

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

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

Как внедрить технологию репликации в свою базу данных

Внедрение репликации — это постепенный процесс, который требует большого внимания от исполнителя. Поэтому осуществлять интеграцию необходимо поэтапно:

• Определить архитектуру. Здесь важно определить, требуется ли реплицировать всю таблицу или нужны только отдельные блоки информации.
•  Определить период обновления. Как часто нужно обновлять данные в реплике.
  
• Выбрать метод репликации. Как данные будут обновляться: полностью, только измененными блоками и т.д.
  
• Выбор программного обеспечения для реализации репликации. Можно использовать средства, которые уже имеются у используемой БД.
  
• Тестовый запуск. Создание копии основной БД. При этом требуется оценить нагрузку, которую испытывает система, просчитать задержки и их влияние на работу основного клиента.
  
• Запуск технологии в работу. В первое время важно постоянно отслеживать качество данных, до момента полной уверенности в работоспособности алгоритма репликации.
  

Заключение

Репликация баз данных — это инструмент, который позволяет обеспечить сохранность информации и в аварийной ситуации быстро получить доступ к ней. Ее внедрение достаточно затратно, поэтому рекомендуется применение репликации там, где затраты от простоя намного выше, чем стоимость реализации технологии репликации.