Что такое репликация базы данных?

IBM® Informix® Enterprise Replication — это асинхронный, основанный на журналах инструмент для репликации данных между серверами баз данных IBM Informix. Репликация предприятия на исходном сервере фиксирует транзакции, подлежащие репликации, путем чтения логического журнала, сохранения транзакций и надежной передачи каждой транзакции в качестве данных репликации на целевые серверы.

На каждом целевом сервере Enterprise Replication получает и применяет каждую транзакцию, содержащуюся в данных репликации, к соответствующим базам данных и таблицам как обычную зарегистрированную транзакцию.

===================================

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

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

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

======================================

Асинхронная репликация часто предпочтительнее, поскольку она допускает сбои системы и сети.

Асинхронная репликация допускает следующие модели репликации:

Первичная цель (основная целевая система репликации)

Все изменения базы данных исходят из первичной базы данных и реплицируются в целевые базы данных. Изменения в целевых базах данных не реплицируются в основную.

======================================

Update-Anywhere (система репликации Update-Anywhere)

Все базы данных имеют возможности чтения и записи. Обновления применяются ко всем базам данных.

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

Официальная документация IBM/Informix Enterprise Replication.

=======================================

Асинхронная репликация часто предпочтительнее, поскольку она допускает сбои системы и сети.

Восстановление после сбоя - то над чем наша команда работала около года. Ресинхронизация Update-Anywhere кластера иногда требует нескольких попыток.

RPC (remote procedure call ) протокол лежит на нижнем уровне репликаций баз данных и так или иначе его реализация является причиной потенциальных проблем.

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

============================

Вот некоторые из преимуществ, которые RPC предоставляет разработчикам и менеджерам приложений:

Может использоваться в распределенной среде, а также в локальной среде.

Поддерживает модели, ориентированные на процессы и потоки.

Скрывает от пользователя внутренний механизм передачи сообщений.

Требуются лишь минимальные усилия по переписыванию и доработке кода.

Обеспечивает абстракцию, т. е. передача сообщений по сети скрыта от пользователя.

Исключает многие уровни протокола для повышения производительности.

==========================

С другой стороны, некоторые из недостатков RPC включают следующее:

==========================

Клиент и сервер используют разные среды выполнения для своих подпрограмм, а использование ресурсов (например, файлов) также является более сложным. Следовательно, системы RPC не всегда подходят для передачи больших объемов данных.

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

Единого стандарта для RPC не существует; это может быть реализовано различными способами.

RPC основан только на взаимодействии и поэтому не обеспечивает никакой гибкости, когда речь идет об аппаратной архитектуре.

Если говорить просто - это клонирование базы данных. Но при этом обе базы работают одновременно и позволяют разделять нагрузку, отправляя часть запросов на реплику. Кроме того одна база может выступать копией второй базы. В случае потери одной из двух - вторая становится основной.

Хорошо описано это здесь