По-моему, проблема рестарта при смене реплика=>мастер не страшна — всё равно даунтайм больше времени рестарта — требуется же задетектить саму проблему, принять решение что надо менять мастера и тп.
Автор, думаю, вы не правы (ну или частично неправы). При втором способе такое прокатит только если будет совершенно случайная ситуация когда на слэйвах после отключения мастера актуальными оказалась одинаковые точки в бинарном логе. При активной работе с БД даже при штатном отключении мастера это очень маловероятно. А уж тем более при падении на мастер метеорита.
Я с этим экспериментировал и мне не удалось вторым способ восстановить работу слэйвов без перезаливки базы.
Не могли бы вы рассказать в чём именно заключалась проблема — я постараюсь её воспроизвести? Дело в том, что переключение со смещенной позицией(когда есть отстающие реплики) я тоже, разумеется, рассматривал — все отработало штатно. В моём случае я тестировался так:
1. Из /dev/urandom в 5-6 потоков льются данные в одну из таблиц.
2. Я закрываю мастер фаерволлом от одной из реплик(дабы спровоцировать отставание), жду пару минут — делал и с этим пунктом и без него.
3. Выключаю мастер.
4. Делаю описанное выше.
Более того, мне известен случай, когда случай, когда подобным образом неоднократно переключали production-кластер. Успешно, разумеется.
Отказ мастера в PostgreSQL-кластере: как быть?