Configuración de MongoDB replica set + sharding

Síntoma

Objetivo: configurar un replica set con failover automático para MongoDB y ampliarlo a un clúster particionado (sharded cluster) para escalado horizontal.

1. Inicie los procesos mongod con el mismo nombre de replSet

Inicie cada miembro del replica set con el mismo nombre --replSet y un --bind_ip accesible. En producción se recomienda autenticación interna con keyFile o TLS. Procure un número impar de miembros con voto para tener una mayoría 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. Inicialice el replica set

Conéctese a un miembro con mongosh, llame a rs.initiate() y defina todos los miembros. Esto desencadena la primera elección y se elige un primario. Verifique los roles PRIMARY/SECONDARY con 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. Agregue miembros, defina prioridades y un árbitro si es necesario

Agregue miembros más adelante con rs.add(). priority determina qué miembro tiende a convertirse en primario (0 = nunca se convierte en primario). Un árbitro solo vota y no almacena datos; se usa para desempatar con un número par de nodos de datos, pero para la seguridad de los datos es preferible un miembro real. En topologías con árbitro (especialmente PSA), el write concern majority no puede satisfacerse cuando cae un nodo de datos y las escrituras quedan en espera; en 5.0+ puede ser necesario definir explícitamente el write concern por defecto de todo el clúster con setDefaultRWConcern antes de agregar un árbitro.

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 el replica set de config servers para sharding

Los metadatos del sharded cluster se guardan en un replica set de config servers (--configsvr). Se inicializa a su vez como replica set; se recomiendan 3 miembros para alta disponibilidad.

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 los replica sets de shard y el router mongos

Cada shard es su propio replica set iniciado con --shardsvr (la durabilidad de los datos proviene de la replicación dentro del shard). El router mongos se inicia apuntando a los config servers; las aplicaciones se conectan a 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. Agregue los shards y particione la colección

Conéctese a mongos y agregue cada replica set de shard con sh.addShard(). Habilite el sharding en la base de datos y distribuya la colección por una shard key con sh.shardCollection(). La elección de la clave es crítica: debe tener alta cardinalidad y una distribución uniforme. Monitoree la distribución de chunks con 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()