Vorteile der Azure-Datenbank für PostgreSQL mit Elastic Cluster

Azure Database for PostgreSQL – Elastic Clusters ist die nächste Weiterentwicklung des verteilten PostgreSQL-Angebots von Azure, das auf Azure Database for PostgreSQL Flexible Server mit der Citus-Erweiterung basiert. Für Kunden, die Azure Cosmos DB für PostgreSQL heute ausführen, bietet Elastic Clusters Featureparität für verteilte Postgres-Workloads und bietet einen integrierteren, flexibleren und kosteneffizienteren Weg.

• Eine klare zukunftsgerichtete Roadmap: Elastic Clusters ist die strategische Richtung für verteilte PostgreSQL auf Azure, mit laufenden Investitionen (z. B. geplante Verbesserungen wie geplante Failovers, Speicher autogrow und langfristige Aufbewahrung). Azure Cosmos DB für PostgreSQL befindet sich in diesem Zeitraum auf dem Weg zur Deaktivierung mit eingeschränkter Unterstützung.

• Niedrigeres und einfacheres Kostenmodell (kein dedizierter Koordinatorzuschlag): Elastic Clusters erfordert keinen separat berechneten Nur-Koordinator-Knoten, der die geplanten Kosten reduzieren und die Preisgestaltung beim Skalieren einfacher vorhersagen kann.

• Flexiblere Leistungsauswahl: Wählen Sie zwischen den Stufen "Burstable", "General Purpose" und "Memory Optimized" sowie neueren Computereihen, um Kosten und Leistung pro Knoten anzupassen, wenn sich die Workloads ändern.

• Ausführen von Abfragen von jedem Knoten: Elastic Clusters ermöglicht den Abfragezugriff über jeden Knoten, wodurch die betriebstechnische Flexibilität für Tools, Problembehandlung und Arbeitsauslastungsmuster verbessert wird, die von mehreren Eingangspunkten profitieren.

• Moderne PostgreSQL-Funktionen früher: Schnellere Einführung neuerer PostgreSQL-Versionen (einschließlich PostgreSQL 17-Unterstützung) hilft Kunden, auf Sicherheitsupdates, Leistungsverbesserungen und neue Sprachfeatures zuzugreifen.

• Basierend auf der Azure-Datenbank für PostgreSQL Flexible Server: Elastic Clusters übernimmt das Betriebsmodell, das Kunden bereits für Flexible Server verwenden, einschließlich Sicherungen, Überwachung und Metriken, Wartungskontrollen und Plattformintegration und reduziert so die Komplexität nachgelagerter Betriebsaktivitäten.

• Stärkere Identitäts- und Sicherheitsintegration: Die Unterstützung für verwaltete Identitäten und die Microsoft Entra ID-Authentifizierung trägt dazu bei, die Geheimverwaltung zu vereinfachen und den Datenbankzugriff auf Unternehmensidentitätskontrollen auszurichten.

Funktionsvergleich

Entfernen eines Knotens ist durch Neuverteilung möglich, um Daten von einem Knoten zu verlagern, aber der Knoten selbst wird nicht automatisch außer Betrieb genommen.

Migrationstool

Ein dediziertes Migrationstool wird bereitgestellt, um den nahtlosen Übergang von Azure Cosmos DB für PostgreSQL zu Azure Database für PostgreSQL Elastic Cluster zu erleichtern. Dieses Tool automatisiert die Schema- und Datenmigration, minimiert Ausfallzeiten und stellt die Datenintegrität sicher.

Der Migrationsansatz konzentriert sich auf die Erstellung eines neuen Datenträgers auf Flex, indem eine Momentaufnahme von einem CPG-Cluster erstellt und als primärer Datenträger des Ziel-Elastic Cluster (EC) bereitgestellt wird, wodurch die Migrationszeit drastisch reduziert und die Datentreue sichergestellt wird, ohne dass die Netzwerkqualität beeinträchtigt wird. Anschließend kopieren wir die Delta-Dateien (Erweiterungen, PG - Erweiterungskonfigurationen, Zertifikate, Archivprotokolle usw.) aus dem ursprünglichen Flex /datadrive in den neuen Datenträger.

Das Tool zusammen mit der Popuperinnerung wird ab dem 13^. April über die Registerkarte "Migration" in Azure Cosmos DB für PostgreSQL verfügbar sein.

Von dort aus kann die Migration initiiert werden, indem einfache Details für den Zielserver bereitgestellt werden.

SKU-Zuordnung

Die Azure Cosmos DB für PostgreSQL wird gemäß der folgenden Zuordnungstabelle mit der Ziel-Azure-Datenbank für PostgreSQL (Elastic Cluster) abgeglichen. Nach der Migration können Kunden mit fast 0 Ausfallzeiten nach oben oder unten skalieren.

Migrationsfluss

1. Der Benutzer startet die Migration von der CPG-Clusterseite im Azure-Portal.

2. Das Portal führt Vorab-Prüfungen durch.

3. Wenn die Überprüfung erfolgreich ist, stellt das Portal den ziellastischen Cluster (EC) mit CPG-Migrationseinstellungen (z. B. Sortierung/PG+Citus-Version einrichten) bereit.

4. Das Portal startet die Migration auf der bereitgestellten EC.

5. Das Migrationstool versetzt den CPG-Cluster in den Nur-Lese-Modus und löst die Snapshot-Erstellung (einer pro Knoten für Multi-Knoten Umgebungen) aus.

6. Es ruft Elastic Cluster mit Snapshot-Ressourcen-IDs auf, um die datenträgerbasierte Migration zu starten.

7. Es erstellt neue Datenträger aus den Momentaufnahmen, sperrt die EC, stoppt Container und tauscht die neuen Datenträger als primäre /datadrive ein.

8. Es kopiert "Delta"-Plattformdateien auf den neuen Datenträger (Erweiterungen, PG/Erweiterungskonfigurationen, Zertifikate, Archiv/WAL usw.), stellt dann Besitz/Berechtigungen wieder her und führt erforderliche Metadatenkorrekturen (z. B. Knotenzuordnungen, Rollen, Erweiterungen) aus.

9. Er startet Container und schließt den Migrationsvorgang ab;

10. Nach erfolgreichem Erfolg wendet das Tool Einstellungen nach der Migration auf EC an (benutzerüberschriebene Konfigurationen, HA-Einstellungen).

11. Die Migration wird abgeschlossen: Das Portal aktualisiert den Erfolgs-/Fehlerstatus nach Abschluss. Der CPG Cluster wird gestoppt, und der Elastic Cluster wird das neue beschreibbare Ziel, zu dem der Kunde wechselt (neuer Verbindungsstring, PEC bei Bedarf neu erstellen).

Durchschnittliche Migrationsdauer

In den meisten Fällen wird die End-to-End-Migration in weniger als 10 Minuten abgeschlossen. Das Schreibsperrfenster (schreibgeschützt), von dem Punkt, an dem der Quellcluster auf schreibgeschützt umgestellt wird, bis der Ziel-Elastic-Cluster beschreibbar ist, liegt durchschnittlich bei ca. 5 bis 8 Minuten, sodass es innerhalb eines standardmäßigen geplanten Wartungsfensters ausgeführt werden kann.

Wichtige Faktoren, die sich auf das Timing auswirken können: Datenbankgröße und Anzahl von Knoten (mehr Snapshots/Datenträger), Erweiterungsumfang.

Verwandte Inhalte

• Azure-Datenbank für PostgreSQL