PostgreSQL-App mit hoher Leselast? Lesereplikat erstellen

Kunden bestellen, während Berichte dieselbe Datenbank wiederholt durchsuchen. Diese Lesezugriffe konkurrieren mit Bestellabfragen um CPU, Arbeitsspeicher und Datenträgerzugriffe und verlangsamen die Anwendung. Ein Lesereplikat stellt einen separaten PostgreSQL-Server für Berichte und weitere Leseabfragen bereit. Es erhält Änderungen asynchron vom primären Server. Die Anwendung wählt daher das Ziel jeder Abfrage und berücksichtigt eine mögliche Verzögerung der replizierten Daten.

Vorhandenen Server verwenden

Verwende pg-ctappweu in rg-cloudtrips-pg-test-weu mit Datenbank appdb aus PostgreSQL-Server erstellen.

Prüfe unter Compute + storage die Ebene General Purpose oder Memory Optimized. Falls du nach dem HA-Trip zu Burstable zurückgewechselt bist, wähle eine kleine General-Purpose-Größe und warte auf den Abschluss. Vorhandene HA kann aktiviert bleiben: Ihr Standby übernimmt bei Ausfällen; dieses zusätzliche Replikat bedient Lesezugriffe.

Replikat erstellen

Öffne pg-ctappweu → Settings → Replication → Create replica. Konfiguriere:

Resource group: rg-cloudtrips-pg-test-weu
Replica server name: pg-ctreadweu (weltweit eindeutig)
Region: West Europe
Compute + storage: Für dieses Lab an die Quelle anpassen

Verwende bei Bedarf einen anderen Namen. Prüfe zusätzliche Compute- und Speicherkosten und wähle Review + create → Create. Azure kopiert die Datenbanken des Quellservers einschließlich appdb und startet die Replikation.

Prüfe pg-ctappweu als Quelle, pg-ctreadweu als neuen Server und die gewünschte Labkapazität. Das Replikat wird separat berechnet.

Warte auf den Abschluss und öffne Replication des Quellservers.

Prüfe, dass das Replikat aufgeführt ist und sein Server Ready erreicht. Die erste Kopie kann je nach Datenmenge dauern.

Primär schreiben, auf dem Replikat lesen

Öffne in VS Code eine mit pg-ctappweu → appdb verbundene Abfrage und führe aus:

CREATE TABLE IF NOT EXISTS replica_check (
    id integer PRIMARY KEY,
    note text NOT NULL
);
INSERT INTO replica_check VALUES (1, 'Written on primary')
ON CONFLICT (id) DO UPDATE SET note = EXCLUDED.note;

Erfolgreiche Ausführung schreibt eine erkennbare Testzeile auf dem primären Server. Öffne anschließend pg-ctreadweu → Networking, prüfe öffentlichen Zugriff und füge bei Bedarf deine aktuelle Client-IP hinzu.

Erstelle in Microsofts PostgreSQL-Erweiterung eine separate Verbindung:

Server: pg-ctreadweu.postgres.database.azure.com
Port: 5432
Database: appdb
User: ctadmin
Password: PostgreSQL-Adminpasswort des Quellservers
SSL mode: Verify-Full
SSL root certificate mode: System

Öffne eine neue Abfrage über diese Replikatverbindung und prüfe den Host oberhalb des Editors. Führe aus:

SELECT current_database() AS database_name,
       pg_is_in_recovery() AS is_replica;
SHOW transaction_read_only;
SELECT * FROM replica_check;

Erwarte appdb, is_replica = true, transaction_read_only = on und 1 / Written on primary. Falls Tabelle oder Zeile noch fehlen, warte kurz und wiederhole die Abfrage. Der primäre Server nimmt Schreibzugriffe an; das Replikat stellt diese Änderungen nach dem Aufholen lesbar bereit.

App-Abfragen verteilen

Lasse Schreibzugriffe auf pg-ctappweu und sende Berichtsabfragen über eine zweite Anwendungsverbindung an pg-ctreadweu. Abfragen, die einen gerade geschriebenen Wert sofort sehen müssen, verwenden den primären Server. Beobachte Physical replication delay in den Replikatmetriken; ein ruhiges Lab kann kaum Verzögerung zeigen. Der Test bestätigt Replikation und schreibgeschützten Zugriff; Leistungsgewinne hängen von tatsächlich ausgelagerter Leselast ab.

Bereinigen

Lösche nach Abschluss pg-ctreadweu. Der ursprüngliche pg-ctappweu und seine Daten bleiben verfügbar. Behalte die Ressourcengruppe für weitere Labs; ihr Löschen entfernt alle darin enthaltenen Server.