Observação
Esta funcionalidade não é aplicável ao Atlas Infinite. Para saber mais sobre os recursos e o comportamento do Atlas Infinite, consulte MongoDB Atlas Infinite: visão geral.
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 a 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 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 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 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 saber como 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 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 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 rollback é possível.