Einheit 5.3: Relationale Datenbanken (Managed PostgreSQL / MariaDB)

Einführung

Die relationale Ebene ist der Bereich, in dem FinCorps wichtigste Designentscheidungen konzentriert sind. Das Ledger einer Bank kann nicht einfach ohne Vorwarnung committete Transaktionen verlieren, aber eine Ebene, die Schreibvorgänge blockiert, sobald ein Node ausfällt, ist ihrerseits eine Art Ausfall. Die gemanagten Datenbankdienste ermöglichen es Ihnen, die Einstellung für Dauerhaftigkeit gegenüber Verfügbarkeit genau vorzunehmen, aber nur, wenn Sie verstehen, was jede Einstellung garantiert und welche Bequemlichkeiten die Plattform bewusst nicht anbietet. Diese Einheit behandelt die Replikation, Skalierung, Failover, Zugriff und Wiederherstellungsentscheidungen und baut dann die relationale FinCorp-Cluster in der Data Center Designer mit diesen Entscheidungen auf.

Die ehrliche Darstellung ist hier wichtiger als sonst. Es gibt keine Lesereplikate, kein gemanagtes Failover-Produkt und die Backup Service berührt keine gemanagte Datenbank. Jede Lücke hat ein natives Muster, das sich darum komponiert, und ein Architekt, der diese als Design-Eingaben und nicht als fehlende Funktionen behandelt, endet mit einer sauberen, vorhersehbareren Daten-Ebene.

1. Die Entscheidung über den Replikationsmodus

Ein Managed PostgreSQL Cluster ist ein primärer Server mit einem bis fünf Instanzen insgesamt, also bis zu vier Standbys. Der Replikationsmodus regelt den Vertrag zwischen einer bestätigten Transaktion und ihrer Dauerhaftigkeit über diese Knoten hinweg, und er ist die einzige Entscheidung, die die RPO des Cluster festlegt. PostgreSQL unterstützt zwei aktuelle Modi: Asynchron (Standard) und Streng Synchron. Ein dritter Modus, nicht-streng Synchron, ist für neue Cluster veraltet und sollte nicht gewählt werden; bestehende Cluster können jedoch über die Replikationsmodus-API auf asynchron oder streng-synchron umgestellt werden.

Asynchron bestätigt eine Transaktion, sobald sie auf dem primären Server auf die Festplatte geschrieben wurde; die Replikation auf die Standbys erfolgt im Hintergrund, mit einer Verzögerung von typischerweise wenigen Millisekunden. Der Vorteil ist die geringste Schreibverzögerung. Der Nachteil ist ein nicht-nuller RPO: Wenn der primäre Server vor einer kürzlichen Bestätigung einer Transaktion ausfällt, geht diese Transaktion verloren, wenn ein Standby-Server aktiviert wird. Der dokumentierte Worst-Case für den Sicherungspfad ist der Verlust von bis zu 30 Minuten oder 16 MB Daten, wenn alle Replikate ihre Daten gleichzeitig verlieren, da archivierte Daten in 16-MB-Blöcken oder alle 30 Minuten, je nachdem, was zuerst kommt, verschickt werden. Bei einem gesunden, mehrinstanziellen Cluster ist die realistische Exposition jedoch nur ein paar Millisekunden der in Flug befindlichen Commits, aber der architektonische Punkt bleibt bestehen: Asynchron-Modus tauscht ein kleines, begrenztes Datenverlustrisiko gegen Verfügbarkeit und Verzögerung.

Streng Synchron hält die Bestätigung, bis mindestens ein synchroner Standby die Transaktion hat, sodass keine bestätigten Daten während eines Failovers verloren gehen, einschließlich eines primären Speicherfehlers mit gleichzeitigem Verlust aller Standbys. Der Preis wird an zwei Stellen bezahlt. Die Verzögerung erhält einen konstanten pro-Transaktions-Aufwand, da jeder COMMIT nun auf die Replikation wartet (die Verzögerung zwischen den Node-Servern beträgt normalerweise weniger als 1 ms, aber wird zu jeder Schreiboperation hinzugefügt). Wichtiger ist jedoch, dass dieser Modus die Verfügbarkeit für die Dauerhaftigkeit opfert: Wenn kein synchroner Standby verfügbar ist, stoppt der primäre Server das Akzeptieren von Schreiboperationen, anstatt ungeschützt fortzufahren. Um es sicher auszuführen, benötigen Sie daher mindestens drei Instanzen, sodass der Verlust eines Node-Servers immer noch einen primären Server und einen synchronen Standby-Server übrig lässt. Die Bereitstellung weniger Knoten ist die klassische Falle, da ein einzelner Standby-Ausfall dann alle Schreiboperationen stoppt.

Die folgende Tabelle aus der Dokumentation vergleicht die beiden Modi, die in der Produktion verwendet werden sollten:

PostgreSQL ermöglicht es Ihnen auch, die Commit-Garantien pro Transaktion zu ändern, und die Asymmetrie ist wichtig: Sie können keinen synchronen Commit auf einem asynchronen Cluster erzwingen (ohne einen synchronen Standby-Server, bricht jede stärkere Einstellung auf lokale zusammen), aber Sie können einen streng-synchronen Cluster ausführen und einzelne Transaktionen auf synchronous_commit=local lockern, wenn ein kleiner Datenverlust akzeptabel ist. Die vertretbare Standard-Einstellung ist daher, den Cluster auf die strengere Garantie zu setzen, die der Workload benötigt, und selektiv zu lockern, nicht umgekehrt.

MariaDB entfernt diese Entscheidung vollständig. Managed MariaDB ist asynchron-only: Ein Replikationsmodus, der Standard. Das ist eine Entscheidung über den Umfang, nicht ein Fehler, den man umgehen muss. MariaDB läuft auf virtuellen Servern (nicht auf Cube-Instanzen), verwendet SSD-Premium-Speicher mit InnoDB-, MyISAM- oder Aria-Engines und liefert nur LTS-Versionen, derzeit ab 10.6. Wenn ein FinCorp-Workload wirklich Null-Datenverlust-Commits benötigt, gehört es auf PostgreSQL im streng-synchronen Modus und nicht auf MariaDB. Die Auswahl des Engines ist also teilweise eine Entscheidung über die Dauerhaftigkeit und nicht nur über die SQL-Dialekte.

1.1 Was automatisches Failover innerhalb eines Cluster macht

Das Failover innerhalb eines einzelnen Cluster ist automatisch und benötigt kein externes Produkt. Wenn der primäre Server nicht mehr verfügbar ist, wird ein Standby-Server aktiviert. Im asynchronen Modus kann jeder Standby-Server aktiviert werden und nicht replizierte Transaktionen werden verloren; im streng-synchronen Modus kann nur ein Standby-Server, der alle bestätigten Transaktionen enthält, aktiviert werden, was der Grund ist, warum dieser Modus keine bestätigten Daten verlieren kann. Es gibt höchstens einen synchronen Standby-Server zur gleichen Zeit, und wenn er ausfällt, wird ein anderer automatisch zum synchronen Standby-Server befördert. Diese Beförderung innerhalb des Cluster ist die gesamte Plattform-Verwaltung für ein Failover einer Datenbank: Sie schützt gegen den Verlust eines Node-Servers innerhalb eines Cluster und nicht über Cluster oder Regionen hinweg.

2. Leseskalierung ohne Lesereplikate

PostgreSQL-Standbys existieren für eine hohe Verfügbarkeit, nicht für die Bedienung von Leseverkehr. Es gibt keine Lesereplikate: Sie können keinen Bericht oder leseintensiven Verkehr auf ein Standby verweisen, und es gibt keinen gemanagten schreibgeschützten Endpunkt. Dies ist eine harte Plattformgrenze, und das native Muster, das es ersetzt, hat zwei Teile.

Erstens, eine Verbindungsobergrenze, die abgeleitet und nicht gewählt wird. Die maximale Anzahl von Verbindungen zu einem PostgreSQL Cluster wird aus der RAM-Größe berechnet und ist nicht benutzerkonfigurierbar. Die dokumentierte Zuordnung ist:

Davon sind 11 Verbindungen für Systemzwecke reserviert, so dass der nutzbare Budget des Anwendungsprogramms der Tabellenwert minus elf ist. Die Konsequenz ist, dass Sie einen Verbindungssturm nicht durch die Bearbeitung eines Parameters lösen können; die einzigen Hebel sind mehr RAM (bis zur 1000-Verbindungs-Obergrenze) oder weniger reale Verbindungen. Für ein Microservice-Anwesen oder ein serverloses Frontend, das weit mehr logische Verbindungen öffnet, als die Obergrenze zulässt, ist die Antwort Pooling.

Zweitens, der gemanagte Verbindungspooler (pgbouncer). Sie können es auf dem Cluster aktivieren; das Einzige, was Sie konfigurieren, ist der Poolmodus. Transaktions-Modus (Standard) gibt die Verbindung am Ende jeder Transaktion an den Pool zurück, was viele Client-Verbindungen auf wenige Backend-Verbindungen multiplexiert und die richtige Wahl für typischen Web- und Microservice-Verkehr ist. Sitzungs-Modus hält die Backend-Verbindung, bis der Client sich trennt, was nur benötigt wird, wenn eine Sitzung auf verbindungsbasierten Zustand wie Sitzungsvariablen oder vorbereiteten Anweisungen angewiesen ist, die persistieren müssen. Der Pooler hört auf einem anderen Port: 6432 anstelle des Standardports 5432 der Datenbank, so dass die Aktivierung auch eine Client-Konfigurationsänderung und kein transparenter Schalter ist. Anwendungen müssen auf 6432 verweisen, um den Vorteil zu erhalten.

Leseskalierung im eigentlichen Sinne wird ein Tier höher im Cache gelöst. Da Standbys keine Lesevorgänge bedienen können, ist das Plattformmuster für Leseskalierung der In-Memory DB-Cache (Einheit 5.5) vor der relationalen Ebene im privaten Netzwerk platziert, kombiniert mit Pooling, um den Verbindungsrahmen zu schützen. Heiße Lesevorgänge werden vom Cache absorbiert, die relationale Hauptkomponente behandelt Schreibvorgänge und Lesevorgänge, die den Cache verfehlen, und Pooling hält die Verbindungsanzahl unter der RAM-abgeleiteten Obergrenze. Diese Cache-Plus-Pooling-Zusammensetzung ist, was "Leseskalierung" auf dieser Plattform bedeutet, und es ist der Grund, warum Einheit 5.5 eine direkte Abhängigkeit von jedem hochleseintensiven FinCorp-Service ist und kein optionaler Zusatz.

3. Failover Across Clusters und Private Access

Die In-Cluster-Förderung (Abschnitt 1.1) ist das einzige gemanagte Failover. Es gibt kein gemanagtes Failover-Produkt, das Clusters oder Regionen umfasst, und es gibt keine native Cross-Region- oder Cross-Cluster-Datenbank-Replikation. Wenn FinCorp eine Kontinuität über einen einzelnen Cluster hinaus benötigt, wird diese Kontinuität konstruiert und gesteuert, nicht jedoch auf der Datenbankebene repliziert.

Das native Cross-Cluster-Muster ist das kundenseitig orchestrierte DNS-Failover (in Einheit 3.7 aufgebaut und in Einheit 7.1 für die Widerstandsfähigkeit überarbeitet). Zwei unabhängige Cluster werden eingerichtet, die durch die Anwendung oder durch periodische Dump-/Wiederherstellungs-Vorgänge synchron gehalten werden, und ein externer Gesundheitscheck verweist einen Low-TTL-Cloud DNS-Datensatz auf den gesunden Endpunkt. Der Cloud DNS selbst ist nicht gesundheitsbewusst; er dient dem Datensatz, den Sie festgelegt haben. Zwei Eigenschaften bestimmen das Design: Das DNS steuert nur neue Verbindungen, so dass bestehende Sitzungen nicht migrieren und die Anwendung sauber neu verbinden muss; und die Wiederherstellungszeit wird von der TTL-Untergrenze des Failover-Datensatzes bestimmt, die Sie für die RTO einstellen. Da die zweite Cluster eine separate Datenbank ist, handelt es sich um ein Verfügbarkeitsmechanismus mit seinem eigenen RPO, der durch die Synchronisierung der beiden bestimmt wird, und nicht um ein spiegelbildliches Zero-Loss-System.

Der Zugriff ist nur über private Endpunkte möglich. Ein gemanagtes Cluster hat keinen öffentlichen IP; es ist nur innerhalb des virtuellen Rechenzentrums über ein privates LAN erreichbar. Während der Erstellung wählen Sie ein Rechenzentrum, ein LAN und einen privaten IP. Verbindungen sind standardmäßig durch TLS geschützt: Der SSL-Modus ist prefer und kann vom Client nicht deaktiviert werden, wobei das Serverzertifikat von einer vertrauenswürdigen Behörde ausgestellt wird. Mehrere interne CIDR-Bereiche sind plattformreserviert und können nicht für die private IP des Cluster verwendet werden. Der Vorteil besteht darin, dass die Datenebene hinter dem privaten Layer-4-Lastenausgleich der kanonischen geschichteten Architektur (Einheit 1.2) liegt, niemals dem Internet ausgesetzt ist und nur von der Anwendungsebene und dem Cache erreicht werden kann.

4. Migration und Wiederherstellung: Dump/Wiederherstellung und PITR

Zwei Fakten definieren die Datenkontinuitätsebene für gemanagte relationale Datenbanken und beide sind Einschränkungen, um die herum man entwerfen muss.

Das Backup Service deckt keine gemanagten Datenbanken ab. Das auf Acronis basierende Backup Service sichert virtuelle Maschinen und Block Storage, nicht jedoch DBaaS, und Block Storage-Schnappschüsse sind VM-Ebene-Rollback, nicht jedoch konsistente Datenbanksicherungen. Die Datenbankkontinuität wird aus zwei nativen Mechanismen aufgebaut: gemanagte Punkt-in-der-Zeit-Wiederherstellung und logische Dump/Wiederherstellung.

Punkt-in-der-Zeit-Wiederherstellung ist das Sicherheitsnetz vor Ort. Der gemanagte Dienst kombiniert periodische Basis-Sicherungen mit kontinuierlicher Archivierung von Write-Ahead-Logs, so dass eine Sicherung einen Zeitraum und nicht nur einen einzelnen Zeitpunkt darstellt. Sicherungen werden erstellt, wenn eine Cluster erstellt wird, wenn ihre Hauptversion erhöht wird und wenn ein PITR-Vorgang ausgeführt wird. Sie werden verschlüsselt in einem IONOS Cloud Object Storage-Bucket in der gleichen Region gespeichert (Datenbanken in einer Region ohne Object Storage werden in eu-central-2 gesichert). Die Aufbewahrungsfrist beträgt standardmäßig 7 Tage und kann über die v2-API von 1 bis 365 Tagen festgelegt werden. Eine Reduzierung der Aufbewahrungsfrist löscht Sicherungen, die älter sind als das neue Zeitfenster. Eine Wiederherstellung zielt auf ein nicht-einschließliches ISO-8601-recoveryTargetTime, kann nur eine Sicherung von der gleichen oder einer älteren Hauptversion verwenden, erfordert, dass die Cluster verfügbar ist, kann die Datenbank in eine andere Region verschieben und macht die Datenbank während der Dauer des Vorgangs nicht verfügbar (der Dienst empfiehlt mindestens 4 GB RAM während einer Wiederherstellung, die danach wieder herabgesetzt werden kann). Behandeln Sie das Standard-7-Tage-Fenster als Deadline: Wenn die Prüfpolitik von FinCorp eine längere Wiederherstellbarkeit erfordert, erhöhen Sie die Aufbewahrungsfrist explizit bei der Entwurfszeit und nicht erst während eines Vorfalls.

Dump/Wiederherstellung ist der einzige Migrationspfad hinein oder hinaus. Es gibt keinen gemanagten Import-Assistenten und keine replikationsbasierte Migration in den Dienst. Das Verschieben einer bestehenden PostgreSQL-Datenbank auf die Plattform oder von ihr weg verwendet die standardmäßigen logischen Tools pg_dump, pg_restore und psql; für MariaDB ist das Äquivalent mariadb-dump. Die Einschränkungen ergeben sich aus der privaten-Endpunkt-Regel: Da das Ziel-Cluster nur von innerhalb des VDC erreichbar ist, muss die Wiederherstellung von einem Host auf dem privaten LAN des Cluster (z. B. einem Sprung-VM in der Anwendungsebene) ausgeführt werden, und der Umstellungsprozess verursacht eine ehrliche Ausfallzeit, die proportional zur Datensatzgröße ist, während die Sicherung geladen wird. Dies ist der relationale Eintrag im Migrationsplan von Einheit 7.4, wo die Datenbankwelle die Dump/Wiederherstellungs-Welle ist. Planen Sie dies als eine geplante, terminierte Operation und nicht als Hintergrund-Synchronisation.

Eine wichtige Ausnahme bei den Anmeldeinformationen hat echtes Gewicht: Die bei der Erstellung der Cluster festgelegten Benutzeranmeldeinformationen sind die einzigen, die der Erstellungsprozess herstellt, und sie können nur einmal festgelegt werden. Erfassen Sie diese in dem Geheimnis-Speicher bei der Bereitstellung, da es danach keinen bequemen Rücksetzweg gibt.

DCD Implementierung Schritt-für-Schritt

Sie werden nun die FinCorp relationale Cluster erstellen: eine multi-Node private PostgreSQL Cluster auf dem bestehenden FinCorp VDC, mit einem bewussten Replikationsmodus, einem echten Wartungsfenster und einer privaten Verbindung in die Anwendungs-LAN. Dies realisiert die Daten-Ebene-Entscheidung aus den Abschnitten 1 bis 3. Die Voraussetzung ist ein bestehendes VDC mit einer privaten LAN, die die Anwendungsebene bereits verwendet (die Topologie aus Einheit 3.1); die Cluster wird sich an diese LAN mit einer privaten IP anhängen, die Sie wählen, um den DHCP-Bereich zu vermeiden.

Ziel: Eine multi-Node private Cluster mit Replikationsmodus, Wartungsfenster und Verbindungsdetails erstellen.

Schritte (im Data Center Designer):

1. Öffnen Sie Menü > Datenbanken > PostgreSQL. Der Überblick zeigt die für Ihren Vertrag zugewiesenen Ressourcen und wie viele verwendet werden; bestätigen Sie, dass genügend Kapazität vorhanden ist, bevor Sie die Cluster erstellen.
2. Klicken Sie auf Cluster erstellen. Geben Sie einen Cluster-Namen ein, der die FinCorp-Umgebung und -Ebene kodiert, und wählen Sie den Standort (Region), der die Residenzentscheidung aus Einheit 1.4 erfüllt. Die Region ist eine Platzierungsentscheidung und sollte nicht später geändert werden.
3. Wählen Sie die PostgreSQL-Version aus dem unterstützten Satz (derzeit 14, 15 oder 16). Die Auswahl einer aktuellen Hauptversion gewährleistet den längsten Upgrade-Pfad.
4. Wählen Sie den Replikationsmodus. Für FinCorps Ledger-Grade-Workload wählen Sie Streng Synchron und stellen Sie sicher, dass die Instanzanzahl im nächsten Schritt mindestens drei beträgt, damit ein einzelner Standby-Verlust die Schreibvorgänge nicht stoppt. Für latenzsensitive, verlusttolerante Dienste, lassen Sie es bei Asynchron. Wählen Sie nicht den veralteten nicht-strengen Synchronmodus.
5. Legen Sie den Sicherungsspeicherort (Region) fest. Sie können Sicherungen in einer anderen Region als die Datenbank für den externen Schutz platzieren; entscheiden Sie dies gegen die Audit- und Residenz-Anforderungen und nicht einfach die Standard-Einstellung akzeptieren.
6. Im Instanz-Konfiguration, legen Sie die CPUs und den RAM pro Instanz fest (denken Sie daran, dass die Verbindungsobergrenze vom RAM abgeleitet wird), wählen Sie einen Speichertyp (HDD ist der Standard; wählen Sie SSD oder SSD Premium für die Datenbank-Workload, da SSD unter 100 GB nicht empfohlen wird) und geben Sie die Speichergröße ein. Legen Sie die Instanzanzahl so fest, dass eine streng-synchrone Cluster mindestens drei Knoten hat.
7. Im Netzwerkkonfiguration, wählen Sie das Rechenzentrum, die Rechenzentrum-LAN, die die Anwendungsebene verwendet, und eine Private IP. Es gibt keinen öffentlichen Endpunkt. Um einen sicheren privaten IP zu finden, beachten Sie, dass der LAN-DHCP einen /24-Bereich verwendet, also die ersten drei Oktetten des Anwendungssubnetzes wiederverwenden und eine Adresse wählen, die zwischen .3 und .10 endet, die DHCP nie zuweist, um eine Kollision zu vermeiden.
8. Im Wartungsfenster, wählen Sie einen Tag und eine Startzeit (UTC). Wählen Sie ein echtes Niedrigverkehrs-Slot, da die Wartung innerhalb eines 4-Stunden-Fensters von dieser Startzeit ausgeführt wird. Wenn Sie dies effektiv unbeschränkt lassen, lädt dies zu störenden Arbeiten während der Geschäftszeiten ein.
9. Im Benutzererstellung, legen Sie den anfänglichen Benutzernamen und Passwort fest. Diese sind die Anmeldedaten, mit denen die Cluster erstellt wird; erfassen Sie sie sofort im Geheimnis-Speicher, da der Erstellpfad der beabsichtigte Ort ist, um sie festzulegen.
10. Erstellen Sie die Cluster. Sobald sie verfügbar ist, verbinden Sie sich von einem Host auf dem gleichen privaten LAN mit der zugewiesenen privaten IP oder dem zurückgegebenen DNS-Namen auf Port 5432. Wenn Sie später den gemanagten Pooler (pgbouncer) aktivieren, verweisen Sie die Clients auf Port 6432 und wählen den Transaktionsmodus, es sei denn, eine Sitzungs-gesteuerte Funktion erzwingt den Sitzungsmodus.

Häufige Fehler:

• Eine streng-synchrone Cluster mit weniger als drei Instanzen bereitstellen. Mit nur einem Standby kann ein einzelner Standby-Verlust alle Schreibvorgänge stoppen, da der strenge Modus die synchrone Replikation nicht aufhebt. Stellen Sie sicher, dass Sie mindestens drei Knoten haben, bevor Sie den strengen Modus wählen.
• Den veralteten nicht-strengen Synchronmodus für eine neue Cluster wählen. Verwenden Sie Asynchron oder Streng Synchron; der mittlere Modus garantiert nicht die multi-Node-Haltbarkeit unter allen Umständen und existiert nur als Legacy-Pfad.
• Der Cluster eine private IP innerhalb des DHCP-Bereichs zuweisen. Kollisionen brechen die Verbindung intermittierend; wiederverwenden Sie die ersten drei Oktetten des LAN und wählen Sie eine Adresse, die zwischen .3 und .10 endet.
• Ein Wartungsfenster während der Geschäftszeiten festlegen oder es als kosmetisch behandeln. Die Wartung wird in einem 4-Stunden-Fenster von der Startzeit ausgeführt, die Sie wählen; wählen Sie ein echtes Niedrigverkehrs-Slot.
• Erwarten, dass Standbys den Leseverkehr bedienen oder ein gemanagter Lese-Endpunkt sind. Es gibt keine Lese-Replikate; skalieren Sie die Lesevorgänge mit dem In-Memory DB-Cache plus dem pgbouncer-Pooler und beachten Sie, dass der Pooler auf Port 6432 ist.
• Annehmen, dass der Backup Service oder ein Block Storage Snapshot die Datenbank schützt. Keiner von beiden schützt die DBaaS. Die Datenbank-Kontinuität ist PITR (Standard-7-Tage-Retention, absichtlich festgelegt) plus Dump/Wiederherstellung.
• Die anfänglichen Datenbank-Anmeldedaten zu verlieren. Sie werden nur einmal auf dem Erstellpfad festgelegt und es gibt keine bequeme Rücksetzung; speichern Sie sie bei der Bereitstellung.

Eine kurze client-seitige Illustration der beiden Fakten, die am häufigsten beißen, der private Endpunkt und der Pooler-Port:

# Direct connection (port 5432), from a host on the cluster's private LAN
psql -h pg-xxxxxxxx.postgresql.de-fra.ionos.com -U fincorp_app -d ledger

# Through the managed pooler (transaction mode): same host, port 6432
psql -h pg-xxxxxxxx.postgresql.de-fra.ionos.com -U fincorp_app -d ledger --port=6432

Zusammenfassung

Die gemanagte relationale Ebene konzentriert FinCorps Ausfallsicherheitsentscheidungen: PostgreSQL's Replikationsmodus setzt den RPO (asynchron für niedrige Latenz, verlusttolerante Arbeit; streng synchron mit drei oder mehr Knoten für null committete Datenverlust; nie den veralteten nicht-strengen Modus) von Cluster, während MariaDB die Wahl durch asynchrone Verarbeitung entfernt. Leseskalierung wird nicht mit Replikaten durchgeführt, die nicht existieren, sondern mit einem In-Memory-Cache und dem pgbouncer-Pooler gegen eine RAM-abgeleitete Verbindungsobergrenze. Failover ist automatisch innerhalb eines Cluster und über Cluster mit DNS-Gesundheitsprüfungen konzipiert. Der Zugriff ist nur über private Endpunkte möglich, und die Kontinuität wird durch PITR und Dump/Wiederherstellung aufgebaut, da der Backup Service keine Datenbanken abdeckt. Der DCD-Build committet dann diese Entscheidungen in eine reale Cluster.

Wichtige Punkte:

• Der Replikationsmodus von PostgreSQL ist die RPO-Einstellung: Asynchron (Standard) akzeptiert ein begrenztes Verlustfenster für Latenz; Streng Synchron verliert keine committeten Daten, benötigt aber ein Minimum von drei Node und stoppt Schreibvorgänge, wenn kein synchroner Standby verfügbar ist. Der nicht-streng synchronisierte Modus ist veraltet; MariaDB ist asynchron-only.
• Es gibt keine Lese-Replikate. Skalieren Sie die Lesevorgänge mit dem In-Memory-Cache und dem gemanagten pgbouncer-Pooler (Transaktionsmodus standardmäßig, Port 6432); die Verbindungsobergrenze wird von RAM abgeleitet (bis zu 1000, minus 11 reservierte) und ist nicht konfigurierbar.
• Failover ist automatisch innerhalb eines Cluster (Standby-Promotion); Failover zwischen Cluster-Clustern wird mit einem kundenseitig orchestrierten, niedrigem TTL-Cloud DNS-Umleitungsprozess konzipiert, der von einer externen Gesundheitsprüfung gesteuert wird, die neue Verbindungen nur umleitet und deren TTL-Boden die Wiederherstellungszeit bestimmt.
• Cluster sind nur über private Endpunkte zugänglich, TLS-enforced (prefer, nicht client-deaktivierbar), und müssen einen privaten IP außerhalb des DHCP-Bereichs erhalten.
• Der Backup Service deckt keine DBaaS ab. Die Kontinuität wird durch PITR (Standard 7-Tage-Retention, einstellbar 1 bis 365 Tage) plus Dump/Wiederherstellung (pg_dump/pg_restore/psql oder mariadb-dump) sichergestellt, die von einem Host auf dem privaten LAN des Cluster-Clusters ausgeführt wird; dies ist der Migrationspfad hinein und hinaus.

Wichtige Begriffe:

• Streng synchronisierte Replikation: Ein Commit wird nur bestätigt, wenn ein synchroner Standby ihn hält, und der Primärserver schreibt nicht, bevor er nicht geschützt ist; garantiert null committete Datenverlust bei gleichzeitiger Beeinträchtigung der Verfügbarkeit und der pro-Transaktions-Latenz.
• Asynchrone Replikation: Der Primärserver bestätigt einen Commit auf lokalem Schreibvorgang und repliziert im Hintergrund; geringste Latenz, mit einem begrenzten Datenverlustfenster bei Failover.
• pgbouncer-Pooler: Der gemanagte Verbindungspooler, der nur über den Poolmodus (Transaktion oder Sitzung) konfiguriert wird, der auf Port 6432 erreicht wird, um Client-Verbindungen unter der RAM-abgeleiteten Obergrenze zu halten.
• Point-in-time-Wiederherstellung (PITR): Wiederherstellung an einem bestimmten Zeitpunkt mithilfe von Basis-Sicherungen und archivierten WAL-Dateien, die standardmäßig 7 Tage lang aufbewahrt werden (1 bis 365 Tage konfigurierbar).

Weitere Lektüre

• Einheit 5.5: In-Memory-Datenbank (Cache-Tier) - die lese-skalierte und session-externisierte Hälfte des no-read-replicas-Musters.
• Einheit 3.7: DNS und Failover-Routing - der cross-Cluster-Failover-Mechanismus, der hier referenziert wird.
• Einheit 5.7: DatenSchutz und Lebenszyklus - wie PITR, dump/restore, Snapshots und Object Storage-Archiv zu einer KontinuitätsEbene zusammengesetzt werden.
• Einheit 7.4: Migration und Hybrid-Übernahme - wo die Datenbankwelle als dump/restore-Welle geplant wird.