ID de la causa db-failover · Responsable principal Infraestructura de BD (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Cuando la BD principal cae, no se puede escribir mientras se cambia a la de respaldo, y los últimos datos que no llegaron a replicarse pueden perderse.
Por qué Por un fallo de la BD principal, se promueve la BD de respaldo → Efecto No se puede escribir durante el cambio, que dura de varios segundos a unos minutos; con replicación asíncrona, pueden perderse los datos no replicados → En pantalla Todos los guardados fallan durante un momento, rollback de objetos y experiencia
Responsable principal Infraestructura de BD (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Hacer guardados que se puedan reintentar, configurar el pool de conexiones y la caché de DNS para abandonar pronto las conexiones cortadas y reconectar a la nueva dirección, comprobar la reconexión en los simulacros de failover.
Tareas (Equipo de infraestructura)
Usar replicación síncrona o semisíncrona (a cambio de más latencia de escritura), hacer simulacros de failover, monitorear el tiempo de failover y el retraso de replicación.
Cifras de referencia
El failover automático de una BD gestionada suele tardar de decenas de segundos a 2 minutos. Con replicación asíncrona, se pueden perder los guardados más recientes, en la medida del retraso de replicación (de menos de 1 s a varios segundos).
En el gráfico
Desconexión masiva · Número de conexiones a la BD, número de errores de escritura
Dónde mirar
Poner en un mismo gráfico el registro de failover de la BD (en RDS, los eventos RDS-EVENT-0013, inicio del failover, y RDS-EVENT-0049, failover completado; en BD autogestionadas, el log de la promoción) y las conexiones a la BD y los errores de conexión del servidor del juego. Con replicación asíncrona, revisar también el retraso de replicación justo antes del fallo (ReplicaLag en RDS, replay_lag de pg_stat_replication en PostgreSQL)
Se confirma si
Los fallos al guardar se concentran en un intervalo que coincide con el periodo entre el inicio y el final del failover. Lo que se revirtió equivale más o menos al retraso de replicación justo antes del fallo. Los servidores del juego que siguen con errores después del failover continúan usando conexiones abiertas con la dirección antigua
Se descarta si
Las desconexiones a horas sin registro de failover apuntan a la red o a una sobrecarga de la BD
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Failing over a Multi-AZ DB instance for Amazon RDSAWS Un failover Multi-AZ suele tardar 60–120 s; después hay que volver a abrir las conexiones, y se recomienda un TTL de caché de DNS de la JVM de 60 s o menos
High availability for Amazon AuroraAWS Durante el fallo fallan las lecturas y escrituras, y la recuperación suele llegar en menos de 60 s (a menudo en menos de 30 s)
Semisynchronous ReplicationMySQL Con replicación asíncrona, si la BD principal cae, puede que una transacción confirmada no esté en la réplica; la semisíncrona lo reduce esperando la confirmación de recepción de una réplica, a cambio de más latencia
Log-Shipping Standby Servers (PostgreSQL Documentation)PostgreSQL El envío de logs es asíncrono, así que si el servidor principal cae se pierden las transacciones que aún no se enviaron; el retraso de la replicación en streaming suele ser de menos de 1 s