Pérdida de progreso por intervalos de guardado largos Periodic save window

ID de la causa db-save-interval · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)

Abrir la ficha interactiva con gráficos y simulaciones →

Si para reducir la carga solo se guarda una vez cada varios minutos, cuando el servidor se cae entre dos guardados se pierde el progreso.

Por qué El estado del personaje se guarda una vez cada varios minutos → Efecto Entre un guardado y otro se produce un crash o un fallo del servidor → En pantalla Al volver a conectar, el personaje está como hace unos minutos (rollback)

Síntomas: Acción perdida / rollback
Factores: Pérdida de paquetes
A quién afecta: Todo el servidor, Una zona o un canal
Cuándo: De vez en cuando, al azar
Responsable: Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Tareas (Equipo de desarrollo): Guardar al instante los eventos importantes (intercambios, obtención de objetos raros), registrar un log de cambios.
Tareas (Equipo de infraestructura): Comprobar que la BD tiene margen de IOPS y CPU para la escritura adicional que supone acortar el intervalo de guardado.
En el gráfico: Desconexión masiva · Número de conexiones, número de reportes de rollback
Dónde mirar: Poner lado a lado la hora del crash o el fallo y la hora del último guardado de los personajes que reportaron rollback (log de guardados del servidor del juego o columna de fecha de modificación en la BD)
Se confirma si: El punto al que volvió coincide con el último guardado antes del crash, y el tiempo perdido es menor que el intervalo de guardado
Se descarta si: Si el log del servidor del juego dice que el guardado terminó y aun así se revirtió, apunta a la pérdida de datos de un failover de la BD (db-failover) o a valores antiguos leídos de una réplica (db-replica-lag)
Se verifica con: Requiere logs y métricas del servidor o el cliente del juego

Fuentes

Asynchronous Commit (PostgreSQL Documentation) PostgreSQL
Agrupar las escrituras y pasarlas a disco más tarde aumenta el throughput, pero ante un fallo pueden perderse las transacciones más recientes (el mismo compromiso)
Redis persistence Redis
Si se hace una instantánea RDB cada pocos minutos, hay que asumir que un cierre anómalo puede hacer perder los datos de los últimos minutos

Ver también

Misma capa: L12 Base de datos

Causas de otras capas con el mismo síntoma (Acción perdida / rollback)

Error de sincronización del reloj L1 Proceso del juego en el cliente
Límites de conexiones y puertos del gateway NAT en la nube L5 Equipos de red del centro de datos
Microrráfagas en el switch L5 Equipos de red del centro de datos
Búfer circular (ring buffer) insuficiente L6 Tarjeta de red del servidor
Límite de PPS de la nube superado L6 Tarjeta de red del servidor
OOM killer L7 SO del servidor (kernel)
Salto del reloj del sistema (step de NTP) L7 SO del servidor (kernel)
Agotamiento de puertos efímeros en conexiones entre servidores L7 SO del servidor (kernel)

Ver la ficha interactiva con gráficos y simulaciones