Разница между репликацией потока и логической репликацией

TL; DR: логическая репликация отправляет изменения строки за строкой, физическая репликация отправляет изменения блока диска. Логическая репликация лучше подходит для некоторых задач, физическая репликация-для других.

по состоянию на 9.5 логическая репликация довольно незрелая. Используйте физическую репликацию, если вы задаете этот вопрос.

потоковую репликацию может быть логическая репликация. Это все немного сложно.

WAL-доставка vs потоковое

существует два основных способа отправки данных из master в replica в PostgreSQL:

• WAL-доставка или непрерывного архивирования, где отдельные файлы журнала записи вперед копируются из pg_xlog на archive_command запуск на master в другое место. А restore_command настроено в реплике recovery.conf запускает реплику для извлечения архивов, чтобы реплика могла воспроизвести WAL.

  это что используется для точка-в-время репликации (PITR), который используется в качестве метода непрерывного резервного копирования.

  прямое сетевое подключение к главному серверу не требуется. Репликация может иметь длительные задержки, особенно без archive_timeout set. Доставка WAL не может использоваться для синхронной репликации.

• потоковую репликацию, где каждое изменение отправляется на один или несколько серверов реплик непосредственно через TCP / IP-соединение как такое случается. Реплики должны иметь прямое сетевое подключение, настроенное мастером в их recovery.conf ' s .

  потоковая репликация имеет небольшую задержку или нет, пока реплика достаточно быстра, чтобы идти в ногу. Его можно использовать для синхронная репликация. Вы не можете использовать потоковую репликацию для PITR¹ так что это не так много пользы для непрерывного резервного копирования. Если вы уроните таблицу на master, oops, она упадет на реплики тоже.

таким образом, эти два метода имеют разные цели.

асинхронная vs синхронная потоковая передача

кроме того, есть синхронно и асинхронные потоковую репликацию:

• на асинхронная потоковая репликация реплики могут отставать от мастера во времени, когда мастер быстрее / занят. Если мастер разбивает вас можете потерять данные, которые еще не были реплицированы.

  если асинхронная реплика слишком сильно отстает от мастера, мастер может выбросить информацию, необходимую реплике, если wal_keep_segments слишком низкий, и слот не используется, что означает, что вы должны воссоздать реплику с нуля. Или хозяина pg_xlog может заполнить и остановить мастер от работы, пока дисковое пространство не будет освобождено, если wal_keep_segments слишком высоко или используется слот.

• на синхронно репликация мастер не завершает фиксацию, пока реплика не подтвердит, что она получила транзакцию². Вы никогда не теряете данные, если мастер аварийно завершает работу, и вы должны перейти к реплике. Мастер никогда не будет выбрасывать данные, необходимые реплике, или заполнять свой xlog и запускать дисковое пространство из-за задержек реплики. В exchange это может привести к замедлению или даже остановке работы, если у реплик есть проблемы, и это всегда оказывает некоторое влияние на производительность мастер из-за задержки сети.

  когда есть несколько реплик, только одна синхронна одновременно. См.synchronous_standby_names.

вы не можете иметь синхронную доставку журналов.

вы можете фактически объединить доставку журналов и асинхронную репликацию, чтобы защитить от необходимости воссоздавать реплику, Если она слишком отстает, не рискуя повлиять на мастера. Это идеальная конфигурация для многих развертываний в сочетании с контролем, как далеко реплика находится за мастером, чтобы убедиться, что она находится в допустимых пределах аварийного восстановления.

логический vs физический

на это у нас есть логическое vs физическая потоковая репликация, представленная в PostgreSQL 9.4:

• на физическая потоковая репликация изменения отправляются почти на уровне дискового блока, как " при смещении 14 диска Страница 18 отношения 12311, написал кортеж с шестнадцатеричным значением 0x2342beef1222....".

  физическая репликация передает все: содержимое каждой базы данных в установке PostgreSQL, все таблицы в каждой базе данных. Он отправляет записи индекса, он отправляет все новые данные таблицы, когда вы VACUUM FULL, он отправляет данные для транзакции, откат и т. д. Таким образом, он генерирует много "шума" и отправляет много избыточных данных. Он также требует, чтобы реплика была полностью идентична, поэтому вы не можете сделать ничего, что требуется транзакция, например создание временных или незаполненных таблиц. Запрос реплики задерживает репликацию, поэтому длинные запросы реплики должны быть отменены.

  в обмен, это просто и эффективно применять изменения на реплике, и реплика надежно точно так же, как мастер. DDL реплицируется прозрачно, как и все остальное, поэтому не требует специальной обработки. Он также может передавать большие транзакции по мере их возникновения, поэтому между фиксацией мало задержки на master и commit на реплику даже для больших изменений.

  физическая репликация зрелая, хорошо протестирована и широко принята.

• логическая потоковая репликация, нового в 9.4, отправляет изменения на более высоком уровне, и гораздо более избирательно.

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

  работа на более высоком уровне также означает, что вы можете выполнять транзакции в базах данных реплик. Можно создавать временные и незаполненные таблицы. Даже обычные столы, если хотите. Вы можете использовать внешние оболочки данных, представления, создавать функции, что угодно. Нет необходимости отменять запросы, если они выполняются слишком долго любой.

  логическая репликация также может использоваться для построения репликации нескольких мастеров в PostgreSQL, что невозможно с помощью физической репликации.

  в обмен, однако, он не может (в настоящее время) передавать большие транзакции, как они происходят. Это должно подождать, пока они не совершат. Таким образом, может быть длительная задержка между совершением большой транзакции на ведущем устройстве и применением к реплике.

  он воспроизводит транзакции строго в порядке фиксации, поэтому маленький быстрый транзакции могут застрять за большой транзакцией и задерживаться довольно долго.

  DDL не обрабатывается автоматически. Определения таблиц необходимо синхронизировать между мастером и репликой самостоятельно, или приложение, использующее логическую репликацию, должно иметь собственные средства для этого. Это может быть сложно сделать правильно.

  процесс apply сам по себе сложнее, чем "написать несколько байтов, где мне говорят", а также. Это также требует больше ресурсов на реплика, чем физическая репликация.

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

слишком много вариантов, скажите мне, что делать

Фух. Сложно, да? И я даже не вдавался в детали отложенной репликации, слотов,wal_keep_segments, сроки, как промотирование работает, Postgres-XL, BDR и multimaster, etc.

так что вы должны do?

нет единого правильного ответа. В противном случае PostgreSQL будет поддерживать только один способ. Но есть несколько распространенных случаев использования:

на резервное копирование и аварийное восстановление использовать pgbarman чтобы сделать базовые резервные копии и сохранить WAL для вас, обеспечивая простое управление непрерывным резервным копированием. Вы все равно должны принимать периодические pg_dump резервные копии в качестве дополнительной страховки.

на высокая доступность с нулевым риском потери данных использовать потоковая синхронная репликация.

на высокая доступность с низким риском потери данных и производительности вы должны использовать асинхронную потоковую репликацию. Либо включите архивацию WAL для резервного копирования, либо используйте слот репликации. Контролируйте, насколько реплика отстает от мастера, используя внешние инструменты, такие как Icinga.

ссылки

• непрерывное архивирование и PITR
• высокая доступность, балансировка нагрузки и репликация
• настройки репликации
• восстановление.conf
• pgbarman
• repmgr
• wiki: репликация, кластеризация и объединение пулов