26.1. Сравнение различных решений#
26.1. Сравнение различных решений
- Shared Disk Failover
Резервное копирование общего диска избегает издержек на синхронизацию, имея только одну копию базы данных. Оно использует один массив дисков, который общий для нескольких серверов. Если основной сервер базы данных выходит из строя, резервный сервер может смонтировать и запустить базу данных, как если бы он восстанавливался после сбоя базы данных. Это позволяет быстрое переключение без потери данных.
Общая функциональность оборудования является распространенной в сетевых устройствах хранения данных. Использование сетевой файловой системы также возможно, однако необходимо обеспечить полное соответствие файловой системы стандарту POSIX (см. Раздел 18.2.2.1). Одним из значительных ограничений этого метода является то, что если общий массив дисков выходит из строя или становится поврежденным, то и первичный, и резервный серверы становятся неработоспособными. Еще одной проблемой является то, что резервный сервер никогда не должен обращаться к общему хранилищу данных во время работы первичного сервера.
- File System (Block Device) Replication
Измененной версией общей функциональности оборудования является репликация файловой системы, при которой все изменения файловой системы отражаются на файловой системе, находящейся на другом компьютере. Единственным ограничением является то, что отражение должно выполняться таким образом, чтобы резервный сервер имел согласованную копию файловой системы - конкретно, записи на резервном сервере должны выполняться в том же порядке, что и на основном сервере. DRBD - популярное решение для репликации файловой системы в Linux.
- Write-Ahead Log Shipping
Теплые и горячие резервные серверы могут быть поддерживаемыми в актуальном состоянии путем чтения потока записей журнала предварительной записи (WAL). Если основной сервер выходит из строя, резервный сервер содержит почти все данные основного сервера и может быстро стать новым основным сервером базы данных. Это может быть синхронным или асинхронным и может быть выполнено только для всего сервера базы данных.
Вторичный сервер может быть реализован с использованием логической репликации на основе файлов (Раздел 26.2) или потоковой репликации (см. Раздел 26.2.5), или комбинации обоих подходов. Дополнительную информацию о горячем резервировании см. в разделе Раздел 26.4.
- Logical Replication
Логическая репликация позволяет серверу базы данных отправлять поток модификаций данных на другой сервер. Tantor SE логическая репликация создает поток логических модификаций данных из WAL. Логическая репликация позволяет тиражировать изменения данных на уровне отдельных таблиц. Кроме того, сервер, который публикует свои изменения, также может подписаться на изменения с другого сервера, что позволяет данным двигаться в нескольких направлениях. Дополнительную информацию о логической репликации см. в разделе Глава 30. Через интерфейс логического декодирования (Глава 47), сторонние расширения также могут предоставлять аналогичную функциональность.
- Trigger-Based Primary-Standby Replication
Настройка репликации на основе триггеров обычно направляет запросы на изменение данных на определенный основной сервер. Работая на уровне отдельных таблиц, основной сервер асинхронно отправляет изменения данных на резервные серверы. Резервные серверы могут отвечать на запросы во время работы основного сервера и могут разрешать некоторые локальные изменения данных или операции записи. Эта форма репликации часто используется для выгрузки больших аналитических запросов или запросов к хранилищу данных.
Slony-I является примером этого типа репликации с гранулярностью на уровне таблицы и поддержкой нескольких резервных серверов. Поскольку он обновляет резервный сервер асинхронно (пакетами), возможна потеря данных во время переключения на резервный сервер.
- SQL-Based Replication Middleware
С помощью промежуточного программного обеспечения для репликации на основе SQL каждый SQL-запрос перехватывается и отправляется на один или все серверы. Каждый сервер работает независимо. Запросы на чтение и запись должны быть отправлены на все серверы, чтобы каждый сервер получал все изменения. Но запросы только на чтение могут быть отправлены только на один сервер, что позволяет распределить нагрузку на чтение между ними.
Если запросы просто передаются без изменений, функции, такие как
random(),CURRENT_TIMESTAMPи последовательности могут иметь разные значения на разных серверах. Это происходит потому, что каждый сервер работает независимо, и потому что SQL-запросы передаются, а не фактически изменяют данные. Если это неприемлемо, то либо промежуточное программное обеспечение, либо приложение должны определить такие значения из одного источника и затем использовать их в запросах на запись. Также необходимо обеспечить, чтобы все транзакции либо коммитились, либо откатывались на всех серверах, возможно, используя двухфазный коммит (PREPARE TRANSACTION и COMMIT PREPARED). Pgpool-II и Continuent Tungsten являются примерами такого типа репликации.- Asynchronous Multimaster Replication
Для серверов, которые не подключены регулярно или имеют медленные связи, такие как ноутбуки или удаленные серверы, поддержание согласованности данных между серверами представляет собой сложную задачу. Используя асинхронную многомастерную репликацию, каждый сервер работает независимо и периодически обменивается информацией с другими серверами для выявления конфликтующих транзакций. Конфликты могут быть разрешены пользователями или правилами разрешения конфликтов. Bucardo является примером такого типа репликации.
- Synchronous Multimaster Replication
В синхронной репликации с множеством равноправных серверов каждый сервер может принимать запросы на запись, и измененные данные передаются с оригинального сервера на каждый другой сервер перед каждым коммитом транзакции. Интенсивная запись может вызвать избыточную блокировку и задержки при коммите, что приводит к плохой производительности. Запросы на чтение могут быть отправлены на любой сервер. Некоторые реализации используют общий диск для снижения издержек на обмен данными. Синхронная репликация с множеством равноправных серверов наиболее подходит для приложений, в которых преобладает чтение, хотя ее большим преимуществом является то, что любой сервер может принимать запросы на запись - нет необходимости разделять рабочие нагрузки между основными и резервными серверами, и поскольку изменения данных отправляются с одного сервера на другой, нет проблем с недетерминированными функциями, такими как
random().Tantor SE не предлагает такого типа репликации, хотя двухфазный коммит (PREPARE TRANSACTION и COMMIT PREPARED) в Tantor SE может быть использован для реализации этого в коде приложения или промежуточном программном обеспечении.
Таблица 26.1 подводит итоги возможностей различных решений, перечисленных выше.
Таблица 26.1. Матрица функций высокой доступности, балансировки нагрузки и репликации
| Функция | Общий диск | Репликация файловой системы | Репликация журнала с предварительной записью | Логическая репликация | Репликация на основе триггеров | Промежуточное программное обеспечение для SQL-репликации | Асинхронная репликация с многомастером | Синхронная репликация с многомастером |
|---|---|---|---|---|---|---|---|---|
| Популярные примеры | NAS | DRBD | встроенная потоковая репликация | встроенная логическая репликация, pglogical | Londiste, Slony | pgpool-II | Bucardo | |
| Comm. method | общий диск | блоки диска | WAL | логическое декодирование | строки таблицы | SQL | строки таблицы | строки таблицы и блокировки строк |
| Не требуется специальное оборудование | • | • | • | • | • | • | • | |
| Позволяет использовать несколько основных серверов | • | • | • | • | ||||
| Нет издержек на основной | • | • | • | • | ||||
| Нет ожидания для нескольких серверов | • | со синхронизацией отключено | со синхронизацией отключено | • | • | |||
| Основная ошибка никогда не потеряет данные | • | • | с синхронизацией включенной | с синхронизацией включенной | • | • | ||
| Реплики принимают только запросы на чтение | с горячим резервированием | • | • | • | • | • | ||
| Гранулярность на уровне таблицы | • | • | • | • | ||||
| Нет необходимости в разрешении конфликтов | • | • | • | • | • | • |
Есть несколько решений, которые не подходят в вышеперечисленные категории:
- Data Partitioning
Разделение данных разбивает таблицы на наборы данных. Каждый набор может быть изменен только одним сервером. Например, данные могут быть разделены по офисам, например, Лондон и Париж, с сервером в каждом офисе. Если необходимы запросы, объединяющие данные Лондона и Парижа, приложение может запрашивать оба сервера, или можно использовать репликацию основной/резервной копии, чтобы хранить только для чтения копию данных другого офиса на каждом сервере.
- Multiple-Server Parallel Query Execution
Многие из вышеуказанных решений позволяют нескольким серверам обрабатывать несколько запросов, но ни одно из них не позволяет одному запросу использовать несколько серверов для более быстрого выполнения. Это решение позволяет нескольким серверам одновременно работать над одним запросом. Обычно это достигается путем разделения данных между серверами и выполнения каждым сервером своей части запроса, а затем объединения и возврата результатов на центральный сервер, откуда они возвращаются пользователю. Это можно реализовать с помощью набора инструментов PL/Proxy.
Также следует отметить, что поскольку Tantor SE является открытым и легко расширяемым исходным кодом, несколько компаний взяли Tantor SE и создали коммерческие закрытые решения с уникальными возможностями аварийного восстановления, репликации и балансировки нагрузки. Об этих решениях здесь не рассказывается.