Я не совсем администратор базы данных, поэтому был бы признателен за простые для понимания ответы. Я должен обеспечить репликацию нашей БД, и pgpool кажется более удобным, потому что, если один экземпляр postgresql выходит из строя, клиентам не нужно ничего менять, чтобы продолжить работу, верно? Итак, в этом случае имеет смысл использовать pgpool, но часть настройки кажется (мне) намного более сложной и запутанной. Например, нужно ли мне настроить WAL на обоих серверах postgresql? Или это нужно только если я хочу настроить репликацию postgresql? Чем больше я пытаюсь получить ответ на эти вопросы, тем менее ясным становится. Может я разучился гуглить ...
В чем разница между репликацией pgpool II и репликацией postgresql?
Ответы (1)
Встроенная репликация, предоставляемая самим PostgreSQL, включает потоковую репликацию, горячий и горячий резерв. Эти параметры основаны на доставке журналов предзаписи (WAL) на все резервные серверы. Операторы записи (например, INSERT
, UPDATE
) будут передаваться мастеру, а мастер будет отправлять журналы (WAL) на резервные серверы (или другие мастера в случае репликации мастер-мастер).
pgpool, с другой стороны, представляет собой тип промежуточного программного обеспечения репликации на основе операторов (например, прокси-сервер базы данных). Все операторы фактически отправляются в pgpool, а pgpool перенаправляет все на все серверы для репликации.
Одним из больших недостатков pgpool является то, что у вас есть единственная точка отказа; если сервер, на котором запущен pgpool, выйдет из строя, весь ваш кластер выйдет из строя.
В документации PostgreSQL есть базовая информация о различных возможных типах репликации: https://www.postgresql.org/docs/current/different-replication-solutions.html
repmgr
помогает в этом. Используйте прокси, например PgBouncer (со сценарием, который изменяет целевой сервер при аварийном переключении), или что-то вроде HAProxy, если вы хотите сделать его прозрачным для клиента. Не пытайтесь полностью автоматизировать отработку отказа, используйте запускаемый вручную сценарий отработки отказа и периодически тестируйте. - person Craig Ringer   schedule 23.06.2014