Потоковая передача PostgreSQL в сравнении с репликацией на основе файлов (с точки зрения поведения и конфигурации сервера)

Я пытаюсь понять, как лучше всего использовать репликацию PostgreSQL и как она работает, чтобы я мог устранять неполадки в производственной среде.

Мне трудно понять различия между этими 2 типами репликации с точки зрения (1) Конфигурации (2) Как работают два сервера Master / Slave в каждом сценарии

Репликация на PostgreSQL (9.2+) - это, по сути, файлы XLOG размером 16 МБ (в зависимости от настроек частоты для создания каждого файла), которые создаются на Master и отправляются каким-либо способом на Slave.

Моя настройка (для целей этого вопроса)

Конфигурация Postgresql.conf на Master
архив_команда = 'rsync -av% p postgres @ [SlaveIP]: [wal_archive_folder] /% f'

Конфигурация Recovery.conf на
подчиненном устройстве для чтения файлов журнала restore_command = 'cp [wal_archive_folder] /% f \ "% p \"'
primary_conninfo = 'host = [MasterIP] port = 5432 user = postgres'

Мой вопрос: какая часть этой конфигурации делает эту «потоковую» репликацию по сравнению с «доставкой журналов»? Мой мастер настроен на использование rsync для отправки журналов на подчиненное устройство (это доставка журналов?) Мой подчиненный настроен на возможность подключения к мастеру в recovery.conf (это потоковая передача?)

Вторая часть вопроса: что происходит? Я понимаю, что есть другой протокол на PostgreSQL через WAL_sender & WAL_receiver. Но мне не ясно, используется ли это только для потоковой передачи, и если да, то как Rsync используется в Master?

:) Спасибо!! И извините, если это очевидный вопрос. Я много читал блоги / книги, но с трудом понимал. Postgres wiki настолько глубока, что требуется много времени, чтобы пройти через все это (и у меня есть сроки)

«Потоковая репликация» относится к непрерывной отправке записей 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, и новой функцией двунаправленной асинхронной репликации с несколькими хозяевами .