Ответ был примерно «я программист , а не администратор 1с,

гугл в помощь». Не суть.

Если основная субд легла, реплику можно сделать автоматически основной?

Спасибо за помощь

Конечно. Любой HA-сервис, вплоть до самописных скриптов.

КРАЙНЕ несоветую. Все реализацыи подобного в постгресе — в среднем несколько хужэ, чем ничего (т.е. ручной файловер). Самая популярная реализацыя при том — настолько хужэ, чем ничего, что непонятно вообще зачем этим можно обмазываться.

То есть при стандартном серверном жэлезе, стандартной серверной с кондицыонированием и стандартном мониторинге (жэлезо, bloat таблиц) — шансы, что вам случайно дернет и навернёт базу шальной failover вроде столона или скриптов к haproxy — несколько вышэ, чем шансы, что что-то реально навернётся само. В случае с patroni — у вас с вероятностью 100% будет периодически пропадать некоторое количество данных на ровном месте, плюс вы задолбаетесь обходить его странности.

https://its.1c.ru/db/metod8dev/content/5971/hdoc На ИТС нашёл такую статью/инструкцию. Т.е. по Вашему не стоит так делать?

Вообще, пристойный автофайловер должэн бы иметь соединение с мониторингом и понимать хотя бы первые сотни проблем, которые приводят к фэйлу. И иметь решэния на большынство решаемых из них (а такжэ планы recovery на нерешаемые). Это сложно написать. И для постгреса ничего похожэго не написано дажэ близко. В реальности оно относится к постгресу как к чёрному ящику, который или как-то работает или не как-то работает — что очень плохо, и в основном приводит к лишним свитчоверам и ускорению падения.

В качестве job security — вполне можно. Особенно если за просер данных вас не будут убивать.

В качестве отказоустойчивого решэния — ни в коем случае.

Зачем тогда это выкладывать на ИТС, неужели там тоже студенты первого курса …

Затем, что это прекрасный ответ на подобные вопросы: https://t.me/PostgreSQL_1C_Linux/154917 Не "вам это ненужно", а "вот, у нас есть". Очень положытельно влияет на удовлетворённость клиентов и продажы.

Да, людям очень нравится чувствовать себя мощным админом масштабируемого решэния. Мульти-мастер, партицыонирование, автофайловер. Примерно каждый первый новичок спрашывает про это, когда получает ответ "этого нет" — кидается написать.

Потом, через пару лет — ещё и хвалебный отчёт пишэт. "Вот, у нас джва года ужэ работает — как часы. Ответственнейшый сервис, продолжает работу. Дажэ когда вот админы решают сетевуху там какую-нибудь поменять — всё автоматически переключается на слейв и продолжает работать!"

Для защиты от простоя какое-то решение существует?

Для абсолютной — нет. Для относительной — мониторинг, тех.поддержка on-site 24x7 с тренингами свитчовера/редеплоя и 100% доступность инжэнера.

И да, если потери от простоя в ночь с пятницы на понедельник меньшэ годовой зарплаты тем дополнительным 4 человекам в ТП on-site и нахождения инжэнеров on-call — то можэт и не требуется вкладываться в повышэние надёжности? Подавляющее большынство инсталляцый могут проваляться день-другой без большого ущерба...