SQL braucht eine zweite Region? Georeplikation aktivieren

Fällt die Region deiner Datenbank aus, verliert die Anwendung den Zugriff auf ihre Daten. Eine Sicherung an anderer Stelle wiederherzustellen braucht Zeit. Aktive Georeplikation hält eine laufende Kopie in einer anderen Region bereit, die übernehmen kann. Änderungen werden asynchron übertragen; die sekundäre Datenbank kann deshalb kurz hinter der primären liegen.

Mit einer Datenbank beginnen

Verwende sqldb-cloudtrips auf sql-ctappweu in West Europe. Falls gelöscht, erstelle sie mit Azure SQL Database erstellen erneut. Basic genügt für dieses Lab; eine vorhandene Hyperscale-Datenbank funktioniert ebenfalls, mit entsprechend bepreistem sekundärem Replikat.

Azure erstellt die sekundäre Datenbank aus der primären. Du brauchst nur die vorhandene Quelldatenbank; sqldb-customer2 aus dem Pool-Lab ist separat.

Sekundäre Datenbank erstellen

Öffne sqldb-cloudtrips → Data management → Replicas → Create replica. Verwende dasselbe Abonnement und konfiguriere:

Resource group: rg-cloudtrips-sql-dr-neu (neu)
Secondary server: sql-ctappneu (neu; weltweit eindeutig)
Server location: North Europe
Authentication: SQL authentication
Server admin: ctadmin
Database name: sqldb-cloudtrips (übernommen)
Elastic pool: No
Compute + storage: Dienstebene und Rechengröße der primären Datenbank

Wähle ein starkes Adminpasswort und verwende deine tatsächlichen Servernamen, falls diese bereits vergeben sind. Wähle ein lesbares Georeplikat statt der Standby-Option, falls angeboten. Prüfe die zusätzlichen Datenbankkosten und wähle Review + create → Create.

Prüfe North Europe als Zielregion und sqldb-cloudtrips als Datenbanknamen. Beide Datenbanken heißen gleich, liegen aber auf unterschiedlichen Servern.

Kehre nach der Bereitstellung zur Seite Replicas der primären Datenbank zurück und warte auf den Abschluss der ersten Datenkopie.

Prüfe beide Servernamen und den Replikationsstatus. Eine funktionierende laufende Verbindung kann je nach Ansicht Readable oder CATCH_UP anzeigen; die asynchrone Replikation läuft nach der ersten Kopie weiter.

Übertragung der Daten prüfen

Verbinde dich über deine SQL-Verbindung in VS Code mit der primären Datenbank und führe aus:

IF OBJECT_ID('dbo.GeoCheck', 'U') IS NULL
    CREATE TABLE dbo.GeoCheck (Id int PRIMARY KEY, Note nvarchar(100));
DELETE FROM dbo.GeoCheck WHERE Id = 1;
INSERT INTO dbo.GeoCheck VALUES (1, N'Written in West Europe');

Das erstellt eine kleine Testtabelle und schreibt eine Zeile. Erfolgreiche Ausführung bestätigt den Schreibvorgang; die nächste Abfrage prüft die Replikation.

Erlaube unter sql-ctappneu → Networking deine aktuelle öffentliche IP in den ausgewählten Netzwerken und speichere. Firewallregeln auf Serverebene werden separat konfiguriert. Lasse Allow Azure services and resources to access this server deaktiviert.

Erstelle in VS Code eine zweite Verbindung zu sql-ctappneu.database.windows.net, Datenbank sqldb-cloudtrips, mit den Adminzugangsdaten des sekundären Servers. Lasse die Verschlüsselung aktiviert und führe aus:

SELECT DB_NAME() AS DatabaseName,
       DATABASEPROPERTYEX(DB_NAME(), 'Updateability') AS AccessMode;
SELECT Id, Note FROM dbo.GeoCheck;

Prüfe sql-ctappneu als Verbindungsziel, READ_ONLY als Zugriffsmodus und Written in West Europe in Zeile 1. Falls Tabelle oder Zeile noch fehlen, warte kurz und wiederhole die Abfrage.

Was passiert bei einem Ausfall?

Failover macht die sekundäre Datenbank zur primären und ermöglicht Schreibzugriffe. Ein geplantes Failover synchronisiert zuerst; ein erzwungenes Failover während eines Ausfalls kann neueste Änderungen verlieren. Bei aktiver Georeplikation startest du das Failover und verbindest die Anwendung mit dem neuen primären Server. Der nächste Trip ergänzt eine Failovergruppe für automatisches Failover und eine stabile Verbindungsadresse.

Behalten oder bereinigen

Behalte beide Datenbanken für den Failovergruppen-Trip; beide verursachen Kosten. Andernfalls wähle auf der Replicas-Seite der primären Datenbank Stop replication für das Georeplikat und lösche danach rg-cloudtrips-sql-dr-neu. Das Beenden der Replikation allein lässt eine kostenpflichtige Datenbank bestehen. Behalte die primäre Datenbank für weitere Trips oder lösche auch ihre Labressourcen.