Slony и PGPool для отработки отказа
Мы рассматриваем Slony и PGPool в качестве альтернативы для обработки отказов в нашем приложении - и, похоже, нам понадобится как минимум два сервера БД, и мы могли бы воспользоваться преимуществами балансировки нагрузки.
При каких обстоятельствах Slony лучше, чем PGPool и наоборот?
1 ответ
Это анекдотично, поэтому возьмите его с крошкой соли.
PGPool и потоковая репликация WAL (с горячим резервированием или без) работают так, как должна репликация базы данных. Вашему приложению не нужно ничего знать о репликации, о том, является ли оно частью кластера или чего-то подобного, оно просто обращается к базе данных, как и любой другой. Потоковая репликация является надежной и может вернуться к доставке WAL в случае прерывания потоковой передачи. PGPool облегчает управление этим процессом и дает хорошие сердцебиения и информацию мониторинга.
Slony, с другой стороны, является административным архивом, которому нужно добавить функции триггера и множество других объектов в вашу базу данных для работы. Кроме того, Slony (легко) не поддерживает возможность репликации изменений схемы (DDL) так же, как реплицирует обычные операции вставки / обновления / удаления (DML). В целом, эти характеристики означают, что во многих случаях ваше приложение должно иметь особые случаи для обработки эксцентриситетов Слони. На мой взгляд, это плохо: приложение не должно знать или вносить изменения, чтобы иметь дело с решением для репликации базы данных, на котором оно работает. Большую часть года я потратил на то, чтобы взломать Slony для работы в качестве стабильного решения для репликации, и в конце концов пришел к выводу, что это плохая идея / плохая механика репликации, реализованная тупым, неразборчивым способом, которая не является стабильной или готовой для предприятия, РЕДАКТИРОВАТЬ: начиная с PostgreSQL 9.3 вы можете устанавливать триггеры (которые Slony использует для обнаружения изменений) на объекты DDL, что может позволить Slony реплицировать больше аспектов базы данных.
Тем не менее, Slony делает две вещи лучше, чем потоковая репликация (администрируется через PGPool или нет):
- Slony позволяет репликацию для каждой таблицы или базы данных. Потоковая репликация разрешает репликацию только всего экземпляра Postgres. Если для вас важна такая гранулярность, вы можете захотеть Слони.
- Slony позволяет осуществлять каскадную (master -> slave -> slave) репликацию. Потоковая репликация допускает только один уровень. РЕДАКТИРОВАТЬ: Это теперь поддерживается в собственной потоковой репликации PostgreSQL, начиная с Postgres версии 9.2.
Практически во всем остальном потоковая репликация лучше и стабильнее.
Но вы не просто спрашиваете о потоковой репликации: PGPool делает гораздо больше. Он позволяет балансировать нагрузки чтения и записи между подчиненными базами данных и мастерами только для чтения, а также реализовывать планы резервного копирования, а также целый ряд других вещей. Особенно по сравнению с загадочным синтаксисом команд Слони и богатыми административными сценариями, PGPool побеждает почти в каждом случае.
Что касается отработки отказа, PGPool имеет мониторы сердцебиения и возможность автоматической маршрутизации трафика базы данных в кластере. У Slony есть только команда "перейти на подчиненное устройство", оставляя все функции мониторинга и приложений на ваше усмотрение.
TL; DR: PGPool хорошо. Слон плохо.