Магнус может быть прав, это может быть просто признаком того факта, что ваша база данных имеет очень высокий трафик. Slony эффективно умножает использование ресурсов любой данной операции DML: не только данные CRUD передаются на мастер репликации, но и каждый раз, когда это происходит, триггер Slony (представленный как слушатель изменений) генерирует идентичную транзакцию и передает ее процесс Slon, который запускает его на других членах кластера.
Однако , есть два других возможных объяснения / решения этой проблемы:
Возможным решением может быть запуск процессов slon на отдельном компьютере от хостов вашей базы данных. Даже если у вас есть схема репликации один главный / один подчиненный, с точки зрения стабильности, разделения ролей и производительности (это вам) выгодно запускать демоны репликации Slon на физически различном наборе оборудования (на одном и том же оборудовании). Сегмент LAN, в идеале). В Slony ничего не говорится о том, что он должен работать на той же машине, что и хост хоста базы данных, поэтому размещение его в другом месте (например, «контроллер трафика») может снизить нагрузку на ресурсы ваших хостов базы данных. Это также хорошая идея с точки зрения как стабильности, так и масштабируемости машины.
Существует также вероятность того, что это только временная проблема, вызванная тем, что вы недавно начали использовать Slony. Когда вы впервые подписываете новый узел на набор репликации, этот узел (и, в некоторой степени, его родитель) испытывает ОЧЕНЬ большую нагрузку на ЦП (и, возможно, также на диск) во время процесса подписки. Я не уверен, как это работает под прикрытием, но, в зависимости от того, сколько данных уже было на подписанном узле, Slony будет либо проверять данные мастера по каждому отдельному фрагменту данных, присутствующему на ведомом устройстве в таблицах, которые реплицируются, и Скопируйте данные в ведомое устройство, если оно отсутствует или отличается. Это потенциально ресурсоемкие операции. Особенно в больших базах данных процесс подписки может занять очень много времени (у меня это заняло один день, но наша база данных превышает 20 ГБ), во время которого загрузка ЦП будет очень высокой. Простой способ узнать, что делает Slony, - это использовать pgAdmin Просмотр состояния сервера , который, хотя и ограничен, даст вам некоторую полезную информацию здесь. Если на узле с высокой загрузкой ЦП выполняется много операций «подготовить таблицу к репликации» или «очистить таблицу после репликации», это, вероятно, связано с тем, что подписка не завершена. Однако просмотрщик статуса pgAdmin не слишком информативен; Есть более надежные способы проверки прогресса подписки с помощью Slony напрямую. Раздел 4.7.6.4 в документации по анализу журнала Slony может помочь с этим, как, например, чтение документа для ПОДПИСКА НА набор (обратите особое внимание на предупреждающее сообщение в штучной упаковке и "Опасный / Unintuitive Behavior ". Простой, но окончательный способ узнать, находится ли набор в процессе подписки, - запустить MERGE SET и попытаться объединить его с пустым (или нет) другим набором. MERGE SET потерпит неудачу с Ошибка «Выполняется подписка», если подписка все еще работает. Однако этот взлом не будет работать в Slony 2.1; MERGE SET просто будет ждать окончания подписки.