Aktivér program robusthed med Azure SQL Database
Georeplikerings- og automatisk failovergrupper er begge mekanismer, der bruges i Azure SQL Database til at forbedre tilgængeligheden og it-katastrofeberedskab, men de har nogle vigtige forskelle.
Om aktiv georeplikering
En metode til at øge tilgængeligheden af en Azure SQL Database er at bruge aktiv georeplikering. Aktiv georeplikering er designet som en løsning til forretningskontinuitet, der giver dig mulighed for at oprette læselige sekundære databaser med individuelle databaser på en server i samme eller et andet område. Den understøtter op til fire sekundære replikaer og er konfigureret pr. database.
I baggrunden bruger Azure Tilgængelighedsgrupper til at levere denne funktionalitet. Med aktiv georeplikering kan kunder programmatisk eller manuelt failovere primære databaser til sekundære områder under større katastrofe.
Hvis du vil undgå replikeringsomkostninger fra en stor skrivearbejdsbelastning, der kan påvirke replikeringsydeevnen, anbefales det at konfigurere det geo-sekundære med samme tjenesteniveau og beregningsstørrelse som det primære.
Du kan manuelt konfigurere georeplikering for Azure SQL Database ved at få adgang til databasesiden og vælge Replikaer i afsnittet Dataadministration .
Når den sekundære replika er oprettet, kan du manuelt starte en failover. Dette skifter rollerne, hvilket gør den sekundære den nye primære og den gamle primære til den nye sekundære.
Georeplikering er asynkron, hvilket betyder, at der kan være en vis dataforskydning mellem de primære og sekundære databaser. Programforbindelsesstrengen skal også opdateres efter en failover.
Konfigurer georeplikering på tværs af abonnementer
I visse scenarier skal du muligvis konfigurere en sekundær replika på et andet abonnement end den primære database. Det er her, georeplikering på tværs af abonnementer kommer i spil. Denne funktion giver dig mulighed for at konfigurere en sekundær replika i et andet abonnement, hvilket giver større fleksibilitet og forbedrede indstillinger for it-katastrofeberedskab. Når du bruger georeplikering på tværs af abonnementer, kan du sikre, at dine data er beskyttet og tilgængelige, selvom et abonnement støder på problemer. Denne konfiguration er nyttig for organisationer med flere abonnementer eller dem, der ønsker at implementere en robust plan for forretningskontinuitet.
Hvis du vil vide mere om de trin, der kræves for at konfigurere georeplikering på tværs af abonnementer, skal du se Geo-replikering på tværs af abonnementer.
Aktivér grupper med automatisk failover
En automatisk failovergruppe er en tilgængelighedsfunktion, der kan bruges med både Azure SQL Database og Azure SQL Managed Instance. Med grupper med automatisk failover kan du administrere, hvordan databaser replikeres til et andet område, og du kan administrere, hvordan failover kan ske. Det navn, der er tildelt gruppen til automatisk failover, skal være entydigt i domænet *.database.windows.net .
Grupper med automatisk failover tilbyder AG-lignende funktionalitet via en lytter, hvilket aktiverer både læse-/skrive-aktiviteter og skrivebeskyttede aktiviteter. Denne funktionalitet adskiller sig en smule fra aktiv georeplikering. Der er to typer lyttere: én til læse-/skrivetrafik og en anden til skrivebeskyttet trafik. Under en failover giver DNS-opdateringer klienter mulighed for at oprette forbindelse til lyttenavnet uden yderligere oplysninger. Databaseserveren med læse-/skrivekopier er den primære, mens den server, der modtager transaktioner fra den primære, er den sekundære.
Grupper med automatisk failover har to forskellige politikker, der kan konfigureres.
- Kundeadministreret (anbefales) – kunder kan manuelt starte en failover, når de registrerer en uventet afbrydelse, der påvirker en eller flere databaser i failovergruppen. Denne manuelle failover kan udføres ved hjælp af kommandolinjeværktøjer som PowerShell, Azure CLI eller Rest API.
- Microsoft-administreret – de startes automatisk af Microsoft under en udbredt afbrydelse, der påvirker et primært område. Denne automatiske failover gælder for alle berørte failovergrupper, hvor deres failoverpolitik er angivet til Microsoft-administreret.
Ikke-planlagt failover kan medføre tab af data, hvis det gennemtvinges, og den sekundære ikke er fuldt synkroniseret med den primære. Konfiguration af GracePeriodWithDataLossHours styrer, hvor længe Azure venter, før der mislykkes. Standarden er én time. Hvis du har et stramt RPO og ikke har råd til meget tab af data, skal du angive værdien højere. Selvom Azure venter længere, før der opstår en fejl, kan denne fremgangsmåde resultere i mindre tab af data, da den sekundære bruger mere tid på at synkronisere med den primære.
Derudover kan en automatisk failovergruppe indeholde en eller flere databaser med samme størrelse og udgave på både de primære og sekundære servere. Databasen på den sekundære server oprettes automatisk via en proces, der kaldes seeding, hvilket kan tage noget tid, afhængigt af databasens størrelse. Det er vigtigt at planlægge i overensstemmelse hermed og overveje faktorer som netværkshastighed.
Sådan vælger du
Georeplikering er velegnet til scenarier, hvor du har brug for flere læsbare replikaer, og manuel failover er acceptabel, mens grupper med automatisk failover er ideelle til scenarier, der kræver automatisk failover og synkron replikering for en gruppe databaser.
I følgende tabel sammenlignes funktionerne i georeplikerings- og automatisk failovergrupper sammen med andre relevante detaljer.
| Funktion | Georeplikering | Grupper til automatisk failover |
|---|---|---|
| Antal replikaer | Understøtter op til fire sekundære replikaer. | Understøtter kun én sekundær replika |
| Konfigurationsniveau | Konfigureret pr. database. | Konfigureret for en gruppe databaser |
| Replikeringstype | Asynkron, hvilket betyder, at der kan være en vis dataforskydning mellem primære og sekundære databaser | Synkron, der sikrer, at den sekundære database altid er synkroniseret med den primære. |
| Failover | Kræver manuel failover. Programforbindelsesstrengen skal opdateres efter en failover | Understøtter automatisk og manuel failover uden at skulle ændre forbindelsesstrenge efter en failover |
| Læselighed | Leverer læselige sekundære databaser. | Leverer læselige sekundære databaser og fungerer som hot-standby for failover |
| use case- | Egnet til scenarier, der kræver flere læsbare replikaer og manuel failover | Ideel til scenarier, der kræver automatisk failover og synkron replikering for en gruppe databaser |