4
SQL Always On High Availability Cluster Upgrade
Guten Morgen Admin-Gemeinde,
folgende Konfiguration:
SRVSQL3 - Win 2012 & SQL Server 2012 v.11.0.7462.6 (Primary Replica)
Always On High Availability- aktiviert
Availability Group- SQL-DAG vorhanden
Availability Databases : ~12 Stück
SRVSQL4 - Win 2012 & SQL Server 2012 v.11.0.7462.6 (Secondary Replica)
Always On High Availability- aktiviert
Availability Group Listener: SRVSQL
Bedeutet also, egal welche Anwendung auf Ihre explizite DB zugreifen will, ist als SQL Source logischerweise der Availability Group Listener 'SRVSQL' gesetzt, damit auch einer der Replicas mal down sein kann, wegen Updates o.ä.
Nun kommen wir zu meiner eigentlichen Frage.
Die beiden vorhandenen SQL Server 2012 sollen durch SQL Server 2016 replaced werden.
Es sind schon zwei neue Win 2016 Server mit installierten SQL Server 2016 v.13.0.4001.0 installiert.
SRVSQL1 - Win 2016 & SQL Server 2016 v.13.0.4001.0
Always On High Availability- aktiviert
SRVSQL2 - Win 2016 & SQL Server 2016 v.13.0.4001.0
Always On High Availability- aktiviert
Nun war die Idee, die 2016 SQLs einfach als zusätzliche Replicas hinzuzufügen, was aber Aufgrund der Versionunterschiede nicht möglich ist.
Ziel ist es, nach Möglichkeit KEINEN Ausfall , sprich "Nicht-Ereichbarkeit" der DBen zu haben....
Der Availability Group Listener 'SRVSQL' soll unbedingt erhalten bleiben, da die DBen ja ihre connections darüber aufbauen.
Mein Gedankengang war wohl zu einfach, die beiden neuen SQL 2016 als Replicas in die Availability Group hinzuzufügen, dann die DBen zu moven und dann die "alten Replicas" rauszuwerfen.
Wer hat eine Idee und kann mir hilfreiche Infos weitergeben.
Vielen Dank.
Gruß
ollip2016
folgende Konfiguration:
SRVSQL3 - Win 2012 & SQL Server 2012 v.11.0.7462.6 (Primary Replica)
Always On High Availability- aktiviert
Availability Group- SQL-DAG vorhanden
Availability Databases : ~12 Stück
SRVSQL4 - Win 2012 & SQL Server 2012 v.11.0.7462.6 (Secondary Replica)
Always On High Availability- aktiviert
Availability Group Listener: SRVSQL
Bedeutet also, egal welche Anwendung auf Ihre explizite DB zugreifen will, ist als SQL Source logischerweise der Availability Group Listener 'SRVSQL' gesetzt, damit auch einer der Replicas mal down sein kann, wegen Updates o.ä.
Nun kommen wir zu meiner eigentlichen Frage.
Die beiden vorhandenen SQL Server 2012 sollen durch SQL Server 2016 replaced werden.
Es sind schon zwei neue Win 2016 Server mit installierten SQL Server 2016 v.13.0.4001.0 installiert.
SRVSQL1 - Win 2016 & SQL Server 2016 v.13.0.4001.0
Always On High Availability- aktiviert
SRVSQL2 - Win 2016 & SQL Server 2016 v.13.0.4001.0
Always On High Availability- aktiviert
Nun war die Idee, die 2016 SQLs einfach als zusätzliche Replicas hinzuzufügen, was aber Aufgrund der Versionunterschiede nicht möglich ist.
Ziel ist es, nach Möglichkeit KEINEN Ausfall , sprich "Nicht-Ereichbarkeit" der DBen zu haben....
Der Availability Group Listener 'SRVSQL' soll unbedingt erhalten bleiben, da die DBen ja ihre connections darüber aufbauen.
Mein Gedankengang war wohl zu einfach, die beiden neuen SQL 2016 als Replicas in die Availability Group hinzuzufügen, dann die DBen zu moven und dann die "alten Replicas" rauszuwerfen.
Wer hat eine Idee und kann mir hilfreiche Infos weitergeben.
Vielen Dank.
Gruß
ollip2016
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: 565536
Url: https://administrator.de/forum/sql-always-on-high-availability-cluster-upgrade-565536.html
Ausgedruckt am: 14.04.2025 um 11:04 Uhr
4 Kommentare
Neuester Kommentar
Moin,
was mir ad hoc dazu einfällt, wäre ein inplace Updgrade auf SQL 2016 und oder W 2016 und dann kannst Du die neuen Server hinzufügen.
Die Links wirst Du wahrscheinlich schon kennen:
https://docs.microsoft.com/de-de/windows-server/failover-clustering/clus ...
https://docs.microsoft.com/de-de/sql/sql-server/failover-clusters/window ...
Hierzu würde ich mir aber ein Systemhaus dazu holen, die das schon mal gemacht haben.
Gruss
was mir ad hoc dazu einfällt, wäre ein inplace Updgrade auf SQL 2016 und oder W 2016 und dann kannst Du die neuen Server hinzufügen.
Die Links wirst Du wahrscheinlich schon kennen:
https://docs.microsoft.com/de-de/windows-server/failover-clustering/clus ...
https://docs.microsoft.com/de-de/sql/sql-server/failover-clusters/window ...
Hierzu würde ich mir aber ein Systemhaus dazu holen, die das schon mal gemacht haben.
Gruss
Danke für deine Antwort.
Aber "der Kollege" in dem Beitrag redet von SQL 2012 und SQL 2014..... einen 2014er SQL kann ich aber mit in die Availiabilty Group beim 2012er reinnehmen, da ist das upgraden nicht so das Problem, weil der Versionssprung nicht so groß ist, wie von 2012 auf 2016..... oder sehe ich das falsch?
Gruß
op
Aber "der Kollege" in dem Beitrag redet von SQL 2012 und SQL 2014..... einen 2014er SQL kann ich aber mit in die Availiabilty Group beim 2012er reinnehmen, da ist das upgraden nicht so das Problem, weil der Versionssprung nicht so groß ist, wie von 2012 auf 2016..... oder sehe ich das falsch?
Gruß
op
Moin,
macht meines Wissens nach keinen Unterschied.
Bin grad leider kurz angebunden. Ich skizze es einmal grob aus der Hüfte:
Gruß,
Dani
macht meines Wissens nach keinen Unterschied.
Bin grad leider kurz angebunden. Ich skizze es einmal grob aus der Hüfte:
- Alle Microsoft Updates für Windows- und SQL Server installieren
- Einen neuen Cluster mit den beiden neuen Windows Servern innerhalb des WFSC erstellen.
- Function Level des Clusters muss 8 (=Mixed) sein
- Beide neuen SQL-Server den AOAGs hinzufügen (der zukünftige primäre SQL Server synchron, der zukünftige sekundäre SQL Server asychron).
- Failover auslösen auf den zukünftig, primären SQL Server auslösen
- Ändere den zukünftig, sedundären SQL Server von asychron zu synchron.
- Alte, sekundäre SQL Server aus BAGs entfernen
- Alte Windows Server aus Cluster entfernen und löschen.
Gruß,
Dani
