Failover automático de Postgres, self-hosted

La mayoría de los setups de “Postgres self-hosted” son, en realidad, solo Postgres corriendo en un servidor. Si ese servidor se cae, tu base de datos se cae con él, y recuperarte significa buscar tu último backup y esperar que sea reciente. Eso está bien para un proyecto personal. Deja de estar bien en el momento en que una caída de la base de datos significa que tu producto está caído.

Railyard trata esto como un problema de la plataforma, no algo que cada equipo tenga que armar a mano con Patroni, repmgr o un script casero que vigila pg_stat_replication y reza.

Qué es realmente un servidor de base de datos

Un servidor de base de datos es uno de tus propios servidores —un droplet de DigitalOcean, una máquina de Hetzner, lo que sea que hayas conectado— que guarda datos y nada más. No recibe proxy web, no recibe herramientas de build, y nunca se despliega ninguna app en él. Sus puertos solo están abiertos a los servidores de apps que realmente lo usan.

Agrega un standby al crearlo (planes Pro y Team) y Railyard mantiene una copia en vivo, siguiendo continuamente, de Postgres, MySQL y Redis en un segundo servidor. No configuras la replicación tú mismo; se activa sola en cuanto ambos servidores están en línea.

Qué pasa cuando el primario muere

Railyard revisa cada standby cada 5 minutos y te muestra cuánto se ha quedado atrás. Si un servidor de base de datos deja de responder durante 3 minutos y su standby también perdió contacto con él por su cuenta —una comprobación deliberada en dos sentidos, para que un bache de red en el propio standby no dispare una promoción falsa—, el standby toma el control:

1. Empieza a servir los datos en los puertos de siempre.
2. Cada app que usa ese servidor de base de datos se redespliega contra él, automáticamente.
3. La recuperación a un punto en el tiempo se reactiva ahí.
4. Recibes una notificación con el detalle exacto de qué se movió.

Nadie tiene que entrar por SSH y correr pg_promote() a las 3 de la mañana. Si prefieres decidirlo tú —el primario sigue medio en pie y todavía no confías en un cutover automático—, Promover a mano hace el mismo traspaso a demanda, desde la página de cualquiera de los dos servidores.

Qué no sobrevive al cutover

Ser honesto sobre esto importa más que la funcionalidad en sí. Las escrituras que el viejo primario recibió en sus últimos segundos antes de apagarse pueden perderse —esa es la contrapartida real de la replicación asíncrona, y es la misma que hace cualquier Postgres administrado con standby, Railyard incluido. Elasticsearch y un Redis dedicado por app no se replican, así que arrancan vacíos en el nuevo primario (las apps reindexan Elasticsearch automáticamente después de su redespliegue; una caché en blanco reconstruyéndose suele ser invisible para los usuarios).

Cuando el servidor viejo vuelve a estar en línea, su página en el panel dice sin rodeos que fue reemplazado y que nada está usando sus datos, ya obsoletos. Convertir en el nuevo standby copia datos frescos desde el nuevo primario, así que la próxima falla también queda cubierta: el par se repara solo en vez de seguir corriendo desprotegido en silencio hasta que alguien lo note.

Por qué esto es distinto a “simplemente usa RDS”

No es un reemplazo de una base de datos administrada si lo que realmente quieres es entregarle todo el problema a AWS —Railyard también lo permite, puedes apuntar una app directo a una URL externa de RDS, ElastiCache o Elastic Cloud. La diferencia está pensada para el caso mucho más común: una base de datos Postgres corriendo en un servidor que tú posees, con el precio que ese servidor realmente cuesta, y que aun así hace failover como lo haría la versión administrada. Los equipos que migran desde Heroku Postgres se topan específicamente con este vacío: el failover administrado de Heroku desaparece en el momento en que te vas, y la mayoría de los setups self-hosted nunca lo reemplazan.

Protegido por defecto también significa respaldado por defecto: cada base de datos de app en un servidor de base de datos recibe un backup diario, y cada uno se verifica restaurándolo de verdad, no solo asumiendo que está bien. Mira Servidores de base de datos para el panorama completo, incluyendo connection pooling y actualizaciones de Postgres, Autoescalado y failover para ver cómo esto encaja con el failover a nivel de app, o servidor de base de datos vs. complemento de base de datos para saber exactamente cuándo entra esta protección frente a la opción más económica por defecto.