MongoDB: collection, cluster e replica set explicados

Quem começa no MongoDB esbarra em três palavras que parecem sinônimos: collection, cluster e replica set. Elas ficam em níveis diferentes. Uma descreve como seus dados são organizados, outra descreve como eles são copiados entre servidores, e a terceira é um apelido para o conjunto todo.

Entender a diferença evita erros práticos: escrever a string de conexão errada, esperar que um secondary tenha sempre o dado mais recente, ou achar que precisa de sharding quando só precisava de uma cópia a mais. Se você ainda não conhece o banco em si, comece por O que é MongoDB.

O que é uma collection no MongoDB?#

O MongoDB guarda dados em documentos (formato BSON, parecido com JSON). Documentos ficam em collections, e collections ficam em um banco (database). Em termos de SQL, a collection é a tabela e o documento é a linha, com uma diferença importante: por padrão, documentos da mesma collection não precisam ter os mesmos campos.

use loja
db.clientes.insertMany([
  { nome: "Ada", idade: 36 },
  { nome: "Linus", linguagens: ["C", "Rust"] },
  { titulo: "Sem nome", tags: [] }
])

Os três documentos acima convivem na collection clientes. Isso dá liberdade no começo do projeto, mas também deixa passar dado malformado.

A collection precisa ser criada antes?#

Não. O MongoDB cria banco e collection na primeira gravação. insertOne cria a collection se ela não existir, e createIndex também. Essa criação implícita usa as opções padrão.

Quando você quer definir opções antes, crie explicitamente com createCollection. Um uso comum é a validação de esquema:

db.createCollection("usuarios", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["nome", "email"],
      properties: {
        nome: { bsonType: "string" },
        email: { bsonType: "string", pattern: "^.+@.+$" }
      }
    }
  }
})

Para mudar as opções depois, use o comando collMod. A validação pode rejeitar a gravação (validationAction: "error") ou só registrar um aviso ("warn"). Se o seu dado tem forma estável, vale ligar a validação cedo.

O que é um replica set?#

Um replica set é um grupo de processos mongod que mantêm o mesmo conjunto de dados. Cada processo pertence a um único replica set. Os papéis são:

• Primary: recebe todas as gravações.
• Secondaries: guardam cópias dos dados e aplicam as mudanças do primary de forma assíncrona.
• Arbiter: vota nas eleições, mas não guarda dados. Serve para quando um terceiro servidor completo custa caro demais, e não acrescenta redundância de dados.

O primary registra cada alteração no oplog (log de operações), e os secondaries leem esse log para ficarem iguais a ele. Como a cópia é assíncrona, um secondary pode estar alguns instantes atrás.

Quantos membros e por quê?#

A documentação indica no mínimo três membros. O formato recomendado é primary, secondary e secondary (P-S-S), com três cópias completas dos dados. A alternativa mais barata é primary, secondary e arbiter (P-S-A): o arbiter só vota, então existe uma única cópia de reserva e a tolerância a falhas é menor.

O motivo do número três é o voto. Com três votantes, a maioria é dois. Se um servidor cai, os outros dois ainda formam maioria e continuam operando. Com dois votantes, perder um deixa o outro sozinho, sem maioria.

O que acontece quando o primary cai?#

Se o primary fica sem se comunicar com o resto do conjunto por mais de electionTimeoutMillis (padrão de 10 segundos), um secondary elegível pede uma eleição. Com as configurações padrão, a mediana para eleger um novo primary normalmente não passa de 12 segundos, contando a detecção da falha.

Durante esse intervalo não há primary, então gravações falham ou esperam. Os drivers atuais repetem automaticamente certas gravações uma vez (retryable writes), o que esconde parte do problema da sua aplicação. Reduzir electionTimeoutMillis detecta falhas mais rápido, mas pode causar eleições à toa em picos de latência de rede.

Como o replica set afeta leituras e gravações?#

Por padrão, o cliente lê do primary. Você pode ler de secondaries com readPreference, aceitando que o dado pode estar atrasado por causa da replicação assíncrona. Transações com leitura precisam usar primary.

Para gravações importantes, use w: "majority". A gravação só é confirmada depois de replicada para a maioria dos votantes, então sobrevive a uma troca de primary. Com w: 1, uma gravação confirmada só pelo primary pode sofrer rollback se ele cair antes de replicar.

O que é um cluster no MongoDB?#

"Cluster" não é um componente com definição única. É a palavra usada para o conjunto de servidores que atende o seu banco, e o sentido depende do contexto:

• Cluster como replica set. Em muitos serviços de banco hospedado, "criar um cluster" resulta num replica set. É o caso mais comum.
• Sharded cluster. No manual do MongoDB, o termo designa a arquitetura de sharding: vários shards (cada um deve ser um replica set), roteadores mongos que recebem as conexões dos clientes e config servers que guardam os metadados.

Ou seja: todo shard é um replica set, mas nem todo replica set é um sharded cluster.

Quando faz sentido usar sharding?#

Sharding divide uma collection em pedaços (chunks) entre vários shards, e um balanceador move esses pedaços para equilibrar o volume. Ele resolve dois limites do escalonamento vertical (servidor maior): CPU saturada por muitas consultas e dados maiores que a RAM.

O custo é complexidade operacional. A chave de shard exige cuidado: dá para refazer o sharding da collection (reshard, desde o MongoDB 5.0), mas o processo é lento e consome muitos recursos. Consultas sem a chave são enviadas a todos os shards. Antes de pensar nisso, vale esgotar índices melhores, consultas mais enxutas e mais RAM. Sharding não substitui a replicação: a alta disponibilidade continua vindo do replica set, já que cada shard é um.

Como o replica set aparece na string de conexão?#

Na string de conexão você lista os membros e informa o nome do conjunto, para o driver descobrir quem é o primary:

mongodb://usuario:senha@host1:27017,host2:27017,host3:27017/loja?replicaSet=rs0&w=majority

O formato mongodb+srv:// descobre a lista de servidores por consulta DNS, então você informa um único nome de host, e ativa TLS por padrão. Caracteres especiais no usuário ou na senha (como $ : / ? # [ ] @) precisam de codificação percentual: @ vira %40. Para ver a conexão em código, leia Como conectar MongoDB ao Node.js.

Quando você não precisa se preocupar com isso?#

Se o seu banco é hospedado por um serviço, a topologia (quantos membros, onde ficam) costuma ser definida por quem fornece o banco, e você usa a string de conexão que ele entrega. Mesmo assim vale conhecer os termos, porque w: "majority" e readPreference mudam o comportamento da sua aplicação. Para comparar o modelo de documentos com tabelas, veja SQL ou NoSQL.

Como fazer isso na Square Cloud#

A Square Cloud oferece hospedagem de MongoDB a partir do plano Standard, sempre em uma versão recente. Você cria o banco no painel, e ele é provisionado em segundos no mesmo datacenter das suas aplicações, com latência média de cerca de 1 ms. O TLS é obrigatório, com o certificado baixado no painel.

O MongoDB hospedado é um nó único (standalone), sem replica set: não há membros secundários, eleição nem replicaSet na string de conexão. Use a URL que o painel entrega e conte com os snapshots para recuperar dados, não com réplicas. Collections, documentos e índices funcionam como descrito acima.

Você tira snapshots manuais do banco quando quiser e, em todo plano com bancos, ganha também um snapshot automático diário, guardado por 7 dias (o mais recente por até 30 dias). Cada snapshot pode ser restaurado no mesmo banco, em outro do mesmo motor ou num banco novo.

Veja os detalhes em hospedagem de MongoDB.