Slony и PGPool для аварийного переключения

Это анекдотично, так что отнеситесь к этому с недоверием.

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

Slony, с другой стороны, представляет собой административную tar-pit, для работы которой необходимо добавить триггерные функции и множество других объектов в вашу базу данных. Более того, Slony не поддерживает (просто) возможность репликации изменений схемы (DDL) так же, как он копирует обычные операции типа вставки/обновления/удаления (DML). Взятые в целом, эти характеристики означают, что во многих случаях ваше приложение должно иметь специальные случаи для обработки эксцентриситетов Slony. На мой взгляд, это плохо: приложение не должно знать/вносить изменения, чтобы иметь дело с решением репликации базы данных, на котором оно работает. Я провел большую часть года, взламывая Slony, чтобы он работал как стабильное решение для репликации, и в конце концов пришел к выводу, что это плохая идея/плохая механика репликации, реализованная тупым, неразборчивым способом, то есть совсем не стабильная и не готовая к корпоративному использованию. . EDIT: начиная с PostgreSQL 9.3 вы можете устанавливать триггеры (которые Slony использует для обнаружения изменений) на объектах DDL, что может позволить Slony реплицировать больше аспектов базы данных.

Тем не менее, Slony делает две вещи лучше, чем потоковая репликация (управляемая через PGPool или нет):

• Slony допускает репликацию для каждой таблицы или для каждой базы данных. Потоковая репликация разрешает репликацию только всего экземпляра Postgres. Если для вас важна такая степень детализации, вам может понадобиться Slony.
• Slony допускает каскадную репликацию (ведущий -> подчиненный -> подчиненный). Потоковая репликация допускает только один уровень. EDIT: это теперь поддерживается в собственной потоковой репликации PostgreSQL, начиная с Postgres версии 9.2.

Буквально во всем остальном потоковая репликация лучше и стабильнее.

Но вы спрашиваете не только о потоковой репликации: PGPool делает гораздо больше. Это позволяет балансировать нагрузку чтения и записи между подчиненными базами данных и мастерами, доступными только для чтения, и реализовывать планы резервного копирования, а также целый ряд других вещей. Особенно по сравнению с загадочным командным синтаксисом Slony и ужасными сценариями администрирования, PGPool выигрывает почти во всех случаях.

Что касается аварийного переключения, в PGPool есть мониторы пульса и возможность автоматически маршрутизировать трафик базы данных в кластере. У Slony есть только команда «переключиться на подчиненное устройство сейчас», оставляя весь мониторинг и маршрутизацию на стороне приложения на ваше усмотрение.

TL;DR: PGPool хорош. Очень плохо.