Anwendungsmigration
Nachdem Sie Ihre Datenbank von der lokalen Datenbank zu Azure migriert haben, müssen Sie Ihre vorhandenen Anwendungen aktualisieren, damit sie an seinem neuen Speicherort auf die PostgreSQL zugreifen können.
Ihr ursprünglicher lokaler Server und Ihre ursprüngliche lokale Datenbank enthalten Rollen. Diese Rollen definieren Berechtigungen, die Benutzern zugeordnet sind, die Vorgänge, die von diesen Benutzern ausgeführt werden können, sowie die Objekte, für die diese Benutzer die genannten Vorgänge ausführen können. Azure Database for PostgreSQL verwendet dieselben Authentifizierungs- und Autorisierungsmechanismen wie PostgreSQL, die lokal ausgeführt werden.
In dieser Lektion erfahren Sie, welche Updates Sie an Ihren Anwendungen vornehmen müssen, um eine Verbindung mit Ihrer neu migrierten Azure-Datenbank für PostgreSQL herzustellen.
Manuelles Erstellen der Benutzerrollen
Wenn Sie eine PostgreSQL-Datenbank mithilfe des Azure Database Migration Service in Azure Database for PostgreSQL übertragen, werden die Rollen und Rollenzuweisungen nicht kopiert. Sie müssen die erforderlichen Rollen und Benutzerkonten für den Administrator und die Benutzer der Tabellen in der Zieldatenbank manuell neu erstellen. Sie verwenden die psql- oder pgAdmin-Hilfsprogramme, um diese Aufgaben auszuführen. Führen Sie den Befehl CREATE ROLE aus. Sie verwenden den GRANT Befehl, um einer Rolle die erforderlichen Berechtigungen zuzuweisen. Beispiel:
CREATE ROLE myuseraccount WITH LOGIN NOSUPERUSER CREATEDB PASSWORD 'mY!P@ss0rd';
GRANT ALL PRIVILEGES ON DATABASE mydatabase TO myuseraccount;
Hinweis
Sie verwenden auch den createuser Befehl aus der Bash-Eingabeaufforderung, um PostgreSQL-Rollen zu erstellen.
Führen Sie die folgende SQL-Anweisung aus, um die vorhandenen Rollen in der lokalen Datenbank anzuzeigen:
SELECT rolname
FROM pg_roles;
Sie können den Befehl \du im psql-Hilfsprogramm verwenden, um die Berechtigungen anzuzeigen, die Rollen zugewiesen sind.
List of roles
Role name | Attributes | Member of
---------------+------------------------------------------------------------+-----------
azureuser | Superuser, Create DB | {}
myuseraccount | Create DB | {}
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
Hinweis
Beachten Sie, dass azure Database for PostgreSQL einige eigene Rollen hinzufügt. Diese Rollen umfassen azure_pg_admin, azure_superuserund den Administratorbenutzer, den Sie beim Erstellen des Diensts angegeben haben. Sie melden sich mit Ihren Administratorkonten an, aber die anderen beiden Rollen sind für die Verwendung durch Azure reserviert– Sie sollten nicht versuchen, sie zu verwenden.
Neukonfigurieren von Anwendungen
Das Neukonfigurieren einer Anwendung zum Herstellen einer Verbindung mit Azure-Datenbank für PostgreSQL ist ein einfacher Prozess. Es ist jedoch wichtiger, eine Strategie für Migrationsanwendungen zu bestimmen.
Überlegungen beim Neukonfigurieren von PostgreSQL-Anwendungen
In einer Unternehmensumgebung haben Sie möglicherweise viele Anwendungen, die mit denselben PostgreSQL-Datenbanken ausgeführt werden. Möglicherweise gibt es eine große Anzahl Benutzer, die diese Anwendungen ausführen. Sie möchten sicher sein, dass Ihre Systeme, wenn Sie vom vorhandenen System zu Azure Database für PostgreSQL wechseln, weiterhin funktionieren, die Benutzer ihre Aufgaben fortsetzen können, und Ihre geschäftskritischen Vorgänge bleiben betriebsbereit. Modul 1, Lektion 2, Überlegungen für die Migration, diskutierten viele der Allgemeinen Probleme. Wenn Sie eine PostgreSQL-Datenbank zu Azure migrieren, gibt es einige Besonderheiten zu beachten:
- Wenn Sie eine Offlinemigration durchführen, können die Daten in der ursprünglichen PostgreSQL-Datenbank und die neuen Datenbanken, die auf Azure ausgeführt werden, schnell abweichen, wenn die alte Datenbank noch verwendet wird. Eine Offlinemigration eignet sich, wenn Sie ein System kurz aus dem Betrieb nehmen und dann alle Anwendungen auf das neue System umstellen, bevor Sie es erneut starten. Dieser Ansatz ist für ein unternehmenskritisches System möglicherweise ungeeignet. Wenn Sie zu PostgreSQL migrieren, die auf einem virtuellen Azure-Computer ausgeführt wird, konfigurieren Sie die PostgreSQL-Replikation zwischen Ihrem lokalen System und dem in Azure ausgeführten. Native PostgreSQL-Replikation funktioniert nur in eine Richtung, aber Drittanbieterlösungen sind verfügbar, die bidirektionale Replikation zwischen PostgreSQL-Servern unterstützen (diese Lösungen funktionieren nicht mit Azure Database für PostgreSQL).
- Wenn Sie eine Onlinemigration durchführen, richtet der Dienst Azure Database for PostgreSQL die Replikation von der lokalen Datenbank zu der in Azure ausgeführten Datenbank ein. Nach der ersten Datenübertragung sorgt die Replikation dafür, dass alle in der lokalen Datenbank vorgenommenen Änderungen in die Datenbank in Azure kopiert werden, jedoch nicht umgekehrt.
In beiden Fällen sollten Sie sicherstellen, dass keine Livedaten durch versehentliches Überschreiben verloren gehen. In einem Onlineszenario könnten beispielsweise Änderungen für eine Anwendung, die mit der in Azure Database for PostgreSQL ausgeführten Datenbank verbunden ist, versehentlich von einer Anwendung überschrieben werden, die noch die lokale Datenbank verwendet. Dabei sollten Sie die folgenden Ansätze berücksichtigen:
- Migrieren Sie Anwendungen basierend auf dem jeweiligen Workloadtyp. Eine Anwendung, die nur auf die Daten zum Lesen zugreift, kann sicher in die Datenbank verschoben werden, die in Azure Database for PostgreSQL ausgeführt wird, und alle Änderungen sehen, die von Anwendungen vorgenommen wurden, die weiterhin die lokale Datenbank verwenden. Sie können auch eine umgekehrte Strategie verwenden, wenn schreibgeschützte Anwendungen nicht vollständig aktuelle Daten benötigen.
- Migrieren Sie Benutzer basierend auf dem jeweiligen Workloadtyp. Diese Strategie ähnelt dem vorherigen, mit der Ausnahme, dass Sie möglicherweise Benutzer haben, die nur Berichte generieren, während andere die Daten ändern. Möglicherweise haben Sie dieselbe Anwendung für die Verbindung mit der entsprechenden Datenbank entsprechend den Benutzeranforderungen konfiguriert.
- Migrieren Sie Anwendungen basierend auf den verwendeten Datasets. Wenn unterschiedliche Anwendungen unterschiedliche Teilmengen der Daten verwenden, können Sie diese Anwendungen möglicherweise unabhängig voneinander migrieren.
Neukonfigurieren einer Anwendung
Beim Neukonfigurieren einer Anwendung verweisen Sie auf die neue Datenbank. Die meisten gut geschriebenen Anwendungen isolieren die Verbindungslogik, und dies sollte der einzige Teil des Codes sein, der geändert werden muss. In vielen Fällen werden die Verbindungsinformationen möglicherweise als Konfigurationsinformationen gespeichert– Sie müssen diese Informationen nur aktualisieren.
Sie finden die Verbindungsinformationen für Ihre Azure-Datenbank für Den PostgreSQL-Dienst im Azure-Portal auf der Seite "Verbindungszeichenfolgen " für Ihren Dienst. Azure stellt diese Informationen für viele gängige Programmiersprachen und Frameworks bereit.
Öffnen von Netzwerkports
Wie in Lektion 1 dieses Moduls erwähnt, ist Azure Database for PostgreSQL ein geschützter Dienst, der hinter einer Firewall ausgeführt wird. Clients können nur eine Verbindung herstellen, wenn ihre IP-Adresse vom Dienst erkannt wird. Sie müssen die IP-Adressen oder Adressblockbereiche für Clients hinzufügen, die Anwendungen ausführen, die eine Verbindung mit Ihren Datenbanken herstellen müssen.
Testen und Überprüfen von Anwendungen
Bevor Sie Ihre Anwendungen und Benutzer zur neuen Datenbank wechseln, ist es wichtig, sicherzustellen, dass Sie alles ordnungsgemäß konfiguriert haben.
Beginnen Sie mit "Trockenlauf"-Anwendungen, und verbinden Sie jede Rolle, um sicherzustellen, dass die richtigen Funktionen verfügbar sind.
Führen Sie dann Belastungstests durch, um die typische Anzahl von Benutzern zu imitieren, die repräsentative Workloads parallel und für einen bestimmten Zeitraum ausführen. Überwachen Sie das System, und stellen Sie sicher, dass Sie ihrer Azure-Datenbank für Den PostgreSQL-Dienst ausreichende Ressourcen zugewiesen haben.
An diesem Punkt können Sie mit dem Rollout des Systems für Benutzer beginnen. Manchmal kann es nützlich sein, eine Art Canarytest zu implementieren, bei dem eine kleine Teilmenge der Benutzer zum neuen System wechselt, ohne davon zu wissen. So erhalten Sie eine unvoreingenommene Meinung darüber, ob Benutzer mit der neuen Datenbank gleich zufrieden, zufriedener oder unzufriedener sind.