Failover automático de Postgres, self-hosted

A maioria das configurações de “Postgres self-hosted” é, na verdade, só Postgres num servidor. Se esse servidor cai, o seu banco de dados também cai, e a recuperação significa achar o seu último backup e esperar que ele seja recente o suficiente. Tudo bem pra um projeto pessoal. Não tá tudo bem quando uma indisponibilidade do banco de dados significa que o seu produto está fora do ar.

A Railyard trata isso como um problema de plataforma, não algo que toda equipe deveria ter que montar sozinha com Patroni, repmgr, ou um script feito à mão que observa o pg_stat_replication e reza.

O que um servidor de banco de dados realmente é

Um servidor de banco de dados é um dos seus próprios servidores — um droplet da DigitalOcean, uma máquina da Hetzner, o que quer que você tenha conectado — que guarda dados e nada mais. Ele não recebe proxy web, nem ferramentas de build, e nenhuma aplicação nunca é implantada nele. As portas dele só ficam abertas pros servidores de aplicação que realmente o usam.

Adicione um standby quando você criar o servidor (planos Pro e Team), e a Railyard mantém uma cópia viva e continuamente atualizada do Postgres, MySQL e Redis num segundo servidor. Você não configura a replicação você mesmo; ela sobe automaticamente quando os dois servidores estão online.

O que acontece quando o primário morre

A Railyard checa todo standby a cada 5 minutos e mostra o quanto ele está atrasado. Se um servidor de banco de dados parar de responder por 3 minutos e o standby dele também tiver perdido contato de forma independente — uma checagem deliberadamente dos dois lados, pra que um probleminha de rede do próprio standby não cause uma promoção falsa — o standby assume:

1. Ele começa a servir os dados nas portas usuais.
2. Toda aplicação que usa esse servidor de banco de dados refaz o deploy contra ele, automaticamente.
3. O point-in-time recovery volta a funcionar ali.
4. Você recebe uma notificação listando exatamente o que mudou.

Ninguém precisa entrar via SSH e rodar pg_promote() às 3 da manhã. Se você preferir decidir sozinho — o primário ainda está parcialmente de pé e você não confia num cutover automático ainda — Promote by hand faz a mesma troca sob demanda, a partir da página de qualquer um dos dois servidores.

O que não sobrevive ao cutover

Ser honesto sobre isso importa mais do que a própria funcionalidade. Escritas que o antigo primário recebeu nos últimos segundos antes de cair podem ser perdidas — essa é a troca real da replicação assíncrona, e é a mesma troca que todo Postgres gerenciado com standby faz, incluindo a Railyard. O Elasticsearch e um Redis dedicado por aplicação não são replicados, então começam vazios no novo primário (as aplicações reindexam o Elasticsearch automaticamente depois do redeploy delas; um cache simples se reconstruindo normalmente é invisível pros usuários).

Quando o servidor antigo volta a ficar online, a página dele no painel diz claramente que ele foi substituído e que nada está usando os dados dele, agora obsoletos. Make it the new standby copia dados novos a partir do novo primário, então a próxima falha também fica coberta — a dupla se repara em vez de ficar rodando desprotegida silenciosamente até alguém notar.

Por que isso é diferente de “só usa o RDS”

Isso não é um substituto pra um banco de dados gerenciado se o que você realmente quer é entregar o problema inteiro pra AWS — a Railyard também dá suporte a isso, você pode apontar uma aplicação direto pra uma URL externa de RDS, ElastiCache, ou Elastic Cloud. A diferença é pro caso muito mais comum: um banco de dados Postgres rodando num servidor que é seu, com o preço do que esse servidor realmente custa, que ainda assim faz failover igual à versão gerenciada. Equipes saindo do Heroku Postgres encontram especificamente essa lacuna — o failover gerenciado do Heroku desaparece no momento em que você sai, e a maioria das configurações self-hosted nunca substitui isso.

Protegido por padrão também significa com backup por padrão: todo banco de dados de aplicação num servidor de banco de dados recebe um backup diário, e cada um é checado restaurando de verdade, não só considerado bom. Veja Database servers pro quadro completo, incluindo connection pooling e upgrades de Postgres, Autoscaling and failover pra como isso se encaixa com o failover no nível da aplicação, ou servidor de banco de dados vs. add-on de banco de dados pra exatamente quando essa proteção entra em ação em comparação com o padrão mais barato.