Betrachten Sie das folgende Setup:
Da gibt es 2 physische Server, die als regulärer Mongodb-Replikationssatz eingerichtet sind (einschließlich eines Arbiter-Prozesses, damit das automatische Failover funktioniert).
Nun, soviel ich weiß, wird die meiste Arbeit auf dem primären Server erledigt, während der Slave meistens nur arbeitet, um seinen Datensatz synchron zu halten.
Wäre es sinnvoll, Sharding in dieses Setup so einzubauen, dass man auf den gleichen zwei Servern einen anderen Replikationssatz einrichtet, so dass jeder von ihnen einen mongod-Prozess als primären und einen Prozess als sekundär ausführt.
Das erwartete Ergebnis wäre, dass beide Server die Auslastung der tatsächlichen Abfragen / Einsätze teilen, während beide aktiv sind. Im Falle eines Ausfalls eines Servers sollte das gesamte Setup elegant fehlschlagen, um weiter zu laufen, bis der andere Server wiederhergestellt ist.
Gibt es Nachteile bei diesem Setup, mit Ausnahme des Overheads beim Setup und der Anzahl der Prozesse (mongos / configserver / arbiquerers)?
Das würde definitiv funktionieren. Ich hatte vor einiger Zeit im #mongodb-IRC-Kanal eine Frage gestellt, ob es eine schlechte Idee sei, mehrere mongod-Prozesse auf einer einzigen Maschine auszuführen. Die Antwort lautete: "Solange Sie RAM / CPU / Bandbreite haben, gehen Sie Nüsse".
Es ist erwähnenswert, dass Sie, wenn Sie nach leistungsstarken Lesevorgängen suchen und nichts dagegen haben, wenn die Schreibvorgänge ein wenig langsamer sind, könnten Sie:
Damit erhalten Sie ein Cluster-Setup ähnlich wie bei MySQL - schreiben Sie einmal auf den Master, aber jeder der Slaves kann gelesen werden. In einem Fall, in dem Sie viel mehr Lesevorgänge als Schreibvorgänge (sagen wir, eine Größenordnung) haben, kann dies eine höhere Leistung sein, aber ich weiß nicht, wie es sich verhalten würde, wenn ein Knoten ausfällt zu 3 Knoten, aber nur 2 sind oben, usw. - das müsste getestet werden.
Beachten Sie, dass Ihre Abfragen zwischen beiden Maschinen aufgeteilt werden, während beide Maschinen aktiv sind. Wenn einer ausfällt, werden alle Abfragen an die verbleibende Maschine weitergeleitet, wodurch die Anforderungen verdoppelt werden. Sie müssten sicherstellen, dass Ihre Maschinen einer plötzlichen Verdoppelung der Abfragen standhalten können.
Es fehlt Ihnen ein entscheidendes Detail: Wenn Sie ein Shard-Setup mit nur zwei physischen Knoten haben, sind alle Ihre Daten weg, wenn eines stirbt. Dies liegt daran, dass Sie unterhalb der Sharding-Schicht keine Redundanz haben (die empfohlene Methode besteht darin, dass jedes Shard aus einer Replikatgruppe besteht).
Was Sie über das Replikat-Set gesagt haben, ist jedoch wahr: Sie können es auf zwei shared-nothing-Knoten ausführen und haben einen zusätzlichen Arbiter. Das empfohlene Setup wäre jedoch 3 Knoten: ein primärer und zwei sekundäre.
Tags und Links mongodb sharding sysadmin replication