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