«Потоковая репликация» относится к непрерывной отправке записей WAL по TCP / IP-соединению между ведущим и репликой с использованием протокола Walsender по replicationсоединениям. Мастер считывает свой собственный WAL pg_xlogи отправляет его в реплику по требованию. Он настроен с помощью primary_conninfoдирективы in recovery.confи pg_hba.confзаписей на ведущем устройстве, чтобы разрешить replicationсоединения. Вам также понадобятся wal_keep_segmentsи некоторые другие варианты, описанные в документах.
«Доставка журналов» означает периодическую отправку записей WAL как целых архивов WAL по протоколу передачи файлов в местоположение архива, откуда реплика может затем извлечь их. Это настроено с restore_commandдирективой в recovery.confи archive_commandв мастере. PostgreSQL не волнует, где находятся файлы и как они передаются, только то, что они помещают archive_commandих туда и restore_commandизвлекают необходимый архив; это позволяет создавать такие системы, как PgBarman и WAL-E.
Потоковая репликация не имеет такой большой задержки, поскольку записи отправляются по мере их генерации. Однако для этого требуется, чтобы и мастер, и реплика были подключены к сети и могли напрямую общаться. Также требуется, чтобы реплика поддерживалась достаточно хорошо, чтобы мастер по-прежнему имел на диске копии WAL, необходимые для реплики, и, как правило, требует, чтобы вы тратили дополнительное pg_xlogпространство на сохранение дополнительного WAL для реплики.
Репликация доставки журналов имеет большую задержку, потому что реплика видит WAL только после отправки всего архива. Однако он может работать даже тогда, когда мастер и реплика не могут напрямую взаимодействовать по TCP / IP с использованием общего хранилища. Он продолжает работать, даже если реплика не работает некоторое время, потому что мастер отменит WAL pg_xlogтолько после его архивирования, поэтому WAL все еще находится в архиве и может использоваться репликой, даже если мастер не может отправить его потоковым больше. Обратите внимание, что archive_commandникогда не сдается, поэтому pg_xlogможет заполниться, если архивирование не удается; по этой причине лучше архивировать в надежное место, а затем получить сервер реплики из этого места.
В общем, вы фактически комбинируете два, то есть используете оба. В этом случае потоковая репликация используется, когда все идет хорошо. Если реплика слишком сильно отстает, и мастер отбросил необходимые ей xlogs, возникнут проблемы с подключением и т. Д., То реплика переключится на чтение архивированной WAL, пока не будет захвачена. Он будет периодически повторять попытку возврата к потоковой передаче, пока это не удастся.
Если вы собираетесь использовать только один, используйте доставку журналов, потому что потоковая репликация без резервирования доставки журналов (до PostgreSQL 9.4) потенциально склонна к задержке репликации, вызывая сбои, которые вынуждают повторную сборку реплики.
PostgreSQL 9.4 немного меняет это, потому что потоковая репликация теперь может использовать «слоты репликации». Это позволяет мастеру отслеживать, сколько WAL нужно реплике, и избегать его выбрасывания, пока реплика не воспроизведет его. Так что больше нет необходимости, wal_keep_segmentsесли вы используете слот репликации (не по умолчанию).
Смотрите мою статью о слотах потоковой репликации в PostgreSQL 9.4 .
9.4 также представляет основы потоковой логической репликации , которая является еще одним механизмом, разработанным для использования системами логической репликации, такими как Londiste, Slony-I, и новой функцией двунаправленной асинхронной репликации с несколькими хозяевами .