Einrichtung von MongoDB Replica Set + Sharding

Symptom

Ziel: ein Replica Set mit automatischem Failover für MongoDB einrichten und es für horizontale Skalierung zu einem Sharded Cluster erweitern.

1. mongod-Prozesse mit demselben replSet-Namen starten

Starte jedes Replica-Set-Mitglied mit demselben --replSet-Namen und einer erreichbaren --bind_ip. In Produktion wird interne Authentifizierung per keyFile oder TLS empfohlen. Strebe für eine eindeutige Mehrheit eine ungerade Anzahl stimmberechtigter Mitglieder an.

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. Replica Set initialisieren

Verbinde dich mit mongosh mit einem Mitglied, rufe rs.initiate() auf und definiere alle Mitglieder. Das löst die erste Wahl aus, und eine Primary wird bestimmt. Prüfe die Rollen PRIMARY/SECONDARY mit 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. Mitglieder hinzufügen, Prioritäten und bei Bedarf einen Arbiter setzen

Füge Mitglieder später mit rs.add() hinzu. priority bestimmt, welches Mitglied bevorzugt Primary wird (0 = wird nie Primary). Ein Arbiter stimmt nur ab und hält keine Daten; er dient bei gerader Anzahl von Datenknoten als Tie-Breaker, für Datensicherheit ist aber ein echtes Mitglied vorzuziehen. In Arbiter-basierten Topologien (vor allem PSA) lässt sich Majority Write Concern nicht erfüllen, wenn ein Datenknoten ausfällt, und Schreibvorgänge warten; ab 5.0 muss der clusterweite Standard-Write-Concern vor dem Hinzufügen eines Arbiters eventuell explizit mit setDefaultRWConcern gesetzt werden.

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. Config-Server-Replica-Set für Sharding einrichten

Die Metadaten des Sharded Clusters liegen in einem Config-Server-Replica-Set (--configsvr). Es wird selbst als Replica Set initialisiert; für Hochverfügbarkeit werden 3 Mitglieder empfohlen.

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. Shard-Replica-Sets und den mongos-Router starten

Jeder Shard ist ein eigenes, mit --shardsvr gestartetes Replica Set (die Dauerhaftigkeit der Daten ergibt sich aus der Replikation innerhalb des Shards). Der mongos-Router wird mit Verweis auf die Config Server gestartet; Anwendungen verbinden sich mit 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. Shards hinzufügen und die Collection sharden

Verbinde dich mit mongos und füge jedes Shard-Replica-Set mit sh.addShard() hinzu. Aktiviere Sharding für die Datenbank und verteile die Collection mit sh.shardCollection() nach einem Shard Key. Die Key-Wahl ist entscheidend: Er sollte hohe Kardinalität und eine gleichmäßige Verteilung haben. Überwache die Chunk-Verteilung mit 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()