Отработка отказа на основе общего диска

Механизм отработки отказа с использованием общего диска позволяет избежать накладных расходов на синхронизацию, так как в системе поддерживается только одна копия базы данных. Данный метод предполагает использование единого дискового массива, совместно используемого несколькими серверами. В случае сбоя основного сервера базы данных резервный сервер монтирует хранилище и запускает базу данных в режиме восстановления после аварийного завершения работы (crash recovery). Это обеспечивает быструю отработку отказа без потери данных.

Функциональность общего доступа к оборудованию является стандартной для сетевых устройств хранения данных. Также возможно использование сетевой файловой системы, однако необходимо убедиться, что она полностью поддерживает POSIX -совместимое поведение (см. Раздел 3.3.2.2.1). Одним из существенных ограничений данного метода является то, что при отказе или повреждении общего дискового массива из строя выходят одновременно и основной, и резервный серверы. Другая проблема заключается в том, что резервный сервер не должен обращаться к общему хранилищу во время работы основного сервера.

Репликация на уровне файловой системы (блочного устройства)

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

Передача журналов WAL

Серверы в режимах теплого и горячего резервирования могут поддерживаться в актуальном состоянии путем считывания потока записей журнала WAL (журнал WAL) записей. В случае сбоя основного сервера резервный узел содержит практически все данные основного сервера и может быть оперативно переведен в режим нового основного узла базы данных. Данный механизм может работать в синхронном или асинхронном режиме и применим только ко всему серверу базы данных в целом.

Резервный сервер может быть реализован с использованием механизма файловой передачи журналов (Раздел 3.11.2) или потоковой репликации (см. Раздел 3.11.2.5), а также путем сочетания обоих методов. Информацию о режиме горячего резервирования см. в разделе Раздел 3.11.4.

Логическая репликация

Логическая репликация позволяет серверу базы данных передавать поток изменений данных на другой сервер. Digital Q.DataBase Механизм логической репликации формирует поток логических изменений данных на основе журнала WAL. Данный вид репликации позволяет передавать изменения на уровне отдельных таблиц. Кроме того, сервер, публикующий собственные изменения, может одновременно подписываться на изменения, поступающие от другого сервера, что обеспечивает возможность многонаправленной передачи данных. Дополнительную информацию о логической репликации см. в разделе Глава 3.14. Через интерфейс логического декодирования (Глава 5.12), аналогичную функциональность могут также предоставлять сторонние расширения.

Репликация между основным и резервным узлами на основе триггеров

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

Slony-I представляет собой пример данного типа репликации с детализацией на уровне отдельных таблиц и поддержкой нескольких резервных серверов. Поскольку обновление резервного сервера выполняется асинхронно (пакетным методом), при отработке отказа возможна потеря данных.

Промежуточное программное обеспечение для репликации на базе SQL

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

Если запросы транслируются без изменений, такие функции, как random(), CURRENT_TIMESTAMP, при этом последовательности могут иметь различные значения на разных серверах. Это обусловлено тем, что каждый сервер функционирует независимо, а также тем, что передаются SQL-запросы, а не фактические изменения данных. Если это недопустимо, то промежуточное программное обеспечение или само приложение должно получать такие значения из единого источника и затем использовать их в запросах на запись. Также необходимо обеспечить, чтобы все транзакции либо фиксировались, либо откатывались на всех серверах, например, с помощью протокола двухфазной фиксации (PREPARE TRANSACTION и COMMIT PREPARED). Pgpool-II и Continuent Tungsten являются примерами такого типа репликации.

Асинхронная мультимастер-репликация

Для серверов, не имеющих постоянного соединения или подключенных по медленным каналам связи (например, переносных компьютеров или удаленных серверов), обеспечение согласованности данных представляет собой сложную задачу. В режиме асинхронной мультимастер-репликации каждый сервер работает автономно и периодически обменивается данными с другими серверами для выявления конфликтующих транзакций. Конфликты могут быть разрешены пользователями или посредством автоматизированных правил. Пример реализации такого типа репликации — Bucardo.

Синхронная мультимастерная репликация

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

Digital Q.DataBase не поддерживает данный тип репликации, однако Digital Q.DataBase двухфазная фиксация транзакции (PREPARE TRANSACTION и COMMIT PREPARED) может использоваться для реализации данного механизма на уровне программного кода приложения или промежуточного ПО.

Таблица 3.11.1 содержит обобщенное описание возможностей различных решений, перечисленных выше.

Существует ряд решений, которые не классифицируются по вышеуказанным категориям:

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