Блокируются ли серверы подписчиков PostgreSQL при синхронизации с обновлением на сервере издателя?

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

  • Db1: only for writes, publisher
    • Db2: only for reads, subscriber to Db1
    • Db3: только для чтения, подписчик на Db1

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

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

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

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

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


postgresql replication logical-replication
person Seu Madruga    schedule 26.10.2019    source источник

Ответы (1)


arrow_upward
-1
arrow_downward

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

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

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

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

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

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

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

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

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

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

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

person jjanes    schedule 26.10.2019
comment
Я отредактировал свой вопрос, чтобы сделать его более понятным. Я не говорю об абсолютной 0 миллисекундной синхронизации. Английский не мой первый язык. Под очередью операций я просто имел в виду любые запросы, ожидающие выполнения, если таковые имеются. Пожалуйста, примите во внимание мои правки в вашем ответе и спасибо за попытку помочь. - person Seu Madruga; 26.10.2019