Hauptserverversion eines Clusters upgraden

Auf dieser Seite wird beschrieben, wie Sie die Datenbankserverversionen in AlloyDB for PostgreSQL aktualisieren und Ihre Daten in einen Cluster migrieren, der mit einer neueren PostgreSQL-Version kompatibel ist.

Weitere Informationen zum Erstellen eines Clusters finden Sie unter Cluster und primäre Instanz erstellen.

Kompatibilität von Clustern und PostgreSQL-Versionen

Wenn Sie einen AlloyDB-Cluster erstellen, wählen Sie die Hauptversion von PostgreSQL aus, die mit den Instanzen im Cluster kompatibel ist. Der Standardwert ist 15.

AlloyDB führt während der regelmäßigen Wartung automatische Upgrades von Nebenversionen der Datenbank durch. Wenn Sie beispielsweise einen Cluster mit der Kompatibilität 15 erstellt haben, werden die Datenbankserver von AlloyDB auf die neueste Minorversion von 15 aktualisiert.

Bei einem Upgrade auf eine neue Hauptversion von PostgreSQL müssen Sie das Upgrade jedoch selbst planen, testen und ausführen.

Es gibt mehrere Methoden, um ein Upgrade auf eine neue Hauptversion Ihres Clusters durchzuführen:

  1. Ein direktes Upgrade auf eine Hauptversion, das wir empfehlen.
  2. Daten mit einem dateibasierten Datenexport migrieren
  3. Database Migration Service verwenden

Jede Upgrade-Lösung bietet unterschiedliche Vor- und Nachteile. In der folgenden Tabelle finden Sie einen kurzen Vergleich, der Ihnen bei der Auswahl des richtigen Ansatzes für Ihr Szenario helfen kann.

Direktes Upgrade auf eine Hauptversion Dateibasierter Datenexport Migration mit dem Database Migration Service
Ihr Cluster, einschließlich Leseinstanzen, wird auf die ausgewählte höhere Hauptversion umgestellt. Bei dateibasierten Exporten wird ein einmaliger Snapshot Ihrer Datenbanken verschoben. Der Database Migration Service bietet während des Migrationsprozesses kontinuierliche Replikationsfunktionen, wodurch die Wahrscheinlichkeit von fehlenden Daten im neuen Cluster verringert wird.
Sie können während der Vorabphase des Upgrades weiter an Ihrem Cluster arbeiten. Ihre Anwendung ist länger nicht verfügbar, wenn Sie die Daten exportieren. Sie können erst dann Datenbankeinträge in Ihrem ursprünglichen Cluster akzeptieren, wenn der neue Cluster voll funktionsfähig ist. Die Ausfallzeit Ihrer Anwendung ist kürzer. Sie beginnt, wenn Sie die Anwendung auf den neuen Cluster umstellen möchten.
Je nach Schema kann das Upgrade etwa 20 Minuten oder länger dauern. Nach dem Upgrade können Sie mit derselben IP-Adresse auf den Cluster zugreifen. Sie haben eine detailliertere Kontrolle darüber, welche Daten in den Export eingeschlossen werden sollen, und können bestimmte Tabellen oder andere Entitäten nicht migrieren. Der Database Migration Service migriert automatisch alle Datenbanken in Ihren Instanzen und alle Instanzen in Ihrem Cluster. Sie können bestimmte Tabellen oder Ansichten nicht aus den Migrationsdaten ausschließen.
Für Ihren Cluster kann der SSL-Erzwigungsmodus aktiviert sein. Für die Migration mit Database Migration Service müssen Sie den SSL-Erzwingungsmodus im Quellcluster deaktivieren.


Im nächsten Abschnitt wird beschrieben, wie Sie ein Upgrade auf eine neue Hauptversion durchführen, einschließlich der Migration Ihrer Daten.

Direktes Upgrade auf eine Hauptversion

So können Sie nahtlos auf die neue Version umstellen, ohne zusätzliche Cluster einrichten zu müssen. Weitere Informationen finden Sie unter Direktes Upgrade der Datenbank-Hauptversion durchführen.

Migration mithilfe von dateibasiertem Datenexport

Wenn Sie einen Datenbankserver verwenden möchten, der mit einer höheren Hauptversion von PostgreSQL kompatibel ist, müssen Sie einen funktional identischen Cluster in derselben Region erstellen und Ihre Daten dann dorthin migrieren.

Gehen Sie so vor:

  1. Erstellen Sie einen Cluster, der mit der gewünschten PostgreSQL-Hauptversion konfiguriert ist. Erstellen Sie den Cluster in derselben Region wie Ihren aktuellen Cluster.

  2. Richten Sie den neuen Cluster mit der neuen Hauptversion ein, damit er der Konfiguration des aktuellen Clusters entspricht:

    1. Erstellen Sie nach Bedarf zusätzliche Lesepoolinstanzen.

    2. Erstellen Sie bei Bedarf sekundäre Cluster.

      Beim Erstellen sekundärer Cluster müssen Sie keine PostgreSQL-Hauptversionsnummer angeben. AlloyDB wendet die PostgreSQL-Version des primären Clusters auf alle sekundären Cluster an.

    3. Aktualisieren Sie die Datenbankflags des neuen Clusters, damit sie den Flag-Einstellungen des aktuellen Clusters entsprechen.

    4. Aktivieren Sie alle Erweiterungen, die Ihre Anwendungen benötigen.

  3. Exportieren Sie Ihre Daten mit psql oder pg_dump aus dem alten Cluster in Dateien.

  4. Importieren Sie die Daten aus den Dateien in den neuen Cluster.

Ihre Anwendungen können jetzt über die neuen IP-Adressen eine Verbindung zu den Instanzen des neuen Clusters herstellen.

Mit dem Database Migration Service migrieren

Mit dem Database Migration Service können Sie Daten aus PostgreSQL-Datenbanken in AlloyDB-Cluster verschieben. Der Database Migration Service bietet keine Konfiguration speziell für AlloyDB-Datenquellen. AlloyDB ist jedoch mit PostgreSQL kompatibel, sodass Sie die Konfiguration für generische PostgreSQL-Quellen verwenden können.

Dieser Migrationspfad ist kein In-Place-Upgrade und führt zum Erstellen eines neuen Clusters mit einer anderen IP-Adresse. Wir empfehlen Ihnen, zuerst Ihren Cluster zu klonen und eine Testmigration durchzuführen, um zu prüfen, ob Ihre Anwendung mit diesem Ansatz kompatibel ist.

Was Sie bedenken sollten

Bevor Sie mit der Migration mit Database Migration Service beginnen, sollten Sie die folgenden Einschränkungen sorgfältig prüfen, um sicherzustellen, dass dieser Migrationspfad zu Ihrem Upgradeszenario passt.

Beschränkungen
  • SSL-Verbindungen müssen in Ihrem Quellcluster deaktiviert sein.
  • AlloyDB-Instanzen, die mit Private Service Connect konfiguriert sind, werden nicht unterstützt.
  • Während der Migration können Sie keine Instanzupdates oder Failover-Anfragen für den Quellcluster ausführen. Diese Vorgänge können dazu führen, dass der Migrationsjob fehlschlägt.
  • Für dieses Szenario gelten alle Standardeinschränkungen für Migrationen von PostgreSQL zu AlloyDB. Eine vollständige Liste der anderen Einschränkungen finden Sie in der Dokumentation zum Database Migration Service unter Bekannte Einschränkungen.
Zuverlässigkeit der Migration
Bestimmte Datentypen, z. B. große Objekte, werden nicht migriert. Eine vollständige Liste der unterstützten Daten finden Sie in der Dokumentation zum Database Migration Service unter Migrationstreue.
Sperrung und Ausfallzeit der Quelldatenbank

Der Database Migration Service verwendet kontinuierliche Migrationen, um Daten in AlloyDB-Cluster zu verschieben. Bei dieser Art der Migration werden die Tabellen der Quelldatenbank beim Erstellen des ersten Datendumps nacheinander für kurze Zeit (weniger als 10 Sekunden) gesperrt.

Nach Abschluss der Migration müssen Sie alle Schreibvorgänge in der Quelldatenbank beenden, bevor Sie Ihre Anwendung auf den neuen Cluster umstellen können. Dieser Vorgang erfordert eine gewisse Ausfallzeit. Eine ausführlichere Übersicht finden Sie in der Dokumentation zum Database Migration Service unter Kontinuierliche Migrationen.

Einschränkungen bei der Replikation

Nachdem der Migrationsjob in die CDC-Phase (Change Data Capture) übergegangen ist, repliziert der Database Migration Service kontinuierlich neue Daten, die in Ihre Quelldatenbanken geschrieben werden.

Bei Tabellen ohne Primärschlüssel werden während der CDC-Phase nur INSERT-Anweisungen repliziert. Alle CREATE-, UPDATE- oder DELETE-Aktionen, die während der CDC-Phase auf Tabellen ohne Primärschlüssel ausgeführt wurden, müssen manuell in der Zieldatenbank neu erstellt werden, um Datenverluste zu vermeiden.

Hinweise

  1. Enable the Database Migration Service API.

    Enable the API

  2. Make sure that you have the following role or roles on the project:

    • One of the following:
      • Cloud AlloyDB > Cloud AlloyDB admin
      • Basic > Owner
      • Basic > Editor
    • You must also have the compute.networks.list permission in the Google Cloud project you are using. To gain this permission while following the principle of least privilege, ask your administrator to grant you the Compute Engine > Compute Network User role (roles/compute.networkUser).
    • Database Migration admin

    Check for the roles

    1. In the Google Cloud console, go to the IAM page.

      Go to IAM
    2. Select the project.

    3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.

    4. For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.

    Grant the roles

    1. In the Google Cloud console, go to the IAM page.

      IAM aufrufen
    2. Wählen Sie das Projekt aus.
    3. Klicken Sie auf Zugriff erlauben.

    4. Geben Sie im Feld Neue Hauptkonten Ihre Nutzer-ID ein. Dies ist in der Regel die E-Mail-Adresse eines Google-Kontos.

    5. Wählen Sie in der Liste Rolle auswählen eine Rolle aus.
    6. Wenn Sie weitere Rollen hinzufügen möchten, klicken Sie auf Weitere Rolle hinzufügen und fügen Sie weitere Rollen hinzu.
    7. Klicken Sie auf Speichern.
    8. Das VPC-Netzwerk in dem von Ihnen verwendeten Google Cloud-Projekt muss für den Zugriff auf private Dienste auf AlloyDB konfiguriert sein.
    9. Legen Sie fest, in welcher Region Sie den Zielcluster erstellen möchten. Alle Entitäten des Database Migration Service (Verbindungsprofile, Migrationsjobs) müssen in derselben Region wie Ihr Zielcluster erstellt werden.
    10. Bereiten Sie einen Datenbanknutzer vor, den Sie mit Ihrem Cluster verbinden und Migrationsabfragen in Ihren Quelldatenbanken ausführen möchten. Für diesen Datenbanknutzer sind bestimmte Berechtigungen und Rollen erforderlich. Wir empfehlen, einen neuen Datenbanknutzer zu erstellen und ihn speziell für die Migration zuzuweisen.

    Quellinstanzen konfigurieren

    Der Database Migration Service erfordert eine bestimmte Konfiguration, um eine Verbindung herzustellen und Daten aus dem Quellcluster in den neuen Zielcluster zu kopieren.

    So konfigurieren Sie Ihre AlloyDB-Quellinstanzen:

    1. Konfigurieren Sie Datenbank-Flags auf jeder Instanz in Ihrem Quellcluster. Verwenden Sie die folgenden Werte:
      Flag Wert
      alloydb.logical_decoding Legen Sie on fest.
      alloydb.enable_pglogical Legen Sie on fest.
      max_replication_slots Mit diesem Flag wird die maximale Anzahl von Replikations-Slots definiert, die von der Quellinstanz unterstützt werden können. Der Mindestwert für dieses Flag ist 50.

      Berechnen Sie den Mindestwert mit der folgenden Formel:

      (the number of databases in your instance) * (the number of simultaneous migration jobs you want to perform) + (slots reserved for table synchronization) + (the number of replication slots you currently use for your read replicas)

      Betrachten Sie ein Beispiel, in dem Folgendes zutrifft:

      • In Ihrer Quelle gibt es keine Lesereplikate.
      • Sie haben 30 Datenbanken in der primären Quellinstanz.
      • Sie möchten zwei Migrationsjobs für den Quellcluster erstellen.
      • Sie möchten 10 Slots für die Tabellenreplikation verwenden.
      In diesem Fall muss die Anzahl der max_replication_slots mindestens 70 betragen, berechnet als 30 * 2 + 10 + 0.
      max_wal_senders Legen Sie für dieses Flag einen Wert fest, der mindestens 10 über dem Wert von max_replication_slots und der Anzahl der Absender liegt, die bereits auf Ihrer Instanz verwendet werden.

      Wenn Sie beispielsweise max_replication_slots flag auf 70 festlegen und bereits zwei Absender verwenden, sollte max_wal_senders mindestens 82 betragen (berechnet als 70 + 10 + 2 = 82).

      max_worker_processes Legen Sie für dieses Flag mindestens die Anzahl der Datenbanken in Ihrer Instanz und die Anzahl der bereits verwendeten max_worker_processes fest.

      Wenn Sie beispielsweise 30 Datenbanken in Ihrer Quellinstanz haben und keine Workerprozesse verwenden, setzen Sie dieses Flag auf 30.
    2. Deaktivieren Sie den SSL-Erzwigungsmodus auf jeder Instanz in Ihrem Quellcluster.

    Quelldatenbanken konfigurieren

    Sie müssen die pglogical-Erweiterung installieren und dem Datenbanknutzer, den Sie als Migrationsnutzer festlegen, die erforderlichen Berechtigungen für jede Datenbank in Ihren Instanzen erteilen.

    So konfigurieren Sie Ihre Datenbanken:

    1. Stellen Sie über den psql-Client eine Verbindung zur Standard-postgres-Datenbank her.

    2. Installieren Sie die pglogical-Erweiterung mit dem folgenden Befehl:

      CREATE EXTENSION IF NOT EXISTS pglogical;

    3. Gewähren Sie dem Nutzer der Migrationsdatenbank Berechtigungen für alle Schemas mit Ausnahme des information-Schemas und der Schemas, deren Namen mit dem Präfix pg_ beginnen. Führen Sie die folgenden Anweisungen aus:

      GRANT USAGE on SCHEMA SCHEMA_NAME to USER_NAME;
GRANT SELECT on ALL TABLES in SCHEMA SCHEMA_NAME to USER_NAME;
GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA_NAME to USER_NAME;

      Ersetzen Sie Folgendes:

      • SCHEMA_NAME: der Name eines Schemas in Ihrer Datenbank
      • USER_NAME: der Name des Datenbanknutzers, den Sie im Abschnitt Vorbereitung vorbereitet haben

      Wiederholen Sie diesen Schritt für jedes Schema in Ihrer Datenbank, mit Ausnahme des information-Schemas und der Schemas, deren Namen mit dem Präfix pg_ beginnen. Mit dem Metabefehl \dn können Sie alle Datenbankschemata auflisten.

    4. Gewähren Sie die verbleibenden erforderlichen Berechtigungen. Führen Sie die folgenden Anweisungen aus:

      GRANT USAGE on SCHEMA pglogical to PUBLIC;
GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER_NAME;
ALTER USER USER_NAME with REPLICATION;

      Ersetzen Sie USER_NAME durch den Namen des Datenbanknutzers, den Sie im Abschnitt Vorbereitung vorbereitet haben.

    5. Stellen Sie eine Verbindung zu jeder anderen Datenbank in Ihrer Instanz her und wiederholen Sie die Schritte 2, 3 und 4.

      • Mit dem Metabefehl \list können Sie alle Datenbanken in Ihrer Instanz auflisten.

      • Mit dem Befehl \connect {database_name_here} können Sie zu einer anderen Datenbank wechseln, ohne Ihre psql-Clientverbindung zurückzusetzen.

    6. Wiederholen Sie diesen Vorgang für jede Instanz in Ihrem Quell-AlloyDB-Cluster.

    Migration im Database Migration Service ausführen

    Gehen Sie so vor:

    1. Erstellen Sie ein Quellverbindungsprofil für Ihren AlloyDB-Cluster. Verwenden Sie die folgenden Werte:

      • Datenbankmodul: Wählen Sie PostgreSQL aus.
      • Hostname/IP: Verwenden Sie die IP-Adresse der primären Instanz in Ihrem Cluster.
      • Nutzername/Passwort: Geben Sie die Anmeldedaten für den Datenbanknutzer ein, den Sie im Abschnitt Vorab vorbereitet haben.
      • Port: Geben Sie 5432 ein.
      • Region: Wählen Sie die Region aus, in der sich der Zielcluster befindet.
      • Verschlüsselungstyp: Wählen Sie Keine aus.

    2. Erstellen und ausführen Sie den Migrationsjob.

      Sie können den neuen AlloyDB-Cluster im Voraus erstellen oder den Database Migration Service damit beauftragen, den Cluster während der Konfiguration des Migrationsjobs für Sie zu erstellen. Weitere Informationen finden Sie in der Dokumentation zum Database Migration Service unter Migrationsjobs – Übersicht.

      Wenn der Database Migration Service den Zielcluster während der Konfiguration des Migrationsjobs für Sie erstellen soll, folgen Sie der Anleitung unter Migrationsjob zu einer neuen Zielinstanz erstellen.

      Wenn Sie den Zielcluster außerhalb des Database Migration Service erstellen möchten, folgen Sie der Anleitung unter Migrationsjob zu einer vorhandenen Zielinstanz erstellen.

    3. Wenn der Status des Migrationsjobs zu CDC wechselt, stufen Sie den Migrationsjob hoch. Sie können den Status des Migrationsjobs auf der Übersichtsseite der Migration prüfen. Weitere Informationen finden Sie in der Dokumentation zum Database Migration Service unter Migrationsjob prüfen.

      Dadurch wird der Bootstrapping-Modus des Zielclusters beendet. Das bedeutet, dass der Ziel-AlloyDB-Cluster nicht mehr im schreibgeschützten Zustand ist.

    4. Optional: Prüfen Sie, ob in Tabellen ohne Primärschlüssel Anweisungen fehlen.

      Wenn Ihre Quell-AlloyDB-Datenbanken Tabellen enthalten, die keine Primärschlüssel haben, müssen Sie möglicherweise fehlende UPDATE- oder DELETE-Anweisungen manuell migrieren. Weitere Informationen finden Sie in der Dokumentation zum Database Migration Service unter UPDATE- und DELETE-Vorgänge für Tabellen ohne Primärschlüssel migrieren.

    5. Stellen Sie Ihre Anwendung auf den neuen Cluster um. Ihre Anwendungen können jetzt über ihre neuen IP-Adressen eine Verbindung zu den Instanzen des neuen Clusters herstellen.