Um rollback reverte operações de escrita em um primary anterior quando ele se junta novamente ao seu conjunto de réplicas após um failover. Os Atlas clusters usam { w: "majority" } como preocupação de gravação padrão para o MongoDB. Com esse padrão, o Atlas reconhece as gravações somente depois de replicá-las para a maioria dos membros. As gravações confirmadas não podem ser revertidas, portanto, uma reversão não resulta em perda de dados.
Se você configurar o preocupação de gravação { w: 1 }, uma reversão poderá afetar as gravações que ainda não foram replicadas. Antes que ocorra uma reversão, planeje como identificar as operações revertidas e decida se devem ser reemitidas.
Para saber mais sobre a mecânica de rollback de conjuntos de réplicas, consulte Rollbacks durante o failover de conjuntos de réplicas.
Comportamento de rollback no Atlas
Quando ocorre um rollback no Atlas, as seguintes condições se aplicam:
O Atlas gera um
HOST_ROLLBACKevento em seu feed de atividades do projeto . Para saber como verificar esse evento, consulte Detectar rollbacks.O Atlas não mantém uma lista de operações revertidas.
Write concern e risco de reversão
Os clusters Atlas usam { w: "majority" } como preocupação de gravação padrão para o MongoDB. Com esse padrão, uma reversão não resulta em perda de dados. A preocupação de gravação que você configura determina se uma reversão pode resultar em perda de dados:
{ w: "majority" }(padrão) — O Atlas reconhece uma gravação somente após a maioria dos membros do conjunto de réplicas confirmá-la. Como a gravação foi replicada antes da saída do primário, uma reversão não pode incluir essas gravações.{ w: 1 }— O Atlas reconhece uma gravação depois que apenas o primário a registra, sem esperar pela replicação para os secundários. Se o primary for desativado antes da escrita ser replicada, a escrita poderá ser revertida e os dados poderão não ser recuperáveis.
Ao contrário dos sistemas autogerenciados, o Atlas também aciona eleições de conjuntos de réplicas durante operações de manutenção de rotina, incluindo:
Atualizações contínuas de manutenção e patches
Dimensionamento de eventos, como alterar a camada do cluster ou o tamanho do disco
Alterações gerais na configuração do cluster
O Atlas executa essas operações de forma contínua para evitar o tempo de inatividade. No entanto, cada eleição cria um período em que as gravações { w: 1 } podem não ter sido replicadas para secundários. Se você usar { w: 1 }, considere essas fontes eleição ao avaliar sua tolerância ao risco de reversão.
Detectar reversões
Quando o Atlas detecta uma condição de rollback durante um failover, ele gera um evento HOST_ROLLBACK. Você pode verificar este evento das seguintes maneiras:
Feed de atividades: visualize
HOST_ROLLBACKeventos no feed de atividades do projeto . Para saber mais, consulte Visualizar feed de atividades.Alertas: configure um alerta no
HOST_ROLLBACKtipo de evento para receber uma notificação quando o evento ocorrer. Para saber mais, consulte Definir configurações de alerta.
Observação
O Atlas também gera um HOST_ROLLBACK evento durante operações de restauração point-in-time devido a diferenças de dados entre os clusters de origem e de destino. Você pode ignorar este evento quando ele ocorre nesse contexto. Para saber mais, consulte Restaurar do Backup Contínuo em Nuvem.
Recuperar dados revertidos
Se ocorrer um rollback, entre em contato com o suporte do MongoDB para determinar se a recuperação dos dados rollback é possível.