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

Может ли кто-нибудь рассказать мне больше о различии между физической репликацией и логической репликацией в PostgreSQL?

Ответ 1

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

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

Потоковая репликация может быть логической репликацией. Все это немного сложно.

WAL-доставка против потоковой передачи

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

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

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

Не требуется прямого сетевого подключения к главному серверу. Репликация может иметь длительные задержки, особенно без набора archive_timeout. Доставка WAL не может использоваться для синхронной репликации.
потоковая репликация, где каждое изменение отправляется на один или несколько серверов реплик непосредственно по TCP/IP-соединению, когда это происходит. Реплики должны иметь прямое сетевое соединение, которое мастер сконфигурировал в своей опции recovery.conf primary_conninfo.

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

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

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

Кроме того, существует синхронная и асинхронная потоковая репликация:

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

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

При наличии нескольких реплик только один синхронный за раз. См. synchronous_standby_names.

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

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

Логический и физический

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

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

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

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

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

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

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

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

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

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

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

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

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

Слишком много опций, скажите мне, что делать

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

Итак, что вы должны делать?

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

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

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

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