Was geschieht mit Azure Database for PostgreSQL – Single Server nach der Ankündigung der Einstellung?

  • Artikel

GILT FÜR: Azure Database for PostgreSQL – Single Server

**Azure Database for PostgreSQL – Single Server wird eingestellt. Der geplante Termin hierfür ist der 28. März 2025.

Azure Database for PostgreSQL – Single Server ist seit 2018 allgemein verfügbar. Angesichts des Kundenfeedbacks und der neuen Fortschritte bei den Funktionen der Azure-Datenbanklandschaft für Berechnung, Verfügbarkeit, Skalierbarkeit und Leistung muss das Single Server-Angebot eingestellt und mit einer neuen Architektur aktualisiert werden. Azure Database for PostgreSQL – Flexible Server ist die nächste Generation des Diensts und bietet Ihnen die beste Azure-Open-Source-Datenbankplattform.

Im Rahmen der Außerbetriebnahme wird das Erstellen neuer Einzelserverinstanzen über das Azure-Portal ab dem 30. November 2023 nicht mehr unterstützt. Wenn Sie jedoch Einzelserverinstanzen erstellen müssen, um die Anforderungen an die Geschäftskontinuität zu erfüllen, können Sie weiterhin bis März 2025 die Azure CLI verwenden.

Wenn Sie derzeit den Dienst Azure Database for PostgreSQL – Single Server zum Hosten von Produktionsservern nutzen, können Sie Ihre Instanzen von Azure Database for PostgreSQL – Single Server zu Azure Database for PostgreSQL – Flexible Server migrieren.

„Azure Database for PostgreSQL – Flexible Server“ ist ein vollständig verwalteter produktionsbereiter Datenbankdienst, der eine differenziertere Steuerung und mehr Flexibilität bei den Verwaltungsfunktionen und Konfigurationseinstellungen der Datenbank ermöglicht. Weitere Informationen zu ihnen finden Sie unter Azure Database for PostgreSQL – Flexible Server.

Migrieren von Azure Database for PostgreSQL – Single Server zu Azure Database for PostgreSQL – Flexible Server

Hier erfahren Sie, wie Sie mithilfe des PostgreSQL-Migrationsdiensts von „Azure Database for PostgreSQL – Einzelserver“ zu „Azure Database for PostgreSQL – flexibler Server“ migrieren können.

Häufig gestellte Fragen (FAQs)

Q. Warum wird Azure Database for PostgreSQL – Single Server eingestellt?

A. Azure Database for PostgreSQL – Single Server ist seit 2018 allgemein verfügbar. Angesichts des Kundenfeedbacks und der neuen Fortschritte bei den Funktionen der Azure-Datenbanklandschaft für Berechnung, Verfügbarkeit, Skalierbarkeit und Leistung muss das Single Server-Angebot eingestellt und mit einer neuen Architektur aktualisiert werden. Azure Database for PostgreSQL – Flexible Server ist die nächste Generation des Diensts und bietet Ihnen die beste Azure-Open-Source-Datenbankplattform.

F: Warum werde ich aufgefordert, zu „Azure Database for PostgreSQL – Flexible Server“ zu migrieren?

A. Azure Database for PostgreSQL – Flexible Server ist die beste Plattform, um alle Ihre Open-Source-PostgreSQL-Workloads unter Azure auszuführen. Azure Database for PostgreSQL – Flexible Server ist wirtschaftlich, bietet auf allen Dienstebenen eine bessere Leistung und bietet mehr Möglichkeiten zur Kostenkontrolle, um eine kostengünstigere und schnellere Notfallwiederherstellung zu ermöglichen. Zu den weiteren Verbesserungen des flexiblen Servers gehören:

  • Unterstützung für Postgres, Version 11 und höher, sowie integrierte Sicherheitsverbesserungen
  • Besseres Preis-Leistungs-Verhältnis mit Unterstützung für burstfähige Compute-Optionen.
  • Verbesserte Uptime durch die Konfiguration von unmittelbar betriebsbereiten Standbyservern in der gleichen oder einer anderen Verfügbarkeitszone und benutzerseitig gesteuerte Wartungsfenster.
  • Eine vereinfachte Entwicklerumgebung für hochleistungsfähige Datenworkloads.

Q. Wie schnell muss ich meine Single Server-Instanz zu Flexible Server migrieren?

A. Azure Database for PostgreSQL – Single Server soll bis zum 28. März 2025 eingestellt werden. Wir empfehlen daher dringend, Ihre Single Server-Instanz so früh wie möglich zu Flexible Server zu migrieren, damit Sie genügend Zeit haben, den Migrationszyklus zu durchlaufen und die Vorteile von Flexible Server zu nutzen.

Q. Was geschieht mit meinen vorhandenen Instanzen von Azure Database for PostgreSQL – Single Server?

A. Ihre vorhandenen Workloads von Azure Database for PostgreSQL – Single Server werden bis März 2025 unterstützt.

F: Kann ich nach dem Datum des Lebensdauerendes für die Community im November 2023 noch neue Instanzen von Azure Database for PostgreSQL – Single Server der Version 11 erstellen?

A. Ab dem 30. November 2023 können über das Azure-Portal keine neuen Einzelserverinstanzen für PostgreSQL (Version 11) mehr erstellt werden. Sie können sie jedoch noch bis März 2025 über die CLI erstellen. Wir unterstützen Einzelserver über unsere Versionsverwaltungsunterstützungsrichtlinie.. Es wäre am besten, mit der Migration zur Azure Database for PostgreSQL – Flexible Server sofort zu beginnen.

F: Kann ich Azure Database for PostgreSQL – Single Server über den 28. März 2025 hinaus weiter ausführen?

A. Wir planen, Single Server bis zum 28. März 2025 zu unterstützen und raten Ihnen dringend, Ihre Migration so bald wie möglich zu planen. Wir planen, die Unterstützung für Single Server-Bereitstellungen am 28. März 2025 zu beenden.

F: Was passiert, wenn ich nach der Ankündigung der Einstellung von Einzelservern noch einen neuen Einzelserver erstellen muss, um meine geschäftlichen Anforderungen zu erfüllen?

A. Wir werden die Möglichkeit, neue Einzelserver zu erstellen, nicht sofort einstellen, sodass Sie weiterhin neue Einzelserver über die CLI erstellen können, um Ihre geschäftlichen Anforderungen für alle PostgreSQL-Versionen zu erfüllen, die von Azure Database for PostgreSQL-Einzelserver unterstützt werden. Wir empfehlen Ihnen dringend, Flexible Server zu erkunden und zu prüfen, ob Sie damit Ihre Anforderungen erfüllen können. Zögern Sie nicht, uns bei Bedarf zu kontaktieren, damit wir Ihnen helfen und den bestmöglichen Weg vorschlagen können.

F: Fallen für die Durchführung der Migration zusätzliche Kosten an?

A. Sie zahlen für den flexiblen Zielserver und den Quelleinzelserver während der Migration. Die Konfiguration und Berechnung des flexiblen Zielservers bestimmen die zusätzlich anfallenden Kosten (weitere Details finden Sie unter Preise). Sobald Sie den Quelleinzelserver nach der erfolgreichen Migration außer Betrieb genommen haben, zahlen Sie nur für Ihren flexiblen Server. Für die Verwendung des Migrationsdiensts für Einzelserver zu flexiblem Server fallen keine zusätzlichen Kosten an. Wenn Sie Fragen oder Bedenken hinsichtlich der Kosten für die Migration Ihres Einzelservers zu einem flexiblen Server haben, wenden Sie sich an Ihren Microsoft-Kontobeauftragten.

Q. Hat es Auswirkungen auf meine Abrechnung, wenn ich Azure Database for PostgreSQL – Flexible Server anstelle von Azure Database for PostgreSQL – Single Server ausführe?

A. Die Abrechnung sollte vergleichbar sein, wenn Sie eine ähnliche Konfiguration wie bei Ihrer Instanz von Azure Database for PostgreSQL – Single Server wählen. Wenn Sie jedoch dieselbe Zone oder eine redundante Zone mit Hochverfügbarkeit für den flexiblen Zielserver auswählen, ist Ihre Rechnung höher als bei Ihrem Einzelserver. Bei derselben Zone oder Zone mit redundanter Hochverfügbarkeit muss ein zusätzlicher unmittelbar betriebsbereiter Standbyserver hochgefahren und redundante Sicherungsdaten gespeichert werden, daher die zusätzlichen Kosten für den zweiten Server. Diese Architektur ermöglicht eine geringere Downtime bei ungeplanten Ausfällen und geplanter Wartung. Im Allgemeinen ist der Preis für Flexible Server besser, dies hängt jedoch von Ihrer Workload ab.

F: Kommt es zu Downtime, wenn ich meine Azure-Datenbank von PostgreSQL – Single Server zu Flexible Server migriere?

A. Der PostgreSQL-Migrationsdienst unterstützt die Offline- und Onlinemigration. Die Offlinemigration erfordert Downtime für Ihre Anwendungen während des Migrationsprozesses. Die Onlinemigration hilft Ihnen beim Migrieren von Datenbanken mit eingeschränkter Ausfallzeit, aber nur wenigen Einschränkungen. Weitere Informationen finden Sie unter PostgreSQL-Migrationsdienst – Azure Database for PostgreSQL Einzelserver zu Flexibler Server.

Die Downtime hängt von verschiedenen Faktoren ab, darunter die Anzahl und die Größe Ihrer Datenbanken, die Anzahl der Tabellen in jeder Datenbank, die Anzahl der Indizes und die Verteilung der Daten auf die Tabellen. Sie hängt auch von der SKU des Quell- und Zielservers sowie von den auf dem Quell- und Zielserver verfügbaren IOPS ab.

Angesichts der vielen Faktoren, die bei einer Migration eine Rolle spielen, ist es am besten, die Downtime Ihrer Anwendung abzuschätzen, indem Sie die Migration auf einem PITR-Server testen, der vom primären Server wiederhergestellt wurde, um Ihre Produktionsmigration zu planen.

Offlinemigrationen sind weniger komplex und haben ein kleineres Fehlerrisiko. Sie sind die empfohlene Methode zum Migrieren von Workloads mit Dienstfenstern von einem einzelnen Server zu einem flexiblen Server. Die Onlinemigration kann für Produktionsumgebungen mit geringer Toleranz für Ausfallzeiten verwendet werden.

F: Wird es in Zukunft Updates für Single Server-Instanzen geben, um die neuesten PostgreSQL-Versionen zu unterstützen?

A. Wir empfehlen Ihnen, zu Flexible Server zu migrieren, wenn Sie die neuesten Versionen der PostgreSQL-Engine ausführen müssen. Wir stellen weiterhin Nebenversionen bereit, die von der Community für Postgres Version 11 freigegeben wurden, bis diese im November 2023 von der Community eingestellt wird.

Hinweis

Wir verlängern den Support für Postgres, Version 11, über das Deaktivierungsdatum der Community hinaus und unterstützen PostgreSQL, Version 11, sowohl auf Single Server als auch auf Flexible Server, um diesen Übergang zu erleichtern. Sie könnten eine Migration zu Flexible Server durchführen, um die Vorteile der neuesten Versionen der Postgres-Engine zu nutzen.

F: Wie unterscheidet sich die Flexible Server-SLA mit 99,99 %Verfügbarkeit von der Single Server-SLA?

A. Die zonenredundante Flexible Server-Bereitstellung bietet eine Verfügbarkeit von 99,99 % mit Resilienz auf Zonenebene, und Single Server bietet eine Verfügbarkeit von 99,99 %, jedoch ohne Zonenresilienz. Die Hochverfügbarkeitsarchitektur (HA) von Flexible Server stellt einen unmittelbar betriebsbereiten Standbyserver mit redundantem Compute und Speicher bereit (wobei die Daten jedes Standorts in drei Kopien gespeichert sind). Die Hochverfügbarkeitsarchitektur von Single Server verfügt nicht über einen passiven unmittelbar betriebsbereiten Standbyserver, um die Wiederherstellung nach zonenbezogenen Fehlern zu erleichtern. Die Hochverfügbarkeitsarchitektur von Flexible Server verringert die Downtime bei ungeplanten Ausfällen und geplanter Wartung.

Q. Meine Single Server-Instanz wurde in einer Region bereitgestellt, die Flexible Server nicht unterstützt. Wie sollte ich bei der Migration vorgehen?

A. Wir haben die regionale Parität mit Single Server fast erreicht. Dies sind die Regionen, in denen es Flexible Server nicht gibt.

  • China, Osten (CE und CE2)
  • China, Norden (CN und CN2)
  • Indien, Westen
  • Schweden, Norden

Es wird empfohlen, zu den Regionen „CN3/CE3“, „Indien, Mitte“, „Schweden, Mitte“ und „Schweden, Süden“ zu migrieren. F: Ich habe für meinen Einzelserver eine private Verbindung konfiguriert. Wie führe ich eine Migration aus?

A. Die Unterstützung von Private Link ist jetzt für Flexible Server verfügbar. Sie können den Runtimeserver verwenden, um zu einem flexiblen Server mit Unterstützung privater Verbindungen zu wechseln. Weitere Informationen finden Sie unter Runtimeserver – Azure Database for PostgreSQL Einzelserver zu Flexibler Server.

F: Gibt es eine Option für den Rollback einer Migration von Single Server zu Flexible Server?

A. Sie können eine beliebige Anzahl von Testmigrationen durchführen, den Erfolg Ihrer Migration testen und die endgültige Migration durchführen, sobald Sie bereit sind. Testmigrationen wirken sich nicht auf die Einzelserverquelle aus, die betriebsbereit bleibt, bis Sie migrieren und Ihre Verbindungszeichenfolge so ändern, dass sie auf den Flexible Server verweist. Wenn während der Testmigration Fehler auftreten, können Sie die endgültige Migration verschieben und Ihren Quellserver weiterhin ausführen. Sie können dann die endgültige Migration erneut versuchen, nachdem Sie die Fehler behoben haben. Nachdem Sie eine abschließende Migration zu einem flexiblen Server durchgeführt und ihn für die Produktionsworkload geöffnet haben, verlieren Sie die Möglichkeit, ohne Datenverlust zu einem Single Server zurückzukehren.

Q. Wie sollte ich meine Datenbank migrieren (> 1 TB)?

A. Der PostgreSQL-Migrationsdienst kann Datenbanken beliebiger Größen von Einzelserver zu flexiblem Server migrieren. Der Migrationsdienst hat keine Einschränkungen hinsichtlich der Größe der Datenbanken.

F: Wird die regionsübergreifende Migration unterstützt?

A. Ja.

F: Wird die abonnementübergreifende Migration unterstützt?

A. Der PostgreSQL-Migrationsdienst unterstützt abonnementübergreifende Migrationen.

F: Wird ein ressourcengruppenübergreifendes Abonnement unterstützt?

A. Der PostgreSQL-Migrationsdienst unterstützt ressourcenübergreifende Gruppenmigrationen.

F: Gibt es eine versionsübergreifende Unterstützung?

A. Der PostgreSQL-Migrationsdienst unterstützt die Migration von einer niedrigeren PostgreSQL-Version (PG 9.5 und höher) zu einer höheren Version. Wie immer sollte die Anwendungskompatibilität mit höheren PostgreSQL-Versionen vorab überprüft werden.

PostgreSQL-Migrationsdienst

Der PostgreSQL-Migrationsdienst ist ein leistungsstarker Dienst, mit dem Sie Ihre PostgreSQL-Server-Datenbank problemlos von einem Einzelserver zu einem flexiblen Server migrieren können. Mit diesem Dienst können Sie Ihre Datenbank ganz einfach von einem lokalen Server oder einem virtuellen Computer auf einen flexiblen Server in der Cloud verschieben, sodass Sie die Skalierbarkeit und Flexibilität des Cloud Computings nutzen können.

F: Welche Daten-, Schema- und Metadatenkomponenten werden im Rahmen der Migration migriert?

A. Der PostgreSQL-Migrationsdienst migriert Schema, Daten und Metadaten von der Quelle zum Ziel. Alle folgenden Daten-, Schema- und Metadatenkomponenten werden im Rahmen der Datenbankmigration migriert:

Datenmigration

  • Alle Tabellen aus allen Datenbanken/Schemas.

Schemamigration:

  • Benennung
  • Primary key (Primärschlüssel)
  • Datentyp
  • Ordinale Position
  • Standardwert
  • NULL-Zulässigkeit
  • Attribute zum automatischen Inkrementieren
  • Sekundäre Indizes

Migration von Metadaten:

  • Gespeicherte Prozeduren
  • Functions
  • Auslöser
  • Ansichten
  • Fremdschlüsseleinschränkungen

Q. Was ist der Unterschied zwischen Offline- und Onlinemigration?

A. Bei einer Offlinemigration beginnt die Downtime der Anwendung, wenn die Migration gestartet wird. Bei einer Onlinemigration ist die Downtime auf die Dauer des Cutovers am Ende der Migration beschränkt. Es verwendet jedoch einen logischen Replikationsmechanismus, der einigen Einschränkungen unterliegt.

Die folgende Tabelle bietet einen Überblick über die Offline- und Onlineoptionen.

Option Vorteile Nachteile Empfohlen für
Offline – Einfach, leicht und weniger komplex in der Ausführung
– Sehr geringes Fehlerrisiko.
– Keine Einschränkungen in Bezug auf Datenbankobjekte, die verarbeitet werden können		 Ausfallzeiten für Anwendungen. – Am besten geeignet für Szenarien, in denen Einfachheit und eine hohe Erfolgsquote unerlässlich sind
– Ideal für Szenarien, in denen die Datenbank offline geschaltet werden kann, ohne erhebliche Auswirkungen auf den Geschäftsbetrieb zu haben.
– Geeignet für Datenbanken, wenn der Migrationsprozess innerhalb eines geplanten Wartungsfensters abgeschlossen werden kann
Online – Minimale Ausfallzeiten für die Anwendung.
– Ideal für große Datenbanken und für Kund*innen mit Anforderungen an begrenzte Downtime		 - Die bei der Onlinemigration verwendete Replikation weist weniger Einschränkungen auf (z. B. dass Primärschlüssel in allen Tabellen benötigt werden).
– Schwierig und komplexer auszuführen als Offlinemigration.
– Größere Wahrscheinlichkeit von Fehlern aufgrund der Komplexität der Migration
– Wenn die Migration lange dauert, hat dies Auswirkungen auf den Speicher- und Computebedarf des Quellservers. Diese Auswirkungen müssen während der Migration genau überwacht werden.		 – Am besten geeignet für Unternehmen, bei denen die Kontinuität kritisch ist und Downtime gering sein muss.
– Empfohlen für Datenbanken, wenn der Migrationsprozess erfolgen muss, ohne laufende Vorgänge zu unterbrechen

F: Gibt es Empfehlungen zur Optimierung der Leistung der Migration von Einzelserver zu flexiblem Server?

A. Ja. Um schnellere Migrationen durchzuführen, wählen Sie eine höhere SKU für Ihren flexiblen Server aus. Wählen Sie mindestens 4VCores oder höher aus, um die Migration schnell abzuschließen. Sie können die SKU immer so ändern, dass sie den Anwendungsanforderungen nach der Migration entspricht. Sehen Sie sich weitere bewährte Methoden an.

F: Wie lange dauert die Durchführung einer Offlinemigration von Einzelserver zu flexiblem Server mit dem Migrationsdienst?

A. Die folgende Tabelle zeigt die aufgewendete Zeit für die Durchführung von Offlinemigrationen für Datenbanken unterschiedlicher Größe mithilfe des PostgreSQL-Migrationsdiensts. Die Migration wurde mit einem flexiblen Server mit folgender SKU durchgeführt:

Standard_D4ds_v4 (4 Kerne, 16 GB Arbeitsspeicher und 500 IOPS)

Datenbankgröße Zeit (HH:MM)
1 GB 00:01
5 GB 00:03
10 GB 00:08
50 GB 00:35
100 GB 01:00
500 GB 04:00
1.000GB 07:00

Hinweis

Die obigen Zahlen geben die ungefähre Zeit an, die für den Abschluss der Migration benötigt wird. Um die genaue Zeit für die Migration zu Ihrem Server zu erhalten, empfehlen wir dringend, eine Zeitpunktwiederherstellung (Point in Time Restore, PITR) Ihres Einzelservers zu erstellen und diese mit dem PostgreSQL-Migrationsdienst zu migrieren.

F: Wie lange dauert die Durchführung einer Onlinemigration von Einzelserver zu flexiblem Server mit dem Migrationstool?

A. Die Onlinemigration umfasst die folgenden Schritte:

  1. Erste Kopie der Datenbanken
  2. Change Data Capture: Wiederholung aller Transaktionen in der Quelle während Schritt 1 am Ziel.

Die in Schritt 1 benötigte Zeit ist die gleiche wie bei Offlinemigrationen (siehe vorherige Frage).

Die für Schritt 2 erforderliche Zeit hängt von den Transaktionen ab, die an der Quelle erfolgen. Wenn es sich um eine schreibintensive Workload handelt, ist dies länger.

F: Gibt es Support von Microsoft für den Wechsel von Einzelserver zu flexiblem Server?

A. Ja. Zusätzlich zur kontinuierlichen Aktualisierung des Migrationsdiensts arbeiten wir mit internen Partnerteams zusammen, die sich während des gesamten Migrationsprozesses mit Ihnen in Verbindung setzen können. Kontaktieren Sie Ihren Kontobeauftragten, um weitere Informationen zu erhalten.

F: Kann Microsoft mir bei der automatischen Migration meines Einzelservers zu flexiblem Server behilflich sein? A. Ja. Sie können Ihre Server für die automatische Migration nominieren. Weitere Informationen und Möglichkeiten zum Nominieren Ihrer Server für die automatische Migration finden Sie hier.

Weiterer Support

Q. Ich habe weitere Fragen zur Außerkraftsetzung.

A. Sie können auf verschiedene Weise weitere Informationen erhalten.

  • Erhalten Sie Antworten von Communityexperten in Microsoft Q&A.

  • Wenn Sie über einen Supportplan verfügen und technische Hilfe benötigen, erstellen Sie eine Supportanfrage: – Geben Sie eine Beschreibung Ihres Problems ein, um eine Zusammenfassung zu erhalten.     – Wählen Sie als „Problemtyp“ die Option „Technisch“ aus.     – Wählen Sie unter „Abonnement“ Ihr Abonnement aus.     – Wählen Sie „Meine Dienste“ als Dienst aus.     – Wählen Sie als „Diensttyp“ die Option „Azure Database for PostgreSQL Single Server“ aus.     – Wählen Sie unter „Ressource“ Ihre Ressource aus.     – Wählen Sie unter „Problemtyp“ die Option „Migration zu Azure DB for PostgreSQL“ aus.     – Wählen Sie unter „Problemuntertyp“ die Option „Migrieren vom Einzelserver zum flexiblen Server“ aus.

Warnung

Dieser Artikel ist nicht für Benutzer von „Azure Database for PostgreSQL – Flexible Server“ vorgesehen. Er richtet sich an Kunden mit Azure Database for PostgreSQL – Single Server, die ein Upgrade auf Azure Database for PostgreSQL – Flexible Server durchführen müssen.

Wir wissen, dass die Migration von Diensten frustrierend sein kann und entschuldigen uns im Voraus für alle Unannehmlichkeiten, die Ihnen dadurch entstehen. Wählen Sie das Szenario aus, das für Sie und Ihre Umgebung am besten geeignet ist.

Zugehöriger Inhalt