FIRST и ANY PostgreSQL: приоритетный набор standby и кворум задают разные ожидания
Фотография конкретного исполнения не приложена.
При синхронной репликации нужно определить, какие подтверждения позволяют завершить транзакцию. Список synchronous_standby_names не является простым перечнем доступных серверов. Его форма задаёт правило выбора участвующих standby и тем самым влияет на задержку и доступность commit.
FIRST выбирает указанное число standby по приоритету их положения в списке. Более поздние участники могут заменять отключившихся выбранных. ANY ждёт необходимое число ответов от любых перечисленных standby. Поэтому одинаковые имена и одинаковое количество сами по себе не делают эти две схемы эквивалентными под разной задержкой участников.
Именем standby здесь служит application_name в соединении. Его нужно сопоставить с реальным узлом и наблюдаемым streaming-состоянием. Запись похожего DNS-имени в конфигурации не подтверждает, что нужная реплика вошла в набор синхронного ожидания. Уровень самого подтверждения дополнительно определяется synchronous_commit.
В приёмке проверяют штатный состав, медленного участника и отключение одного из выбранных. Сопоставляют подтверждающие узлы и время завершения транзакции. Нельзя объявлять кворум независимым от инфраструктуры хранения только по числу процессов: реальные отказовые области и пригодность каждого резервного экземпляра требуют отдельного проектного подтверждения.
Основание — Official PostgreSQL major18 documentation snapshot; stable18.6 observed separately from19RC1, разделы synchronous_standby_names; FIRST; ANY; application_name. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Использована документация ветки PostgreSQL 18; страницы обновляются внутри major-ветки. Версии действующих сервера и libpq, конфигурация и резервные копии не проверялись. Подключения, SQL-команды и восстановление не выполнялись.
Запросы отправляются на наш e-mail из вашей почтовой программы.
