Für viele Administratoren ist der Gedanke an Updates und Migrationen mit eher schlechten Erinnerungen verbunden. Applikation müssen identifiziert werden, es muss gewährleistet sein, dass der produktive Betrieb nur kurz unterbrochen wird, Konfigurationsdateien müssen angepasst werden, DNS Einträge neu zugewiesen - die allermeisten haben hier spannende Geschichten zu erzählen.
Der Produktzyklus des SQL Server sieht es vor, dass man doch häufiger über Upgrades nachdenken muss. Microsoft hat seit SQL Server 2012 mindestens alle zwei Jahre neue Versionen herausgebracht (2012 - 2014 - 2016 - 2017 - 2019). Sicher kann man ältere Versionen länger betreiben, - solange sie noch im Microsoft Support sind - aber wenn man Zugriff auf neue Features benötigt, kommt man meistens nicht an einem Upgrade vorbei. Und dann gibt es selbstverständlich für jede Version auch noch eigenen CUs, um die man schwerlich herumkommt. Sie bringen jedoch häufig wichtige und kritische Patches gegen Sicherheitsprobleme mit.
Glücklicherweise wurden in SQL Server 2012 AlwaysOn Verfügbarkeitsgruppen als Hochverfügbarkeitslösung eingeführt. Dieser Hybrid aus Failover-Clustering und Datenbankreplikation sorgt aber nicht nur für Hochverfügbarkeit und Ausfallsicherheit unserer Datenbanken, er hilft uns auch bei dem Thema der Versionsupgrades und Sicherheitsupdates. Dabei gibt allerdings einiges zu beachten.
Ausgangslage
Wir haben hier eine SQL Server AlwaysOn Availability Group unter SQL Server 2017.
Diese soll auf den neuesten Stand gebracht werden. Unter anderem will man ein neues Feature von SQL Server 2019 einsetzen ("Managed Instance Link", dazu in einem späteren Artikel mehr). Der Betrieb soll aber nicht unterbrochen und Downtimes generell vermieden werden. Also ein ganz typisches Szenario, dass man auch wirklich häufig antrifft.
Upgrade auf SQL Server 2019
Wir führen also zuerst auf einem der passiven Knoten der Availability Group eine Upgrade-Installation von SQL Server 2019 durch. Soweit, so unspektakulär.
Was passiert währenddessen in der Availability Group?
Nicht viel. Im Dashboard sehen wir, wie die Instanz, die gerade das Upgrade erfährt, zweimal die Synchronisation verliert - einmal bei Neustart der SQL-Dienste, während der Upgrade-Installation und einmal während des abschließenden Neustart des Servers.
Nach Neustart haben wir dann also eine Availability Group mit gemischten Knoten - 1x SQL Server 2019, 2x SQL Server 2017.
Wir initiieren nun einen Failover zum Replikat auf dem SQL Server 2019-Knoten.
Der manuell-initiierte Failover ist auch erfolgreich.
Das aktive Replikat liegt nun auf dem Knoten mit SQL Server 2019.
Das Dashboard nach dem Failover zeigt jetzt ein interessantes Bild.
Nur das primäre Replikat (SQL Server 2019) sich befindet noch in der Synchronisation und die sekundären Replikate (SQL Server 2017) zeigen Fehler ("NotSynchronizing").
Denn, wenn wir mit dem Upgrade in der Availability Group angefangen haben, dann gibt es keinen Weg zurück mehr. Wenn die Datenbanken in der Availability Group einmal auf einen Knoten mit höherem Versionsstand verschoben wurden, dann können sie nicht mehr auf einen Knoten mit dem ursprünglichen, niedrigeren Versionsstand verschoben werden. Dies ist wichtig zu bedenken.
Eine Irritation
Wir fahren also fort und starten eine neuerliche Upgrade-Installation von SQL Server 2019 auf einen passiven Knoten. Und hier treffen wir dann auf ein irritierendes Phänomen.
Trotz des neuen Versionstandes befindet sich der aktualisierte Knoten nicht in der Synchronisation. Tatsächlich zeigt sich eigentlich genau dasselbe "Fehlerbild", wie vor der Upgrade-Installation.
Das liegt dann sehr häufig daran, dass die Synchronisation auf den Datenbanken pausiert wurde (bzw. nicht wieder gestartet wurde). Man muss hier gleich sagen, dass dies nicht immer vorkommt, aber häufig genug, um es zu erwähnen.
Beheben lässt sich dies sehr schnell, in dem man die Pausierung wieder aufhebt ("Resume Data Movement").
Nach dieser Aktion sieht das Dashboard wie erwartet aus und wir haben wieder Redundanz in der Availability Group.
Nun führen wir noch eine Upgrade-Installation auf dem letzten Knoten aus (, der eigentlich unser Primärknoten war) und führen die Ausgangslage wieder her - unter einer neuen SQL Server-Version.
Fazit
Eine SQL Server AlwaysOn Availability Group ist sehr hilfreich für Update- und Upgrade-Installationen. Sie verschafft uns die Möglichkeit, diese ohne Downtimes durchzuführen.
Wir müssen hierbei aber beachten, dass Rollbacks nicht möglich sind. Eine aktuelle Sicherung der betroffenen Datenbanken ist also Pflicht. Ein Mischbetrieb von verschiedenen SQL Server-Versionen innerhalb einer Availability Group ist von Microsoft nur supportet, wenn dieser im Rahmen von Upgrade-Installation besteht - d.h. kein Mischbetrieb als Dauerzustand.
Natürlich gestalten sich solche Updates im realen Betrieb vielschichtiger und komplexer, da häufig Abhängigkeiten und Applikationen zu beachten und einzuplanen sind. Falls Sie hierbei Unterstützung benötigen stehen Ihnen unsere SQL Server Spezialisten gerne mit Rat und Tat zur Seite. Kontaktieren Sie uns gerne über unser Kontaktformular, um ein Beratungsgespräch zu vereinbaren.
