PostgreSQL это не только стабильная и надежная СУБД но и плюс ко всем это динамично развивающийся продукт, в котором от релиза к релизу появляются самые разные прорывные вещи. В свое время одной из таких технологий была потоковая репликация. Это высокопроизводительная репликация которая позволяет очень легко и дешево масштабировать базу данных на чтение. Используя ее можно создавать надежные конфигурации распределяя нагрузку на чтение между узлами. Однако как я написал выше, продукт развивается, и сегодня в статье речь пойдет о новой технологии BDR (Bi-Directional Replication).

Немного терминов для тех кто не в теме:
WAL (Write Ahead Log) — журнал транзакции, на нем основана встроенная потоковая репликация в постгресе, СУБД пишет туда все что происходит с данными в БД.
SR (Streaming Replication) — общее название встроенной потоковой репликации которая которая основана на WAL, все что пишется в WAL, затем отправляется на слейвы и воспроизводится. Бывает физическая и логическая потоковая репликация.
PLSR (Physical Log Streaming Replication) — физическая потоковая репликация (то что уже реализовано и работает), все что попало в WAL без последующего разбора реплицируется на слейв сервера, это и изменение данных/схемы и более низкоуровневые вещи (full page writes, vacuum, hint bit settings).
LLSR (Logical Log Streaming Replication) — логическая потоковая репликация (появится в 9.4) также основана на WAL журналах, но уже более интеллектуальная и для репликации извлекается только определенная часть журналов в которых описываются изменения схемы и данных БД (то есть некоторые низкоуровневые вещи отсеиваются).

Что скрывается под термином BDR?
BDR (Bi-Directional Replication) это новая функциональность добавленая в ядро PostgreSQL которая предоставляет расширенные средства для репликации. На данный момент это реализовано в виде небольшого патча и модуля. Заявлено что полностью будет только в PostgreSQL 9.5 (сейчас 9.3-stable и 9.4-beta1).
Если коротко, то BDR позволяет создавать географически распределенные асинхронные мульти-мастер конфигурации (о да, детка) используя для этого встроенную логическую потоковую репликацию LLSR.
Тем не менее, BDR не является инструментом для кластеризации, т.к. здесь нет каких-либо глобальных менеджеров блокировок или координаторов транзакций (привет Postgres-XC/XL). Каждый узел не зависит от других, что было бы невозможно в случае использования менеджеров блокировки. Каждый из узлов содержит локальную копию данных идентичную данным на других узлах. Запросы также выполняются только локально (чтобы было более понятно о чем речь, приведу сравнение с Postgres-XC/Postgres-XL, там все серверы работают как бы в одной упряжке, транзакции рулятся глобальным менеджером транзакции, а запросы от приложения поступают на координатора(ов) который отправляет выполняться пришедшие запросы на любой рабочий узел, вот). При этом каждый из узлов внутренне консистентен в любое время,…