Undocumented Mongodb Upgrade

Eine Mongodb Installation von der 2.4 auf die 2.6 hochzurüsten geht ganz einfach. Einfach neues Paket installieren, wieder starten, fertig. Ein Drop-In Replacement.

Eventuell noch die Upgrade Dokumentation durchsehen, die Upgrade checks durchführen und so weiter.

Aber die Welt ist nicht immer so einfach. Was wenn man ausser der Mongodb Version jetzt auch noch die Server Hardware oder die Virtualisierung und damit auch noch das Betriebssystem wechseln muss?

Beachte: Die Pakete heißen seit Version 2.6 anders! Authentifizierung funktioniert auch anders!

Upgrade ohne Authentifizierung

• Starte die neuen Server
• erweitere das bestehende Replication Set – mit rs.add(„newservername:27017“)
• warte bis alle Daten auf den neuen Servern sind; je nach Auslastung will man vielleicht immer nur einen einzelnen Server dazupacken
• entferne die alten Server mit rs.remove – dieser Schritt muss immer am Primary gemacht werden! Der Primary wird nach jedem remove neu ausgwählt, d.h. Clients ohne Mongo Router verlieren die Verbindung
• Ohne Mongo Router muss jetzt nur noch der Config String auf den Appservern geändert werden
• Mit Mongo Router müssen jetzt dieConfig Server migriert werden
  • Neue Config Server anlegen
  • Mit einem neuen Mongo Router auf die Configserver connecten
  • Konfiguration mit sh.add
  • Restart aller Mongodb Komponenten – sonste kommt es zur Fehlermeldung „mongos specified a different config database string“ beschrieben unter https://jira.mongodb.org/browse/DOCS-1143
  • Werden die gleichen Config Server weiterbenutzt, dann muss ein Mal ein Mongo Router mit –upgrade gestartet werden

Upgrade mit Authentifizierung

Authentifizierung bringt ein kleines Problem mit sich: Das Replication Set kann nicht erweitert werden, weil es die User auf den neuen Servern nicht gibt. Die User können auf den neuen Servern nicht angelegt werden, weil das nur am Primary geht, bzw. wenn die schon Mitglied im Replset sind.

Lösung dafür: Rsync des kompletten Datenbestandes auf die neuen Server. Das geht am bequemsten ein Mal im Betrieb, dann einen Secondary abdrehen und von dort erneut syncen. Jetzt kann der neue Server ins Replset aufgenommen werden. Aus irgend einem Grund mussten im Anschluss die User neu angelegt werden, weil nach der Syncerei die Admin DB leer war!