Einheit 5.3: Relationale Datenbanken (Managed PostgreSQL / MariaDB)

Einführung

Die relationale Schicht ist der Bereich, in dem die entscheidendsten Designentscheidungen von FinCorp zusammenlaufen. Das Hauptbuch einer Bank darf keine bestätigten Transaktionen stillschweigend verlieren, doch eine Schicht, die Schreibvorgänge blockiert, sobald ein Knoten kurz ausfällt, stellt ihrerseits eine Art Ausfall dar. Die verwalteten Datenbankdienste ermöglichen es, den Regler für Ausdauer versus Verfügbarkeit präzise einzustellen, allerdings nur, wenn Sie verstehen, welche Garantie jede Einstellung bietet und welche Bequemlichkeiten die Plattform bewusst nicht bereitstellt. In dieser Einheit werden die Entscheidungen zu Replikation, Skalierung, Failover, Zugriff und Wiederherstellung durchgearbeitet. Anschließend wird der relationale Cluster von FinCorp im Data Center Designer mit diesen Entscheidungen als Grundlage aufgebaut.

Eine ehrliche Einordnung ist hier wichtiger als üblich. Es gibt keine Lese-Replikate, kein verwaltetes Failover-Produkt, und der Backup Service greift nicht in eine verwaltete Datenbank ein. Zu jeder Lücke gibt es ein natives Muster, das sie umschließt. Ein Architekt, der diese Punkte als Designeingaben und nicht als fehlende Funktionen betrachtet, erhält am Ende eine sauberere und vorhersehbare Datenschicht.

1. Die Entscheidung für den Replikationsmodus

Ein verwalteter PostgreSQL-Cluster besteht aus einer Primärinstanz und insgesamt ein bis fünf Instanzen, also bis zu vier Standby-Instanzen. Der Replikationsmodus regelt den Vertrag zwischen einer commiteten Transaktion und ihrer Persistenz über diese Knoten hinweg und ist die einzige Entscheidung, die das RPO des Clusters festlegt. PostgreSQL unterstützt zwei aktuelle Modi: Asynchron (Standard) und Strikt synchron. Ein dritter Modus, nicht strikt Synchron, ist für neue Cluster veraltet und sollte nicht gewählt werden; bestehende Cluster in diesem Modus können über die Replikationsmodus-API auf asynchron oder strikt synchron umgestellt werden.

Asynchron bestätigt eine Transaktion, sobald sie auf der Primärinstanz auf der Festplatte geschrieben wurde; die Replikation auf die Standby-Instanzen erfolgt im Hintergrund, mit einer Verzögerung typischerweise im niedrigen Millisekundenbereich. Der Vorteil ist die geringste Schreiblatenz. Der Nachteil ist ein nicht null RPO: Wenn die Primärinstanz ausfällt, bevor ein kürzlich commiteter Vorgang repliziert wurde, geht dieser Commit verloren, wenn eine Standby-Instanz hochgestuft wird. Der dokumentierte Worst Case für den Sicherungspfad ist der Verlust von bis zu den letzten 30 Minuten oder 16 MB an Daten, falls alle Replikate gleichzeitig ihre Daten verlieren, da archivierten Daten in 16-MB-Blöcken oder alle 30 Minuten, je nachdem, was zuerst eintritt, übertragen werden. In einem gesunden Multi-Node-Cluster ist die realistische Exposition einige Millisekunden an in-flight Commits, aber der architektonische Punkt bleibt: Der asynchrone Modus opfert ein kleines, begrenztes Datenverlustfenster zugunsten von Verfügbarkeit und Latenz.

Strikt synchron hält den Commit zurück, bis mindestens eine synchrone Standby-Instanz die Transaktion besitzt, sodass während eines Failovers keine commiteten Daten verloren gehen, einschließlich eines Primärspeicherfehlers mit gleichzeitigem Verlust aller Standby-Instanzen. Der Preis wird an zwei Stellen bezahlt. Die Latenz erhält einen konstanten pro-Transaktion-Overhead, da jeder COMMIT nun auf die Replikation wartet (die Latenz zwischen den Knoten liegt normalerweise unter 1 ms, wird aber zu jedem Schreibvorgang hinzugefügt). Wichtiger noch opfert dieser Modus die Verfügbarkeit zugunsten der Persistenz: Wenn keine synchrone Standby-Instanz verfügbar ist, stoppt die Primärinstanz das Akzeptieren von Schreibvorgängen, anstatt ungeschützt fortzufahren. Um ihn sicher zu betreiben, werden daher mindestens drei Instanzen benötigt, sodass der Verlust eines Knotens immer noch eine Primärinstanz und eine synchrone Standby-Instanz übrig lässt. Die Bereitstellung weniger Knoten ist die klassische Falle, da ein einzelner Standby-Ausfall dann alle Schreibvorgänge stoppt.

Die folgende Tabelle aus der Dokumentation stellt die beiden Modi gegenüber, die in der Produktion verwendet werden sollten:

PostgreSQL ermöglicht es auch, die Commit-Garantien pro Transaktion zu ändern, und die Asymmetrie ist wichtig: Man kann keinen synchronen Commit auf einem asynchronen Cluster erzwingen (ohne eine synchrone Standby-Instanz kollabiert jede stärkere Einstellung auf lokal), aber man kann ein strikt synchrones Cluster betreiben und einzelne Transaktionen auf synchronous_commit=local lockern, wo ein kleiner Datenverlust akzeptabel ist. Die vertretbare Standardkonfiguration besteht daher darin, den Cluster auf die strengere Garantie einzustellen, die die Arbeitslast benötigt, und selektiv zu lockern, nicht umgekehrt.

MariaDB entfernt diese Entscheidung vollständig. Managed MariaDB ist ausschließlich asynchron: ein Replikationsmodus, der Standard. Das ist eine Scope-Entscheidung, kein Mangel, der umgangen werden muss. MariaDB läuft auf Virtual Servern (nicht Cube-Instanzen), verwendet SSD Premium-Speicher mit InnoDB-, MyISAM- oder Aria-Engines und liefert nur LTS-Versionen, derzeit ab 10.6. Wenn eine FinCorp-Arbeitslast wirklich Commits ohne Datenverlust benötigt, gehört sie auf PostgreSQL im strikt synchronen Modus, nicht auf MariaDB. Die Wahl der Engine ist somit teilweise eine Persistenzentscheidung, nicht nur eine SQL-Dialekt-Entscheidung.

1.1 Was automatisches Failover innerhalb eines Clusters tut

Failover innerhalb eines einzelnen Clusters ist automatisch und benötigt kein externes Produkt. Wenn die Primärinstanz nicht verfügbar wird, wird eine Standby-Instanz hochgestuft. Im asynchronen Modus kann jede Standby-Instanz hochgestuft werden, und nicht replizierte Transaktionen gehen verloren; im strikt synchronen Modus ist nur eine Standby-Instanz, die alle bestätigten Transaktionen hält, qualifiziert, weshalb der Modus keine commiteten Daten verlieren kann. Zu einem Zeitpunkt existiert höchstens eine synchrone Standby-Instanz, und wenn sie ausfällt, wird automatisch eine andere zur synchronen Rolle hochgestuft. Diese In-Cluster-Hochstufung ist das gesamte verwaltete Failover der Plattform für eine Datenbank: Sie schützt vor Knotenverlust innerhalb eines Clusters, nicht über Cluster oder Regionen hinweg.

2. Read Scaling Without Read Replicas

PostgreSQL-Standbys dienen der Hochverfügbarkeit, nicht der Bereitstellung von Leseverkehr. Es gibt keine Read Replicas: Sie können Report- oder leseintensiven Traffic nicht auf einen Standby ausrichten, und es gibt keinen verwalteten, nur lesbaren Endpunkt. Dies ist eine feste Plattformgrenze, und das native Muster, das sie ersetzt, besteht aus zwei Teilen.

Erstens eine Verbindungsbeschränkung, 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 lautet:

Davon sind 11 Verbindungen für Systemzwecke reserviert, sodass das nutzbare Kontingent der Anwendung dem Tabellenwert minus elf entspricht. Die Folge ist, dass Sie einen Verbindungssturm nicht durch das Bearbeiten eines Parameters lösen können; die einzigen Hebel sind mehr RAM (bis zur Obergrenze von 1000 Verbindungen) oder weniger echte Verbindungen. Für ein Microservice-Umfeld oder ein serverloses Frontend, das weit mehr logische Verbindungen öffnet, als die Obergrenze zulässt, lautet die Antwort Pooling.

Zweitens der verwaltete Connection Pooler (pgbouncer). Sie können ihn auf dem Cluster aktivieren; das Einzige, was Sie konfigurieren, ist der Pool-Modus. Der Transaction-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-Traffic ist. Der Session-Modus hält die Backend-Verbindung, bis der Client die Verbindung trennt, was nur erforderlich ist, wenn eine Sitzung auf verbindungsspezifischem Zustand wie Sitzungsvariablen oder vorbereiteten Anweisungen basiert, die bestehen bleiben müssen. Der Pooler lauscht auf einem anderen Port: 6432 statt auf dem Standard-Port 5432 der Datenbank, sodass die Aktivierung auch eine Änderung der Client-Konfiguration darstellt und kein transparenter Umschalter ist. Anwendungen müssen auf 6432 zeigen, um den Vorteil zu nutzen.

Read Scaling im eigentlichen Sinne wird eine Ebene höher gelöst, im Cache. Da Standbys keine Lesezugriffe bedienen können, besteht das Read-Scaling-Muster der Plattform aus dem In-Memory DB-Cache (Einheit 5.5), der vor der relationalen Ebene im privaten Netzwerk platziert wird, kombiniert mit Pooling zum Schutz des Verbindungskontingents. Heiße Lesezugriffe werden vom Cache aufgenommen, das relationale Primärknoten bearbeitet Schreibzugriffe und Lesezugriffe bei Cache-Miss, und Pooling hält die Verbindungsanzahl unter der RAM-abgeleiteten Obergrenze. Diese Kombination aus Cache und Pooling ist es, was „Read Scaling" auf dieser Plattform bedeutet, und deshalb ist Einheit 5.5 eine direkte Abhängigkeit jedes leseintensiven FinCorp-Dienstes, kein optionales Extra.

3. Failover zwischen Clustern und privater Zugriff

Die In-Cluster-Promotion (Abschnitt 1.1) ist der einzige verwaltete Failover. Es gibt kein verwaltetes Failover-Produkt, das Cluster oder Regionen übergreift, und entscheidend ist, dass es überhaupt keine native Datenbankreplikation über Regionen oder Cluster hinweg gibt. Wenn FinCorp Kontinuität über ein einzelnes Cluster hinaus benötigt, wird diese Kontinuität technisch umgesetzt und auf der Datenschicht gesteuert, nicht repliziert.

Das native Muster für den Cluster-übergreifenden Failover ist vom Kunden orchestrierter DNS-Failover (aufgebaut in Einheit 3.7, für Resilienz in Einheit 7.1 wieder aufgegriffen). Zwei unabhängige Cluster werden eingerichtet, durch die Anwendung oder durch periodische Dump/Restore-Prozesse synchron gehalten, und ein externer Health Check lennt einen Cloud DNS-Eintrag mit niedriger TTL auf den jeweiligen gesunden Endpunkt. Cloud DNS selbst ist nicht health-aware; es liefert den gesetzten Eintrag. Zwei Eigenschaften steuern das Design: DNS steuert nur neue Verbindungen, daher migrieren bestehende Sitzungen nicht und die Anwendung muss sauber neu verbinden; und die Wiederherstellungszeit wird durch den TTL-Untergrenzwert des Failover-Eintrags dominiert, den Hebel, den Sie für die RTO justieren. Da das zweite Cluster eine separate Datenbank ist, handelt es sich um einen Verfügbarkeitsmechanismus mit einem eigenen RPO, das davon abhängt, wie Sie die beiden synchron halten, nicht um ein Spiegelung ohne Datenverlust.

Der Zugriff erfolgt ausschließlich über private Endpunkte. Ein verwaltetes Cluster hat keine öffentliche IP; es ist ausschließlich innerhalb des virtuellen Rechenzentrums über ein privates LAN erreichbar. Bei der Erstellung wählen Sie ein Rechenzentrum, ein LAN und eine private IP. Verbindungen sind standardmäßig TLS-geschützt: Der SSL-Modus ist prefer und kann vom Client nicht deaktiviert werden, wobei das Serverzertifikat von einer vertrauenswürdigen Stelle ausgestellt wird. Mehrere interne CIDR-Bereiche sind plattformreserviert und können nicht für die private IP des Clusters verwendet werden. Der Vorteil besteht darin, dass die Datenschicht hinter dem privaten Layer-4-Load Balancer der kanonischen geschichteten Architektur (Einheit 1.2) liegt, niemals dem Internet ausgesetzt ist und nur von der Anwendungsschicht und dem Cache erreicht wird.

4. Migration und Wiederherstellung: Dump/Restore und PITR

Zwei Tatsachen definieren die Ebene der Datenkontinuität für verwaltete relationale Datenbanken, und beide sind Einschränkungen, die bei der Gestaltung berücksichtigt werden müssen.

Der Backup Service deckt verwaltete Datenbanken nicht ab. Der auf Acronis basierende Backup Service sichert VMs und Block Storage, nicht jedoch DBaaS, und Block-Storage-Snapshots stellen einen Rollback auf VM-Ebene dar, keine datenbankkonsistenten Sicherungen. Die Datenbankkontinuität wird ausschließlich aus zwei nativen Mechanismen aufgebaut: verwaltete point-in-time-Wiederherstellung und logisches Dump/Restore.

Point-in-time-Wiederherstellung ist das Sicherheitsnetz vor Ort. Der verwaltete Service kombiniert periodische Basis-Sicherungen mit kontinuierlicher Archivierung des Write-Ahead-Logs, sodass eine Sicherung einen Zeitraum und keinen einzelnen Zeitpunkt darstellt. Sicherungen werden erstellt, wenn ein Cluster erstellt wird, wenn seine Hauptversion hochgestuft wird und wenn eine PITR-Operation ausgeführt wird; sie werden verschlüsselt in einem IONOS Cloud Object Storage-Bucket in derselben Region gespeichert (Datenbanken in einer Region ohne Object Storage werden nach eu-central-2 gesichert). Die Aufbewahrungsdauer beträgt standardmäßig 7 Tage und kann über die v2 API von 1 bis 365 Tage festgelegt werden; eine Verringerung löscht Sicherungen, die älter als das neue Zeitfenster sind. Eine Wiederherstellung richtet sich auf ein nicht einschließendes ISO-8601 recoveryTargetTime, kann nur eine Sicherung aus derselben oder einer älteren Hauptversion verwenden, erfordert, dass das Cluster den Status AVAILABLE hat, kann die Datenbank in eine andere Region verschieben und macht die Datenbank für die Dauer der Operation nicht verfügbar (der Service empfiehlt mindestens 4 GB RAM während einer Wiederherstellung, die danach zurückgestuft wird). Behandeln Sie das Standardzeitfenster von 7 Tagen als Frist: Wenn die Audit-Richtlinie von FinCorp eine längere Wiederherstellbarkeit erfordert, sollten Sie die Aufbewahrungsdauer bei der Konzeption explizit erhöhen, anstatt die Lücke während eines Vorfalls zu entdecken.

Dump/Restore ist der einzige Migrationspfad hinein oder heraus. Es gibt keinen verwalteten Import-Assistenten und keine replikationsbasierte Migration in den Service. Das Verschieben einer bestehenden PostgreSQL-Datenbank auf die Plattform oder von ihr weg verwendet die standardmäßigen logischen Werkzeuge pg_dump, pg_restore und psql; für MariaDB ist das Äquivalent mariadb-dump. Die Einschränkungen folgen aus der Regel für private Endpunkte: Da das Ziel-Cluster nur von innerhalb des VDC aus erreichbar ist, muss das Restore von einem Host im privaten LAN des Clusters ausgeführt werden (zum Beispiel eine Sprung-VM in der Anwendungsebene), und der Wechsel verursacht einen ehrlichen Ausfall, der proportional zur Datensatzgröße ist, während das Dump geladen wird. Dies ist der relationale Eintrag im Migrationsplan der Einheit 7.4, bei dem die Datenbankwelle die Dump/Restore-Welle ist. Planen Sie dies als eine dimensionierte, terminierte Operation, nicht als eine Hintergrund-Synchronisation.

Ein Hinweis zu Zugangsdaten hat erhebliches Gewicht: Die bei der Clustererstellung festgelegten Benutzerzugangsdaten sind die einzigen, die der Erstellungsverlauf einrichtet, und sie können nur einmal festgelegt werden. Erfassen Sie sie bei der Bereitstellung im Secret Store, da es danach keinen bequemen Zurücksetzungsverlauf gibt.

DCD-Implementierungsanleitung

Sie erstellen nun den relationalen Cluster von FinCorp: einen mehrknotigen privaten PostgreSQL-Cluster im bestehenden FinCorp-VDC, mit einem bewusst gewählten Replikationsmodus, einem echten Wartungsfenster und einem privaten Verbindungspfad in das Anwendungslan. Damit wird die Entscheidung für die Datenstufe aus den Abschnitten 1 bis 3 umgesetzt. Voraussetzung ist ein bestehender VDC mit einem privaten LAN, das bereits von der Anwendungsschicht verwendet wird (die Topologie aus Einheit 3.1). Der Cluster wird an dieses LAN mit einer von Ihnen gewählten privaten IP angebunden, um den DHCP-Bereich zu vermeiden.

Ziel der Erstellung: Erstellen eines mehrknotigen privaten Clusters mit Replikationsmodus, Wartungsfenster und Verbindungsdetails.

Schritte (im Data Center Designer):

1. Öffnen Sie Menü > Datenbanken > PostgreSQL. Die Übersicht zeigt die Ihrem Vertrag zugewiesenen Ressourcen und deren Auslastung; stellen Sie vor der Clustererstellung sicher, dass ausreichend Kapazität vorhanden ist.
2. Klicken Sie auf Cluster erstellen. Geben Sie einen Cluster-Namen an, der die FinCorp-Umgebung und die Schicht kodiert, und wählen Sie den Standort (Region), der die in Einheit 1.4 getroffene Entscheidung zur Datenhaltung erfüllt. Die Region ist eine Platzierungsentscheidung, die später nicht erneut überdacht werden sollte.
3. Wählen Sie die PostgreSQL-Version aus dem unterstützten Set (derzeit 14, 15 oder 16). Die Auswahl einer aktuellen Hauptversion sichert den längsten Upgrade-Pfad.
4. Wählen Sie den Replikationsmodus. Für die buchhaltungsrelevante Arbeitslast von FinCorp wählen Sie Streng synchron und stellen Sie sicher, dass die Anzahl der Instanzen im nächsten Schritt mindestens drei beträgt, damit der Verlust eines einzelnen Standby-Knotens Schreibvorgänge nicht unterbricht. Für latenzsensitiv, verlusttolerante Dienste belassen Sie den Modus auf Asynchron. Wählen Sie den veralteten nicht-strengen Synchronmodus nicht aus.
5. Setzen Sie den Sicherungsstandort (Region). Sie können Sicherungen in einer anderen Region als der Datenbank für den Schutz vor Ort ablegen; treffen Sie diese Entscheidung anhand der Audit- und Datenhaltungsanforderungen, anstatt den Standardwert blind zu akzeptieren.
6. Legen Sie in der Instanzkonfiguration die CPUs und den Arbeitsspeicher pro Instanz fest (beachten Sie, dass die Verbindungsgrenze aus dem Arbeitsspeicher abgeleitet wird), wählen Sie einen Speichertyp (SSD Premium ist der Standardwert; behalten Sie ihn für die Datenbankarbeitlast bei und beachten Sie, dass SSD unter etwa 100 GB nicht empfohlen wird) und geben Sie die Speichergröße ein. Setzen Sie die Instanzanzahl so, dass ein streng synchroner Cluster drei oder mehr Knoten hat.
7. Wählen Sie in der Netzwerkkonfiguration das Rechenzentrum, das Rechenzentrum-LAN, das die Anwendungsschicht verwendet, und eine Private IP. Es gibt keinen öffentlichen Endpunkt. Um eine sichere private IP zu finden, beachten Sie, dass der DHCP des LANs ein /24 verwendet; verwenden Sie die ersten drei Oktette des Anwendungssubnets und wählen Sie eine Adresse, die zwischen .3 und .10 endet, da DHCP diese nie zuweist, um Kollisionen zu vermeiden.
8. Wählen Sie im Wartungszeitraum einen Tag und eine Startzeit (UTC). Wählen Sie ein echtes Zeitfenster mit geringem Verkehr, da Wartung innerhalb eines 4-Stunden-Fensters ab der Startzeit ausgeführt wird. Wenn dieses Feld praktisch unbegrenzt bleibt, riskieren Sie störende Arbeiten während der Geschäftszeiten.
9. Legen Sie in der Benutzererstellung den anfänglichen Benutzernamen und das Passwort fest. Dies sind die Zugangsdaten, mit denen der Cluster erstellt wird; erfassen Sie sie sofort im Secret Store, da der Erstellungspfad der vorgesehene Ort für deren Festlegung ist.
10. Erstellen Sie den Cluster. Sobald er den Status AVAILABLE erreicht, verbinden Sie sich von einem Host im selben privaten LAN über die zugewiesene private IP oder den zurückgegebenen DNS-Namen auf Port 5432. Wenn Sie später den verwalteten Pooler (pgbouncer) aktivieren, leiten Sie Clients auf Port 6432 um und wählen Sie den Transaktionsmodus, es sei denn, eine auf Sitzungsebene basierende Funktion erzwingt den Sitzungsmodus.

Häufige Fehler:

• Bereitstellung eines streng synchronen Clusters mit weniger als drei Instanzen. Mit nur einem Standby-Knoten unterbricht ein einzelner Standby-Ausfall alle Schreibvorgänge, da der strenge Modus die Aufhebung der synchronen Replikation verweigert. Dimensionieren Sie auf drei oder mehr Knoten, bevor Sie den strengen Modus wählen.
• Auswahl des veralteten nicht-strengen Synchronmodus für einen neuen Cluster. Verwenden Sie Asynchron oder Streng synchron; der mittlere Modus garantiert nicht in allen Umgebungen die Mehrknoten-Dauerhaftigkeit und existiert nur als Legacy-Pfad.
• Zuweisung einer privaten IP innerhalb des DHCP-Bereichs an den Cluster. Kollisionen führen zu intermittierenden Verbindungsstörungen; verwenden Sie die ersten drei Oktette des LANs und wählen Sie eine Adresse, die zwischen .3 und .10 endet.
• Festlegung eines Wartungsfensters während der Geschäftszeiten oder Behandlung desselben als rein kosmetisch. Wartung wird in einem 4-Stunden-Fenster ab der von Ihnen gewählten Startzeit ausgeführt; wählen Sie ein echtes Zeitfenster außerhalb der Spitzenzeiten.
• Erwartung, dass Standbys Leseverkehr bedienen oder als verwalteter Lese-Endpunkt dienen. Es gibt keine Lese-Replikate; skalieren Sie Lesevorgänge mit dem In-Memory DB-Cache plus dem pgbouncer-Pooler, und beachten Sie, dass der Pooler auf Port 6432 läuft.
• Annahme, dass der Backup Service oder ein Block Storage-Snapshot die Datenbank schützt. Keines davon deckt DBaaS ab. Die Datenbankkontinuität besteht aus PITR (Standard: 7 Tage Aufbewahrung, bewusst festgelegt) plus Dump/Restore.
• Verlust der anfänglichen Datenbankzugangsdaten. Diese werden einmalig auf dem Erstellungspfad festgelegt, ohne bequeme Zurücksetzung; speichern Sie sie zum Bereitstellungszeitpunkt.

Eine kurze clientseitige Veranschaulichung der beiden am häufigsten auftretenden Punkte, dem privaten Endpunkt und dem 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 verwaltete relationale Ebene bündelt die Entscheidungen von FinCorp zur Datenbeständigkeit: Der Replikationsmodus von PostgreSQL bestimmt die RPO des Clusters (asynchron für latenzarme, verlusttolerante Arbeitslasten; strikt synchron mit drei oder mehr Knoten für den Verlust von null commit-bereiten Daten; niemals der veraltete nicht-strikte Modus), während MariaDB die Wahl entfällt, da er ausschließlich asynchron arbeitet. Das Skalieren von Lesezugriffen erfolgt nicht über Replikate, die nicht existieren, sondern über einen In-Memory-Cache und den pgbouncer-Pooler gegenüber einer aus dem RAM abgeleiteten Verbindungsgrenze. Der Failover ist innerhalb eines Clusters automatisch und über Cluster hinweg durch DNS-Health-Checks gestaltet. Der Zugriff erfolgt ausschließlich über private Endpunkte, und die Kontinuität wird aus PITR und Dump/Restore aufgebaut, da der Backup Service Datenbanken nicht abdeckt. Der DCD-Build setzt diese Entscheidungen dann in einem echten Cluster um.

Wichtige Punkte:

• Der PostgreSQL-Replikationsmodus ist der RPO-Regler: Asynchron (Standard) akzeptiert ein begrenztes Verlustfenster für Latenz; Strictly Synchronous verliert keine commit-bereiten Daten, benötigt jedoch mindestens drei Knoten und stoppt Schreibvorgänge, wenn kein synchroner Standby verfügbar ist. Der nicht-strikte Synchronous-Modus ist veraltet; MariaDB ist ausschließlich asynchron.
• Es gibt keine Lese-Replikate. Skalieren Sie Lesezugriffe mit dem In-Memory-Cache plus dem verwalteten pgbouncer-Pooler (Standard: Transaktionsmodus, Port 6432); die Verbindungsgrenze wird aus dem RAM abgeleitet (bis zu 1000, minus 11 reserviert) und ist nicht konfigurierbar.
• Der Failover ist innerhalb eines Clusters automatisch (Standby-Promotion); der Failover über Cluster hinweg wird durch eine von der Kundenseite orchestrierte Cloud DNS-Umleitung mit niedriger TTL gestaltet, die von einem externen Health-Check gesteuert wird, nur neue Verbindungen lenkt und deren TTL-Untergrenze die RTO bestimmt.
• Cluster sind ausschließlich private Endpunkte, TLS-erzwungen (prefer, nicht vom Client deaktivierbar), und müssen eine private IP außerhalb des DHCP-Bereichs zugewiesen werden.
• Der Backup Service deckt DBaaS nicht ab. Die Kontinuität besteht aus PITR (Standard: 7 Tage Aufbewahrung, einstellbar von 1 bis 365 Tagen) plus Dump/Restore (pg_dump/pg_restore/psql, oder mariadb-dump), ausgeführt von einem Host im privaten LAN des Clusters; dies ist der Migrationspfad hinein und heraus.

Wichtige Begriffe:

• Strictly Synchronous Replikation: Ein Commit wird erst bestätigt, nachdem ein synchroner Standby ihn hält, und der Primärknoten verweigert Schreibvorgänge, anstatt ungeschützt zu arbeiten; garantiert den Verlust von null commit-bereiten Daten auf Kosten der Verfügbarkeit und der Transaktionslatenz.
• Asynchrone Replikation: Der Primärknoten bestätigt einen Commit beim lokalen Schreiben und repliziert im Hintergrund; niedrigste Latenz, mit einem begrenzten Datenverlustfenster beim Failover.
• pgbouncer-Pooler: Der verwaltete Verbindungspooler, konfiguriert nur durch Pool-Modus (Transaktion oder Sitzung), erreichbar auf Port 6432, verwendet, um Client-Verbindungen unter der aus dem RAM abgeleiteten Grenze zu halten.
• Point-in-time recovery (PITR): Wiederherstellung an Ort und Stelle zu einem gewählten nicht-einschließenden Zeitstempel unter Verwendung von Basis-Sicherungen plus archiviertem WAL, standardmäßig 7 Tage aufbewahrt (1 bis 365 konfigurierbar).

Weitere Lektüre

• Einheit 5.5: In-Memory Database (Cache-Ebene) - die Hälfte des Musters ohne Lese-Replikate, die sich auf Skalierung der Lesezugriffe und die Externalisierung von Sitzungen bezieht.
• Einheit 3.7: DNS und Failover-Routing - der hier erwähnte Failover-Mechanismus zwischen Clustern.
• Einheit 5.7: Datensicherung und Lebenszyklus - wie PITR, Dump/Restore, Snapshots und Object Storage-Archivierung zu einer einheitlichen Kontinuitätsebene zusammengeführt werden.
• Einheit 7.4: Migration und Hybrid-Cutover - der Punkt, an dem die Datenbankwelle als Dump/Restore-Welle geplant wird.