Freigeben über

Automigration von Azure Database for PostgreSQL – Single Server zu Flexibler Server

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

Azure-Datenbank für PostgreSQL Einzelserver wurde jetzt eingestellt. Daher werden die Migrationsartikel zu diesem Dienst in Kürze entfernt. Es ist wichtig, zu Azure Database für den flexiblen PostgreSQL-Server zu migrieren, um kontinuierlichen Service und Support sicherzustellen. Überprüfen und abschließen Sie alle erforderlichen Migrationen zum flexiblen Server, bevor diese Ressourcen nicht mehr verfügbar sind.

Automigration von Azure Database for PostgreSQL – Single Server zu Flexibler Server ist eine vom Dienst initiierte Migration, die während eines geplanten Ausfallzeitfensters für Single Server stattfindet, getrennt vom Patch- oder Wartungsfenster. Der Dienst identifiziert berechtigte Server und sendet vorab Benachrichtigungen mit detaillierten Schritten zum Automigrationsprozess. Sie können den Migrationszeitplan bei Bedarf überprüfen und anpassen oder eine Supportanfrage senden, um die Automigration für Ihre Server zu deaktivieren.

Die Automigration nutzt den Azure PostgreSQL-Migrationsdienst, um während des geplanten Migrationsfensters eine resiliente Offlinemigration bereitzustellen. Die Downtime variiert je nach Workloadmerkmalen. Informationen zu Benchmarks zur Migrationsgeschwindigkeit finden Sie unter Azure PostgreSQL – Benchmarking der Migrationsgeschwindigkeit. Diese Migration entfernt die Notwendigkeit einer manuellen Servermigration. Nach der Migration können Sie von flexiblen Serverfeatures wie verbesserter Preisleistung, granularer Datenbankkonfigurationskontrolle und benutzerdefinierten Wartungsfenstern profitieren.

Hinweis

Der Automigrationsdienst kann alle einzelnen Server migrieren, außer in den folgenden Fällen:

  • Server mit vom Kunden verwalteten Schlüsseln konfiguriert
  • Server mit Zugriff verweigern für das öffentliche Netzwerk auf Ja festgelegt

Nominieren von Einzelservern für die Automigration

Der Nominierungsprozess richtet sich an Benutzer, die ihre Migration auf flexiblen Server freiwillig schnell nachverfolgen möchten. Wenn Sie über eine Arbeitsauslastung mit einem Single Server verfügen, können Sie sich jetzt selbst (sofern nicht bereits vom Dienst geplant) für die automatische Migration benennen. Übermitteln Sie Ihre Serverdetails über dieses Formular.

Voraussetzungen für die Automigration

Überprüfen Sie die folgenden Voraussetzungen, um eine erfolgreiche automatische Migration sicherzustellen:

  • Die Single Server-Instanz sollte während des geplanten Migrationsfensters bereit sein, damit die automatische Migration stattfindet.

  • Für die Einzelserverinstanz muss die Einstellung Öffentlichen Netzwerkzugriff verweigern auf Nein festgelegt sein. Diese Option finden Sie auf der Seite "Verbindungssicherheit " im Azure-Portal.

  • Stellen Sie für die Single Server-Instanz mit aktiviertem SSL sicher, dass alle Zertifikate (DigiCertGlobalRootG2 Root CA, DigiCertGlobalRootCA Root CA) im vertrauenswürdigen Stammspeicher verfügbar sind. Wenn Sie das Zertifikat an die Verbindungszeichenfolge angeheftet haben, erstellen Sie vor der geplanten automatischen Migration ein kombiniertes Zertifizierungsstellenzertifikat mit allen drei Zertifikaten, um die Geschäftskontinuität nach der Migration sicherzustellen.

  • Wenn die Quellinstanz von Azure Database for postgreSQL – Single Server über Firewallregelnamen mit mehr als 80 Zeichen verfügt, benennen Sie sie um, um sicherzustellen, dass die Namen weniger als 80 Zeichen lang sind. (Die auf flexiblen Servern unterstützte Länge der Firewallregelnamen beträgt 80 Zeichen, während auf einem Single Server die zulässige Länge 128 Zeichen beträgt.)

Automigrationsprozess

Der Automigrationsprozess umfasst mehrere wichtige Phasen:

  • Erstellung des flexiblen Zielservers: Ein flexibler Server, der mit Leistung und Kosten Ihrer Single Server-SKU übereinstimmt, wird erstellt. Er erbt alle Firewallregeln von der Single Server-Quelle.

  • Datenmigration: Die Datenmigration erfolgt während des festgelegten Migrationsfensters, in der Regel außerhalb der Geschäftszeiten für die Hostingregion des Servers (wenn das Fenster vom Dienst ausgewählt wird). Der Quell-Single Server ist auf schreibgeschützt festgelegt. Die Migration überträgt alle Daten, Schemas, Benutzerrollen, Berechtigungen und den Besitz von Datenbankobjekten an den flexiblen Server. Darüber hinaus werden alle vorhandenen Firewallregeln auf den flexiblen Server kopiert, um eine unterbrechungsfreie Konnektivität sicherzustellen.

  • DNS-Switch: Nach der Datenmigration wird ein DNS-Switch ausgeführt, sodass die vorhandene Single Server-Verbindungszeichenfolge nahtlos mit dem neuen flexiblen Server verbunden werden kann. Beide Verbindungszeichenfolgenformate – Single und Flexibler Server – sowie die Benutzernamenformate (username@server_name und username) werden auf dem migrierten flexiblen Server unterstützt.

  • Sichtbarkeit des flexiblen Servers: Nach erfolgreicher Datenmigration und Erstellung des DNS-Switch wird der neue flexible Server unter Ihrem Abonnement angezeigt und kann über das Azure-Portal oder die CLI verwaltet werden.

  • Aktualisierte Single Server-Verbindungszeichenfolgen: Aktualisierte Verbindungszeichenfolgen für den älteren Single Server werden über Dienststatusbenachrichtigungen im Azure-Portal gesendet. Sie sind auch auf der Seite "Single Server-Portal" unter "Einstellungen –> Verbindungszeichenfolgen" verfügbar.

  • Löschen eines einzelnen Servers – Der Einzelne Server wird sieben Tage nach der Migration aufbewahrt, bevor er gelöscht wird.

Wie wird der flexible Zielserver für Postgresql bereitgestellt?

Die Computeebene und die SKU für den flexiblen Zielserver werden basierend auf der Preisebene und vCores des Einzelnen Servers bereitgestellt.

Single Server: Tarif Single Server: Virtuelle Kerne Flexibler Server – Ebene Flexibler Server – SKU-Name
Basic 1 Burstfähig B1ms
Basic 2 Burstfähig B2s
Universell 2 GeneralPurpose Standard_D2s_v3
Universell 4 GeneralPurpose Standard_D4s_v3
Universell 8 GeneralPurpose Standard_D8s_v3
Universell 16 GeneralPurpose Standard_D16s_v3
Universell 32 GeneralPurpose Standard_D32s_v3
Universell 64 GeneralPurpose Standard_D64s_v3
Arbeitsspeicheroptimiert 2 MemoryOptimized Standard_E2s_v3
Arbeitsspeicheroptimiert 4 MemoryOptimized Standard_E4s_v3
Arbeitsspeicheroptimiert 8 MemoryOptimized Standard_E8s_v3
Arbeitsspeicheroptimiert 16 MemoryOptimized Standard_E16s_v3
Arbeitsspeicheroptimiert 32 MemoryOptimized Standard_E32s_v3
  • Die Postgresql-Version, Region, Verbindungszeichenfolge, Abonnement und Ressourcengruppe für den flexiblen Zielserver bleiben mit den Einstellungen des Quell-Single Servers identisch.
  • Bei Single Server mit weniger als 20 GiB-Speicher wird die Speichergröße auf 32 GiB festgelegt, da dies das Mindestspeicherlimit für Azure Database for postgreSQL – Flexible Server ist.
  • Für Single Server mit einer höheren Speicheranforderung wird ausreichender Speicher in Höhe von 1,25 Mal oder 25 % mehr Speicherplatz zugewiesen, als auf dem Single Server verwendet wird. Während der anfänglichen Basiskopie von Daten werden mehrere Einfügeanweisungen für das Ziel ausgeführt, die WALs (Write Ahead Logs) generieren. Bis diese WALs archiviert sind, verbrauchen die Protokolle Speicherplatz auf dem Ziel und damit die Sicherheitsmarge.
  • Beide Benutzernamenformate – „username@server_name“ (Einzelserver) und „username“ (flexibler Server) – werden auf dem migrierten flexiblen Server unterstützt.
  • Beide Verbindungszeichenfolgenformate – Einzelserver und flexibler Server – werden auf dem migrierten flexiblen Server unterstützt.

Automigration in PostgreSQL-Hauptversionen

Diese Migration kann das Verschieben von Daten von PostgreSQL Single Server (Versionen 9.5, 9.6 oder 10) nach PostgreSQL 11 auf flexiblem Server umfassen. Die PostgreSQL-Community hat diese früheren Versionen eingestellt. Um Sicherheit, Stabilität und Leistung sicherzustellen, empfiehlt es sich, unterstützte Communityversionen zu übernehmen.

Berücksichtigen Sie bei der Migration über PostgreSQL-Hauptversionen die folgenden wichtigen Faktoren, um einen erfolgreichen und reibungslosen Übergang sicherzustellen:

  • Eingestellte Features – Features, die in älteren Versionen eingestellt wurden, sind in PostgreSQL 11 möglicherweise nicht mehr verfügbar. Es ist wichtig, die Versionshinweise für alle wichtigen Änderungen oder veralteten Features zu überprüfen, die sich auf Ihre Anwendung auswirken könnten.

  • Anwendungstests – Führen Sie gründliche Tests Ihrer Anwendung auf PostgreSQL 11 durch. Achten Sie auf potenzielle Probleme mit SQL-Abfragen, Funktionen oder Tools von Drittanbietern, da sich diese aufgrund von Änderungen in der neueren Version möglicherweise anders verhalten oder fehlschlagen.

  • Konfigurationsänderungen – Hauptversionsupgrades enthalten häufig Änderungen an Serverparametern, entweder durch Hinzufügen neuer Parameter oder durch Ändern der Standardwerte vorhandener Parameter. Diese Änderungen können sich auf Sortierung, Abfrageausführung und Datenspeicher auswirken. Um die Kompatibilität sicherzustellen, testen Sie Ihre Anwendung anhand dieser aktualisierten Einstellungen, und beheben Sie alle auftretenden Probleme. Wenn Probleme auftreten, verwenden Sie das im Abschnitt Schritte nach der Migration bereitgestellte Skript, um die vorhandenen Serverparameter aus Ihrer Einzelserverinstanz auf den automatisch migrierten flexiblen Server zu kopieren.

Schritte nach der Migration

Hier sind die Informationen, die Sie benötigen, um die Schritte nach der Automigration zu berücksichtigen.

  • Wenn die Automigration die Migration über PostgreSQL-Hauptversionen umfasst, testen Sie Ihre Anwendung gründlich, um die Auswirkungen von aktuellen Änderungen und Parameteranpassungen zu identifizieren. Nehmen Sie die erforderlichen Änderungen vor, um Kompatibilität und optimale Leistung sicherzustellen.

  • Alle Terraform-/CLI-Skripts, die Sie zum Verwalten Ihrer Einzelserver-Instanz hosten, sollten mit Verweisen zum flexiblen Server aktualisiert werden.

  • Die Serverparameter in flexiblem Server sind auf die Communitystandards abgestimmt. Wenn Sie die gleichen Serverparameterwerte wie Ihr Einzelner Server beibehalten möchten, können Sie sich über PowerShell anmelden und das Skript hier ausführen, um die Parameterwerte zu kopieren.

  • Zugriffssteuerungseinstellungen (IAM) für Ihren flexiblen Server werden von den Abonnementeinstellungen geerbt. Wenn Sie rollenspezifische Rollenzuweisungen für den einzelnen Server bereitgestellt haben, müssen Sie diese Rollenzuweisungen auf Ihrem flexiblen Server erstellen.

  • Kopieren Sie Einstellungen der Überwachungsseite (Warnungen, Metriken und Diagnoseeinstellungen) auf den flexiblen Server.

  • Um Erkenntnisse zur Abfrageleistung zu aktivieren, müssen Sie den Abfragespeicher auf dem flexiblen Server aktivieren, der standardmäßig nicht aktiviert ist.

  • Wenn hohe Verfügbarkeit erforderlich ist, können Sie sie ohne Ausfallzeiten aktivieren.

  • Überprüfen Sie, ob Ihre flexible Server-SKU mit der in der Service Health-Automigrationsbenachrichtigung erwähnten übereinstimmt. Wenn sie anders ist, setzen Sie sie auf die in der Benachrichtigung angegebene SKU zurück. Dies ist entscheidend, um eine genaue Abrechnung sicherzustellen.

  • Die vorhandenen Verbindungsdaten Ihres Single Servers verweisen jetzt auf den flexiblen Server. Für den Zugriff auf Den einzelnen Server wird eine neue Gruppe von Verbindungszeichenfolgen generiert. Sie können sie aus der Service Health-Benachrichtigung abrufen, die für die Automigration Ihres Einzelservers gesendet wird.

Behandeln von Regeln für virtuelle Netzwerke auf flexiblem Server

In Azure Database for PostgreSQL Single Server ist eine Virtuelle Netzwerkregel (virtuelles Netzwerk) ein Subnetz, das in der Zugriffssteuerungsliste (Access Control List, ACL) des Servers aufgeführt ist. Diese Regel ermöglicht es dem einzelnen Server, Kommunikation von Knoten innerhalb dieses bestimmten Subnetzes zu akzeptieren. Für flexible Server werden virtuelle Netzwerkregeln nicht unterstützt. Stattdessen ermöglicht ein flexibler Server die Erstellung von privaten Endpunkten, damit der Server innerhalb Ihres virtuellen Netzwerks funktioniert. Ein privater Endpunkt weist dem flexiblen Server eine private IP-Adresse zu, und der gesamte Datenverkehr zwischen Ihrem virtuellen Netzwerk und dem Server wird sicher über das Azure-Backbonenetzwerk geleitet, wodurch das öffentliche Internet umgangen wird.

Nach der Migration müssen Sie ihrem flexiblen Server einen privaten Endpunkt für alle Subnetze hinzufügen, die zuvor von virtuellen Netzwerkregeln auf Ihrem Einzelnen Server abgedeckt wurden. Hierfür können Sie entweder das Azure-Portal oder die Azure CLI verwenden. Nach Abschluss dieses Schritts bleibt Ihre Netzwerkkonnektivität auf dem flexiblen Server erhalten, nachdem die Migration des einzelnen Servers durchgeführt wurde.

Sicherung mit Langzeitaufbewahrung

Die automatische Migration einzelner Server konfiguriert nach der Migration zu flexiblem Server keine langfristige Aufbewahrung (LTR)-Sicherung. Sie können für „Azure Database for PostgreSQL – Flexibler Server“ mithilfe von Azure Backup eine Sicherung mit Langzeitaufbewahrung erstellen.

So überprüfen Sie, ob der Single Server für die Automigration geplant ist

Führen Sie die folgenden Schritte aus, um herauszufinden, ob der Single Server für die Automigration ausgewählt ist:

  • Dienststatusbenachrichtigungen: Wechseln Sie im Azure-Portal zu Dienststatus > Geplante Wartung. Suchen Sie nach Ereignissen mit der Bezeichnung „Benachrichtigung für geplante automatische Migration zu Azure-Datenbank for PostgreSQL – Single Server”. Die Benachrichtigungen werden 30, 14 und 7 Tage vor dem Migrationsdatum und wieder während der Migrationsphasen gesendet: in Bearbeitung, abgeschlossen und sechs Tage vor der Außerbetriebnahme des Single Servers.

    Hinweis

    Diese Benachrichtigungen landen standardmäßig nicht in Ihrem Posteingang. Um sie per E-Mail oder SMS zu empfangen, müssen Sie Dienststatuswarnungen einrichten. Weitere Informationen finden Sie unter Einrichten von Dienststatuswarnungen.

  • Single Server-Übersichtsseite: Navigieren Sie im Azure-Portal zu Ihrer Single Server-Instanz, und überprüfen Sie die Seite „Übersicht”. Wenn die Automigration geplant ist, finden Sie hier Details.

    Hinweis

    Der Migrationszeitplan wird sieben Tage vor dem geplanten Migrationsfenster gesperrt, in dieser Zeit können Sie den Zeitplan nicht ändern oder verschieben.

  • Azure CXP-E-Mail-Benachrichtigungen: Azure Customer Experience(CXP) sendet außerdem direkte E-Mails an klassische Rollen und RBAC-Rollen, die dem Abonnement zugeordnet sind, das den Single Server enthält, und liefert Informationen zu anstehenden Automigrationen.

Häufig gestellte Fragen (FAQs)

Q. Warum wird bei mir eine automatische Migration durchgeführt?

A. Ihre Instanz von Azure Database for PostgreSQL – Single Server ist zur automatischen Migration zu unserem Vorzeigeangebot Azure Database for PostgreSQL – Flexibler Server berechtigt. Diese Automigration beseitigt den Mehraufwand durch eine manuelle Migration des Servers. Sie können die Vorteile von „Flexibler Server“ nutzen, einschließlich besserer Preise und Leistung, einer präzisen Steuerung über die Datenbankkonfiguration und benutzerdefinierter Wartungsfenster.

Q. Wie läuft die automatische Migration ab? Was wird alles migriert?

A. Der flexible Server wird so bereitgestellt, dass er die gleiche Anzahl VCores und denselben Speicher wie Ihr Single Server aufweist. Als Nächstes wird der Quell-Single Server in einen schreibgeschützten Zustand versetzt, Schema und Daten werden auf den flexiblen Server kopiert. Die DNS-Umstellung wird ausgeführt, um alle vorhandenen Verbindungen an das Ziel weiterzuleiten, und die Zielinstanz des flexiblen Servers wird online geschaltet. Die automatische Migration migriert die Datenbanken (einschließlich Schema, Daten, Benutzer/Rollen und Berechtigungen). Die Migration ist offline, bei der Sie Ausfallzeiten von ein paar Minuten bis zu einigen Stunden je nach Größe Ihrer Arbeitslast erleben. Informationen zu Benchmarks zur Migrationsgeschwindigkeit finden Sie unter Azure PostgreSQL – Benchmarking der Migrationsgeschwindigkeit.

Q. Wie kann ich Automigrationswarnungen einrichten oder anzeigen?

A. Im Folgenden können Sie Warnungen einrichten:

  • Konfigurieren Sie Dienstintegritätswarnungen, um einen Zeitplan für die direkte Migration und Statusbenachrichtigungen per E-Mail/SMS zu empfangen, indem Sie die folgenden Schritte hier ausführen.
  • Überprüfen Sie die Benachrichtigung über die direkte Migration im Azure-Portal, indem Sie die folgenden Schritte hier ausführen.

Q. Wie kann ich eine geplante Automatische Migration meines Single Server deaktivieren?

A. Wenn Sie die Automigration deaktivieren möchten, können Sie hierfür ein Supportticket auslösen.

Q. Welche Schritte nach der Migration sollten ich ausführen, wenn mein Einzelner Server Regeln für virtuelle Netzwerke verwendet?

A. Virtuelle Netzwerkregeln werden auf flexiblem Server nicht unterstützt. Lesen Sie diesen Abschnitt

Q. Muss ich Sicherungen mit Langzeitaufbewahrung für „Flexibler Server“ neu konfigurieren?​

A. Ja. Lesen Sie diesen Abschnitt

Q. Welcher Benutzername und welche Verbindungszeichenfolge unterstützt der migrierte flexible Server? ​​

A. Beide Benutzernamensformate – „username@server_name“ (Einzelserver) und „username“ (flexibler Server) – werden auf dem migrierten flexiblen Server unterstützt. Daher müssen Sie sie nicht aktualisieren, um die Anwendungskontinuität nach der Migration aufrechtzuerhalten. Überdies werden beide Verbindungszeichenfolgenformate (Format für Einzelserver und flexible Server) auch auf dem migrierten flexiblen Server unterstützt.

Q. Ich sehe einen Preisunterschied bei einem möglichen Wechsel von einem postgresql Basic Single Server zu einem postgresql Flexible Server.

A. Bei einigen wenigen Servern kommt es nach der Migration ggf. zu einer geringfügigen Preisanpassung, da sich das Mindestspeicherlimit der beiden Angebote unterscheidet (5 GiB bei Einzelserver und 32 GiB bei flexiblem Server). Die Speicherkosten für Flexible Server sind geringfügig höher als Single Server. Jede Preiserhöhung wird durch einen besseren Durchsatz und eine bessere Leistung im Vergleich zu Single Server versetzt. Weitere Informationen zu flexiblen Serverpreisen finden Sie in diesem Dokument.

Q. Was passiert, wenn ich bis zum 28. März 2025 nicht migriere oder mein Server nicht automatisch migriert wird?

A. Nach der Ablauffrist am 28. März 2025 werden alle vorhandenen Einzelserver, die nicht migriert wurden, zwangsweise auf den Flexible Server migriert. Server mit Zusatzfunktionen wie privatem Endpunkt und Lesereplikaten erfordern nach der Migration weitere Aktionen des Benutzers, um einen reibungslosen Betrieb sicherzustellen. Die Frist für die Einstellung wird nicht verlängert.

Q. Gibt es Einschränkungen beim Ausführen eines Major Version Upgrade (MVU) auf einem automatisch migrierten Server?

A. Ja, es gibt eine wichtige Einschränkung zu beachten. Während Hauptversionsupgrades auf jede auf flexiblem Server unterstützte PostgreSQL-Version vollständig für automatisch migrierte Server unterstützt werden, ändert sich das Verbindungszeichenfolgenformat geringfügig nach einem erfolgreichen Upgrade. Insbesondere wird das Benutzernamenformat "username@servername" nach dem Upgrade nicht mehr unterstützt. Wenn Ihre Anwendung oder Skripts derzeit dieses Format in der Verbindungszeichenfolge verwenden, müssen Sie sie aktualisieren, um das Standardformat zu verwenden: nur "Benutzername". Überprüfen und aktualisieren Sie alle betroffenen Verbindungszeichenfolgen nach dem Upgrade, um Verbindungsprobleme zu vermeiden.

Q. Unterstützt automigration die Migration von authentifizierten Microsoft Entra-Rollen?

A. Ja, die automatische Migration unterstützt die Übertragung authentifizierter Microsoft Entra-Rollen. Nachdem Ihr Server automatisch zu einem flexiblen Server migriert wurde, müssen Sie das Format entraid@servername als Benutzername verwenden, wenn Sie sich mit Ihrer Entra-ID anmelden. Das einfachere Format entraid wird derzeit nicht unterstützt.

Beispiel:

Wenn Ihre Entra-ID abc@xyz.com ist und Ihr Servername server1 ist, lautet der Benutzername für die Anmeldung beim automatisch migrierten Flexiblen Server abc@xyz.com@server1. Der Versuch, sich nur mit abc@xyz.com als Benutzernamen anzumelden, wird nicht funktionieren.

Dies ist ein bekanntes Problem, und Microsoft arbeitet aktiv daran, es in zukünftigen Updates zu beheben.

Verwandte Inhalte