Driftlägen för databasspegling
gäller för:
SQL Server
I det här avsnittet beskrivs synkrona och asynkrona driftlägen för databasspeglingssessioner.
Not
En introduktion till databasspegling finns i Database Mirroring (SQL Server).
Villkor och definitioner
I det här avsnittet beskrivs några termer som är centrala i det här avsnittet.
Läge med höga prestanda
Databasspeglingssessionen fungerar asynkront och använder endast huvudservern och speglingsservern. Den enda formen av rollväxling är tvingad tjänst (med möjlig dataförlust).
Högsäkerhetsläge
Databasspeglingssessionen fungerar synkront och använder eventuellt ett vittne, samt huvudservern och speglingsservern.
Transaktionssäkerhet
En speglingsspecifik databasegenskap som avgör om en databasspeglingssession fungerar synkront eller asynkront. Det finns två säkerhetsnivåer: FULL och OFF.
Vittne
För användning endast med högsäkerhetsläge, en valfri instans av SQL Server som gör det möjligt för speglingsservern att känna igen om en automatisk redundansväxling ska initieras. Till skillnad från de två failover-partnerna betjänar vittnet inte databasen. Stöd för automatisk redundans är vittnets enda roll.
Asynkron databas spegling (High-Performance läge)
I det här avsnittet beskrivs hur asynkron databasspegling fungerar, när det är lämpligt att använda högprestandaläge och hur du svarar om huvudservern misslyckas.
Not
De flesta utgåvor av SQL Server stöder endast synkron databasspegling ("endast säkerhet"). Information om utgåvor som har fullt stöd för databasspegling finns i "Hög tillgänglighet (Alltid på)" i Utgåvor och funktioner som stöds i SQL Server 2022.
När transaktionssäkerheten är inställd på OFF fungerar databasspeglingssessionen asynkront. Asynkron åtgärd stöder endast ett driftläge med höga prestanda. Det här läget förbättrar prestandan på bekostnad av hög tillgänglighet. Läget med höga prestanda använder bara huvudservern och speglingsservern. Problem på speglingsservern påverkar aldrig huvudservern. Vid förlusten av huvudservern är speglingsdatabasen markerad som FRÅNKOPPLAD men är tillgänglig som ett varmt vänteläge.
Högprestandaläge stöder endast en form av rollväxling: tvingad tjänst (med möjlig dataförlust), som använder speglingsservern som en varm väntelägesserver. Tvingad tjänst är ett av de möjliga svaren på felet för huvudservern. Eftersom dataförlust är möjlig bör du överväga andra alternativ innan du tvingar tjänsten till speglingen. Mer information finns i Svara på fel för huvudprincipen, senare i det här avsnittet.
Följande bild visar konfigurationen av en session med högprestandaläge.
När huvudservern skickar loggen för en transaktion till speglingsservern i högprestandaläge skickar huvudservern en bekräftelse till klienten utan att vänta på en bekräftelse från speglingsservern. Transaktioner bekräftas kontinuerligt utan att vänta på att speglingsservern ska skriva loggen till disken. Asynkron åtgärd tillåter att huvudservern körs med minsta transaktionsfördröjning.
Speglingsservern försöker hålla jämna steg med loggposterna som skickas av huvudservern. Men speglingsdatabasen kan ligga något efter huvuddatabasen, men vanligtvis är klyftan mellan databaserna liten. Gapet kan dock bli betydande om huvudservern är hårt belastad eller om speglingsserverns system är överladdat.
i det här avsnittet:
När är High-Performance läge lämpligt?
Högprestandaläge kan vara användbart i ett haveriberedskapsscenario där huvud- och speglingsservrarna avgränsas med ett betydande avstånd och där du inte vill att små fel ska påverka huvudservern.
Anteckning
Loggleverans kan vara ett komplement till databasspegling och är ett bra alternativ till asynkron databasspegling. Information om fördelarna med loggleverans finns i SQL Server (High Availability Solutions). Information om hur du använder loggöverföring med databasspegling finns i Database Mirroring and Log Shipping (SQL Server).
Ett vittnes inverkan på High-Performance läge
Om du använder Transact-SQL för att konfigurera högpresterande läge rekommenderar vi starkt att egenskapen WITNESS också är INSTÄLLD på AV när egenskapen SAFETY är inställd på OFF. Ett vittne kan samexistera med högpresterande läge, men vittnet ger ingen fördel och medför risker.
Om vittnet kopplas bort från sessionen när någon av partnerna går ner blir databasen otillgänglig. Detta beror på att även om läget med höga prestanda inte kräver ett vittne, kräver sessionen ett kvorum som består av två eller flera serverinstanser om ett har angetts. Om sessionen förlorar kvorumet kan den inte hantera databasen.
När ett vittne placeras i ett högprestandaläge innebär tillämpningen av kvorum att:
Om speglingsservern går förlorad måste huvudservern vara ansluten till vittnet. Annars tar huvudservern sin databas offline tills antingen vittnet eller speglingsservern ansluter till sessionen.
Om huvudservern går förlorad måste speglingsservern vara ansluten till vittnet för att tjänsten ska kunna överföras till speglingsservern.
Not
Information om typer av kvorum finns i kvorum: Hur ett vittne påverkar databastillgänglighet (databasspegling).
Att hantera rektorns misslyckande
När huvudansvarig misslyckas har databasägaren flera alternativ, enligt följande:
Låt databasen vara otillgänglig tills huvudkontot blir tillgängligt igen.
Om huvuddatabasen och dess transaktionslogg är intakta bevarar det här valet alla de checkade transaktionerna på bekostnad av tillgängligheten.
Stoppa databasspeglingssessionen, uppdatera databasen manuellt och starta sedan en ny databasspeglingssession.
Om huvuddatabasen går förlorad men huvudservern fortfarande körs, bör du omedelbart säkerhetskopiera svansen på loggen i huvuddatabasen. Om säkerhetskopieringen av slutloggen lyckas kan det vara det bästa alternativet att ta bort speglingen. När du har tagit bort speglingen kan du återställa loggen till den tidigare speglingsdatabasen, som bevarar alla data.
Notis
Om säkerhetskopieringen av slutloggen misslyckades och du inte kan vänta på att huvudservern ska återställas bör du överväga att forcera tjänsten, vilket har fördelen att behålla sessionstillståndet.
Tvångskör tjänsten (med möjlig dataförlust) på spegelservern.
Tvingad tjänst är strikt en haveriberedskapsmetod och bör användas sparsamt. Det går bara att tvinga tjänsten om huvudservern är avstängd, sessionen är asynkron (transaktionssäkerheten är inställd på AV) och antingen har sessionen inget vittne (egenskapen WITNESS är inställd på AV) eller så är vittnet anslutet till speglingsservern (det vill: de har kvorum).
Genom att tvinga tjänsten att agera, antar speglingsservern rollen som huvudenhet och tillhandahåller sin kopia av databasen för klienterna. När tjänsten tvingas stängas av, finns risken att de transaktionsloggar huvudservern ännu inte har skickat till speglingsservern förloras. Därför bör du begränsa tvingad tjänst till situationer där eventuell dataförlust är acceptabel och omedelbar databastillgänglighet är kritisk. Information om hur tvingad tjänst fungerar och om metodtips för att använda den finns i rollväxling under en databasspeglingssession (SQL Server).
Synkron databasspegling (High-Safety-läget)
I det här avsnittet beskrivs hur synkron databasspegling fungerar, inklusive alternativa högsäkerhetslägen (med automatisk redundans och utan automatisk redundans), och innehåller information om vittnets roll vid automatisk redundansväxling.
När transaktionssäkerheten är full körs databasspeglingssessionen i högsäkerhetsläge och fungerar synkront efter en inledande synkroniseringsfas. I det här avsnittet beskrivs information om databasspeglingssessioner som har konfigurerats för synkron åtgärd.
För att uppnå synkron åtgärd för en session måste speglingsservern synkronisera speglingsdatabasen med huvuddatabasen. När sessionen börjar börjar huvudservern skicka sin aktiva logg till speglingsservern. Speglingsservern skriver alla inkommande loggposter till disken så snabbt som möjligt. Så snart alla mottagna loggposter har skrivits till disk synkroniseras databaserna. Så länge partnerna fortsätter att kommunicera är databaserna fortfarande synkroniserade.
Notera
Om du vill övervaka tillståndsändringar i en databasspeglingssession använder du Database Mirroring State Change händelseklass. Mer information finns i Database Mirroring State Change Event Class.
När synkroniseringen är klar utförs varje transaktion som görs på huvuddatabasen också på speglingsservern, vilket garanterar skydd av data. Detta uppnås genom att vänta på att genomföra en transaktion på huvuddatabasen tills huvudservern får ett meddelande från speglingsservern om att den har härdat transaktionens logg till disk. Observera att vänta på det här meddelandet ökar svarstiden för transaktionen.
Den tid som krävs för synkronisering beror i huvudsak på hur långt speglingsdatabasen låg bakom huvuddatabasen i början av sessionen (mätt med antalet loggposter som ursprungligen togs emot från huvudservern), arbetsbelastningen på huvuddatabasen och speglingssystemets hastighet. När en session har synkroniserats finns den härdade loggen som ännu inte har gjorts om på speglingsdatabasen kvar i redo-kön.
Så snart speglingsdatabasen synkroniseras ändras tillståndet för båda kopiorna av databasen till SYNKRONISERAD.
Synkron drift bibehålls på följande sätt:
När en transaktion tas emot från en klient skriver huvudservern loggen för transaktionen till transaktionsloggen.
Huvudservern skriver transaktionen till databasen och skickar samtidigt loggposten till speglingsservern. Huvudservern väntar på en bekräftelse från speglingsservern innan någon av följande bekräftas för klienten: en transaktionsbekräftelse eller en återgång.
Speglingsservern härdar loggen till disken och returnerar en bekräftelse till huvudservern.
När du tar emot bekräftelsen från speglingsservern skickar huvudservern ett bekräftelsemeddelande till klienten.
Högsäkerhetsläget skyddar dina data genom att kräva att data synkroniseras mellan två platser. Alla committerade transaktioner kommer garanterat att skrivas till disken på speglingsservern.
i det här avsnittet:
High-Safety läge utan automatisk redundans
Följande bild visar konfigurationen av högsäkerhetsläge utan automatisk övertagning. Konfigurationen består bara av de två partnerna.
När partnerna är anslutna och databasen redan har synkroniserats stöds manuell redundans. Om speglingsserverinstansen slutar fungera, påverkas inte huvudserverinstansen och den körs utan skydd, det vill säga utan att spegla data. Om huvudservern förloras pausas speglingsprocessen, men tjänsten kan flyttas till speglingsservern (med möjlig dataförlust). För mer information, se Rollväxling under en databasspeglingssession (SQL Server).
High-Safety-läge med automatisk failover
Automatisk redundans ger hög tillgänglighet genom att säkerställa att databasen fortfarande hanteras efter förlusten av en server. Automatisk omkoppling kräver att sessionen har en tredje serverinstans, vittnet , som helst är placerad på en tredje dator. Följande bild visar konfigurationen av en session med hög säkerhet som stöder automatisk redundans.
Till skillnad från de två partnerna betjänar vittnet inte databasen. Vittnet stöder helt enkelt automatisk redundans genom att kontrollera om huvudservern är igång och fungerar. Speglingsservern initierar endast automatisk redundans om speglingen och vittnet förblir anslutna till varandra efter att båda har kopplats från huvudservern.
När ett vittne har angetts kräver sessionen kvorum– en relation mellan minst två serverinstanser som gör att databasen kan göras tillgänglig. För mer information, se Databasspeglingsvittne och Kvorum: hur ett vittne påverkar databastillgängligheten (Databasspegling).
Automatisk omkoppling kräver följande villkor:
Databasen är redan synkroniserad.
Felet inträffar när alla tre serverinstanserna är anslutna och vittnes- och speglingsservern förblir anslutna.
Förlusten av en partner har följande effekt:
Om huvudservern blir otillgänglig under ovanstående villkor sker automatisk redundans. Speglingsservern övertar rollen som huvudserver och erbjuder sin databas som huvuddatabas.
Om huvudservern blir otillgänglig när dessa villkor inte uppfylls kan det vara möjligt att tvinga tjänsten (med möjlig dataförlust). Mer information finns i Rollväxling under en databasspeglingssession (SQL Server).
Om den enda speglingsservern blir otillgänglig fortsätter huvudservern och vittnesservern.
Om sessionen förlorar sitt vittne kräver kvorum båda partnerna. Om någon av partnerna förlorar kvorum förlorar båda partnerna kvorum och databasen blir otillgänglig tills kvorumet har återupprättats. Det här kvorumkravet säkerställer att databasen aldrig körs exponeradi avsaknad av ett vittne, utan att speglas.
Not
Om du förväntar dig att vittnet förblir frånkopplat under en betydande tid rekommenderar vi att du tar bort vittnet från sessionen tills det blir tillgängligt.
Transact-SQL Inställningar och driftlägen för databasspegling
I det här avsnittet beskrivs en databasspeglingssession med avseende på ALTER DATABASE-inställningarna och tillstånden för den speglade databasen och eventuella vittnen. Avsnittet riktar sig till användare som hanterar databasspegling i första hand eller uteslutande med Hjälp av Transact-SQL, i stället för att använda SQL Server Management Studio.
Tips
Som ett alternativ till att använda Transact-SQL kan du styra driftsläget för en session i Object Explorer med hjälp av sidan Spegling i dialogrutan Database Properties. Mer information finns i Upprätta en databasspeglingssession med Windows-autentisering (SQL Server Management Studio).
i det här avsnittet:
Hur transaktionssäkerhet och vittnestillstånd påverkar driftläget
Driftsläget för en session bestäms av kombinationen av dess inställning för transaktionssäkerhet och vittnets tillstånd. Databasägaren kan när som helst ändra transaktionssäkerhetsnivån och lägga till eller ta bort vittnet.
i det här avsnittet:
Transaktionssäkerhet
Transaktionssäkerhet är en speglingsspecifik databasegenskap som avgör om en databasspeglingssession fungerar synkront eller asynkront. Det finns två säkerhetsnivåer: FULL och OFF.
SÄKERHET FULL
Fullständig transaktionssäkerhet gör att sessionen fungerar synkront i högsäkerhetsläge. Om ett vittne är närvarande stöder en session automatisk redundans.
När du upprättar en session med ALTER DATABASE-instruktioner börjar sessionen med egenskapen SAFETY inställd på FULL. det vill: sessionen börjar i högsäkerhetsläge. När sessionen har börjat kan du lägga till ett vittne.
Mer information finns i Synkron databasspegling (High-Safety läge), tidigare i det här avsnittet.
SÄKERHET AV
Om du inaktiverar transaktionssäkerheten fungerar sessionen asynkront i högpresterande läge. Om egenskapen SAFETY är inställd på OFF ska egenskapen WITNESS också vara inställd på OFF (standardvärdet). Information om vittnets inverkan i högpresterande läge finns i Vittnets tillståndsenare i det här avsnittet. Mer information om hur du kör med transaktionssäkerhet inaktiverad finns i Asynkron databasspegling (High-Performance läge), tidigare i det här avsnittet.
Databasens transaktionssäkerhetsinställning registreras för varje partner i katalogvyn sys.database_mirroring i kolumnerna mirroring_safety_level och mirroring_safety_level_desc. Mer information finns i sys.database_mirroring (Transact-SQL).
Databasägaren kan när som helst ändra transaktionssäkerhetsnivån.
Vittnets tillstånd
Om ett vittne har ställts in krävs kvorum, så vittnets tillstånd är alltid betydelsefullt.
Om det finns har vittnet ett av två tillstånd:
När vittnet är kopplat till en partner är vittnet i tillståndet ANSLUTEN i förhållande till den partnern och har kvorum med den partnern. I det här fallet kan databasen göras tillgänglig, även om någon av partnerna inte är tillgänglig.
När vittnet finns men inte är kopplat till en partner är vittnet i okänt eller frånkopplat tillstånd i förhållande till den partnern. I det här fallet saknar vittnet kvorum med den partnern, och om partnerna inte är anslutna till varandra blir databasen otillgänglig.
Information om kvorum finns i kvorum: Hur ett vittne påverkar databastillgänglighet (databasspegling).
Tillståndet för varje vittne på en serverinstans registreras i kolumnerna mirroring_witness_state och mirroring_witness_state_desc i katalogvyn sys.database_mirroring. Mer information finns i sys.database_mirroring (Transact-SQL).
I följande tabell sammanfattas hur driftsläget för en session beror på dess inställning för transaktionssäkerhet och vittnets tillstånd.
| Driftläge | Transaktionssäkerhet | Vittnestillstånd |
|---|---|---|
| Läge med höga prestanda | AV | NULL (inget vittne)** |
| Högsäkerhetsläge utan automatisk failover | FULL | NULL (inget vittne) |
| Högsäkerhetsläge med automatisk fjärrdrift* | Fullt | ANSLUTEN |
*Om vittnet kopplas från rekommenderar vi att du ställer in WITNESS OFF tills vittnesserverinstansen blir tillgänglig.
**Om ett vittne är närvarande i högpresterande läge deltar inte vittnet i sessionen. För att göra databasen tillgänglig måste dock minst två av serverinstanserna förbli anslutna. Därför rekommenderar vi att du håller egenskapen WITNESS inställd på AV i sessioner med hög prestanda. För mer information, se Kvorum: Hur ett vittne påverkar databastillgängligheten (databasspegling).
Visa säkerhetsinställningen och vittnets tillstånd
Om du vill visa säkerhetsinställningen och vittnets tillstånd för en databas använder du sys.database_mirroring katalogvyn. De relevanta kolumnerna är följande:
| Faktor | Kolumner | Beskrivning |
|---|---|---|
| Transaktionssäkerhet | mirroring_safety_level eller mirroring_safety_level_desc | Säkerhetsinställning för transaktioner för uppdateringar i speglingsdatabasen, något av: OKÄND AV FULL NULL= databasen är inte online. |
| Finns det ett vittne? | spegling_vittne_namn | Servernamn för databasspeglingsvittnet eller NULL, som anger att inget vittne finns. |
| Vittnestillstånd | mirroring_witness_state eller mirroring_witness_state_desc | Vittnets tillstånd i databasen på en viss partner: OKÄND ANSLUTEN BORTKOPPLAD NULL = inget vittne finns eller så är databasen inte online. |
På antingen huvudservern eller speglingsservern anger du till exempel:
SELECT mirroring_safety_level_desc, mirroring_witness_name, mirroring_witness_state_desc FROM sys.database_mirroring
Mer information om den här katalogvyn finns i sys.database_mirroring (Transact-SQL).
Faktorer som påverkar beteendet vid förlust av huvudservern
I följande tabell sammanfattas den kombinerade effekten av inställningen för transaktionssäkerhet, databasens tillstånd och vittnets tillstånd på beteendet för en speglingssession vid förlusten av huvudservern.
| Transaktionssäkerhet | Speglingstillstånd för speglingsdatabas | Vittnestillstånd | Beteende när huvudanvändaren förloras |
|---|---|---|---|
| FULL | SYNKRONISERAS | ANSLUTEN | Automatisk omkoppling sker. |
| FULL | SYNKRONISERAS | BORTKOPPLAD | Speglingsservern stannar; Redundansväxling är inte möjlig och databasen kan inte göras tillgänglig. |
| AV | PAUSAD ELLER FRÅNKOPPLAD | NULL (inget vittne) | Tjänsten kan omdirigeras till speglingsservern, vilket kan leda till dataförlust. |
| FULL | Synkronisera eller Avstängd | NULL (inget vittne) | Tjänsten kan omdirigeras till speglingsservern (med risk för dataförlust). |
Relaterade uppgifter
Lägg till eller ersätt ett databasspeglingsvittne (SQL Server Management Studio)
Lägg till ett databasspeglingsvittne med Windows-autentisering (Transact-SQL)
Ta bort vittnet från en databasspeglingssession (SQL Server)
Ändra transaktionssäkerhet i en databasspeglingssession (Transact-SQL)
Se även
Övervakning av databasspegling (SQL Server)
databasspeglingsvittne