Database-mirroring als alternatief voor clustering en FT
Gepubliceerd op 28 september 2010 • 4 min leestijd • 775 woordenToen ik de mogelijkheid onderzocht om een redundante Microsoft SQL Server-omgeving te creëren zonder het gebruik van gedeelde opslag, merkte ik dat veel van de opties gedeelde opslag nodig hadden: clustering, FT, enz. Sommige producten, zoals everRun, kunnen worden gebruikt zonder gedeelde opslag, maar zijn erg duur.
Een alternatief voor de bovenstaande opties is Database Mirroring (DBM), een onderdeel van Microsoft SQL Server. Database Mirroring (DBM) is in essentie de mogelijkheid om alle database-inhoud te repliceren/spiegelen naar een tweede databaseserver. Met DBM kunt u een hoge beschikbaarheid van uw databases realiseren zonder de rompslomp van Microsoft Clustering Services (MSCS) en zonder de noodzaak van gedeelde opslag.
Het gebruik van databasespiegeling is een van mijn favoriete oplossingen, omdat:
- het kan worden gebruikt in omgevingen zonder gedeelde opslag;
- de opzet kan een actieve/actieve configuratie zijn, waarbij beide knooppunten worden gebruikt voor het bewaren van databases;
- je kunt mirroring per database inschakelen;
- u geeft de controle terug aan de DBA’s bij de keuze of zij wel of niet willen dat hun database wordt beschermd;
- het kan worden gebruikt op gedeelde opslag, bijvoorbeeld wanneer u gedeelde opslag op basis van iSCSI gebruikt in een virtuele omgeving (wat momenteel niet wordt ondersteund);
- u kunt databases spiegelen op servers met meer dan 1 vCPU (de limiet voor FT in vSphere op dit moment);
- het beheer van de Windows Server wordt eenvoudiger.
Over het beheer van de SQL-omgeving kun je discussiëren. Omdat u geen gebruik maakt van Microsoft Clustering Services is het beheer van Windows wat eenvoudiger, maar verschuift het beheer naar de databasebeheerder.
Van de Microsoft MSDN:
Bij het spiegelen van databases wordt elke invoeg-, update- en verwijderbewerking die in de hoofddatabase plaatsvindt, zo snel mogelijk opnieuw uitgevoerd in de spiegeldatabase. Dit opnieuw uitvoeren wordt bereikt door een stroom actieve transactielogboekrecords naar de spiegelserver te sturen, die logrecords zo snel mogelijk achtereenvolgens op de spiegeldatabase toepast. In tegenstelling tot replicatie, die op logisch niveau werkt, werkt databasespiegeling op het niveau van het fysieke logboekrecord.
Zonder getuige:
In het scenario zonder getuigenserver/instantie worden alle transacties naar de secundaire database getransporteerd. Als de hoofddatabaseserver (srv1) uitvalt, moet de DBA enkele handmatige acties uitvoeren om de database op de secundaire server (srv2) te openen.
met getuige:
Als u een getuigenserver of instance gebruikt, kan de failover transparant zijn. Gebruikers zullen de failover meestal niet opmerken ALS de applicatie database-mirroring kan gebruiken. Wanneer uw applicatie de native SQL-client of ADO.NET gebruikt, zal de failover transparant zijn.
Databasekant
Hier volgen de stappen om een gespiegelde database te maken:
Hoofdserver (primaire):
- Zorg ervoor dat u een database heeft waarvan de herstelmodus is ingesteld op Volledig. Wanneer u migreert van SQL Express naar SQL Standard, bevinden de databases zich in de eenvoudige herstelmodus;
- Zet de databaseoptie “AUTO CLOSE” op Uit. Nogmaals, als u migreert vanuit SQL Express, is deze waarde ingesteld op AAN;
- Maak een volledige back-up van de database;
- Maak een transactielogboek van de database.
Spiegelserver:
- Herstel de volledige back-up op een tweede server met de optie GEEN HERSTEL;
- Herstel de transactielogboeken naar een tweede server met de optie GEEN HERSTEL; Na beide herstelbewerkingen bevindt de database zich nog steeds in de herstelmodus. Dit is de beoogde modus.
Hoofdserver:
Nu u de primaire database en de spiegeldatabase hebt voorbereid, is het tijd om de spiegeling in te stellen:
- Maak een spiegel van de database (klik met de rechtermuisknop -> taken -> spiegel);
- Kies of u wel of niet een getuigenserver gaat gebruiken;
- Kies de server met de primaire database als hoofdserver;
- kies uw 2e server als standby/secundaire server;
- Kies uw getuigenserver, als u die heeft. Dit kan een SQL Express-editie zijn;
- Voer de juiste inloggegevens in;
- Start spiegel.
Voilà. U bent klaar.. Als u geen databaseaanmeldingsaccounts gebruikt.
Als u database-inlogaccounts gebruikt, moet u ervoor zorgen dat de inlogaccounts op beide servers worden gesynchroniseerd, aangezien ze niet worden gerepliceerd. Raadpleeg dit Microsoft KB-artikel voor meer informatie over het synchroniseren van gebruikersaccounts tussen de twee servers.
Zorg er, zoals bij alle failover-oplossingen, voor dat de servers niet op dezelfde virtualisatiehost terechtkomen.
Klantkant
Aan de clientzijde moeten enkele kleine wijzigingen worden aangebracht om gebruik te kunnen maken van de automatische failover. De verbindingsreeks wijzigen van
“Server=srv1;database=db1”
aan
“Server=srv1; Failover_Partner=srv2; Database=db1”
is voldoende om de nieuw gecreëerde hoog(ere) beschikbare oplossing te gebruiken.