Блокируются ли серверы подписчиков PostgreSQL при синхронизации с обновлением на сервере издателя? - PullRequest
0 голосов
/ 26 октября 2019

Если у меня есть 3 базы данных

  • Db1: только для записи, издатель
    • Db2: только для чтения, подписчик на Db1
    • Db3: только для чтенияподписчик на Db1

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

Некоторые вопросы, ответы на которые я не смог найти, просматривая официальную документацию для логической репликации :

  • В сценарии, где есть новая запись в Db1, блокируются ли Db2 и Db3 при синхронизации с изменениями, или они позволят выполнять чтение параллельно с синхронизацией?

  • Если сервер подписчика выполняет чтение к моменту публикации нового изменения в Db1, будет ли доступное изменение следующей операцией, которая будет выполнена, как только они поступят к подписчику, независимо от того, сколькочтения уже ожидали выполнения (если они есть)?

Меня беспокоит согласованность в кластере с балансировкой нагрузки (только для чтения) серверов PostgreSQL, которые являются репликами Db1. Все они должны синхронизироваться с Db1, не допуская новых чтений к ним, прежде чем синхронизироваться с новыми изменениями, опубликованными Db1. Если я не могу сделать это с помощью логической репликации, то каковы альтернативы, если таковые имеются?

1 Ответ

0 голосов
/ 26 октября 2019

В сценарии, где есть новая запись в Db1, блокируют ли Db2 и Db3 чтение при обновлении?

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

Будут ли какие-либо ожидания завершения текущих чтений перед синхронизацией с Db1 - даже на многоядерном сервере?

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

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

Что такое «очередь операций»? Я не верю, что PostgreSQL имеет один.

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

Дажеесли все запросы выполняются на одном и том же сервере, вы не можете контролировать, будет ли запрос только для чтения выполнять наносекунду до того, как что-то еще зафиксировано, или наносекунду после. Даже с сериализуемым уровнем изоляции вы гарантированно существует только последовательный порядок транзакций. Вам не говорят, что это за порядок, и вам не разрешено смотреть на что-то вроде clock_timestamp (), чтобы понять это. Если запрос «только для чтения» должен убедиться, что что-то стоит, он должен его заблокировать.

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

Если я не могу сделать это с помощью логической репликации, то каковы альтернативы, если таковые имеются?

Хочешь что-то другое. Вы не можете сделать это даже на одном сервере.

...