Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

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

L'upgrade del cluster AlloyDB per PostgreSQL a una versione principale successiva di PostgreSQL ti consente di utilizzare le funzionalità, i miglioramenti delle prestazioni e gli aggiornamenti della sicurezza più recenti del database. Puoi eseguire l'upgrade della versione principale di un cluster in loco o eseguendo la migrazione dei dati a un cluster che esegue una versione di PostgreSQL successiva.

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

Compatibilità delle versioni dei cluster e di PostgreSQL

Quando crei un cluster AlloyDB, scegli la versione principale di PostgreSQL compatibile con le istanze del cluster. Per impostazione predefinita, questo valore è 17.

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

Tuttavia, l'upgrade della versione principale di PostgreSQL richiede la pianificazione, il test e l'esecuzione dell'upgrade da parte tua.

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

Un upgrade della versione principale in loco, che consigliamo di utilizzare.
Migrazione dei dati con un'esportazione dati basata su file.
.

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 della versione principale in loco	Esportazione dei dati basata su file	Migrazione con Database Migration Service
Viene eseguito l'upgrade del cluster, incluse le istanze di lettura, alla versione principale successiva scelta.	Le esportazioni basate su file spostano uno snapshot 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.	L'applicazione subisce un tempo di inattività più lungo che inizia quando esporti i dati. Non puoi accettare scritture nel database nel cluster originale finché il nuovo cluster non è completamente operativo.	L'applicazione subisce un tempo di inattività più breve che inizia quando vuoi cambiare l'applicazione per utilizzare il nuovo cluster.
A seconda dello schema, il tempo di inattività durante il processo di upgrade può essere di circa 20 minuti o più. Dopo l'upgrade, puoi accedere al cluster con lo stesso indirizzo IP.	Hai un maggiore controllo 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 tuo cluster. Non puoi scegliere di escludere determinate tabelle o visualizzazioni dai dati di migrazione.
Il cluster può avere la modalità di applicazione forzata SSL abilitata.	Il cluster può avere la modalità di applicazione forzata SSL abilitata.	Ai fini della migrazione, Database Migration Service richiede di disattivare la modalità di applicazione forzata di SSL sul cluster di origine.

La sezione successiva descrive in dettaglio il processo di upgrade della versione principale, inclusa la migrazione dei dati.

Upgrade della versione principale in loco

Un upgrade in loco aggiorna il cluster esistente senza richiedere la configurazione di altri cluster. Per saperne di più, consulta Esegui l'upgrade della versione principale in loco di un database.

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

Per utilizzare un server di database compatibile con una versione principale di PostgreSQL successiva, devi creare un cluster funzionalmente identico nella stessa regione, quindi eseguire la migrazione dei dati al suo interno.

Segui questi passaggi:

Crea un cluster configurato con la versione principale di compatibilità con 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 tue esigenze.
2. Crea cluster secondari in base alle esigenze.
  
  Quando crei cluster secondari, non è necessario 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 di database del nuovo cluster in modo che corrispondano alle impostazioni dei flag del cluster attuale.
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.

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

Esegui 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 destinata alle 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 di clonare prima 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 istanze AlloyDB configurate con Private Service Connect non sono supportate.
Durante la migrazione, non puoi eseguire aggiornamenti delle istanze o richieste di failover sul cluster di origine. Queste operazioni possono causare l'errore 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, consulta Fedeltà 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 blocco (meno di 10 secondi) delle tabelle del database di origine, una alla volta, durante la creazione del dump dei dati iniziale.

Al termine della migrazione, devi interrompere tutte le scritture sul database di origine prima di poter passare l'applicazione 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. Tutte le azioni CREATE, UPDATE o DELETE eseguite su tabelle che non hanno chiavi primarie durante la fase CDC devono essere ricreate manualmente nel database di destinazione per evitare la perdita di dati.

Prima di iniziare

Abilita l'API Database Migration Service, se non è già abilitata.
Ruoli richiesti per abilitare le API
Per abilitare le API, devi disporre dell'autorizzazione serviceusage.services.enable. Se hai creato il progetto, probabilmente hai già questa autorizzazione tramite il ruolo Proprietario (roles/owner). In caso contrario, puoi ottenere questa autorizzazione tramite il ruolo Amministratore Service Usage (roles/serviceusage.serviceUsageAdmin). Scopri come concedere i ruoli.
Abilitare l'API

Assicurati di disporre dei seguenti ruoli nel progetto:
- Uno dei seguenti:
  - AlloyDB > AlloyDB Admin
  - Di base > Proprietario
  - Di base > Editor
- Devi anche disporre dell'autorizzazione compute.networks.list nel progetto Google Cloud che stai utilizzando. Per ottenere questa autorizzazione seguendo il principio del privilegio minimo, chiedi all'amministratore di concederti il ruolo Compute Engine > Utente di rete Compute (roles/compute.networkUser).
- Database Migration Admin
Controlla i ruoli
1. Nella console Google Cloud vai alla pagina IAM.
  Vai a IAM
2. Seleziona il progetto.
3. Nella colonna Entità, individua tutte le righe che identificano te o un gruppo di cui fai parte. Per scoprire in quali gruppi sei incluso, contatta l'amministratore.
4. Per tutte le righe che ti specificano o ti includono, controlla la colonna Ruolo per verificare se l'elenco dei ruoli include i ruoli richiesti.
Concedi i ruoli
1. Nella console Google Cloud vai alla pagina IAM.
  Vai a IAM
2. Seleziona il progetto.
3. Fai clic su Concedi l'accesso.
4. Nel campo Nuove entità, inserisci il tuo identificatore dell'utente. In genere si tratta dell'indirizzo email di un Account Google.
5. Fai clic su Seleziona un ruolo, quindi cerca il ruolo.
6. Per concedere altri ruoli, fai clic su Aggiungi un altro ruolo e aggiungi ogni ruolo successivo.
7. Fai clic su Salva.
Assicurati che la rete Virtual Private Cloud (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à di Database Migration Service (profili di connessione, job di migrazione) devono essere create nella stessa regione del cluster di destinazione.
Prepara un utente del database che vuoi connettere 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 del database e di designarlo specificamente per l'esecuzione della 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`	Da impostare su `on`.
`alloydb.enable_pglogical`	Da impostare 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 that you use for your read replicas)` Considera un esempio in cui: Non hai repliche di lettura nell'origine. Hai 30 database nell'istanza di 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 superiore di almeno 10 rispetto al valore `max_replication_slots` più il numero di mittenti già utilizzati nell'istanza. Ad esempio, se imposti il flag `max_replication_slots` 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 su un valore almeno pari al 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 processi worker, imposta questo flag su `30`.

Disabilita la modalità di applicazione forzata SSL su ogni istanza del 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, segui questi passaggi:

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 dello schema 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 dello schema information e degli schemi i cui nomi iniziano con il prefisso pg_. Puoi elencare tutti gli schemi del database con il metacomando \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 nell'istanza e ripeti i passaggi 2, 3 e 4.
- Puoi elencare tutti i database della tua istanza con il metacomando \list.
- Puoi passare a un altro database senza reimpostare la connessione client psql utilizzando il comando \connect DATABASE_NAME.
Ripeti questa procedura per ogni istanza del cluster AlloyDB di origine.

Esegui la migrazione in Database Migration Service