Mise en place d'un replica set MongoDB + sharding

Symptôme

Objectif : mettre en place un replica set avec failover automatique pour MongoDB et l'étendre à un cluster shardé pour la mise à l'échelle horizontale.

1. Démarrez les processus mongod avec le même nom de replSet

Démarrez chaque membre du replica set avec le même nom --replSet et un --bind_ip joignable. En production, l'authentification interne par keyFile ou TLS est recommandée. Visez un nombre impair de membres votants pour une majorité claire.

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. Initialisez le replica set

Connectez-vous à un membre avec mongosh, appelez rs.initiate() et définissez tous les membres. Cela déclenche la première élection et un primaire est choisi. Vérifiez les rôles PRIMARY/SECONDARY avec 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. Ajoutez des membres, définissez les priorités et un arbiter si besoin

Ajoutez des membres ultérieurement avec rs.add(). priority détermine quel membre tend à devenir primaire (0 = ne devient jamais primaire). Un arbiter ne fait que voter et ne contient aucune donnée ; il sert à départager avec un nombre pair de nœuds de données, mais un vrai membre est préférable pour la sécurité des données. Dans les topologies avec arbiter (surtout PSA), le write concern majority ne peut pas être satisfait lorsqu'un nœud de données tombe et les écritures attendent ; en 5.0+, le write concern par défaut du cluster peut devoir être défini explicitement avec setDefaultRWConcern avant d'ajouter un 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. Mettez en place le replica set des config servers pour le sharding

Les métadonnées du cluster shardé sont conservées dans un replica set de config servers (--configsvr). Il est lui-même initialisé comme un replica set ; 3 membres sont recommandés pour la haute disponibilité.

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. Démarrez les replica sets des shards et le routeur mongos

Chaque shard est son propre replica set démarré avec --shardsvr (la durabilité des données vient de la réplication au sein du shard). Le routeur mongos est démarré en pointant vers les config servers ; les applications se connectent à 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. Ajoutez les shards et shardez la collection

Connectez-vous à mongos et ajoutez chaque replica set de shard avec sh.addShard(). Activez le sharding sur la base et répartissez la collection selon une shard key avec sh.shardCollection(). Le choix de la clé est essentiel : elle doit avoir une cardinalité élevée et une répartition uniforme. Surveillez la répartition des chunks avec 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()