ApsaraDB for MongoDB:Como funcionam os replica sets do MongoDB

Acesse a documentação oficial do MongoDB. A figura a seguir ilustra um replica set típico com um nó primário e dois nós secundários.

Eleição do nó primário

Você inicializa um replica set usando replSetInitiate ou rs.initiate(). Após a inicialização, os membros trocam heartbeats e elegem um nó primário. O nó que obtém a maioria dos votos assume como primário; os demais tornam-se secundários.

Inicialize um replica set

    config = {
        _id : "my_replica_set",
        members : [
             {_id : 0, host : "rs1.example.net:27017"},
             {_id : 1, host : "rs2.example.net:27017"},
             {_id : 2, host : "rs3.example.net:27017"},
       ]
    }
    rs.initiate(config)

Definição de "maioria"

Para N membros com direito a voto, a maioria é igual a N/2 + 1. Se a quantidade de membros ativos for inferior à maioria, o replica set não consegue eleger um nó primário e torna-se somente leitura.

Use um número ímpar de membros. Um replica set com três nós e outro com quatro nós toleram apenas uma falha cada, mas quatro nós oferecem armazenamento de dados mais confiável.

Nós secundários especiais

Por padrão, um nó secundário participa das eleições, pode se tornar primário e sincroniza dados a partir do nó primário para manter um conjunto de dados idêntico.

Ative as solicitações de leitura nos nós secundários para aumentar a capacidade de leitura. O MongoDB oferece suporte a vários tipos de nós secundários especializados para diferentes cenários.

• Arbiter

  Um arbiter apenas vota nas eleições. Ele não pode se tornar o nó primário e não armazena dados.

  Em um replica set de dois nós, se um dos nós cair, o conjunto não conseguirá eleger um nó primário. Adicionar um arbiter garante o sucesso das eleições mesmo quando um nó com dados está indisponível.

  Por serem leves (sem armazenamento de dados), os arbiters são ideais para replica sets com um número par de membros.

• Priority0

  Um nó com prioridade 0 não é elegível como nó primário.

  Por exemplo, em uma implantação multidatacenter, defina a prioridade dos membros no datacenter B como 0 para garantir que o nó primário sempre permaneça no datacenter A.

  Nota

  A maioria dos nós deve estar no datacenter A. Caso contrário, o replica set não conseguirá eleger um nó primário durante uma partição de rede.

• Vote 0

  No MongoDB 3.0, um replica set aceita até 50 membros, mas apenas sete podem votar. Os membros sem direito a voto (Vote0) devem ter a propriedade vote definida como 0.

• Hidden

  Um nó hidden tem prioridade 0 e é invisível para o driver.

  Nós hidden são ideais para backup de dados ou computação offline, pois não atendem a solicitações do cliente.

• Delayed

  Um nó delayed é um nó hidden cujos dados ficam atrasados em relação ao nó primário por um período configurável, como uma hora.

  Nós delayed permitem a recuperação em um ponto específico no tempo caso dados incorretos sejam gravados no nó primário.

Reeleição do nó primário

Além da inicialização, a reeleição do nó primário ocorre nos seguintes cenários:

• Reconfiguração do replica set

  Uma reeleição ocorre quando um nó secundário detecta que o nó primário está inativo ou quando o nó primário renuncia voluntariamente. O resultado depende dos heartbeats, da prioridade e do carimbo de data/hora mais recente do oplog.

  • Prioridade do nó

    Os nós votam no candidato de maior prioridade. Um nó com prioridade 0 nunca inicia uma eleição. Se o nó primário identificar um nó secundário de maior prioridade com atraso de dados inferior a 10 segundos, ele renuncia para permitir que esse nó secundário assuma.

  • Optime

    Apenas o nó com o optime mais recente (o carimbo de data/hora da entrada mais recente do oplog) pode assumir como nó primário.

• Partição de rede

  Um nó só pode assumir como primário se estiver conectado à maioria dos nós com direito a voto. Se o nó primário perder a conectividade com a maioria, ele renuncia e passa a ser um nó secundário. Durante uma partição de rede, vários nós primários podem coexistir brevemente. Defina o write concern como majority para garantir que apenas um nó primário possa concluir gravações com sucesso.

Sincronização de dados

A sincronização de dados do nó primário para os nós secundários utiliza um oplog. Cada gravação no nó primário cria uma entrada na coleção local.oplog.rs. Os nós secundários buscam e aplicam continuamente as novas entradas do oplog.

A coleção local.oplog.rs é limitada (capped): ao atingir o limite de tamanho, o MongoDB exclui as entradas mais antigas. As entradas do oplog são idempotentes — reaplicar uma operação produz o mesmo resultado — porque podem ser aplicadas várias vezes nos nós secundários.

Uma entrada do oplog tem o seguinte formato:

    {
      "ts" : Timestamp(1446011584, 2),
      "h" : NumberLong("1687359108795812092"), 
      "v" : 2, 
      "op" : "i", 
      "ns" : "test.nosql", 
      "o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "100" } 
    }

Um nó secundário realiza uma sincronização inicial (init sync) ao ingressar no conjunto pela primeira vez e copia o conjunto de dados completo do nó primário ou de um nó secundário mais atualizado. Depois disso, ele usa um tailable cursor para buscar e aplicar continuamente novas entradas do oplog a partir da coleção local.oplog.rs do nó primário.

O processo de init sync ocorre da seguinte forma:

1. Em T1, o nó secundário copia todos os bancos de dados (exceto local) do nó primário usando listDatabases, listCollections e cloneCollection. Considere que todas as operações terminem em T2.

2. O nó secundário aplica todas as entradas do oplog geradas entre T1 e T2. Algumas entradas podem se sobrepor à Etapa 1, mas a reaplicação é segura porque as entradas do oplog são idempotentes.

3. O nó secundário cria índices com base nas configurações de índice do nó primário. A Etapa 1 já cria o índice _id de cada coleção.

   Nota

   Dimensione o oplog com base no tamanho do seu banco de dados e no volume de gravação. Se o oplog for muito grande, haverá desperdício de espaço de armazenamento. Se for muito pequeno, o init sync pode nunca terminar. Por exemplo, se o banco de dados for grande, o oplog pode não reter todas as entradas entre T1 e T2 e causar falha na sincronização.

Modifique a configuração do replica set

Adicione ou exclua membros, ou atualize propriedades como priority, vote, hidden ou delayed usando replSetReconfig ou rs.reconfig().

Por exemplo, defina a prioridade do segundo membro como 2:

    cfg = rs.conf();
    cfg.members[1].priority = 2;
    rs.reconfig(cfg);

Tratamento de erros (Rollback)

Se o nó primário cair com dados não sincronizados e ocorrerem gravações no novo nó primário antes que o nó antigo se reconecte, o nó primário antigo reverte (rollback) suas operações não sincronizadas para corresponder ao conjunto de dados do novo nó primário.

O MongoDB salva os dados revertidos em um diretório de rollback. Os administradores podem recuperá-los usando mongorestore, se necessário.

Configurações de leitura e gravação

• Read Preference

  Por padrão, todas as leituras são direcionadas ao nó primário. Configure o read preference no driver para rotear as leituras para outros nós.

  • primary: O modo padrão. Todas as leituras são direcionadas ao nó primário.

  • primaryPreferred: Lê do nó primário; usa os nós secundários como fallback se o nó primário estiver inacessível.

  • secondary: Todas as leituras são direcionadas aos nós secundários.

  • secondaryPreferred: Lê dos nós secundários; usa o nó primário como fallback se todos os nós secundários estiverem inacessíveis.

  • nearest: Lê do nó acessível mais próximo, determinado pela latência do ping.

• Write Concern

  Por padrão, o nó primário retorna uma resposta após concluir uma gravação. Configure o Write Concern no driver para definir as regras de gravação bem-sucedida.

  O exemplo a seguir exige o sucesso de uma gravação na maioria dos nós dentro de 5 segundos.

      db.products.insert(
        { item: "envelopes", qty : 100, type: "Clasp" },
        { writeConcern: { w: "majority", wtimeout: 5000 } }
      )

  O método anterior aplica-se a uma única solicitação. Defina o write concern padrão para todo o replica set:

      cfg = rs.conf()
      cfg.settings = {}
      cfg.settings.getLastErrorDefaults = { w: "majority", wtimeout: 5000 }
      rs.reconfig(cfg)