postgresql_replication.tex

\chapter{Репликация}

\begin{epigraphs}
\qitem{Когда решаете проблему, ни о чем не беспокойтесь.
Вот когда вы её решите, тогда и наступит время беспокоиться.}{Ричард Филлипс Фейман}
\end{epigraphs}

\section{Введение}

Репликация (англ. replication)~--- механизм синхронизации содержимого нескольких копий объекта (например, содержимого базы данных). Репликация~--- это процесс, под которым понимается копирование данных из одного источника на множество других и наоборот. При репликации изменения, сделанные в одной копии объекта, могут быть распространены в другие копии. Репликация может быть синхронной или асинхронной.

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

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

Рассмотрим кратко проблему согласованности (или, скорее, несогласованности). Дело в том, что реплики могут становиться несовместимыми в результате ситуаций, которые трудно (или даже невозможно) избежать и последствия которых трудно исправить. В частности, конфликты могут возникать по поводу того, в каком порядке должны применяться обновления. Например, предположим, что в результате выполнения транзакции А происходит вставка строки в реплику X, после чего транзакция B удаляет эту строку, а также допустим, что Y~--- реплика X. Если обновления распространяются на Y, но вводятся в реплику Y в обратном порядке (например, из-за разных задержек при передаче), то транзакция B не находит в Y строку, подлежащую удалению, и не выполняет своё действие, после чего транзакция А вставляет эту строку. Суммарный эффект состоит в том, что реплика Y содержит указанную строку, а реплика X~--- нет.

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

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

Для репликации PostgreSQL существует несколько решений, как закрытых, так и свободных. Закрытые системы репликации не будут рассматриваться в этой книге. Вот список свободных решений:

\begin{itemize}
  \item \href{http://www.slony.info/}{Slony-I}~--- асинхронная Master-Slave репликация, поддерживает каскады(cascading) и отказоустойчивость(failover). Slony-I использует триггеры PostgreSQL для привязки к событиям INSERT/DELETE/UPDATE и хранимые процедуры для выполнения действий;

  \item \href{http://pgfoundry.org/projects/pgcluster/}{PGCluster}~--- синхронная Multi-Master репликация. Проект на мой взгляд мертв;

  \item \href{http://pgpool.projects.postgresql.org/}{Pgpool-I/II}~--- это замечательный инструмент для PostgreSQL (лучше сразу работать с II версией). Позволяет делать:
  \begin{itemize}
    \item репликацию (в том числе, с автоматическим переключением на резервный stand-by сервер);
    \item online-бэкап;
    \item pooling коннектов;
    \item очередь соединений;
    \item балансировку SELECT-запросов на несколько postgresql-серверов;
    \item разбиение запросов для параллельного выполнения над большими объемами данных;
  \end{itemize}

  \item \href{http://bucardo.org/}{Bucardo}~--- асинхронная репликация, которая поддерживает Multi-Master и Master-Slave режимы, а также несколько видов синхронизации и обработки конфликтов;

  \item \href{http://skytools.projects.postgresql.org/doc/londiste.ref.html}{Londiste}~--- асинхронная Master-Slave репликация. Входит в состав Skytools\footnote{http://pgfoundry.org/projects/skytools/}. Проще в использовании, чем Slony-I;

  \item \href{http://www.commandprompt.com/products/mammothreplicator/}{Mammoth Replicator}~--- асинхронная Multi-Master репликация;

  \item \href{http://www.postgres-r.org/}{Postgres-R}~--- асинхронная Multi-Master репликация. Проект на мой взгляд мертв;

  \item \href{http://www.rubyrep.org/}{RubyRep}~--- написанная на Ruby, асинхронная Multi-Master репликация, которая поддерживает PostgreSQL и MySQL.
\end{itemize}

Это, конечно, не весь список свободных систем для репликации, но я думаю даже из этого есть что выбрать для PostgreSQL.


\input{replication/streaming}
\input{replication/bdr}
\input{replication/slony}
\input{replication/londiste}
\input{replication/bucardo}
\input{replication/rubyrep}


\section{Заключение}

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

В главе было рассмотрено несколько видов репликации PostgreSQL. Нельзя четко сказать какая лучше всех. Потоковая репликация~--- один из самых лучших вариантов для поддержки идентичных кластеров баз данных, но доступна только с 9.0 версии PostgreSQL. Slony-I~--- громоздкая и сложная в настройке система, но имеющая в своем арсенале множество функций, таких как поддержка каскадной репликации, отказоустойчивости (failover) и переключение между серверами (switchover). В тоже время Londiste имея в своем арсенале подобный функционал, может похвастатся еще компактностью и простой в установке. Bucardo~--- система которая может быть или master-master, или master-slave репликацией. RubyRep, как для master-master репликации, очень просто в установке и настройке, но за это ему приходится расплачиваться скоростью работы~--- самый медленный из всех (синхронизация больших объемов данных между таблицами).