Tutorial: Onlinemigration von Amazon RDS for PostgreSQL zu Azure Database for PostgreSQL mit dem Migrationsdienst (Vorschau)
In diesem Artikel wird erläutert, wie Sie eine PostgreSQL-Datenbank online von Amazon RDS for PostgreSQL zu Azure Database for PostgreSQL migrieren.
Der Migrationsdienst in Azure Database for PostgreSQL ist ein vollständig verwalteter Dienst, der in das Azure-Portal und in Azure CLI integriert ist. Er vereinfacht die Migration zu einem Azure Database for PostgreSQL-Server.
- Voraussetzungen
- Durchführen der Migration
- Überwachen der Migration
- Übernahme
- Überprüfen der abgeschlossenen Migration
Voraussetzungen
Für die Migration müssen folgende Voraussetzungen erfüllt sein:
Für die Migration mit dem Migrationsdienst von Azure Database for PostgreSQL müssen die folgenden, speziell für Onlinemigrationsszenarien geltenden Voraussetzungen erfüllt sein:
- Überprüfen der Quellversion
- Installieren von „test_decoding“ (Quellensetup)
- Konfigurieren des Zielsetups
- Aktivieren von CDC als Quelle
- Konfigurieren des Netzwerksetups
- Aktivieren von Erweiterungen
- Überprüfen der Serverparameter
- Überprüfen von Benutzern und Rollen
Überprüfen der Quellversion
Die Version des PostgreSQL-Quellservers muss mindestens 9.5 sein.
Sollte die PostgreSQL-Quellversion niedriger als 9.5 sein, führen Sie ein Upgrade auf 9.5 oder auf eine höhere Version durch, bevor Sie mit der Migration beginnen.
Installieren von „test_decoding“ (Quellensetup)
- test_decoding empfängt WAL über den logischen Decodierungsmechanismus und decodiert die Daten in Textdarstellungen der ausgeführten Vorgänge.
- In Amazon RDS für PostgreSQL ist das Plug-In „test_decoding“ bereits vorinstalliert und für die logische Replikation bereit. Dadurch können Sie mühelos logische Replikationsslots einrichten und WAL-Änderungen streamen, was Anwendungsfälle wie Change Data Capture (CDC) oder die Replikation auf externen Systemen erleichtert.
- Weitere Informationen zum Plug-In „test_decoding“ finden Sie in der PostgreSQL-Dokumentation.
Konfigurieren des Zielsetups
- Vor der Migration muss Azure Database for PostgreSQL – Flexibler Server erstellt werden.
- Die für Azure Database for PostgreSQL – Flexibler Server bereitgestellte SKU muss mit der Quelle übereinstimmen.
- Informationen zum Erstellen einer neuen Instanz von Azure Database for PostgreSQL finden Sie unter Schnellstart: Erstellen einer Instanz von Azure Database for PostgreSQL – Flexibler Server im Azure-Portal.
Aktivieren von CDC als Quelle
- Das Plug-In
test_decoding
für die logische Decodierung erfasst die geänderten Datensätze aus der Quelle. - Führen Sie den folgenden Befehl aus, um dem Migrationsbenutzer den Zugriff auf Replikationsberechtigungen zu ermöglichen:
GRANT rds_replication TO <<username>>;
Ändern Sie in der Quelle die folgenden Parameter, indem Sie eine neue Parametergruppe erstellen:
- Legen Sie
rds.logical_replication = 1
fest. - Legen Sie
max_replication_slots
auf einen Wert größer als eins fest. Der Wert muss größer sein als die Anzahl von Datenbanken, die für die Migration ausgewählt wurden. - Legen Sie
max_wal_senders
auf einen Wert größer als eins fest. Der Wert muss mindestens dem Wert vonmax_replication_slots
plus der Anzahl von Absendern entsprechen, die bereits in Ihrer Instanz verwendet werden. - Der Parameter
wal_sender_timeout
beendet Replikationsverbindungen, die länger als die angegebene Anzahl von Millisekunden inaktiv sind. Der Standardwert für eine Instanz von AWS RDS für PostgreSQL lautet30000 milliseconds (30 seconds)
. Wenn Sie den Wert auf null festlegen, wird der Timeoutmechanismus deaktiviert. Dies ist eine gültige Einstellung für die Migration.
- Legen Sie
Um zu verhindern, dass die Onlinemigration nicht mehr genügend Speicherplatz zum Speichern der Protokolle hat, stellen Sie auf dem flexiblen Zielserver sicher, dass Sie über ausreichend Tabellenbereich-Speicherplatz auf einem bereitgestellten verwalteten Datenträger verfügen. Deaktivieren Sie dazu den Serverparameter
azure.enable_temp_tablespaces_on_local_ssd
für die Dauer der Migration, und setzen Sie ihn nach der Migration wieder in den ursprünglichen Zustand zurück.
Konfigurieren des Netzwerksetups
Das Netzwerksetup ist entscheidend, damit der Migrationsdienst ordnungsgemäß funktioniert. Stellen Sie sicher, dass der PostgreSQL-Quellserver mit dem Azure Database for PostgreSQL-Zielserver kommunizieren kann. Die folgenden Netzwerkkonfigurationen sind für eine erfolgreiche Migration unerlässlich.
Informationen zum Netzwerksetup finden Sie im Netzwerkhandbuch für den Migrationsdienst.
Aktivieren von Erweiterungen
Um eine erfolgreiche Migration mit dem Migrationsdienst in Azure Database for PostgreSQL sicherzustellen, müssen Sie möglicherweise Erweiterungen für Ihre PostgreSQL-Quellinstanz überprüfen. Erweiterungen bieten Funktionalität und Features, die für Ihre Anwendung möglicherweise erforderlich sind. Überprüfen Sie die Erweiterungen unbedingt in der PostgreSQL-Quellinstanz, bevor Sie den Migrationsprozess initiieren.
Aktivieren Sie in der Zielinstanz von Azure Database for PostgreSQL – Flexibler Server unterstützte Erweiterungen, die in der PostgreSQL-Quellinstanz identifiziert werden.
Weitere Informationen finden Sie unter Erweiterungen in Azure Database for PostgreSQL.
Hinweis
Bei Änderungen am shared_preload_libraries
-Parameter ist ein Neustart erforderlich.
Überprüfen der Serverparameter
Diese Parameter werden nicht automatisch in die Zielumgebung migriert und müssen manuell konfiguriert werden.
Stimmen Sie Serverparameterwerte aus der PostgreSQL-Quelldatenbank mit der Azure Database for PostgreSQL-Instanz ab, indem Sie im Azure-Portal auf den Abschnitt „Serverparameter“ zugreifen und die Werte entsprechend manuell aktualisieren.
Speichern Sie die Parameteränderungen, und starten Sie die Azure Database for PostgreSQL-Instanz neu, um die neue Konfiguration bei Bedarf anzuwenden.
Überprüfen der Benutzer und Rollen
Bei der Migration zu Azure Database for PostgreSQL ist es wichtig, die Migration von Benutzer*innen und Rollen separat zu behandeln, da sie manuelle Eingriffe erfordern:
Manuelle Migration von Benutzer*innen und Rollen: Benutzer*innen und ihre zugehörigen Rollen müssen manuell zur Azure Database for PostgreSQL-Instanz migriert werden. Um diesen Prozess zu unterstützen, können Sie das
pg_dumpall
-Hilfsprogramm mit der--globals-only
-Kennzeichnung verwenden, um globale Objekte wie Rollen und Benutzerkonten zu exportieren. Führen Sie den folgenden Befehl aus, indem Sie<<username>>
mit dem tatsächlichen Benutzernamen und<<filename>>
mit dem von Ihnen gewünschten Ausgabedateinamen ersetzen:pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
Einschränkung für Superuserrollen: Azure Database for PostgreSQL unterstützt keine Superuserrollen. Daher müssen für Benutzer*innen mit Berechtigungen als Superuser diese Berechtigungen vor der Migration entfernt werden. Stellen Sie sicher, dass Sie die Berechtigungen und Rollen entsprechend anpassen.
Indem Sie diese Schritte ausführen, können Sie sicherstellen, dass Benutzerkonten und Rollen ordnungsgemäß zur Azure Database for PostgreSQL-Instanz migriert werden, ohne dass Probleme im Zusammenhang mit Einschränkungen für Superuser auftreten.
Deaktivieren der Hochverfügbarkeit (Zuverlässigkeit) und Lesereplikaten im Ziel
Das Deaktivieren der Hochverfügbarkeit (Zuverlässigkeit) und der Lesereplikate in der Zielumgebung ist unerlässlich. Diese Features sollten erst aktiviert werden, nachdem die Migration abgeschlossen wurde.
Wenn Sie diese Richtlinien befolgen, können Sie einen reibungslosen Migrationsprozess ohne die zusätzlichen Variablen sicherstellen, die durch Hochverfügbarkeit und Lesereplikate eingeführt wurden. Sobald die Migration abgeschlossen und die Datenbank stabil ist, können Sie diese Features aktivieren, um die Verfügbarkeit und Skalierbarkeit Ihrer Datenbankumgebung in Azure zu verbessern.
Durchführen der Migration
Für die Migration kann das Azure-Portal oder die Azure-Befehlszeilenschnittstelle (Command Line Interface, CLI) verwendet werden.
Das Azure-Portal bietet eine einfache und intuitive assistentenbasierte Oberfläche, die Sie durch die Migration führt. Mithilfe der in diesem Tutorial beschriebenen Schritte können Sie Ihre Datenbank nahtlos in Azure Database for PostgreSQL – Flexibler Server übertragen und von den leistungsstarken Features und der Skalierbarkeit von Azure profitieren.
Wenn Sie die Migration über das Azure-Portal durchführen möchten, müssen Sie zuerst die Migrationsaufgabe konfigurieren. Anschließend können Sie eine Verbindung mit der Quelle und dem Ziel herstellen und dann die Migration durchführen.
Konfigurieren der Migrationsaufgabe
Der Migrationsdienst verfügt über eine einfache, Assistenten-basierte Erfahrung im Azure-Portal. Gehen Sie wie folgt vor:
Browsen Sie zum Portal. Geben Sie Ihre Anmeldeinformationen ein. Die Standardansicht ist Ihr Dienstdashboard.
Navigieren Sie zu Ihrer Zielinstanz von Azure Database for PostgreSQL – Flexible Server.
Scrollen Sie auf der Registerkarte „Übersicht“ des flexiblen Servers im linken Menü nach unten zu „Migration“, und wählen Sie diese Option aus.
Wählen Sie die Schaltfläche Erstellen aus, um von Amazon RDS for PostgreSQL zu Azure Database for PostgreSQL – Flexibler Server zu migrieren. Wenn Sie den Migrationsdienst zum ersten Mal verwenden, erscheint ein leeres Raster mit einer Eingabeaufforderung, um mit Ihrer ersten Migration zu beginnen.
Wenn Sie bereits Migrationen zu Ihrem Ziel vom Typ „Azure Database for PostgreSQL“ erstellt haben, enthält das Raster Informationen zu Migrationsversuchen.
Wählen Sie die Schaltfläche Erstellen. Anschließend durchlaufen Sie mehrere assistentenbasierte Registerkarten, um eine Migration von der PostgreSQL-Quellinstanz zu diesem Ziel vom Typ „Azure Database for PostgreSQL“ zu erstellen.
Setup
Die erste Registerkarte ist die Registerkarte Setup. Hier müssen Migrationsdetails wie Migrationsname und Quelltyp angegeben werden, um die Migration zu initiieren.
Beim Migrationsnamen handelt es sich um den eindeutigen Bezeichner für eine Migration zu diesem Flexible Server-Ziel. In dieses Feld dürfen nur alphanumerische Zeichen eingegeben werden, und mit Ausnahme von Bindestrichen (-) dürfen keine Sonderzeichen verwendet werden. Der Name darf nicht mit einem Bindestrich beginnen und muss für den Zielserver eindeutig sein. Zwei Migrationen zum selben Flexible Server-Ziel dürfen nicht denselben Namen aufweisen.
Typ des Quellservers – Je nach PostgreSQL-Quelle können Sie den entsprechenden Quelltyp auswählen, z. B. einen cloudbasierten PostgreSQL-Dienst, ein lokales Setup oder eine virtuelle Maschine.
Migrationsoption – Ermöglicht es Ihnen, Validierungen durchzuführen, bevor Sie eine Migration auslösen. Folgenden Optionen stehen zur Auswahl:
- Überprüfen: Mit dieser Option werden die Server- und Datenbankbereitschaft für die Migration zum Ziel überprüft.
- Migrieren: Überspringt Überprüfungen und startet die Migration.
- Überprüfen und migrieren: Führt eine Überprüfung durch, bevor eine Migration ausgelöst wird. Die Migration wird nur ausgelöst, wenn keine Überprüfungsfehler vorhanden sind.
Das Auswählen der Option Überprüfen oder Überprüfen und migrieren ist eine bewährte Methode, wenn Überprüfungen vor der Migration durchgeführt werden. Weitere Informationen zur Überprüfung vor der Migration finden Sie in dieser Dokumentation.
- Im Migrationsmodus können Sie den Modus für die Migration auswählen. Offline ist die Standardoption.
Wählen Sie die Schaltfläche Weiter: Mit Quelle verbinden aus.
Auswählen des Runtimeservers
Der Runtimeserver für die Migration ist ein spezielles Feature innerhalb des Migrationsdiensts, das während der Migration als Zwischenserver fungiert. Es handelt sich um eine separate Instanz von Azure Database for PostgreSQL – Flexibler Server, die nicht als Zielserver fungiert, sondern verwendet wird, um die Migration von Datenbanken aus einer Quellumgebung zu ermöglichen, auf die nur über ein privates Netzwerk zugegriffen werden kann.
Weitere Informationen zum Runtimeserver finden Sie im Artikel zum Runtimeserver für die Migration.
Herstellen einer Verbindung mit der Quelle
Auf der Registerkarte Mit Quelle verbinden werden Sie aufgefordert, Details zu der Quelle anzugeben, die auf der Registerkarte Setup ausgewählt wurde. Hierbei handelt es sich um die Quelle der Datenbanken.
- Servername – Geben Sie den Hostnamen oder die IP-Adresse der PostgreSQL-Quellinstanz an
- Port – Portnummer des Quellservers
- Anmeldename des Serveradministrators – Benutzername des PostgreSQL-Quellservers
- Kennwort: Das Kennwort des PostgreSQL-Quellservers.
- SSL-Modus: Die unterstützten Werte sind „prefer“ (bevorzugen) und „require“ (erforderlich). Wenn SSL auf dem PostgreSQL-Quellserver DEAKTIVIERT ist, verwenden Sie „SSLMODE=prefer“. Wenn SSL auf dem Quellserver AKTIVIERT ist, verwenden Sie „SSLMODE=require“. SSL-Werte können in der Datei „postgresql.conf“ bestimmt werden.
- Verbindung testen: Testet die Verbindung zwischen Ziel und Quelle. Sobald die Verbindung erfolgreich hergestellt ist, können Benutzer*innen mit dem nächsten Schritt fortfahren. Andernfalls müssen die Netzwerkprobleme zwischen dem Ziel und der Quelle identifiziert und der Benutzername bzw. das Kennwort für die Quelle überprüft werden. Das Herstellen einer Testverbindung dauert einige Minuten.
Wählen Sie nach dem erfolgreichen Testen der Verbindung die Schaltfläche Weiter: Migrationsziel auswählen aus.
Auswählen des Migrationsziels
Auf der Registerkarte Migrationsziel auswählen werden Metadaten für das Ziel vom Typ „Flexibler Server“ angezeigt, z. B. Abonnementname, Ressourcengruppe, Servername, Standort und PostgreSQL-Version.
- Administratorbenutzername – Administratorbenutzername des PostgreSQL-Zielservers
- Kennwort – Kennwort des PostgreSQL-Zielservers
- FQDN/IP-Adresse (benutzerdefiniert): Die Angabe in diesem Feld ist optional und kann verwendet werden, wenn sich das Ziel hinter einem benutzerdefinierten DNS-Server befindet oder über benutzerdefinierte DNS-Namespaces verfügt, sodass nur über bestimmte FQDNs oder IP-Adressen darauf zugegriffen werden kann. Hierbei kann es sich beispielsweise um Einträge wie
flexibleserver.example.com
,198.1.0.2
oder um einen PostgreSQL-FQDN wieflexibleserver.postgres.database.azure.com
handeln, wenn der benutzerdefinierte DNS-Server die DNS-Zonepostgres.database.azure.com
enthält oder Abfragen für diese Zone an168.63.129.16
weiterleitet, wobei der FQDN in der öffentlichen oder privaten DNS-Zone von Azure aufgelöst wird. - Verbindung testen: Testet die Verbindung zwischen Ziel und Quelle. Sobald die Verbindung erfolgreich hergestellt ist, können Benutzer*innen mit dem nächsten Schritt fortfahren. Andernfalls müssen die Netzwerkprobleme zwischen dem Ziel und der Quelle identifiziert und der Benutzername bzw. das Kennwort für das Ziel überprüft werden. Die Herstellung einer Testverbindung zwischen Ziel und Quelle dauert ein paar Minuten.
Wählen Sie nach dem erfolgreichen Test der Verbindung die Option Weiter: Datenbank(en) für die Migration auswählen aus
Auswählen von Datenbanken für die Migration
Auf dieser Registerkarte befindet sich eine Liste der Benutzerdatenbanken innerhalb des Quellservers, der auf der Registerkarte „Setup“ ausgewählt wurde. Sie können bis zu acht Datenbanken im Rahmen eines einzelnen Migrationsversuchs auswählen und migrieren. Wenn mehr als acht Benutzerdatenbanken vorhanden sind, wird der Migrationsprozess zwischen den Quell- und Zielservern für den nächsten Satz von Datenbanken wiederholt.
Wählen Sie nach dem Auswählen der Datenbanken die Schaltfläche Weiter: Zusammenfassung aus.
Zusammenfassung
Auf der Registerkarte Zusammenfassung werden alle Quell- und Zieldetails für die Erstellung der Überprüfung oder Migration zusammengefasst. Überprüfen Sie die Details, und wählen Sie die Schaltfläche „Starten“ aus.
Überwachen der Migration
Einige Sekunden nach dem Auswählen der Schaltfläche „Starten“ wird eine Benachrichtigung mit dem Hinweis angezeigt, dass die Erstellung der Überprüfung oder Migration erfolgreich war. Anschließend werden Sie automatisch zur Seite Migration des flexiblen Servers umgeleitet, die nun einen neuen Eintrag für die kürzlich erstellte Überprüfung oder Migration enthält.
Das Raster mit den Migrationen umfasst folgende Spalten: Name, Status, Migrationsmodus, Migrationstyp, Quellserver, Quellservertyp, Datenbanken, Dauer und Startzeit. Die Einträge werden in absteigender Reihenfolge nach Startzeit angezeigt. Der neueste Eintrag befindet sich also am Anfang der Liste. Sie können die Schaltfläche zum Aktualisieren verwenden, um den Status der Überprüfung oder Migration zu aktualisieren. Wählen Sie den Migrationsnamen im Raster aus, um die zugehörigen Details anzuzeigen.
Nach dem Erstellen der Überprüfung oder Migration wird diese in den Zustand InProgress und in den Unterzustand PerformingPreRequisiteSteps versetzt. Der Workflow benötigt 2 bis 3 Minuten, um die Migrationsinfrastruktur und die Netzwerkverbindungen einzurichten.
Details zur Migration
Auf der Registerkarte „Setup“ haben wir die Migrationsoption Überprüfen und migrieren ausgewählt. In diesem Szenario werden Validierungen als erstes ausgeführt, bevor die Migration startet. Nach Abschluss des Unterzustands PerformingPreRequisiteSteps wechselt der Workflow in den Unterzustand Überprüfung wird ausgeführt.
- Wenn bei der Überprüfung Fehler auftreten, wechselt die Migration in den Zustand Fehler.
- Wenn die Überprüfung ohne Fehler abgeschlossen wird, beginnt die Migration, und der Zustand des Workflows ändert sich in den Unterzustand Daten werden migriert.
Die Ergebnisse der Überprüfung und Migration können auf Instanz- und Datenbankebene angezeigt werden.
Hier finden Sie einige mögliche Migrationszustände:
Migrationsstatus
State | Beschreibung |
---|---|
InProgress | Die Migrationsinfrastruktur wird gerade eingerichtet, oder die eigentliche Datenmigration wird gerade durchgeführt. |
Canceled | Die Migration wurde abgebrochen oder gelöscht. |
Fehlgeschlagen | Bei der Migration ist ein Fehler aufgetreten. |
Überprüfung fehlgeschlagen | Die Überprüfung war nicht erfolgreich. |
Erfolgreich | Die Migration wurde erfolgreich durchgeführt und ist beendet. |
WaitingForUserAction | Gilt nur für die Onlinemigration. Warten auf Benutzeraktion zum Ausführen des Cutover. |
Migrationsunterzustände
Unterzustand | Beschreibung |
---|---|
PerformingPreRequisiteSteps | Die Infrastruktur für die Datenmigration wird gerade eingerichtet. |
Überprüfung wird ausgeführt | Die Überprüfung wird ausgeführt. |
MigratingData | Die Datenmigration wird durchgeführt. |
CompletingMigration | Die Migration ist fast abgeschlossen. |
Abgeschlossen | Die Migration wurde abgeschlossen. |
Fehler | Die Migration ist fehlgeschlagen. |
Unterzustände der Überprüfung
Unterzustand | Beschreibung |
---|---|
Fehler | Fehler bei der Überprüfung. |
Erfolgreich | Die Überprüfung war erfolgreich. |
Warning | Die Überprüfung befindet sich im Zustand „Warnung“. |
Übernahme
Bei Migrieren und Überprüfen und migrieren ist noch ein weiterer Schritt erforderlich, um die Onlinemigration abzuschließen: Der Benutzer muss eine Cutover-Aktion ausführen. Nach Abschluss des Kopierens/Klonens der Basisdaten wird die Migration in den Zustand WaitingForUserAction
und den Unterstatus WaitingForCutoverTrigger
versetzt. In diesem Zustand kann der Benutzer den Cutover auslösen, indem er im Portal die Migration auswählt.
Vor dem Initiieren der Übernahme ist es wichtig, folgendes zu gewährleisten:
Schreibvorgänge in die Quelle werden beendet. Der Wert
Latency
ist 0 oder fast 0. DieLatency
-Information kann über den Bildschirm mit den Migrationsdetails ermittelt werden:Der Wert
latency
sinkt auf 0 oder auf einen Wert nahe 0.Der Wert
latency
gibt an, wann das Ziel zuletzt mit der Quelle synchronisiert wurde. An diesem Punkt kann das Schreiben in die Quelle beendet und der Cutover initiiert werden. Im Falle eines hohen Datenverkehrsaufkommens für die Quelle empfiehlt es sich, zuerst die Schreibvorgänge zu beenden, damit sichLatency
dem Wert 0 annähern kann. Anschließend wird dann ein Cutover initiiert. Der Übernahmevorgang wendet alle ausstehenden Änderungen von der Quelle auf das Ziel an und schließt die Migration ab. Wenn Sie einen Cutover auslösen, wird die Replikation bis zu diesem Zeitpunkt angehalten, auch wennLatency,
nicht null ist. Alle Quelldaten befinden sich in der Quelle, bis der Cutoverpunkt auf das Ziel angewendet wird. Wenn die Wartezeit am Cutoverpunkt also beispielsweise 15 Minuten betrug, werden alle geänderten Daten der letzten 15 Minuten auf das Ziel angewendet. Die Zeit hängt vom Rückstand der Änderungen in den letzten 15 Minuten ab. Daher empfiehlt es sich, mit dem Auslösen des Cutovers zu warten, bis die Wartezeit null oder nahezu null ist.Der Zustand der Migration ändert sich in
Succeeded
, wenn der UnterzustandMigrating Data
oder der Cutover (bei der Onlinemigration) erfolgreich abgeschlossen wurde. Wenn im UnterzustandMigrating Data
ein Problem auftritt, geht die Migration in den ZustandFailed
über.
Überprüfen der abgeschlossenen Migration
Nach Fertigstellung der Datenbanken müssen Sie die Daten zwischen Quelle und Ziel manuell überprüfen und sich vergewissern, dass alle Objekte in der Zieldatenbank erfolgreich erstellt wurden.
Nach der Migration können Sie die folgenden Aufgaben ausführen:
- Überprüfen Sie die Daten auf Ihrem flexiblen Server, und stellen Sie sicher, dass es sich um eine genaue Kopie der Quellinstanz handelt.
- Nach der Überprüfung aktivieren Sie die Option für Hochverfügbarkeit auf Ihrem flexiblen Server nach Bedarf.
- Ändern Sie die SKU des flexiblen Servers entsprechend den Anwendungsanforderungen. Diese Änderung erfordert einen Neustart des Datenbankservers.
- Wenn Sie Serverparameter gegenüber ihren Standardwerten in der Quellinstanz ändern, kopieren Sie diese Serverparameterwerte auf den flexiblen Server.
- Kopieren Sie weitere Servereinstellungen wie Tags, Warnungen und Firewallregeln (falls zutreffend) aus der Quellinstanz auf den flexiblen Server.
- Nehmen Sie Änderungen an Ihrer Anwendung vor, um die Verbindungszeichenfolgen auf einen flexiblen Server zu verweisen.
- Überwachen Sie die Datenbankleistung genau, um festzustellen, ob Leistungsoptimierung erforderlich ist.