Configuração de replica set + sharding no MongoDB

Sintoma

Objetivo: configurar um replica set com failover automático para o MongoDB e estendê-lo para um cluster com sharding para escalabilidade horizontal.

1. Inicie os processos mongod com o mesmo nome de replSet

Inicie cada membro do replica set com o mesmo nome em --replSet e um --bind_ip acessível. Em produção, recomenda-se autenticação interna com keyFile ou TLS. Busque um número ímpar de membros votantes para uma maioria clara.

MongoDB

mongod --replSet rs0 --port 27017 --dbpath /data/n1 --bind_ip localhost,10.0.0.11
mongod --replSet rs0 --port 27017 --dbpath /data/n2 --bind_ip localhost,10.0.0.12
mongod --replSet rs0 --port 27017 --dbpath /data/n3 --bind_ip localhost,10.0.0.13

2. Inicie o replica set

Conecte-se a um membro com o mongosh, chame rs.initiate() e defina todos os membros. Isso dispara a primeira eleição e um primário é escolhido. Verifique os papéis PRIMARY/SECONDARY com rs.status().

MongoDB

rs.initiate({
  _id: 'rs0',
  members: [
    { _id: 0, host: '10.0.0.11:27017' },
    { _id: 1, host: '10.0.0.12:27017' },
    { _id: 2, host: '10.0.0.13:27017' }
  ]
})
rs.status()

3. Adicione membros, defina prioridades e um arbiter se necessário

Adicione membros depois com rs.add(). A priority determina qual membro tende a virar primário (0 = nunca vira primário). Um arbiter só vota e não guarda dados; é usado como desempate com um número par de nós de dados, mas um membro real é preferível pela segurança dos dados. Em topologias com arbiter (principalmente PSA), o write concern majority não pode ser atendido quando um nó de dados cai e as escritas ficam esperando; no 5.0+, pode ser preciso definir explicitamente o write concern padrão do cluster com setDefaultRWConcern antes de adicionar um arbiter.

MongoDB

rs.add({ host: '10.0.0.14:27017', priority: 0.5 })
// Arbiter only if really needed (a data-bearing member is preferred):
rs.addArb('10.0.0.15:27017')
// change priority:
cfg = rs.conf(); cfg.members[0].priority = 2; rs.reconfig(cfg)

4. Configure o replica set do config server para o sharding

Os metadados do cluster com sharding ficam em um replica set de config server (--configsvr). Ele mesmo é iniciado como replica set; recomenda-se 3 membros para alta disponibilidade.

MongoDB

mongod --configsvr --replSet cfgrs --port 27019 --dbpath /data/cfg1 --bind_ip localhost,10.0.0.21
-- mongosh (on the config server):
rs.initiate({ _id: 'cfgrs', configsvr: true, members: [
  { _id: 0, host: '10.0.0.21:27019' },
  { _id: 1, host: '10.0.0.22:27019' },
  { _id: 2, host: '10.0.0.23:27019' } ] })

5. Inicie os replica sets dos shards e o roteador mongos

Cada shard é seu próprio replica set iniciado com --shardsvr (a durabilidade dos dados vem da replicação dentro do shard). O roteador mongos é iniciado apontando para os config servers; as aplicações se conectam ao mongos.

MongoDB

mongod --shardsvr --replSet shard1rs --port 27018 --dbpath /data/s1 --bind_ip localhost,10.0.0.31
# initiate shard1rs with rs.initiate, then mongos:
mongos --configdb cfgrs/10.0.0.21:27019,10.0.0.22:27019,10.0.0.23:27019 --port 27017 --bind_ip localhost,10.0.0.40

6. Adicione os shards e faça o sharding da coleção

Conecte-se ao mongos e adicione cada replica set de shard com sh.addShard(). Ative o sharding no banco e distribua a coleção por uma shard key com sh.shardCollection(). A escolha da chave é crítica: deve ter alta cardinalidade e distribuição uniforme. Monitore a distribuição dos chunks com sh.status().

MongoDB

sh.addShard('shard1rs/10.0.0.31:27018')
sh.addShard('shard2rs/10.0.0.32:27018')
sh.enableSharding('appdb')
sh.shardCollection('appdb.events', { customer_id: 'hashed' })
sh.status()