Использование общего диска
Использование общего диска позволяет избежать накладок на выполнение синхронизации, так как у Вас будет всего одна копия базы данных. При этом способе используется всего один дисковый массив, общий для нескольких серверов. Если основной сервер базы данных падает, резервный сервер может смонтировать и запустить базу данных, как если бы она была восстановлена после сбоя. Это позволяет быстро восстановить работу без потери данных.
Обычно для этих целей используются общие физические носители. Однако так же возможно использовать сетевую файловую систему, но необходимо убедиться, что она ведёт себя полностью в соответствии со стандартом POSIX (См. раздел 17.2.1). Существенное ограничение этого метода состоит в том, что если общий дисковый массив выходит из строя или повреждается, основной и резервный сервера перестают функционировать. Другая проблема состоит в том, что резервный сервер не должен обращаться к общему хранилищу в то время как работает основной сервер.
Репликация файловой системы (Block-Device)
Этот способ является модификацией предыдущего и состоит в том, что мы используем репликацию файловой системы, когда все изменения в файловой системы зеркалируются на ФС, находящуюся на другом компьютере. Единственным ограничением этого метода является то, что зеркалирование должно быть настроено так, чтобы резервный сервер гарантированно имел актуальную копию файловой системы - в частности, запись в резервном сервере должна быть в том же порядке, как и на основном. DRBD - популярное решение для организации репликации ФС на Linux.
"Теплый" и "горячий" резерв, используя Point-In-Time восстановление (PITR)
"Теплые" и "горячие" резервные сервера могут поддерживать актуальное состояние читая поток упреждающего журнала (write-ahead log - WAL). Если основной сервер выходит из строя, резервные сервера содержат почти все данные основного сервера, и могут быть быстро запущены как новые основные сервера БД. Этот метод работает асинхронно и может быть реализован только для всего сервера базы данных.
Резервный сервер PITR может быть реализован при помощи передачи файлов журнала (file-based log shipping) ( раздел 25.2 ), потоковой репликации (см. раздел 25.2.5 ), или комбинация этих двух методов. Для получения информации о "горячем" резерве, см. раздел 25.5 .
Репликация мастер-резерв на основе триггеров (Trigger-Based Master-Standby Replication)
Настройка репликации мастер-резерв посылает все запросы по модификации данных на главный сервер. Он, в свою очередь, асинхронно посылает изменения данных резервному серверу. Резервный сервер может отвечасть только на запросы чтения данных до тех пор пока главный сервер работает. Резервный сервер идеально подходит для запросов к хранилищу данных.
Slony-I это пример такого типа репликации с потабличной детализацией и поддержкой нескольких резервных серверов. Поскольку обновления на резервном сервере происходят асинхронно (пакетами), существует возможность потери данных при сбое.
ПО для репликации на основе выражения (Statement-Based Replication Middleware)
С репликацией на основе выражения при помощи ПО, программа перехватывает все запросы SQL и отправляет их на один или всех сервера. Каждый сервер работает независимо. Запросы на чтение/запись должны быть направлены на всех серверах, так что каждый сервер получает все изменения. Но запросы только на чтение могут быть отправлены только одному серверу, что позволяет распределить нагрузку чтения между всеми серверами.
Если запросы просто транслировать без изменений, то функции, такие как random(), CURRENT_TIMESTAMP и последовательности могут иметь разные значения на разных серверах. Это потому, что каждый сервер работает независимо, и потому что SQL запросы широковещательные (а не фактически измененные строки). Если это неприемлемо, то либо ПО, либо приложение должно запрашивать такие значения с одного сервера а затем использовать эти значения в запросах на запись. Другой выход заключается в использовании этой опции репликации с обычной настройкой мастер-резерв, т.е. когда запросы на изменение данных отправляются только на мастер и затем распространяются на резервные серверы с помощью мастер-резерв репликации, а не при помощи промежуточного программного обеспечения. Необходимо также учитывать, что все транзакции должны либо фиксироваться, либо откатываться на всех серверах, возможно, используя двухфазной фиксации ( PREPARE TRANSACTION и COMMIT PREPARED. PGPool-II и Continuent Tungsten являются примерами этого типа репликации.
Асинхронная репликация при наличии нескольких мастеров (Asynchronous Multimaster Replication)
Для серверов, которые не связаны постоянно, например, ноутбуки или удаленные серверы, поддержка соответствия данных может оказаться непростой задачей. В таком случае можно использовать асинхронной репликации между мастер-серверами , каждый из которых работает независимо, и периодически связывается с другими серверами для выявления конфликтных транзакций. Конфликты могут быть разрешены пользователями или при помощи правил. Bucardo - примером этого типа репликации.
Синхронная репликация при наличии нескольких мастеров (Synchronous Multimaster Replication)
При синхронной репликации с несколькими мастерами, каждый сервер может принимать запросы на запись, а изменение данных передается от исходного сервера на все остальные серверы перед подтверждением каждой транзакции. Большие объёмы записи в базу могут привести к длительным блокировкам, что, в свою очередь, ведёт к ухудшению производительности. В действительности, скорость записи в этом случае зачастую хуже, чем в случае единичного сервера. Запросы на чтение могут быть посланы на любой сервер. Некоторые реализации используют общий диск для уменьшения накладок на связь. Синхронная репликация при наличии нескольких мастеров лучше всего подходит для нагрузок, большую часть которых составляет чтение, поскольку большим достоинством этого типа репликации является то, что любой сервер может принимать запросы на запись; у Вас нет необходимости разделять нагрузку мастером и резервными серверами, и, поскольку изменения данных посылаются с одного сервера на другой, нет никаких проблем с недетерминированными функциями, такими как как random().
PostgreSQL не предлагает этот тип репликации, хотя PostgreSQL двухфазная фиксации ( PREPARE TRANSACTION и COMMIT PREPARED) может быть использована для реализации этого в коде приложения или в промежуточном программном обеспечении.
Коммерческие решения
Поскольку PostgreSQL является проектом с открытым исходным кодом и легко расширем, ряд компаний взяли PostgreSQL и создали уникальные коммерческие проприентарные решения для обеспечения отказоустойчивости, репликации и возможности балансировки нагрузки.
Таблица 25-1 показывает возможности различных решений перечисленных выше.
Таблица 25-1. Высокая доступность, балансировку нагрузки, и варианты репликации.
| Вариант | Общий диск | Репликация ФС | "Горячий" / "Теплый" резервный сервер, используя PITR | Репликация мастер-резерв на основе триггеров (Trigger-Based Master-Standby Replication) | ПО для репликации на основе выражения (Statement-Based Replication Middleware) | Асинхронная репликация при наличии нескольких мастеров (Asynchronous Multimaster Replication) | Синхронная репликация при наличии нескольких мастеров (Synchronous Multimaster Replication) |
| Наиболее распространенные реализации | NAS | DRBD | PITR | Slony | pgpool-II | Bucardo | |
| Метод связи | общий диск | дисковые блоки | WAL | строки таблицы | SQL | строки таблицы | строки таблицы и блокировки строк |
| Не требуется специального оборудования | • | • | • | • | • | • | |
| Позволяет иметь несколько мастер серверов | • | • | • | ||||
| Нет накладных расходов мастер сервера | • | • | • | ||||
| Не нужно ждать других серверов | • | • | • | • | |||
| Крах мастера не приводит к потере данных | • | • | • | • | |||
| Резервные сервера используются только запросов на чтение | только "горячие" | • | • | • | • | ||
| Потабличная детализация | • | • | • | ||||
| Не требуется разрешения конфликтов | • | • | • | • | • |
Есть несколько решений, которые не вписываются в вышеупомянутые категории:
Разделение данных
При разделении данных таблицы разбиваются на наборы данных. Каждый набор может быть изменен только одним сервером. Например, данные могут быть разделены по офисам, например, лондонский офис и парижский офис, и сервера стоят в каждом офисе. Если в запросе нужно объединить данные из Лондона и Парижа, приложение может запросить оба сервера; или же может использоваться репликация мастер-резервный для хранения доступной только для чтения копии данных другого офиса для каждого сервера.
Несколько серверов для параллельного выполнения запросов
Многие из перечисленных выше решений позволяет нескольким серверам обрабатывать несколько запросов, но ни одна из них не позволяет один запрос передать на обработку нескольким серверам для ускорения его выполнения. Это же решение позволяет нескольким серверам одновременно работать над одним запросом. Обычно это достигается путем разделения данных между серверами и каждый сервер выполняет свою часть запроса и возвращает результаты на центральный сервер, где они объединяются и возвращаются пользователю. PGPool-II имеет такую возможность. Кроме того, это может быть реализовано с помощью набора инструментов PL / Proxy.
Комментариев нет:
Отправить комментарий