Um rollback reverte as operações de gravação em um antigo primário quando ele se junta novamente ao seu conjunto de réplicas após um failover. Os clusters do Atlas usam { w: "majority" } como o write concern padrão para o MongoDB. Com esse padrão, o Atlas reconhece as gravações somente após replicá-las para a maioria dos nós. As operações de gravar reconhecidas não podem ser revertidas, portanto, um rollback não resulta em perda de dados.
Se você configurar o write concern { w: 1 }, um rollback poderá afetar as gravações que ainda não foram replicadas. Antes que um rollback ocorra, planeje como identificar as operações de rollback e decida se deseja reemití-las.
Para aprender sobre a mecânica de rollback do conjunto de réplicas, consulte Rollback durante o failover do conjunto de réplicas.
Comportamento de rollback no Atlas
Quando um rollback ocorre no Atlas, as seguintes condições se aplicam:
O Atlas gera um evento
HOST_ROLLBACKno feed de atividades do seu projeto. Para aprendercomo verificar esse evento, consulte Detectar rollback.O Atlas não mantém uma lista de operações revertidas.
Write concern e risco de rollback
Os clusters do Atlas usam { w: "majority" } como o write concern padrão para o MongoDB. Com esse padrão, um rollback não resulta em perda de dados. O write concern que você configura determina se um rollback pode resultar em perda de dados:
{ w: "majority" }(padrão) — o Atlas reconhece uma gravar somente depois que a maioria dos conjunto de réplicas a confirma. Como a gravação foi replicada antes que o primário fosse desativado, um rollback não pode incluir essas gravações.{ w: 1 }— O Atlas reconhece uma gravação somente depois que o primário a registra, sem esperar pela replicação para os secundários. Se o primário for desativado antes da replicação de gravar, o gravar poderá ser revertido e os dados poderão não ser recuperáveis.
Ao contrário das implantações autogerenciadas, o Atlas também aciona eleições de conjunto de réplicas durante operações de manutenção de rotina, incluindo:
Manutenção contínua e atualizações de patches
Dimensionamento de eventos, como alteração da camada do cluster ou do tamanho do disco
Alterações gerais na configuração do cluster
O Atlas executa essas operações de forma contínua para evitar tempo de inatividade. No entanto, cada eleição cria um período em que { w: 1 } gravar podem não ter sido replicadas para secundários. Se você usar { w: 1 }, considere essas fontes de eleição ao avaliar sua tolerância ao risco de rollback.
Detectar rollback
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 seu projeto. Para aprender mais, consulte Visualizar feed de atividades.Alertas: configure um alerta no tipo de evento
HOST_ROLLBACKpara receber uma notificação quando o evento ocorrer. Para aprender mais, consulte Definir configurações de alerta.
Observação
O Atlas também gera um evento HOST_ROLLBACK durante as 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 ocorrer nesse contexto. Para aprender mais, consulte Restaurar a partir de backups em nuvem contínuos.
Recuperar dados revertidos
Se ocorrer um rollback, entre em contato com o suporte do MongoDB para determinar se a recuperação dos dados com rollback é possível.