Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Upgrade der Hauptserverversion eines Clusters durchführen

Auf dieser Seite wird der Prozess für die Aktualisierung von Datenbankserverversionen in AlloyDB for PostgreSQL beschrieben. Außerdem wird erläutert, wie Sie Ihre Daten zu einem Cluster migrieren, der mit einer neueren Version von PostgreSQL kompatibel ist.

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, werden die Datenbankserver in AlloyDB auf die neueste Nebenversion von 17 aktualisiert.

Für ein Hauptversionsupgrade der PostgreSQL-Version müssen Sie das Upgrade jedoch selbst planen, testen und ausführen.

Es gibt mehrere Methoden, um Hauptversionsupgrades Ihres Clusters durchzuführen:

Ein In-Place-Upgrade der Hauptversion, das wir empfehlen.
Daten mit einem dateibasierten Datenexport migrieren
Database Migration Service verwenden

Jede Upgrade-Lösung bietet unterschiedliche Vor- und Nachteile. Die folgende Tabelle enthält einen kurzen Vergleich, der Ihnen bei der Auswahl des richtigen Ansatzes für Ihr Szenario helfen soll.

Direktes Upgrade der Hauptversion	Dateibasierter Datenexport	Migration mit Database Migration Service
Ihr Cluster, einschließlich der Leseinstanzen, wird auf die ausgewählte höhere Hauptversion aktualisiert.	Bei dateibasierten Exporten wird eine einmalige Momentaufnahme Ihrer Datenbanken verschoben.	Database Migration Service bietet während der Migration Funktionen für die kontinuierliche Replikation, wodurch die Wahrscheinlichkeit, dass Daten in Ihrem neuen Cluster fehlen, geringer ist.
Sie können während der Vorbereitungsphase des Upgrades weiter an Ihrem Cluster arbeiten.	Bei Ihrer Anwendung kommt es zu längeren Ausfallzeiten, die mit dem Export der Daten beginnen. 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 kann es während des Upgrades zu Ausfallzeiten von etwa 20 Minuten oder mehr kommen. Nach dem Upgrade können Sie mit derselben IP-Adresse auf den Cluster zugreifen.	Sie haben mehr Kontrolle darüber, welche Daten in den Export aufgenommen werden sollen, und können bestimmte Tabellen oder andere Einheiten von der Migration ausschließen.	Database Migration Service migriert automatisch alle Datenbanken in Ihren Instanzen und alle Instanzen in Ihrem Cluster. Sie können nicht auswählen, dass bestimmte Tabellen oder Ansichten aus Ihren Migrationsdaten ausgeschlossen werden.
	In Ihrem Cluster kann der SSL-Erzwingungsmodus aktiviert sein.	Für Migrationszwecke erfordert Database Migration Service, dass Sie den SSL-Erzwingungsmodus im Quellcluster deaktivieren.

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

Direktes Upgrade der Hauptversion

So wird ein reibungsloses Upgrade ermöglicht, ohne dass Sie zusätzliche Cluster einrichten müssen. Weitere Informationen finden Sie unter Direktes Upgrade der Datenbank-Hauptversion durchführen.

Mithilfe des dateibasierten Datenexports 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 seine 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 für Ihre Anwendungen erforderlich sind.
Daten aus dem alten Cluster mit psql oder pg_dump in Dateien exportieren
Daten aus den Dateien in den neuen Cluster importieren

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 Database Migration Service können Sie Daten aus PostgreSQL-Datenbanken in AlloyDB-Cluster verschieben. Database Migration Service bietet keine Konfiguration speziell für AlloyDB-Datenquellen, aber AlloyDB ist mit PostgreSQL kompatibel. Daher können Sie die für allgemeine PostgreSQL-Quellen vorgesehene Konfiguration verwenden.

Bei diesem Migrationspfad handelt es sich nicht um ein In-Place-Upgrade. Es wird ein neuer Cluster mit einer anderen IP-Adresse erstellt. Wir empfehlen, dass Sie zuerst Ihren Cluster klonen und eine Testmigration durchführen, um zu prüfen, ob Ihre Anwendung mit diesem Ansatz kompatibel ist.

Was Sie bedenken sollten

Bevor Sie die Migration mit Database Migration Service vorbereiten, sollten Sie die folgenden Einschränkungen sorgfältig prüfen, um sicherzustellen, dass dieser Migrationspfad für Ihr Upgradeszenario geeignet ist.

Beschränkungen

AlloyDB-Instanzen, die mit Private Service Connect konfiguriert sind, werden nicht unterstützt.
Sie können während der Migration 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 Database Migration Service-Dokumentation unter Bekannte Einschränkungen.

Zuverlässigkeit der Migration

Bestimmte Datentypen, z. B. Large Objects, werden nicht migriert. Eine vollständige Liste der unterstützten Daten finden Sie in der Dokumentation zu Database Migration Service unter Zuverlässigkeit der Migration.

Sperrung und Ausfallzeiten der Quelldatenbank

Database Migration Service verwendet kontinuierliche Migrationen, um Daten in AlloyDB-Cluster zu übertragen. Bei dieser Art der Migration werden die Quelldatenbanktabellen einzeln gesperrt, während der erste Daten-Dump erstellt wird. Die Sperrung dauert jeweils nur kurz (weniger als 10 Sekunden).

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. Für dieses Verfahren ist eine Ausfallzeit erforderlich. Eine detailliertere Ü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 in der Zieldatenbank manuell neu erstellt werden, um Datenverlust zu vermeiden.

Hinweis

Aktivieren Sie die Database Migration Service API.
Rollen, die zum Aktivieren von APIs erforderlich sind
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 Rolle „Inhaber“ (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:
  - Cloud AlloyDB > Cloud AlloyDB-Administrator
  - Einfach > Inhaber
  - Einfach > Editor
- Außerdem benötigen Sie die Berechtigung compute.networks.list für das Google Cloud -Projekt, das Sie verwenden. Bitten Sie Ihren Administrator, Ihnen die Rolle „Compute Engine > Compute Network User“ (roles/compute.networkUser) zuzuweisen, um diese Berechtigung zu erhalten und dem Prinzip der geringsten Berechtigung zu folgen.
- 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 dann 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 im Google Cloud -Projekt, das Sie verwenden, für den Zugriff auf private Dienste für 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 Ihr Zielcluster erstellt werden.
Bereiten Sie einen Datenbanknutzer vor, mit dem Sie eine Verbindung zu Ihrem Cluster herstellen und Migrationsanweisungen für Ihre Quelldatenbanken ausführen möchten. 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 zum Quellcluster herzustellen und Daten in den neuen Zielcluster zu kopieren.

So konfigurieren Sie Ihre AlloyDB-Quellinstanzen:

Datenbank-Flags auf jeder Instanz in Ihrem Quellcluster konfigurieren 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 you currently use for your read replicas)` Angenommen, Folgendes ist der Fall: Sie haben keine Lesereplikate in Ihrer Quelle. 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 dieses Flag auf mindestens 10 mehr als den Wert von `max_replication_slots` plus die Anzahl der Absender fest, 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` 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 in Ihrer Quellinstanz haben und keine Workerprozesse verwenden, setzen Sie dieses Flag auf `30`.

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

Quelldatenbanken konfigurieren

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

So konfigurieren Sie Ihre Datenbanken:

Stellen Sie mit dem psql-Client eine Verbindung zur Standarddatenbank postgres her.
Installieren Sie die pglogical-Erweiterung mit dem folgenden Befehl:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Gewähren Sie dem Migrationsdatenbanknutzer 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 Schemas information und der Schemas, deren Namen mit dem Präfix pg_ beginnen. Mit dem Meta-Befehl \dn können Sie alle Datenbankschemata 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 jeder anderen Datenbank 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.
- Sie können zu einer anderen Datenbank wechseln, ohne die psql-Clientverbindung zurückzusetzen. Verwenden Sie dazu den Befehl \connect {database_name_here}.
Wiederholen Sie diesen Vorgang für jede Instanz in Ihrem AlloyDB-Quellcluster.

Migration in Database Migration Service ausführen