Сравнение различных решений
Эта страница переведена при помощи нейросети GigaChat.
Отказоустойчивость на разделяемых дисках
: Отказоустойчивость на разделяемых дисках устраняет накладные расходы на синхронизацию за счет наличия только одной копии базы данных. Она использует один дисковый массив, которым совместно пользуются несколько серверов. Если основной сервер базы данных выходит из строя, резервный сервер может монтировать и запускать базу данных так, как будто он восстанавливается после сбоя базы данных. Это позволяет быстро переключаться с отказом без потери данных.
Совместное использование аппаратных функций является обычным для сетевых устройств хранения. Также возможно использование сетевой файловой системы, хотя следует соблюдать осторожность, чтобы файловая система имела полное поведение POSIX. Одним из существенных ограничений этого метода является то, что если общий дисковый массив выходит из строя или повреждается, основной и резервный серверы становятся нефункциональными. Еще одна проблема заключается в том, что резервный сервер никогда не должен обращаться к общему хранилищу при работающем основном сервере.
Репликация файловой системы (блочного устройства)
: Модифицированная версия общей функциональности оборудования - это репликация файловой системы, когда все изменения в файловой системе зеркалируются в файловой системе, находящейся на другом компьютере. Единственное ограничение состоит в том, что зеркалирование должно выполняться таким образом, чтобы обеспечить наличие у резервного сервера согласованной копии файловой системы - конкретно, записи на резервную копию должны выполняться в том же порядке, что и на основную. DRBD - популярное решение для репликации файловых систем в Linux.
Трансляция журнала предзаписи
: Серверы горячей и теплой замены могут поддерживаться актуальными путем чтения потока записей журнала опережающей записи (WAL). Если основной сервер выходит из строя, резервный сервер содержит почти все данные основного сервера и может быть быстро преобразован в новый основной сервер баз данных. Это может быть синхронным или асинхронным и может выполняться только для всего сервера баз данных.
Сервер резервного копирования может быть реализован с использованием логической репликации на основе файлов (Раздел «Трансляция журналов на резервные серверы») или потоковой репликации, либо их комбинации. Для получения информации о горячем резерве см. раздел «Горячий резерв».
Логическая репликация
: Логическая репликация позволяет серверу базы данных отправлять поток изменений данных на другой сервер. Логическая репликация PostgreSQL создает поток логических изменений данных из WAL. Логическая репликация позволяет выполнять репликацию изменений данных на основе каждой таблицы. Кроме того, сервер, который публикует свои собственные изменения, также может подписываться на изменения от другого сервера, что позволяет данным перемещаться в нескольких направлениях. Для получения дополнительной информации о логической репликации. Через интерфейс логической декодировки сторонние расширения также могут предоставлять аналогичную функциональность.
Репликация главный-резервный на основе триггеров
: Настройка триггерной репликации обычно направляет запросы на изменение данных на выделенный основной сервер. Работая на уровне отдельных таблиц, основной сервер отправляет изменения данных (обычно) асинхронно на резервные серверы. Резервные серверы могут отвечать на запросы во время работы основного сервера и могут допускать некоторые локальные изменения данных или активность записи. Эта форма репликации часто используется для разгрузки больших аналитических запросов или запросов к хранилищам данных.
Slony-I является примером такого типа репликации с гранулярностью на уровне таблиц и поддержкой нескольких серверов ожидания. Поскольку он обновляет сервер ожидания асинхронно (пакетами), возможна потеря данных при отказе.
Репликация SQL в среднем слое
: В схеме с репликацией SQL в среднем слое, средний слой перехватывает каждый запрос SQL и отправляет его на один или все серверы. Каждый сервер работает независимо. Запросы чтения-записи должны быть отправлены на все серверы, чтобы каждый сервер получал любые изменения. Но запросы только для чтения могут быть отправлены только на один сервер, что позволяет распределить нагрузку чтения среди них.
Если запросы просто транслируются без изменений, функции, такие как random(), CURRENT_TIMESTAMP и последовательности могут иметь разные значения на разных серверах. Это связано с тем, что каждый сервер работает независимо, а также потому, что SQL-запросы транслируются вместо фактических изменений данных. Если это неприемлемо, либо промежуточное программное обеспечение, либо само приложение должно определять такие значения из одного источника, а затем использовать эти значения в запросах записи. Также следует позаботиться о том, чтобы все транзакции либо фиксировались, либо отменялись на всех серверах, возможно, используя двухфазную фиксацию (PREPARE TRANSACTION и COMMIT PREPARED). Pgpool-II и Continuent Tungsten являются примерами такого типа репликации.
Асинхронная репликация с несколькими ведущими
: Для серверов, которые не регулярно подключены или имеют медленные каналы связи, например ноутбуков или удаленных серверов, поддержание согласованности данных между серверами является сложной задачей. Используя асинхронную многоверсионную репликацию, каждый сервер работает независимо и периодически связывается с другими серверами для выявления конфликтующих транзакций. Конфликты могут быть разрешены пользователями или правилами разрешения конфликтов. Bucardo является примером этого типа репликации.
Синхронная репликация с несколькими ведущими
: В синхронной репликация с несколькими ведущими каждый сервер может принимать запросы на запись, и измененные данные передаются с исходного сервера на все остальные серверы до завершения каждой транзакции. Интенсивная активность записи может привести к избыточному блокированию и задержке фиксации, что приводит к ухудшению производительности. Запросы на чтение могут быть отправлены на любой сервер. Некоторые реализации используют общую дисковую память для уменьшения накладных расходов на связь. Синхронная многоосновная репликация лучше всего подходит для рабочих нагрузок, состоящих главным образом из чтения, хотя ее большим преимуществом является то, что любой сервер может принимать запросы на запись - нет необходимости разделять рабочие нагрузки между основными и резервными серверами, а поскольку изменения данных отправляются от одного сервера к другому, не возникает проблем с недетерминированными функциями, такими как random().
PostgreSQL не предлагает этот тип репликации, хотя PostgreSQL двухфазная фиксация (PREPARE TRANSACTION и COMMIT PREPARED) может быть использована для реализации этого в коде приложения или промежуточном программном обеспечении.
Таблица ниже суммирует возможности различных решений, перечисленных выше.
Матрица функций высокой доступности, балансировки нагрузки и репликации
| Функция | Разделяемый диск | Репликация файловой системы | Трансляция журнала предзаписи | Логическая репликация | Триггерная репликация | Репликация SQL в среднем слое | Асинхронная репликация с несколькими ведущими | Синхронная репликация с несколькими ведущими |
|---|---|---|---|---|---|---|---|---|
| Популярные примеры | NAS | DRBD | встроенная потоковая репликация. | встроенная логическая репликация, pglogical | Londiste, Slony | pgpool-II | Bucardo | |
| Метод связи | разделяемые диски | дисковые блоки | WAL | логическая декодировка | строки таблицы | SQL | табличные строки | табличные строки и блокировки строк |
| Не требуется специальное оборудование | • | • | • | • | • | • | • | |
| Разрешает несколько основных серверов | • | • | • | • | ||||
| Без накладных расходов на основной | • | • | • | • | ||||
| Нет ожидания нескольких серверов | • | с выключенной синхронизацией | с синхронизацией выключенной | • | • | |||
| Основное повреждение никогда не приведет к потере данных | • | • | с синхронизацией включенной | с синхронизацией включенной | • | • | ||
| Реплики принимают запросы только для чтения | с горячим резервированием | • | • | • | • | • | ||
| Гранулярность на уровне таблиц | • | • | • | • | ||||
| Разрешение конфликтов не требуется | • | • | • | • | • | • |
Есть несколько решений, которые не вписываются в вышеуказанные категории:
Партиционирование данных
: Разделение данных разбивает таблицы на наборы данных. Каждый набор может быть изменен только одним сервером. Например, данные могут быть разделены по офисам, например, Лондон и Париж, с сервером в каждом офисе. Если необходимы запросы, объединяющие данные Лондона и Парижа, приложение может запросить оба сервера или использовать репликацию основного/дополнительного режима для сохранения копии данных другого офиса на каждом сервере только для чтения.
Выполнение параллельных запросов на нескольких серверах
: Многие из вышеперечисленных решений позволяют нескольким серверам обрабатывать несколько запросов, но ни одно не позволяет одному запросу использовать несколько серверов для завершения работы быстрее. Это решение позволяет нескольким серверам одновременно работать над одним запросом. Обычно это достигается путем разделения данных между серверами и выполнения каждой серверной частью запроса с возвратом результатов на центральный сервер, где они объединяются и возвращаются пользователю. Это может быть реализовано с использованием набора инструментов PL/Proxy.
Также следует отметить, что поскольку PostgreSQL имеет открытый исходный код и легко расширяется, ряд компаний взяли PostgreSQL и создали коммерческие закрытые решения с уникальными возможностями отказоустойчивости, репликации и балансировки нагрузки. Они здесь не обсуждаются.