Aktiver programmotstand med Azure SQL Database
Georeplikering og auto-failover-grupper er begge mekanismer som brukes i Azure SQL Database for å forbedre tilgjengelighet og nødgjenoppretting, men de har noen viktige forskjeller.
Forstå aktiv georeplikering
Én metode for å øke tilgjengeligheten for en Azure SQL Database er å bruke aktiv georeplikering. Aktiv georeplikering er utformet som en forretningskontinuitetsløsning som lar deg opprette lesbare sekundære databaser for individuelle databaser på en server i samme eller forskjellige område. Den støtter opptil fire sekundære replikaer og er konfigurert per database.
Bak kulissene bruker Azure Tilgjengelighetsgrupper til å tilby denne funksjonaliteten. Med aktiv georeplikering kan kunder programmatisk eller manuelt failover primærdatabaser til sekundære områder under store katastrofer.
For å unngå replikering av overhead fra en stor arbeidsbelastning som kan påvirke replikeringsytelsen, anbefales det å konfigurere geo-sekundæren med samme tjenestenivå og databehandlingsstørrelse som primær.
Du kan konfigurere georeplikering manuelt for Azure SQL Database ved å få tilgang til databasesiden og velge replikaer i delen Databehandling .
Når den sekundære replikaen er opprettet, kan du starte en failover manuelt. Dette bytter rollene, noe som gjør den sekundære til den nye primæren og den gamle primæren den nye sekundæren.
Georeplikering er asynkront, noe som betyr at det kan være noe dataforsinkelse mellom de primære og sekundære databasene. Programtilkoblingsstrengen må også oppdateres etter en failover.
Konfigurer georeplikering på tvers av abonnement
I enkelte scenarioer må du kanskje konfigurere en sekundær replika på et annet abonnement enn den primære databasen. Det er her georeplikering på tvers av abonnementer kommer inn i bildet. Med denne funksjonen kan du konfigurere en sekundær replika i et annet abonnement, noe som gir større fleksibilitet og forbedrede alternativer for nødgjenoppretting. Ved å bruke georeplikering på tvers av abonnementer kan du sikre at dataene dine er beskyttet og tilgjengelige selv om det oppstår problemer med ett abonnement. Dette oppsettet er nyttig for organisasjoner med flere abonnementer eller de som ønsker å implementere en robust forretningskontinuitetsplan.
Hvis du vil lære mer om trinnene som kreves for å konfigurere en georeplikering på tvers av abonnementer, kan du se Georeplikering på tvers av abonnementer.
Aktiver auto-failover-grupper
En auto-failover-gruppe er en tilgjengelighetsfunksjon som kan brukes med både Azure SQL Database og Azure SQL Managed Instance. Med auto-failover-grupper kan du administrere hvordan databaser replikeres til et annet område, og la deg administrere hvordan failover kan skje. Navnet som er tilordnet til auto-failover-gruppen, må være unikt i domenet *.database.windows.net .
Auto-failover-grupper tilbyr AG-lignende funksjonalitet gjennom en lytter, slik at både skrivebeskyttede og skrivebeskyttede aktiviteter aktiveres. Denne funksjonaliteten skiller seg litt fra aktiv georeplikering. Det finnes to typer lyttere: én for lese-skrivetrafikk og en annen for skrivebeskyttet trafikk. Dns-oppdateringer tillater klienter å koble til lytternavnet under en failover uten å trenge mer informasjon. Databaseserveren med skrivebeskyttede kopier er den primære, mens serveren som mottar transaksjoner fra primæren, er den sekundære.
Auto-failover-grupper har to forskjellige policyer som kan konfigureres.
- Kundeadministrert (anbefales) – kunder kan starte en failover manuelt når de oppdager et uventet strømbrudd som påvirker én eller flere databaser i failover-gruppen. Denne manuelle failoveren kan utføres ved hjelp av kommandolinjeverktøy som PowerShell, Azure CLI eller Rest API.
- Microsoft-administrert – de startes automatisk av Microsoft under et omfattende strømbrudd som påvirker et primært område. Denne automatiske failoveren gjelder for alle berørte failover-grupper med failover-policyen satt til Microsoft-administrert.
Ikke-planlagt failover kan føre til tap av data hvis tvunget og den sekundære ikke er fullstendig synkronisert med den primære. Konfigurering GracePeriodWithDataLossHours av kontroller hvor lenge Azure venter før den mislykkes. Standardverdien er én time. Hvis du har et stramt RPO og ikke har råd til mye tap av data, angir du verdien høyere. Selv om Azure venter lenger før den mislykkes, kan denne tilnærmingen føre til mindre tap av data ettersom den sekundære har mer tid til å synkronisere fullstendig med den primære.
I tillegg kan en auto-failover-gruppe inkludere én eller flere databaser, med samme størrelse og utgave på både primære og sekundære servere. Databasen på den sekundære serveren opprettes automatisk gjennom en prosess som kalles seeding, noe som kan ta litt tid avhengig av databasestørrelsen. Det er viktig å planlegge deretter og vurdere faktorer som nettverkshastighet.
Slik velger du
Georeplikering er egnet for scenarioer der du trenger flere lesbare replikaer og manuell failover er akseptabelt, mens auto-failover-grupper er ideelle for scenarioer som krever automatisk failover og synkron replikering for en gruppe databaser.
Tabellen nedenfor sammenligner funksjonene i georeplikerings- og auto-failover-grupper, sammen med andre relevante detaljer.
| Trekk | Georeplikering | Auto-failover-grupper |
|---|---|---|
| Antall replikaer | Støtter opptil fire sekundære replikaer. | Støtter bare én sekundær replika |
| Konfigurasjonsnivå | Konfigurert per database. | Konfigurert for en gruppe databaser |
| Replikeringstype | Asynkront, noe som betyr at det kan være noe dataforsinkelse mellom primære og sekundære databaser | Synkront, slik at den sekundære databasen alltid er synkronisert med primær. |
| Failover | Krever manuell failover. Programtilkoblingsstrengen må oppdateres etter en failover | Støtter automatisk og manuell failover, uten behov for å endre tilkoblingsstrenger etter en failover |
| Lesbarhet | Inneholder lesbare sekundære databaser. | Gir lesbare sekundære databaser og fungerer som hot-standbys for failover |
| Brukstilfelle | Egnet for scenarioer som trenger flere lesbare replikaer og manuell failover | Ideell for scenarioer som krever automatisk failover og synkron replikering for en gruppe databaser |