Репликация данных в PostgreSQL

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

Таким образом появляется возможность распределить нагрузку с одного сервера на несколько.

Варианты репликации

WAL (Write Ahead Log) — журнал транзакции, СУБД пишет туда все что происходит с данными в БД. После записи в WAL СУБД делает системный вызов fsync, благодаря чему данные попадают сразу на диск, а не висят в где-то в кэше файловой системы. Таким образом, если взять и обесточить сервер, при следующей загрузке СУБД прочитает последние записи из WAL и применит к базе данных соответствующие изменения.

При физической репликации передается информация о физическом изменении страниц базы данных, а при логической – об изменениях записей.

Физическая репликация работает следующим образом: сначала главный сервер записывает изменения данных в WAL, затем подчиненный сервер копирует события WAL и впоследствии воспроизводит эти изменения.

Достоинства физической репликации:

• -    простота и надежность;

• -    подчиненный сервер в точности соответствует мастер – серверу;

• -    практически отсутствуют накладные расходы на реплики.

Недостатки физической репликации:

Если на мастере данные были испорчены, то они также будут испорчены на подчиненном сервере.

• -    На реплике не может быть локальных изменений схемы данных.

• -    Обновление индексов и VACUUM также попадают в журнал транзакций, что порождает избыточное сетевое общение.

• -    Реплика может отставать, если на подчиненном сервере выполняется запрос на длительное чтение данных.

• -    На подчиненном сервере должна быть та же версия PostgreSQL, что и на мастере.

• -    Невозможна мастер - мастер репликация.

Общий принцип логической репликации заключается в следующем: мастер записывает изменения в WAL, на базе которого в дальнейшем восстанавливает информацию об изменении записей и передает данные об изменении записей на подчиненный сервер.

Достоинства логической репликации:

• -    Более компактный обмен данными.

• -    Если данные на мастере были испорчены - репликация остановится.

• -    Репликация не будет отставать из-за VACUUM.

• -    На мастере и подчиненном сервере могут быть разные версии СУБД.

• -    На мастере и подчиненном сервере могут быть различные схемы данных.

• -    Можно реализовать мастер - мастер репликацию.

Недостатки логической репликации:

• -    Более высокая нагрузка на подчиненном сервере.

• -    Надо крайне аккуратно работать со схемой данных.

• -    Нет хорошего решения проблемы репликации DDL - запросов (для реализации create/alter/drop table надо делать хранимую процедуру).

Гарантии репликации

Синхронная репликация - мастер-сервер не подтверждает транзакцию до того, как реплика не подтвердит получение данных. Данные сначала записываются в WAL как минимум одной реплики, после чего транзакция выполняется уже на мастере. Недостатком является то, что запросы на запись выполняются медленнее в результате возникающих сетевых задержек. Достоинством является надежность данного метода.

Асинхронная репликация - мастер-сервер не ждет подтверждения получения данных от реплики. Используется в PostgreSQL по умолчанию. При этом методе запрос тут же выполняется на мастере, а соответствующие данные из WAL доезжают до реплик отдельно, в фоне. Недостатоком является то, что при внезапном падении мастера часть данных будет потеряна, так как они не успели доехать до реплик. Достоинством является высокая скорость.

Варианты взаимодействия

Существует два основных подхода при работе с репликацией данных:

• -    Репликация Master-Slave;

• -    Репликация Master-Master.

В Master-Slave подходе выделяется один основной сервер базы данных, который называется Мастером. На нем происходят все изменения в данных (любые запросы MySQL INSERT/UPDATE/DELETE). Слейв сервер постоянно копирует все изменения с Мастера. С приложения на Слейв сервер отправляются запросы чтения данных (запросы SELECT). Таким образом Мастер сервер отвечает за изменения данных, а Слейв за чтение.

В Master-Master схеме, любой из серверов может использоваться как для чтения так и для записи.

Выводы

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