Да все в порядке, я понял ваш подход, который в целом верный, есть автоматический фейловер, а чинить зовём инженера, который работает руками. Для 1-10 кластеров это приемлемо. Но когда их 100+ уже затруднительно. Спасибо вам за статью. Действительно для PostgresPro его нужно пересобирать, благо разработчик любезно предоставляет для таких целей дев пакеты. Pg_auto_failover вполне пригодное решение, особенно мне нравится монитор, который, будучи один, может обслуживать довольно много кластеров.
А вы как-то решили проблему с тем, что в случае выхода узла кластера из строя, или новый инстанс инициализируется путём снятия резервной копии с мастера и это pg_basebackup, что в случае большой базы может привести к неприятным эффектам? pg_auto_failover в отличие от patroni не умеет автоматически создавать реплики из последнего актуального бекапа не нагружая при этом мастер.
Вот что не хватает в этом обзоре, так это брифа прошедших конференций по PostgreSQL в Австрии и Германии. Там было интересное.
Да все в порядке, я понял ваш подход, который в целом верный, есть автоматический фейловер, а чинить зовём инженера, который работает руками. Для 1-10 кластеров это приемлемо. Но когда их 100+ уже затруднительно. Спасибо вам за статью. Действительно для PostgresPro его нужно пересобирать, благо разработчик любезно предоставляет для таких целей дев пакеты. Pg_auto_failover вполне пригодное решение, особенно мне нравится монитор, который, будучи один, может обслуживать довольно много кластеров.
А вы как-то решили проблему с тем, что в случае выхода узла кластера из строя, или новый инстанс инициализируется путём снятия резервной копии с мастера и это pg_basebackup, что в случае большой базы может привести к неприятным эффектам? pg_auto_failover в отличие от patroni не умеет автоматически создавать реплики из последнего актуального бекапа не нагружая при этом мастер.