Är det dags att uppgradera er SQL-miljö men ni är bekymrade över nertiden?

Oopps! Upgrade your browser pretty please.Oopps! Upgrade your browser pretty please.

Med hjälp av t ex Windows kluster och Availability Groups kan man göra ”Rullande” uppgraderingar och på så vis minimera den nertid som behövs för att utföra uppgraderingarna både för att uppgradera operativsystem och SQL-server. Detta som ett alternativ till en traditionell flytt av databaserna till en ny miljö.

Det finns flera sätt att gå till väga, möjligheten finns att behålla befintliga kluster och AG:s eller om man har SQL Server 2017 Enterprise genom att migrera till nya kluster och AG:s genom Distribuerade AG. Metoderna skiljer sig såklart lite åt och har lite olika fördelar och nackdelar.

 

Uppgradera i ett befintligt AG

 

Om man behåller sitt befintliga kluster och AG:s så kan man välja mellan att behålla servrarna och uppgradera på dem (”Inplace upgrade”) eller att addera nya Windowsservrar och SQL-instanser för att migrera till dem.

Fördel:

Samma klusternamn, AG-namn och AG-listeners

Nackdel:

Windowsklustret kan inte uppgraderas från 2012 R2 direkt till Windows 2019, då det förnärvarande inte stöds i samma kluster. Windows 2012 R2 -> Windows 2016 och Windows 2016 -> Windows 2019 går bra.

 

Förenklat kan tillvägagångssätten för alternativen beskrivas så här:

”Inplace” uppgradering

 

Börja med de passiva klusternoderna, om operativsystemet skall uppgraderas samt de sekundära replikorna för SQL-server, efter att eventuell automatisk failover har stängt av. När alla sekundära replikor är uppgraderade verifierar man synkroniseringarna är i fas varefter man initierar en failover till en synkroniserad sekundär. Sist uppgraderar man den ursprungliga primären.

När uppgraderingen är klar måste man också göra en uppgradering av ”Cluster functional level” genom att köra ett powershellkommando.

 

Fördel:

Kräver inte mer servrar, all övrig konfiguration består.

Nackdel:

Om man endast har 2 noder och 1 sekundär replika så har man inte någon redundans under uppgraderingen och vid eventuella problem. All installation bör ske i servicefönster.

Uppgradering med nya noder, migrera

 

Med det här alternativet behövs det lämpligen minst 2 nya servrar. Dessa servrar installeras med det operativ och SQL-serverversion som man vill nå. SQL-serverinstanserna konfigureras i enlighet med övriga sekundära replikor som ingår i AG:na och alla serverobjekt, SQL-agentjobb, logins etc kopieras över.

Efter detta tas de nya noderna med i Windowsklustret och SQL-instanserna in som sekundära replikor, här får man tänka på att automatisk population vid initieringen av de nya replikorna kräver samma sökvägar för datafilerna för SQL Server 2016, vilket också är rekommenderat för SQL Server 2017. Tänk på att stänga av automatisk ”failover” av AG.

När de nya replikorna är på plats och synkroniserade, gör man failover till en primär replika. När det är gjort kan man inte backa, det går ju inte att gå tillbaka till en äldre version av SQL. Nu kan de gamla replikorna tas ur AG:et. Nu kan eventuell automatisk failover aktiveras igen.

Flytta klustret till en ny nod, stoppa klustertjänsterna på de gamla noderna och ta ur dem ur klustret.

Nu måste man också göra en uppgradering av ”Cluster functional level” genom att köra ett powershellkommando.

Nu är miljön uppgraderad med nya servrar.

 

Fördel:

Samma klusternamn, AG-namn och AG-listeners, nyinstallerade servrar, installationen sker parallellt med den befintliga miljön, och kan göras utanför servicefönster.

Nackdel:

Fler servrar initialt, mer konfigurering med nya servrar.

 

Uppgradering via Distribuerat AG

 

Med SQL Server 2016 kom möjligheten till Distribuerade AG:s och från SQL Server 2017 blev det möjligt att ha senare version av SQL-server som Distribuerad replika. Enkelt kan man säga att ett Distribuerat AG replikerar data ifrån ett primärt AG till ett sekundärt AG.

Uppgraderingsmetoden innebär kort att en ny parallell miljö skapas, ett nytt Windowskluster på nya Windowsservrar med nya installationer av SQL-server, där man skapar ett nytt AG utan databaser. Till de nya instanserna för det sekundära AG:t kopieras alla serverobjekt, SQL-agentjobb, logins etc från det Primära AG:t

På ursprungsmiljön skapar man ett Distribuerat AG (vilket kräver att det finns en listener på bägge AG:na) och ansluter det på det nya sekundära AG:t och kopierar över Primära AG:ts databaser på sedvanligt vis och ansluter till det sekundära AG:t

Nu är det dags att göra det nya AG:t till Primär, då är det en bra idé att stoppa inkommande trafik, sätt det distribuerade AG:t i ”syncron commit ” och kontrollera att det synkroniserat och gör sen en manuell failover på distribuerade AG:t. Nu är det nya AG:t primär och väntar på data. Nu tar man bort det distribuerade AG:t och ändrar listenern så att trafiken går till rätt AG sen kan trafiken släppas på igen och det gamla AG:et stängas ned.

 

Fördel:

Möjlighet till snabbare återställning om problem uppstår vid migrationen, då det ursprungliga AG:t finns kvar.

Installationen av det sekundära AG:t kan ske parallellt med befintlig miljö och ske utanför servicefönster.

Nackdel:

Fler servrar initialt.

Förnärvarnade är denna typ av uppgradering bara möjligt från SQL Server 2017. Mer konfigurering av bland annat AG-listeners vid migration, som potentiellt ger längre nertid vid migrationen.

Användandet av metoden skapar nya AG-grupper och nytt Windowsklusternamn, AG-listerner kan dock flyttas över.

Endast Enterprise Edition.

 

Som vanligt, så ser vi till att ha ordentliga, testade backuper och provkör i testmiljö innan vi går igång med produktionsmiljöer.

 

Referenser:

https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/upgrading-always-on-availability-group-replica-instances?view=sql-server-ver15

https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/administration-of-an-availability-group-sql-server?view=sql-server-ver15

https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/configure-distributed-availability-groups?view=sql-server-ver15

https://docs.microsoft.com/sv-se/windows-server/failover-clustering/cluster-operating-system-rolling-upgrade