1. Создаёшь в их облаке кластер Postgres, по умолчанию будет два узла.
2. Узлы публично доступны по конкретным FDQN.
3. Во время техобслуживания текущий мастер могут вырубить, тогда реплика становится новым мастером.
4. После завершения работ мастер так и остаётся мастером.
5. FDQN для мастера больше не работает.
6. Читает документанию, находишь FDQN, который всегда указывает на текущего мастера.
7.

Использование особого FQDN упрощает написание приложений, но приводит к временной недоступности кластера при переключении на новый мастер. Для быстрого переключения на новый мастер необходимо реализовать на стороне приложения отслеживание смены мастера.

ах-ха-ха, Яндекс, прекрати, что ты делаешь. Переворачивание бинарных деревьев in-place совсем разжижило мозг, затем кто-то из разработчиков пукнул в лужу, и решили это назвать облачной инфраструктурой.

P.S. В английской версии документации написано что-то типа "особый FDQN может быть использован, только если ваше приложение сможет пережить 10-ти минутные моменты недоступности мастера" Я бы очень хотел посмотреть на приложение, которое:

1. Требует HA для БД.
2. Может пожить 10 минут без доступа к БД.

Здравствуйте, cppguard, Вы писали:

C>Я бы очень хотел посмотреть на приложение, которое:

C>1. Требует HA для БД.
C>2. Может пожить 10 минут без доступа к БД.

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

Именно так и делается в HA-приложениях.

А твои претензии к FQDN стоит переадресовать к протоколу DNS — станет понятно откуда возникают 10 минут

Здравствуйте, Буравчик, Вы писали:

Б>Именно так и делается в HA-приложениях.

Конечно же, нет. В нормальных облаках, например, гугловском, всё есть из коробки.

Б>А твои претензии к FQDN стоит переадресовать к протоколу DNS — станет понятно откуда возникают 10 минут

Конечно. Только зачем использовать DNS для HA? Есть другие решения.

Здравствуйте, Буравчик, Вы писали:

Б>Написано же явно: Для быстрого переключения на новый мастер необходимо реализовать на стороне приложения отслеживание смены мастера.
Б>Именно так и делается в HA-приложениях.

Как-то очень категорично. Обязательно это делать в приложениях? А stolon для чего сделан?

Б>А твои претензии к FQDN стоит переадресовать к протоколу DNS — станет понятно откуда возникают 10 минут

А можно конкретное место в протоколе DNS? И почему сделанные в cloudflare изменения приходят за секунды, если кто-то не настроил специальные кеши?

Здравствуйте, cppguard, Вы писали:

c> ах-ха-ха, Яндекс, прекрати, что ты делаешь. Переворачивание бинарных деревьев in-place совсем разжижило мозг, затем кто-то из разработчиков пукнул в лужу, и решили это назвать облачной инфраструктурой.

Ну если уж на то пошло, то использовать DNS для HA в данном сценарии — это крайне плохая идея (если HA тебе действительно нужен). Скорее всего данную возможность оставили для всякого legacy или мелких приложений, где принимаются риски подобного решения. О чем и пишут в документации.

c> Я бы очень хотел посмотреть на приложение, которое:
c> 1. Требует HA для БД.
c> 2. Может пожить 10 минут без доступа к БД.

Да в общем-то любой сценарий сложнее WordPress. Ведь здесь речь не только про HA, но и например про разделение read/write, про наличие актуальных данных в случае умирания мастера (доступностью приложения при этом вполне могут жертвовать).