Wissensprüfung - Daten und Speicher
Das Kundenportal von FinCorp dient den Kontenübersichts- und Transaktionsverlaufsansichten, die viel häufiger gelesen als geschrieben werden, alles aus einem regulierten Managed PostgreSQL Cluster auf der privaten Datenebene. Ein Architekt schlägt vor, Lesereplikate zu diesem Cluster hinzuzufügen und den Berichtsverkehr auf einen Standby umzuleiten. Warum ist dies der falsche Ausgangspunkt und was ist das native Muster?
Managed PostgreSQL-Standbys existieren für die Hochverfügbarkeit, nicht für die Bedienung von Leseverkehr; es gibt keine Lesereplikate und keinen gemanagten schreibgeschützten Endpunkt. Das native Muster ersetzt die fehlende Funktion durch eine In-Memory DB-Cache vor der relationalen Ebene (die Lesehälfte des Keine-Lesereplikate-Musters) plus den gemanagten pgbouncer-Pooler. Die Ablenker erfinden einen Modus, der die Leseskalierung ermöglicht, die Instanzanzahl falsch interpretiert und Snapshots missbraucht, die konsistente Blockbilder sind und keine konsistente Datenbankquelle darstellen.
Ein Architekt entwirft die Datenkontinuität für das Anwesen von FinCorp, das migrierte virtuelle Maschinen, Block Storage-Volumen, ein Managed PostgreSQL-Cluster-System und ein Managed MongoDB-Cluster-System umfasst. Ein Teammitglied schlägt einen einzigen Plan vor: Installieren Sie den Acronis-basierten Backup Service-Agent überall, einschließlich auf den Datenbank-Hosts, sodass eine Konsole das gesamte Anwesen abdeckt. Was ist der entscheidende Fehler?
Die wichtigste Grenze in diesem Modul ist, dass der Backup Service keine verwalteten Datenbanken sichert; die Datenbank-Kontinuität wird innerhalb jedes Datenbank-Dienstes durch PITR und logische Dump/Wiederherstellung bereitgestellt. Die Ablenker sind falsch in Bezug auf die Fakten: Die externen Agenten-Variante schützt lokale und in anderen Clouds gehostete virtuelle Maschinen, der Backup Service bietet keine unveränderlichen Sicherungen (Unveränderlichkeit ist eine Eigenschaft von Object Storage-Objekten), und die Speicherklasse macht eine Datenbank nicht durch den Agenten sichern.
FinCorp muss sein mehrjähriges Prüfungsarchiv in Object Storage als manipulationsicher, schreibgeschützter Speicherplatz mit einer Aufbewahrungsfrist speichern, die nicht einmal ein Vertragsadministrator vor dem Ablauf der Aufbewahrungsfrist verkürzen oder löschen kann. Der Architekt bereitstellt einen vertragsgeführten Bucket in einer deutschen Region, lädt die ersten Exporte hoch und versucht dann, Object Lock im COMPLIANCE-Modus zu aktivieren. Die Konsole bietet jedoch keine Option, um es zu aktivieren. Was ist schief gelaufen, und wie lautet das korrekte Design?
Object Lock kann nur bei der Bucket-Erstellung aktiviert werden und nie später hinzugefügt werden, und die Aktivierung von Object Lock schaltet auch die Versionierung ein, wobei keines von beiden rückgängig gemacht werden kann; der COMPLIANCE-Modus macht das Objekt dann bis zum Ablauf der Aufbewahrungsfrist unveränderlich, wobei die Frist von niemandem verkürzt werden kann. Die Ablenker verkehren das Versionierungsverhältnis, erfinden einen API-only-Pfad, der immer noch eine Nachrüstung ermöglicht, und erfinden ein GOVERNANCE-und-dann-COMPLIANCE-Upgrade, das nicht existiert.
Die hohe Volume-Transaktionsrate von FinCorp fließt durch den Event Streams for Apache Kafka. Die Anforderung besteht darin, dass alle Ereignisse für ein bestimmtes Konto in der Reihenfolge verarbeitet werden, in der sie aufgetreten sind, während verschiedene Konten gleichzeitig verarbeitet werden, und dass die Partitionen gleichmäßig auf die drei Broker des Cluster verteilt werden. Welches Themen-Design erfüllt alle drei Einschränkungen gleichzeitig?
Die Reihenfolge in Kafka ist pro Partition, sodass die Verwendung eines Schlüssels auf den Kontoidentifikator jedes Kontos Ereignisse auf einer Partition platziert und eine strikte Reihenfolge pro Schlüssel mit Konkurrenz zwischen den Schlüsseln bietet. Die Anzahl der Partitionen ist auch die harte Obergrenze für die Consumer-Parallelität, und die Verwendung eines Vielfachen der drei Broker (3, 6, 9) hält die Verteilung gleichmäßig. Eine einzelne Partition serialisiert alle Konten und begrenzt die Parallelität auf einen Consumer, 5 ist kein Vielfaches von drei und gibt die Reihenfolge pro Konto auf, und die spekulative Inflation von Partitionen multipliziert Dateihandler, Replikationsverkehr und Ausgleichszeit.
Die gemanagten Datenbanken von FinCorp geben keinen Change-Data-Capture-Stream aus, dem nachgelagerte Systeme abonnieren können, doch die Analyse-Datenbank, das Betrugsmodell und ein Suchindex müssen auf jede Änderung reagieren. Die Architektur muss auch die künstliche Intelligenz-Ebene ermöglichen, die Änderungshistorie von einer committeten Position aus erneut zu lesen, wenn ein Modell neu trainiert wird. Welcher Ansatz ist der native Ersatz auf IONOS?
Da die gemanagten Datenbanken von IONOS keinen abonnierbaren Change-Data-Capture-Stream ausgeben, invertiert das native Muster die Abhängigkeit: die Anwendung veröffentlicht ein Domänen-Ereignis in Kafka, während sie die Änderung vornimmt, und jedes nachgelagerte System liest dieses Thema, wobei Verbrauchergruppen ihre eigenen Offsets verfolgen, sodass die künstliche Intelligenz-Ebene von einer committeten Position aus erneut abspielen kann. Das Auslesen des WAL ist kein unterstützter abonnierbarer Stream, das Differenzieren von Sicherungen ist langsam und fehleranfällig, und MongoDB hat keine gemanagte Änderungs-Stream-Replikation zu einer zweiten Cluster.
FinCorp benötigt eine manipulationsbeweisbare, langfristige Kopie seiner Managed PostgreSQL-Daten, die außerhalb des Cluster überlebt und über Jahre hinweg aufbewahrt werden kann, getrennt von dem 7-Tage-Punkt-in-der-Zeit-Wiederherstellungsfenster des Cluster. Welche Zusammensetzung erfüllt dies, während sie die Grenzen der Plattform respektiert?
PITR ist an ein Fenster gebunden und an den eigenen Sicherungsspeicher des Cluster geknüpft, sodass die portable, langfristige Kopie aus einem logischen Dump (pg_dump) stammt, der an den Object Storage gesendet wird, wo die Objektsperre im COMPLIANCE-Modus die Manipulationsbeweise hinzufügt, die der Datenbankdienst selbst nicht liefert. Die Erweiterung von PITR hält die Kopie nicht-portabel und an den Cluster gebunden, Schnappschüsse sind konsistente Blockabbilder und keine Datenbank-konsistenten Sicherungen, und der Backup Service sichert keine verwalteten Datenbanken überhaupt.