Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui l'upgrade della versione principale del server di un cluster

Questa pagina descrive il processo di AlloyDB per PostgreSQL per l'aggiornamento delle versioni del server di database e spiega come eseguire la migrazione dei dati a un cluster compatibile con una versione successiva di PostgreSQL.

Per saperne di più su come creare un cluster, vedi Creare un cluster e la relativa istanza principale.

Compatibilità tra cluster e versione PostgreSQL

Quando crei un cluster AlloyDB, scegli la versione principale di PostgreSQL compatibile con le istanze del cluster. Il valore predefinito è 16.

AlloyDB esegue gli upgrade automatici delle versioni secondarie del database durante la manutenzione periodica. Ad esempio, se hai creato un cluster con compatibilità 16, AlloyDB mantiene i server di database aggiornati all'ultima versione secondaria di 16.

Tuttavia, l'upgrade di una versione principale di PostgreSQL richiede di pianificare, testare ed eseguire l'upgrade autonomamente.

Esistono diversi metodi per eseguire gli upgrade della versione principale del cluster:

Un upgrade della versione principale sul posto che ti consigliamo di utilizzare.
Eseguire la migrazione dei dati con un'esportazione dei dati basata su file.
Utilizzo di Database Migration Service.

Ogni soluzione di upgrade offre vantaggi e svantaggi diversi. Consulta la tabella seguente per un breve confronto che ti aiuti a scegliere l'approccio giusto per il tuo scenario.

Upgrade in loco della versione principale	Esportazione dei dati basata su file	Migrazione con Database Migration Service
Il cluster, incluse le istanze di lettura, viene sottoposto all'upgrade alla versione principale superiore scelta.	Le esportazioni basate su file spostano un'istantanea una tantum dei tuoi database.	Database Migration Service offre funzionalità di replica continua durante il processo di migrazione, riducendo la possibilità di perdere dati nel nuovo cluster.
Puoi continuare a lavorare sul cluster durante la fase di pre-upgrade.	La tua applicazione subisce un tempo di inattività più lungo che inizia quando esporti i dati. Non puoi accettare scritture di database nel cluster originale finché il nuovo cluster non è completamente operativo.	La tua applicazione subisce un tempo di inattività più breve che inizia quando vuoi passare all'utilizzo del nuovo cluster.
Durante la procedura di upgrade, puoi prevedere un tempo di inattività di circa 20 minuti o più, a seconda dello schema. Dopo l'upgrade, puoi accedere al cluster con lo stesso indirizzo IP.	Hai un controllo più granulare sui dati da includere nell'esportazione e puoi scegliere di non eseguire la migrazione di determinate tabelle o altre entità.	Database Migration Service esegue automaticamente la migrazione di tutti i database presenti nelle tue istanze e di tutte le istanze nel cluster. Non puoi scegliere di escludere determinate tabelle o viste dai dati di migrazione.
	Nel cluster può essere attivata la modalità di applicazione SSL.	Ai fini della migrazione, Database Migration Service richiede di disattivare la modalità di applicazione SSL sul cluster di origine.

La sezione successiva descrive in dettaglio la procedura di esecuzione di un upgrade della versione principale, inclusa la migrazione dei dati.

Upgrade in loco della versione principale

In questo modo, l'esperienza di upgrade è fluida e non richiede la configurazione di cluster aggiuntivi. Per ulteriori informazioni, vedi Eseguire l'upgrade in loco di una versione principale del database.

Eseguire la migrazione utilizzando l'esportazione dei dati basata su file

Per utilizzare un server di database compatibile con una versione principale di PostgreSQL superiore, devi creare un cluster funzionalmente identico nella stessa regione e poi migrare i dati al suo interno.

Segui questi passaggi:

Crea un cluster configurato con la versione principale della compatibilità PostgreSQL che vuoi utilizzare. Crea il cluster nella stessa regione del cluster attuale.
Configura il nuovo cluster con la nuova versione principale in modo che corrisponda alla configurazione del cluster attuale:
1. Crea altre istanze del pool di lettura in base alle esigenze.
2. Crea cluster secondari in base alle tue esigenze.
  
  Quando crei cluster secondari, non devi specificare un numero di versione principale di PostgreSQL. AlloyDB applica la versione di PostgreSQL del cluster principale a tutti i suoi cluster secondari.
3. Aggiorna i flag del database del nuovo cluster in modo che corrispondano alle impostazioni dei flag del cluster corrente.
4. Attiva le estensioni necessarie per le tue applicazioni.
Esporta i dati dal vecchio cluster in file utilizzando psql o pg_dump.
Importa i dati dai file nel nuovo cluster.

Ora le tue applicazioni possono connettersi alle istanze del nuovo cluster ai nuovi indirizzi IP.

Eseguire la migrazione utilizzando Database Migration Service

Puoi utilizzare Database Migration Service per spostare i dati dai database PostgreSQL ai cluster AlloyDB. Database Migration Service non fornisce una configurazione dedicata specificamente alle origini dati AlloyDB, ma AlloyDB è compatibile con PostgreSQL, quindi puoi utilizzare la configurazione pensata per le origini PostgreSQL generiche.

Questo percorso di migrazione non è un upgrade in loco e comporta la creazione di un nuovo cluster con un indirizzo IP diverso. Ti consigliamo innanzitutto di clonare il cluster ed eseguire una migrazione di test per verificare se la tua applicazione è compatibile con questo approccio.

Considerazioni importanti

Prima di prepararti alla migrazione con Database Migration Service, valuta attentamente le seguenti limitazioni per assicurarti che questo percorso di migrazione sia adatto al tuo scenario di upgrade.

Limitazioni

Le connessioni SSL devono essere disattivate nel cluster di origine.
Le istanze AlloyDB configurate con Private Service Connect non sono supportate.
Durante la migrazione, non puoi eseguire aggiornamenti dell'istanza o richieste di failover sul cluster di origine. Queste operazioni possono causare l'esito negativo del job di migrazione.
A questo scenario si applicano tutte le limitazioni standard per le migrazioni da PostgreSQL ad AlloyDB. Per l'elenco completo delle altre limitazioni, consulta Limitazioni note nella documentazione di Database Migration Service.

Precisione della migrazione

Alcuni tipi di dati, come gli oggetti di grandi dimensioni, non vengono migrati. Per l'elenco completo dei dati supportati, vedi Fidelizzazione della migrazione nella documentazione di Database Migration Service.

Blocco e tempi di inattività del database di origine

Database Migration Service utilizza migrazioni continue per spostare i dati nei cluster AlloyDB. Questo tipo di migrazione comporta un breve (meno di 10 secondi) blocco delle tabelle del database di origine, una alla volta, man mano che viene creato il dump iniziale dei dati.

Al termine della migrazione, devi interrompere tutte le scritture sul database di origine prima di poter passare al nuovo cluster. Questa procedura richiede un po' di tempo di inattività. Per una panoramica più dettagliata, consulta Migrazioni continue nella documentazione di Database Migration Service.

Limitazioni della replica

Dopo che il job di migrazione passa alla fase Change Data Capture (CDC), Database Migration Service replica continuamente i nuovi dati scritti nei database di origine.

Per le tabelle senza chiavi primarie, durante la fase CDC vengono replicate solo le istruzioni INSERT. Qualsiasi azione CREATE, UPDATE o DELETE eseguita su tabelle senza chiavi primarie durante la fase CDC deve essere ricreata manualmente nel database di destinazione per evitare la perdita di dati.

Prima di iniziare

Enable the Database Migration Service API.
Enable the API

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.
  Vai a IAM
2. Seleziona il progetto.
3. Fai clic su Concedi l'accesso.
4. Nel campo Nuove entità, inserisci il tuo identificatore utente. In genere si tratta dell'indirizzo email di un Account Google.
5. Nell'elenco Seleziona un ruolo, seleziona un ruolo.
6. Per concedere altri ruoli, fai clic su Aggiungi un altro ruolo e aggiungi ogni ruolo aggiuntivo.
7. Fai clic su Salva.
Assicurati che la rete VPC nel progetto Google Cloud che stai utilizzando sia configurata per l'accesso privato ai servizi ad AlloyDB.
Decidi in quale regione vuoi creare il cluster di destinazione. Tutte le entità Database Migration Service (profili di connessione, job di migrazione) devono essere create nella stessa regione del cluster di destinazione.
Prepara un utente del database a cui vuoi connetterti al tuo cluster ed esegui le istruzioni di migrazione sui database di origine. Questo utente del database richiede un insieme specifico di autorizzazioni e ruoli. Ti consigliamo di creare un nuovo utente di database e designarlo specificamente per lo scopo di eseguire la migrazione.

Configura le istanze di origine

Database Migration Service richiede una configurazione specifica per potersi connettere e copiare i dati dal cluster di origine al nuovo cluster di destinazione.

Per configurare le istanze di origine AlloyDB, segui questi passaggi:

Configura i flag di database su ogni istanza del cluster di origine. Utilizza i seguenti valori:

Flag	Valore
`alloydb.logical_decoding`	Imposta su `on`.
`alloydb.enable_pglogical`	Imposta su `on`.
`max_replication_slots`	Questo flag definisce il numero massimo di slot di replica che l'istanza di origine può supportare. Il valore minimo per questo flag è `50`. Calcola il valore minimo utilizzando la seguente formula: `(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)` Considera un esempio in cui sono vere le seguenti condizioni: Non hai repliche di lettura nella tua origine. Hai 30 database nell'istanza dell'origine principale. Vuoi creare due job di migrazione per il cluster di origine. Vuoi utilizzare 10 slot per la replica delle tabelle. In questo caso, il numero di `max_replication_slots` deve essere almeno `70`, calcolato come `30 * 2 + 10 + 0`.
`max_wal_senders`	Imposta questo flag su un valore di almeno 10 unità superiore al valore di `max_replication_slots` più il numero di mittenti già utilizzati nella tua istanza. Ad esempio, se imposti `max_replication_slots flag` su `70` e utilizzi già 2 mittenti, `max_wal_senders` deve essere almeno `82` (calcolato come `70 + 10 + 2 = 82`).
`max_worker_processes`	Imposta questo flag almeno sul numero di database nella tua istanza più il numero di `max_worker_processes` che utilizzi già. Ad esempio, se hai 30 database nell'istanza di origine e non utilizzi alcun processo worker, imposta questo flag su `30`.

Disabilita la modalità di applicazione SSL su ogni istanza nel cluster di origine.

Configura i database di origine

Devi installare l'estensione pglogical e concedere le autorizzazioni richieste all'utente del database che designi come utente di migrazione su ogni database delle tue istanze.

Per configurare i database:

Connettiti al database postgres predefinito utilizzando il client psql.
Installa l'estensione pglogical eseguendo questo comando:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Concedi le autorizzazioni all'utente del database di migrazione su tutti gli schemi ad eccezione di quello information e degli schemi i cui nomi iniziano con il prefisso pg_. Esegui le seguenti istruzioni:
```
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;
```
Sostituisci quanto segue:
- SCHEMA_NAME: il nome di uno schema presente nel tuo database
- USER_NAME: il nome dell'utente del database che hai preparato nella sezione Prima di iniziare
Ripeti questo passaggio per ogni schema del database ad eccezione di information e degli schemi i cui nomi iniziano con il prefisso pg_. Puoi elencare tutti gli schemi di database con il meta-comando \dn.
Concedi le autorizzazioni richieste rimanenti. Esegui le seguenti istruzioni:
```
GRANT USAGE on SCHEMA pglogical to PUBLIC;
GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER_NAME;
ALTER USER USER_NAME with REPLICATION;
```
Sostituisci USER_NAME con il nome dell'utente del database che hai preparato nella sezione Prima di iniziare.
Connettiti a ogni altro database nella tua istanza e ripeti i passaggi 2, 3 e 4.
- Puoi elencare tutti i database nella tua istanza con il meta-comando \list.
- Puoi passare a un altro database senza reimpostare la connessione del client psql utilizzando il comando \connect {database_name_here}.
Ripeti questa procedura per ogni istanza nel cluster AlloyDB di origine.

Esegui la migrazione in Database Migration Service