Perda de progresso por intervalo de salvamento longo Periodic save window

ID da causa db-save-interval · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)

Abrir o card interativo, com figuras e simulações →

Se, para reduzir a carga, o salvamento só acontece a cada alguns minutos, uma queda do servidor nesse intervalo apaga o progresso.

Por quê O estado do personagem é salvo uma vez a cada alguns minutos → Efeito Nesse intervalo, o servidor sofre um crash ou uma falha → Na tela Ao reconectar, o personagem está como estava alguns minutos antes (rollback)

Sintomas: Ação perdida / rollback
Fatores: Perda de pacotes
Quem é afetado: Servidor inteiro, Local ou canal específico
Quando: Aleatoriamente, de vez em quando
Responsável: Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento): Salvar na hora os eventos importantes (trocas, drops raros), registrar um log de alterações.
O que fazer (Equipe de infraestrutura): Verificar se o BD tem folga de IOPS e CPU para aguentar as escritas extras de um intervalo de salvamento menor.
No gráfico: Queda de conexões em massa · Número de conexões, reports de rollback
Onde olhar: Colocar lado a lado o horário do crash ou da falha e o último salvamento dos personagens com rollback reportado (log de salvamento do servidor do jogo ou coluna de data de alteração no BD)
Confirma se: O ponto para onde o personagem voltou coincide com o último salvamento antes do crash, e o tempo perdido é menor que o intervalo de salvamento
Descarta se: O log do servidor do jogo registra o salvamento como concluído e mesmo assim houve rollback: perda de dados no failover do BD (db-failover) ou valor antigo lido da réplica (db-replica-lag)
Como verificar: Exige logs e métricas do servidor ou do cliente do jogo

Fontes

Asynchronous Commit (PostgreSQL Documentation) PostgreSQL
Acumular gravações e enviá-las ao disco mais tarde aumenta a vazão, mas numa falha as transações mais recentes podem se perder (o mesmo trade-off)
Redis persistence Redis
Se o snapshot RDB é feito a cada alguns minutos, é preciso aceitar perder os últimos minutos de dados num encerramento anormal

Veja também

Mesma camada: L12 Banco de dados

Mesmo sintoma (Ação perdida / rollback) em outras camadas

Erro na sincronização do relógio L1 Processo do jogo no cliente
Limite de conexões e portas do gateway NAT na nuvem L5 Equipamentos de rede do data center
Microburst no switch L5 Equipamentos de rede do data center
Ring buffer insuficiente L6 Placa de rede do servidor
Limite de PPS da nuvem excedido L6 Placa de rede do servidor
OOM killer L7 SO do servidor (kernel)
Salto do relógio do sistema (step do NTP) L7 SO do servidor (kernel)
Esgotamento de portas efêmeras em conexões entre servidores L7 SO do servidor (kernel)

Ver o card interativo, com figuras e simulações