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 erklärt, 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. Standardmäßig ist das Version 17.

AlloyDB führt während der regelmäßigen Wartung automatische Upgrades der Nebenversion der Datenbank durch. Wenn Sie beispielsweise einen Cluster mit Version 17 erstellt haben, werden die Datenbankserver in AlloyDB auf die neueste Nebenversion von Version 17 aktualisiert.

Für ein Upgrade auf eine neue Hauptversion von PostgreSQL müssen Sie das Upgrade jedoch selbst planen, testen und durchführen.

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

Ein direktes Upgrade auf eine neue Hauptversion, das wir empfehlen.
Migration der Daten mit einem dateibasierten Datenexport.
Verwendung von Database Migration Service.

Jede Upgrade-Lösung hat Vor- und Nachteile. In der folgenden Tabelle finden Sie einen kurzen Vergleich, der Ihnen bei der Auswahl der richtigen Methode für Ihr Szenario helfen soll.

Direktes Upgrade auf eine neue 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 ein einmaliger Snapshot Ihrer Datenbanken verschoben.	Database Migration Service bietet während des Migrationsprozesses Funktionen für die kontinuierliche Replikation, wodurch die Wahrscheinlichkeit verringert wird, dass Daten in Ihrem neuen Cluster fehlen.
Sie können während der Vorbereitungsphase des Upgrades weiter an Ihrem Cluster arbeiten.	Ihre Anwendung ist länger nicht verfügbar. Die Ausfallzeit beginnt, wenn Sie die Daten exportieren. Sie können keine Schreibvorgänge in Ihrer ursprünglichen Datenbank akzeptieren bis der neue Cluster vollständig betriebsbereit ist.	Ihre Anwendung ist kürzer nicht verfügbar. Die Ausfallzeit beginnt, wenn Sie die Anwendung auf den neuen Cluster umstellen.
Während des Upgrades ist je nach Schema mit einer Ausfallzeit von etwa 20 Minuten oder mehr zu rechnen. 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 aufgenommen 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 aus Ihren Migrationsdaten ausschließen.
	Für Ihren Cluster kann der SSL-Erzwingungsmodus aktiviert sein.	Für die Migration muss der SSL-Erzwingungsmodus im Quellcluster deaktiviert sein.

Im nächsten Abschnitt wird der Prozess für das Upgrade auf eine neue Hauptversion beschrieben, einschließlich der Migration Ihrer Daten.

Direktes Upgrade auf eine neue Hauptversion

So können Sie ein nahtloses Upgrade durchführen, ohne zusätzliche Cluster einrichten zu müssen. Weitere Informationen finden Sie unter Direkte Datenbankaktualisierung durchführen.

Migration mit dateibasiertem Datenexport

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

Gehen Sie so vor:

Erstellen Sie einen Cluster, der mit der Hauptversion von PostgreSQL konfiguriert ist, die Sie verwenden möchten. Erstellen Sie den Cluster in derselben Region wie Ihren aktuellen Cluster.
Konfigurieren Sie den neuen Cluster mit der neuen Hauptversion so, 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, damit sie mit den Flag-Einstellungen des aktuellen Clusters übereinstimmen.
4. Aktivieren Sie alle Erweiterungen, die Ihre Anwendungen benötigen.
Exportieren Sie Ihre Daten aus dem alten Cluster in Dateien mit psql oder pg_dump.
Importieren Sie Ihre 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.

Migration mit Database Migration Service

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

Bei dieser Migrationsmethode wird kein direktes Upgrade durchgeführt, sondern ein neuer Cluster mit einer anderen IP-Adresse erstellt. Wir empfehlen, zuerst Ihren Cluster zu klonen und eine Testmigration durchzuführen, um zu prüfen, ob Ihre Anwendung mit dieser Methode 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 diese Migrationsmethode für Ihr Upgrade-Szenario geeignet ist.

Beschränkungen

AlloyDB-Instanzen, die mit Private Service Connect konfiguriert sind, werden nicht unterstützt.
Während der Migration können Sie keine Instanzaktualisierungen oder Failover-Anfragen für den Quellcluster durchführen. Diese Vorgänge können dazu führen, dass der Migrations Job fehlschlägt.
Für dieses Szenario gelten alle Standardeinschränkungen für die Migration von PostgreSQL zu AlloyDB Eine vollständige Liste der weiteren Einschränkungen finden Sie unter Bekannte Einschränkungen in der Dokumentation zu Database Migration Service.

Zuverlässigkeit der Migration

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

Sperrung der Quelldatenbank und Ausfallzeit

Database Migration Service verwendet kontinuierliche Migrationen, um Daten zu AlloyDB-Clustern zu verschieben. Bei dieser Art der Migration wird eine kurze (weniger als 10 Sekunden) Sperrung der Quelldatenbanktabellen einzeln durchgeführt, während der erste Daten-Dump erstellt wird.

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 detailliertere Übersicht finden Sie unter Kontinuierliche Migrationen in der Dokumentation zu Database Migration Service.

Einschränkungen bei der Replikation

Nachdem der Migrationsjob in die CDC-Phase (Change Data Capture) übergegangen ist, Database Migration Service repliziert 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.
Rollen, die zum Aktivieren von APIs erforderlich sind
Zum Aktivieren von APIs benötigen Sie die IAM-Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin), die die Berechtigung serviceusage.services.enable enthält. Informationen zum Zuweisen von Rollen.
API aktivieren

Sie benötigen die folgenden Rollen für das Projekt:
- Beispiele:
  - Cloud AlloyDB > Cloud AlloyDB-Administrator
  - Einfach > Inhaber
  - Einfach > Editor
- Sie benötigen außerdem die Berechtigung compute.networks.list im Google Cloud verwendeten Projekt. 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 Rolle Spalte , 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 Add another role, wenn Sie weitere Rollen zuweisen möchten.
7. Klicken Sie auf Speichern.
Prüfen Sie, ob das VPC-Netzwerk im verwendeten Google Cloud Projekt 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 eine bestimmte Reihe von 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 herzustellen und Daten aus Ihrem Quellcluster in den neuen Zielcluster zu kopieren.

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 von Replikations-Slots definiert, die von der Quellinstanz unterstützt werden können. Der Mindestwert für this 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)` Hier ein Beispiel: 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 für dieses Flag mindestens 10 mehr als den `max_replication_slots` Wert plus die Anzahl der Absender fest, die bereits auf Ihrer Instanz verwendet werden. Wenn Sie beispielsweise das `max_replication_slots flag` auf `70` setzen 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 plus die Anzahl der `max_worker_processes` bereits verwendeten fest. Wenn Sie beispielsweise 30 Datenbanken in Ihrer Quellinstanz haben und keine Worker-Prozesse 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, die erforderlichen Berechtigungen für jede Datenbank in Ihren Instanzen gewähren.

So konfigurieren Sie Ihre Datenbanken:

Stellen Sie mit dem psqlClient eine Verbindung zur Standarddatenbank postgresher.
Installieren Sie die Erweiterung pglogical, indem Sie den folgenden Befehl ausführen:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Gewähren Sie dem Migrationsdatenbanknutzer Berechtigungen für alle Schemas außer für das Schema information und 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 erstellt haben
Wiederholen Sie diesen Schritt für jedes Schema in Ihrer Datenbank außer für das Schema information und Schemas, deren Namen mit dem Präfix pg_ beginnen. Sie können alle Datenbankschemas mit dem \dn Metadatenbefehl auflisten.
Gewähren Sie die restlichen 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 erstellt haben.
Stellen Sie eine Verbindung zu jeder anderen Datenbank in Ihrer Instanz her und wiederholen Sie die Schritte 2, 3 und 4.
- Sie können alle Datenbanken in Ihrer Instanz mit dem \list Metadatenbefehl auflisten.
- Sie können zu einer anderen Datenbank wechseln, ohne die psql Client Verbindung zurücksetzen zu müssen, indem Sie den \connect {database_name_here} Befehl verwenden.
Wiederholen Sie diesen Vorgang für jede Instanz in Ihrem AlloyDB-Quellcluster.

Migration in Database Migration Service ausführen