03.07.2025
1673
6
0MongoDB-Upgrade gelingt auf Hypervisor A VM, nicht auf HV-B
Guten Abend Mitadmins!
Hat einer von den MongoDB-Profis sowas schon mal gehört?
Unser mongoDB-Server ist ein Server 2016. Es ist eine VM auf Hyper-V (2019).
Die DB ist auf Version 4.4 und muss auf V8.10 aktualisiert werden.
Das Upgrade installiert also v8, aber das Migrieren der Datenbank misslingt (Fehlermeldung erstmal egal, siehe weiterer Text)
Um das zu untersuchen, habe ich eine Kopie der VM auf einem Test-Hyper-V gestartet und dort klappt das Upgrade.
Das Verrückte ist nun, dass ich diese Kopie natürlich auch wieder zurück ins Produktivnetzwerk bringen kann, aber sobald ich das tu (also sobald ich diese VM auf dem ursprünglichen Hyper-V starte), stürzt der mongo-DB-Dienst ab.
Leere ich das DB-Verzeichnis, startet er wieder. Spiele ich mit Mongo-restore ein Backup der DB aus dem Testnetz-Hyper-V ein, dann misslingt auch das.
Was bitte schert sich ein Mongo-DB-Dienst um den unterliegenden Hypervisor!?
Wäre es hier nicht schon auf 20 Grad abgekühlt, würde ich sagen, ich phantasiere.
PS: Ja, mongo-DB v8 ist auf Server 2016 nicht supportet, ich weiß. Wir haben jedoch die Versicherung des Softwareherstellers, dass das in all seinen Tests lief.
Hat einer von den MongoDB-Profis sowas schon mal gehört?
Unser mongoDB-Server ist ein Server 2016. Es ist eine VM auf Hyper-V (2019).
Die DB ist auf Version 4.4 und muss auf V8.10 aktualisiert werden.
Das Upgrade installiert also v8, aber das Migrieren der Datenbank misslingt (Fehlermeldung erstmal egal, siehe weiterer Text)
Um das zu untersuchen, habe ich eine Kopie der VM auf einem Test-Hyper-V gestartet und dort klappt das Upgrade.
Das Verrückte ist nun, dass ich diese Kopie natürlich auch wieder zurück ins Produktivnetzwerk bringen kann, aber sobald ich das tu (also sobald ich diese VM auf dem ursprünglichen Hyper-V starte), stürzt der mongo-DB-Dienst ab.
Leere ich das DB-Verzeichnis, startet er wieder. Spiele ich mit Mongo-restore ein Backup der DB aus dem Testnetz-Hyper-V ein, dann misslingt auch das.
Was bitte schert sich ein Mongo-DB-Dienst um den unterliegenden Hypervisor!?
Wäre es hier nicht schon auf 20 Grad abgekühlt, würde ich sagen, ich phantasiere.
PS: Ja, mongo-DB v8 ist auf Server 2016 nicht supportet, ich weiß. Wir haben jedoch die Versicherung des Softwareherstellers, dass das in all seinen Tests lief.
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673684
Url: https://administrator.de/forum/mongodb-upgrade-hypervisor-vm-673684.html
Ausgedruckt am: 30.07.2025 um 11:07 Uhr
6 Kommentare
Neuester Kommentar
Moin,
Eventuell anderer Prozessor im Host? Wir hatten es gerade im Thread Umziehen von VirtualBox VMs von Intel-Host auf AMD-Host davon, wie das ist. wenn sich die drunterliegende Prozessor-Architektur ändert.
lks
Eventuell anderer Prozessor im Host? Wir hatten es gerade im Thread Umziehen von VirtualBox VMs von Intel-Host auf AMD-Host davon, wie das ist. wenn sich die drunterliegende Prozessor-Architektur ändert.
lks
Moin,
War auch mein erster Gedanke, aber MongoDB braucht nur einen SandyBridge Core Prozessor bzw. Einen Bulldozer bei AMD. Ich denke Mal nicht, dass der Produktionsserver noch so alte Prozessoren hat?
Gruß,
Avoton
Eventuell anderer Prozessor im Host?
War auch mein erster Gedanke, aber MongoDB braucht nur einen SandyBridge Core Prozessor bzw. Einen Bulldozer bei AMD. Ich denke Mal nicht, dass der Produktionsserver noch so alte Prozessoren hat?
Gruß,
Avoton
Moin,
Ich bin vor kurzem selber darüber gestolpert, dass ab MongoDB V5 die CPU AVX-Instruktionen unterstützen muss.
Unter Proxmox war es dann nur ein anpassen des CPU-Typs für die VM.
Vielleicht scheiterst du ja an was Ähnlichem.
Gruß
Flemming
Ich bin vor kurzem selber darüber gestolpert, dass ab MongoDB V5 die CPU AVX-Instruktionen unterstützen muss.
Unter Proxmox war es dann nur ein anpassen des CPU-Typs für die VM.
Vielleicht scheiterst du ja an was Ähnlichem.
Gruß
Flemming
2
Spiele dich mal mit den Prozessor Einstellungen im Hyper-V: Kompatibilität, NUMA
Ansonsten auch mal die grundlegend RAM und Anzahl der zugewiesenen CPUs kontrollieren.
ansonsten:
Ansonsten auch mal die grundlegend RAM und Anzahl der zugewiesenen CPUs kontrollieren.
ansonsten:
aber das Migrieren der Datenbank misslingt (Fehlermeldung erstmal egal
Vermutlich bringt Dich die Fehlermeldung weiter, was genau er nicht mag.
+1 für fehlende Instruktionsets der CPU
Alternativ könnte es auch sein dass sich Windows/Schlangenöl auf einer anderen HW Sicherheitstechnisch anders verhält.
Schönes Wochenende
Michael
Alternativ könnte es auch sein dass sich Windows/Schlangenöl auf einer anderen HW Sicherheitstechnisch anders verhält.
Fehlermeldung erstmal egal
Verbose auf maximales Level und dann die Meldung in eine Suchmaschine deiner Wahl einkippen würde eventuell auch Probleme aufzeigen vermute ich mal. Bist vermutlich nicht der erste und einzige auf der Welt mit dem Problem Schönes Wochenende
Michael
Die Hardwarerequirements habe ich mir nun genauer angesehen, danke für den Hinweis.
AVX ist auf der Hypervisor-CPU des Prod-Hyper-V (ein oller Xeon aus der Ivy-Bridge Generation) aktiv, auf der Gast-CPU laut CPU-Z auch.
Vielleicht sind es einfach undokumentierte Dinge, die als selbstverständlich vorausgesetzt werden. Wir warten dann mit dem Upgrade und bauen erstmal einen neuen Hyper-V auf, das steht eh dringend an.
AVX ist auf der Hypervisor-CPU des Prod-Hyper-V (ein oller Xeon aus der Ivy-Bridge Generation) aktiv, auf der Gast-CPU laut CPU-Z auch.
Vielleicht sind es einfach undokumentierte Dinge, die als selbstverständlich vorausgesetzt werden. Wir warten dann mit dem Upgrade und bauen erstmal einen neuen Hyper-V auf, das steht eh dringend an.
Vermutlich bringt Dich die Fehlermeldung weiter, was genau er nicht mag.
Leider nein, die ist dem SW-Hersteller ebenso unbekannt:2025-07-01T23:12:22.804+0200 Failed: Projektname_SD.VERSIONS: error creating collection Projektname_SD.VERSIONS: error running create command: connection(localhost:27017[-7]) incomplete read of message header: read tcp 127.0.0.1:50069->127.0.0.1:27017: wsarecv:
An existing connection was forcibly closed by the remote host.
-> Hier stürzt also beim Import der Dienst ab und hört natürlich auch auf zu lauschen auf 27017. Nehme ich "Projekt" raus, stürzt mongorestore an anderer Stelle ab - wie gesagt: nur auf dem Prod-Hyper-V, mit der selben VM auf dem neuen Test-Hyper-V klappt das alles.An existing connection was forcibly closed by the remote host.
Spiele doch mal mit den Prozessor Einstellungen im Hyper-V: Kompatibilität, NUMA
Da ist nicht viel zu spielen, erfolglos.
