Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Upgrade der Hauptserverversion eines Clusters durchführen

Wenn Sie ein Upgrade Ihres AlloyDB for PostgreSQL-Clusters auf eine neuere Hauptversion von PostgreSQL durchführen, können Sie die neuesten Datenbankfunktionen, Leistungsverbesserungen und Sicherheitsupdates nutzen. Sie können die Hauptversion eines Clusters direkt aktualisieren oder Ihre Daten in einen Cluster migrieren, auf dem eine neuere PostgreSQL-Version ausgeführt wird.

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

Cluster und PostgreSQL-Versionskompatibilität

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 17.

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

Ein Upgrade der Hauptversion der PostgreSQL-Version erfordert jedoch, dass Sie das Upgrade selbst planen, testen und ausführen.

Es gibt mehrere Methoden, um Upgrades der Hauptversion Ihres Clusters durchzuführen:

Ein direktes Upgrade einer Hauptversion, das wir empfehlen.
Daten mit einem dateibasierten Datenexport migrieren
Database Migration Service verwenden

Jede Upgradelösung hat andere Vor- und Nachteile. In der folgenden Tabelle finden Sie einen kurzen Vergleich, der Ihnen bei der Auswahl des richtigen Ansatzes für Ihr Szenario hilft.

Direktes Upgrade der Hauptversion	Dateibasierter Datenexport	Migration mit Database Migration Service
Ihr Cluster, einschließlich Leseinstanzen, wird auf die ausgewählte höhere Hauptversion aktualisiert.	Bei dateibasierten Exporten wird ein einmaliger Snapshot Ihrer Datenbanken verschoben.	Database Migration Service bietet während des Migrationsprozesses Funktionen für die kontinuierliche Replikation, wodurch die Wahrscheinlichkeit, dass Daten in Ihrem neuen Cluster fehlen, verringert wird.
Sie können während der Phase vor dem Upgrade weiter an Ihrem Cluster arbeiten.	Bei Ihrer Anwendung kommt es zu einer längeren Ausfallzeit, die mit dem Export der Daten beginnt. Sie können erst dann Datenbankschreibvorgänge in Ihrem ursprünglichen Cluster akzeptieren, wenn der neue Cluster vollständig betriebsbereit ist.	Die Ausfallzeit Ihrer Anwendung ist kürzer und beginnt, wenn Sie die Anwendung auf den neuen Cluster umstellen möchten.
Je nach Schema müssen Sie während des Upgrades mit einer Ausfallzeit von etwa 20 Minuten oder mehr rechnen. Nach dem Upgrade können Sie mit derselben IP-Adresse auf den Cluster zugreifen.	Sie haben eine bessere Kontrolle darüber, welche Daten in den Export einbezogen werden sollen, und können bestimmte Tabellen oder andere Entitäten von der Migration ausschließen.	Database Migration Service migriert automatisch alle Datenbanken in Ihren Instanzen und alle Instanzen in Ihrem Cluster. Sie können bestimmte Tabellen oder Ansichten nicht von den Migrationsdaten ausschließen.
Für Ihren Cluster kann der SSL-Erzwingungsmodus aktiviert sein.	Für Ihren Cluster kann der SSL-Erzwingungsmodus aktiviert sein.	Für die Migration müssen Sie den SSL-Erzwingungsmodus im Quellcluster deaktivieren.

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

Direktes Upgrade der Hauptversion

Bei einem direkten Upgrade wird der vorhandene Cluster aktualisiert, ohne dass Sie zusätzliche Cluster einrichten müssen. Weitere Informationen finden Sie unter Direktes Upgrade der Datenbank-Hauptversion durchführen.

Mit dateibasiertem Datenexport migrieren

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 dann Ihre Daten dorthin migrieren.

Gehen Sie so vor:

Erstellen Sie einen Cluster, der mit der Hauptversion der PostgreSQL-Kompatibilität konfiguriert ist, die Sie verwenden möchten. Erstellen Sie den Cluster in derselben Region wie Ihren aktuellen Cluster.
Richten Sie den neuen Cluster mit der neuen Hauptversion so ein, dass er der Konfiguration des aktuellen Clusters entspricht:
1. Erstellen Sie bei Bedarf zusätzliche Lesepoolinstanzen.
2. Erstellen Sie bei Bedarf sekundäre Cluster.
  
  Wenn Sie sekundäre Cluster erstellen, 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 Datenbank-Flags des neuen Clusters, sodass sie den Flag-Einstellungen des aktuellen Clusters entsprechen.
4. Aktivieren Sie alle Erweiterungen, die Ihre Anwendungen benötigen.
Exportieren Sie die Daten aus dem alten Cluster mit psql oder pg_dump in Dateien.
Importieren Sie die Daten aus den Dateien in den neuen Cluster.

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

Mit Database Migration Service migrieren

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

Dieser Migrationspfad ist kein direktes Upgrade und führt zur Erstellung eines neuen Clusters mit einer anderen IP-Adresse. Wir empfehlen, 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 sich auf die Migration mit Database Migration Service vorbereiten, sollten Sie die folgenden Einschränkungen sorgfältig prüfen, um sicherzustellen, dass dieser Migrationspfad zu Ihrem Upgradeszenario passt.

Beschränkungen

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 Standardbeschränkungen für Migrationen von PostgreSQL zu AlloyDB. Eine vollständige Liste der anderen Einschränkungen finden Sie in der Database Migration Service-Dokumentation unter Bekannte Einschränkungen.

Zuverlässigkeit der Migration

Bestimmte Datentypen wie große Objekte werden nicht migriert. Eine vollständige Liste der unterstützten Daten finden Sie in der Database Migration Service-Dokumentation unter Migrationstreue.

Sperrung und Ausfallzeit der Quelldatenbank

Database Migration Service verwendet kontinuierliche Migrationen, um Daten in AlloyDB-Cluster zu verschieben. Bei dieser Art der Migration werden die Tabellen der Quelldatenbank nacheinander für kurze Zeit (unter 10 Sekunden) gesperrt, während der erste Datendump erstellt wird.

Wenn die Migration abgeschlossen ist, müssen Sie alle Schreibvorgänge in der Quelldatenbank beenden, bevor Sie Ihre Anwendung auf den neuen Cluster umstellen können. Dieses Verfahren erfordert eine gewisse Ausfallzeit. Eine ausführlichere Übersicht finden Sie in der Dokumentation zu Database Migration Service unter Kontinuierliche Migrationen.

Einschränkungen bei der Replikation

Nachdem der Migrationsjob in die CDC-Phase (Change Data Capture) übergegangen ist, repliziert 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 für Tabellen ohne Primärschlüssel ausgeführt werden, müssen manuell in der Zieldatenbank neu erstellt werden, um Datenverlust zu vermeiden.

Hinweis

Aktivieren Sie die Database Migration Service API, falls sie noch nicht aktiviert ist.
Erforderliche Rollen zum Aktivieren von APIs
Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Inhaberrolle (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen
API aktivieren

Prüfen Sie, ob Sie die folgenden Rollen für das Projekt haben:
- Beispiele:
  - AlloyDB > AlloyDB Admin
  - Einfach > Inhaber
  - Einfach > Bearbeiter
- Außerdem benötigen Sie die Berechtigung compute.networks.list für das Projekt Google Cloud , das Sie verwenden. Bitten Sie Ihren Administrator, Ihnen die Rolle „Compute Engine > Compute-Netzwerknutzer“ (roles/compute.networkUser) zuzuweisen, um diese Berechtigung nach dem Prinzip der geringsten Berechtigung zu erhalten.
- Administrator für die Datenbankmigration
Rollen prüfen
1. Rufen Sie in der Google Cloud Console die Seite IAM auf.
  IAM aufrufen
2. Wählen Sie das Projekt aus.
3. Suchen Sie in der Spalte Hauptkonto nach allen Zeilen, in denen Sie oder eine Gruppe, zu der Sie gehören, angegeben sind. Fragen Sie Ihren Administrator, zu welchen Gruppen Sie gehören.
4. Prüfen Sie in allen Zeilen, in denen Sie angegeben oder enthalten sind, die Spalte Rolle, um zu sehen, ob die Liste der Rollen die erforderlichen Rollen enthält.
Rollen zuweisen
1. Rufen Sie in der Google Cloud Console die Seite IAM auf.
  IAM aufrufen
2. Wählen Sie das Projekt aus.
3. Klicken Sie auf Zugriffsrechte erteilen.
4. Geben Sie im Feld Neue Hauptkonten Ihre Nutzer-ID ein. Das ist in der Regel die E‑Mail-Adresse eines Google-Kontos.
5. Klicken Sie auf Rolle auswählen und suchen Sie nach der Rolle.
6. Klicken Sie auf Weitere Rolle hinzufügen, wenn Sie weitere Rollen zuweisen möchten.
7. Klicken Sie auf Speichern.
Achten Sie darauf, dass das VPC-Netzwerk (Virtual Private Cloud) im Projekt von Google Cloud , das Sie verwenden, für den Zugriff auf private Dienste auf AlloyDB konfiguriert ist.
Entscheiden Sie, in welcher Region Sie den Zielcluster erstellen möchten. Alle Database Migration Service-Entitäten (Verbindungsprofile, Migrationsjobs) müssen in derselben Region wie der Zielcluster erstellt werden.
Bereiten Sie einen Datenbanknutzer vor, den Sie mit Ihrem Cluster verbinden möchten, und führen Sie Migrationsanweisungen für Ihre Quelldatenbanken aus. Dieser Datenbanknutzer benötigt bestimmte Berechtigungen und Rollen. Wir empfehlen, einen neuen Datenbanknutzer zu erstellen und ihn speziell für die Migration zu verwenden.

Quellinstanzen konfigurieren

Database Migration Service erfordert eine bestimmte Konfiguration, um eine Verbindung herstellen und Daten aus dem Quellcluster in den neuen Zielcluster kopieren zu können.

So konfigurieren Sie Ihre AlloyDB-Quellinstanzen:

Konfigurieren Sie Datenbank-Flags für jede 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 an 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 that you use for your read replicas)` Hier ein Beispiel: Sie haben keine Lesereplikate in Ihrer Quelle. Sie haben 30 Datenbanken auf 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`	Setzen Sie dieses Flag auf mindestens 10 mehr als den Wert `max_replication_slots` plus die Anzahl der Absender, die bereits auf Ihrer Instanz verwendet werden. Wenn Sie beispielsweise das Flag `max_replication_slots` auf `70` setzen und bereits 2 Sender verwenden, sollte `max_wal_senders` mindestens `82` sein (berechnet als `70 + 10 + 2 = 82`).
`max_worker_processes`	Setzen Sie dieses Flag auf mindestens die Anzahl der Datenbanken in Ihrer Instanz plus die Anzahl der `max_worker_processes`, die Sie bereits verwenden. Wenn Sie beispielsweise 30 Datenbanken auf Ihrer Quellinstanz haben und keine Worker-Prozesse verwenden, setzen Sie dieses Flag auf `30`.

Deaktivieren Sie den SSL-Erzwingungsmodus für jede Instanz im Quellcluster.

Quelldatenbanken konfigurieren

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

So konfigurieren Sie Ihre Datenbanken:

Stellen Sie mit dem psql-Client eine Verbindung zur Standarddatenbank postgres her.
Installieren Sie die Erweiterung pglogical mit dem folgenden Befehl:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Gewähren Sie dem Nutzer der Migrationsdatenbank Berechtigungen für alle Schemas mit Ausnahme des Schemas information 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 Schemas information und der Schemas, deren Namen mit dem Präfix pg_ beginnen. Mit dem Metabefehl \dn können Sie alle Datenbankschemas auflisten.
Erteilen 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.
Stellen Sie eine Verbindung zu allen anderen Datenbanken in Ihrer Instanz her und wiederholen Sie die Schritte 2, 3 und 4.
- Mit dem Meta-Befehl \list können Sie alle Datenbanken in Ihrer Instanz auflisten.
- Mit dem Befehl \connect DATABASE_NAME können Sie zu einer anderen Datenbank wechseln, ohne die psql-Clientverbindung zurückzusetzen.
Wiederholen Sie diesen Vorgang für jede Instanz im AlloyDB-Quellcluster.

Migration in Database Migration Service ausführen