ID da causa db-failover · Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando o BD primário cai, não dá para gravar durante a troca para o BD reserva, e os últimos dados que não foram replicados podem se perder.
Por quê Uma falha no BD primário faz o BD reserva ser promovido → Efeito Durante a troca, escrita indisponível por alguns segundos a alguns minutos; com replicação assíncrona, dados não replicados podem se perder → Na tela Todos os salvamentos falham por um momento, rollback de itens e experiência
Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Fazer salvamentos que possam ser repetidos com segurança, configurar para descartar rápido as conexões quebradas e reconectar no novo endereço (pool de conexões, cache de DNS), verificar a reconexão nos treinamentos de failover.
O que fazer (Equipe de infraestrutura)
Usar replicação síncrona ou semissíncrona (em troca de mais latência de escrita), fazer treinamentos de failover, monitorar o tempo de failover e o atraso de replicação.
Números de referência
O failover automático de um BD gerenciado leva em geral de dezenas de segundos a 2 minutos. Com replicação assíncrona, dá para perder os salvamentos mais recentes, na medida do atraso de replicação (de menos de 1 s a alguns segundos).
No gráfico
Queda de conexões em massa · Conexões com o BD, erros de escrita
Onde olhar
Colocar no mesmo gráfico os registros de failover do BD (no RDS, os eventos RDS-EVENT-0013, início do failover, e RDS-EVENT-0049, failover concluído; em BD autogerenciado, o log de promoção) e o número de conexões e de erros de conexão com o BD nos servidores do jogo. Com replicação assíncrona, ver também o atraso de replicação logo antes da falha (ReplicaLag no RDS, replay_lag no pg_stat_replication do PostgreSQL)
Confirma se
As falhas de salvamento se concentram em um intervalo que coincide com o período entre o início e a conclusão do failover. O volume revertido é parecido com o atraso de replicação logo antes da falha. Servidores do jogo que continuam com erro depois do failover ainda estão usando conexões abertas com o endereço antigo
Descarta se
Conexões caindo em horários sem registro de failover: mais provável, rede ou sobrecarga do BD
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Failing over a Multi-AZ DB instance for Amazon RDSAWS Failover Multi-AZ leva em geral 60–120 segundos; depois dele é preciso reconectar, e recomenda-se TTL de cache de DNS da JVM de no máximo 60 segundos
High availability for Amazon AuroraAWS Durante a falha, leituras e escritas falham, e a recuperação costuma acontecer em até 60 segundos (muitas vezes em até 30)
Semisynchronous ReplicationMySQL Com replicação assíncrona, se o BD primário cai, transações já confirmadas podem não estar na réplica; a semissíncrona reduz esse risco esperando a confirmação de recebimento de uma réplica, em troca de mais latência
Log-Shipping Standby Servers (PostgreSQL Documentation)PostgreSQL O envio de logs é assíncrono, então, se o servidor primário cai, as transações ainda não enviadas se perdem; o atraso da replicação por streaming costuma ser menor que 1 segundo