Ваше решение имеет тот же недостаток, что и любое другое внешнее кластерное ПО - нужно дополнительно обеспечивать отказоустойчивость самих компонент этого внешнего ПО
точка доступа находится внутри postgrespro на каждом узле, поэтому не требуется дополнительное резервное копирование и построение дополнительной отказоустойчивости для неё
проблема видимости транзакций и локального коммита при прерывании тех транзакций , которые ещё ожидают подтверждения от реплики , может решиться просто отсутствием такого ожидания как такового, например наличием второй кворумной синхронной реплики. В BiHA есть узел рефери с WAL, для которого не требуется делать дополнительную копию всей БД, что экономит дисковое пространство, и этот рефери может также подтверждать транзакции для синхронного режима, что устранит проблемы , вытекающие из-за долгого ожидания с синхронной реплики.
На PGConf 2025 Василий Пучков проводил мастеркласс по резервному копированию BiHA. Мы скоро по его материалам выпустим статью на habr. Но если кратко, то лучше всего использовать pg_probackup (он идет в поставке с Postgres Pro), резервную копию можно делать с любого узла. При восстановлении одного узла кластера нужно сначала исключить этот узел из кластера (выполнить на лидере biha.remove_node()), а затем использовать опцию --restore-as-replica, перед запуском экземпляра: удалить файлы конфигурации BiHA и добавить восстановленный экземпляр в BiHA кластер через bihactl add с опцией --convert-standby, и только потом запускать экземпляр на этом узле. Если вы потеряли весь кластер, то восстанавливается сначала только один узел, он станет лидером в режиме только чтение, исключить все остальные узлы из кластера (выполнить biha.remove_node() для каждого узла), а затем восстановить остальные узлы по процедуре выше (или создать их с нуля без использования резервной копии на основе лидера bihactl add).
Ваше решение имеет тот же недостаток, что и любое другое внешнее кластерное ПО - нужно дополнительно обеспечивать отказоустойчивость самих компонент этого внешнего ПО
точка доступа находится внутри postgrespro на каждом узле, поэтому не требуется дополнительное резервное копирование и построение дополнительной отказоустойчивости для неё
проблема видимости транзакций и локального коммита при прерывании тех транзакций , которые ещё ожидают подтверждения от реплики , может решиться просто отсутствием такого ожидания как такового, например наличием второй кворумной синхронной реплики. В BiHA есть узел рефери с WAL, для которого не требуется делать дополнительную копию всей БД, что экономит дисковое пространство, и этот рефери может также подтверждать транзакции для синхронного режима, что устранит проблемы , вытекающие из-за долгого ожидания с синхронной реплики.
На PGConf 2025 Василий Пучков проводил мастеркласс по резервному копированию BiHA. Мы скоро по его материалам выпустим статью на habr. Но если кратко, то лучше всего использовать pg_probackup (он идет в поставке с Postgres Pro), резервную копию можно делать с любого узла. При восстановлении одного узла кластера нужно сначала исключить этот узел из кластера (выполнить на лидере biha.remove_node()), а затем использовать опцию --restore-as-replica, перед запуском экземпляра: удалить файлы конфигурации BiHA и добавить восстановленный экземпляр в BiHA кластер через bihactl add с опцией --convert-standby, и только потом запускать экземпляр на этом узле. Если вы потеряли весь кластер, то восстанавливается сначала только один узел, он станет лидером в режиме только чтение, исключить все остальные узлы из кластера (выполнить biha.remove_node() для каждого узла), а затем восстановить остальные узлы по процедуре выше (или создать их с нуля без использования резервной копии на основе лидера bihactl add).
"Что касается host=pgnode-01, pgnode-02, pgnode-03 ... 1С выберет его и рухнет с ошибкой"
1С не рухнет, обратите внимание на параметр target_session_attrs=read-write , в нём весь фокус