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

Questa pagina descrive in dettaglio la procedura 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, consulta Creare un cluster e la relativa istanza principale.

Compatibilità tra cluster e versione di PostgreSQL

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

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

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

Esistono diversi metodi per eseguire gli upgrade delle versioni principali del cluster:

Un upgrade della versione principale in loco, che ti consigliamo di utilizzare.
Eseguire la migrazione dei dati con un'esportazione dei dati basata su file.
Utilizzare 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 della versione principale in loco	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 database.	Database Migration Service offre funzionalità di replica continua durante il processo di migrazione, riducendo la probabilità 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 in le istanze e di tutte le istanze del cluster. Non puoi scegliere di escludere determinate tabelle o viste dai dati di migrazione.
	Il cluster può avere la modalità di applicazione SSL abilitata.	Ai fini della migrazione, Database Migration Service richiede di disabilitare la modalità di applicazione SSL nel cluster di origine.

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

Upgrade della versione principale in loco

Questa opzione offre un'esperienza di upgrade senza interruzioni senza richiedere la configurazione di cluster aggiuntivi. Per saperne di più, consulta Eseguire l'upgrade della versione principale di un database in loco.

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

Per utilizzare un server di database compatibile con una versione principale superiore di PostgreSQL, devi creare un cluster funzionalmente identico nella stessa regione e poi eseguire la migrazione dei dati.

Segui questi passaggi:

Crea un cluster configurato con la versione principale di PostgreSQL con cui vuoi la compatibilità. 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, se necessario.
2. Crea cluster secondari, se necessario.
  
  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 cluster secondari.
3. Aggiorna i flag del database del nuovo cluster in modo che corrispondano alle impostazioni dei flag del cluster attuale.
4. Abilita 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 ora 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 prevista 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 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, esamina 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.
Non puoi eseguire aggiornamenti delle istanze o richieste di failover sul cluster di origine durante la migrazione. 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 a questo scenario. 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 sottoposti a migrazione. Per l'elenco completo dei dati supportati, consulta Precisione della migrazione nella documentazione di Database Migration Service.

Blocco e tempi di inattività del database di origine

Database Migration Service utilizza le 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 iniziale dei dati.

Al termine della migrazione, devi interrompere tutte le scritture nel database di origine prima di poter passare all'utilizzo del 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. Per evitare la perdita di dati, le azioni CREATE, UPDATE o DELETE eseguite sulle tabelle senza 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.
Ruoli richiesti per abilitare le API
Per abilitare le API, devi disporre del ruolo IAM Amministratore utilizzo servizi (roles/serviceusage.serviceUsageAdmin), che contiene l'autorizzazione serviceusage.services.enable. Scopri come concedere i ruoli.
Abilitare l'API

Assicurati di disporre dei seguenti ruoli nel progetto:
- Uno dei seguenti:
  - Cloud AlloyDB > Amministratore Cloud AlloyDB
  - Di base > Proprietario
  - Di base > Editor
- Devi anche disporre dell'autorizzazione compute.networks.list nel Google Cloud progetto che stai utilizzando. Per ottenere questa autorizzazione seguendo il principio del privilegio minimo, chiedi all'amministratore di concederti il ruolo Compute Engine > Utente rete Compute (roles/compute.networkUser).
- Amministratore migrazione del database
Controlla i ruoli
1. Nella Google Cloud console vai alla pagina IAM.
  Vai a IAM
2. Seleziona il progetto.
3. Nella colonna Entità, trova tutte le righe che identificano te o un gruppo di cui fai parte. Per scoprire i gruppi di cui fai parte, 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 Google Cloud console 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 aggiuntivo.
7. Fai clic su Salva.
Assicurati che la rete VPC nel Google Cloud progetto che stai utilizzando sia configurata per l'accesso privato ai servizi per 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 di database a cui vuoi connetterti al tuo cluster ed esegui le istruzioni di migrazione sui database di origine. Questo utente di database richiede un insieme specifico di autorizzazioni e ruoli. Ti consigliamo di creare un nuovo utente di database e di designarlo specificamente per eseguire la migrazione.

Configurare 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:

Configura i flag del 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 nell'origine. Hai 30 database nell'istanza di origine principale. Vuoi creare 2 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 superiore al `max_replication_slots` valore più il numero di sender già utilizzati nell'istanza. Ad esempio, se imposti il `max_replication_slots flag` su `70` e utilizzi già 2 sender, allora `max_wal_senders` deve essere almeno `82` (calcolato come `70 + 10 + 2 = 82`).
`max_worker_processes`	Imposta questo flag su un valore pari almeno al numero di database nell'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 del cluster di origine.

Configurare i database di origine

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

Per configurare i database:

Connettiti al database postgres predefinito utilizzando il client psql.
Installa l'estensione pglogical eseguendo il seguente comando:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Concedi le autorizzazioni all'utente di database di migrazione su tutti gli schemi tranne lo schema information e gli 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 di database che hai preparato nella sezione Prima di iniziare
Ripeti questo passaggio per ogni schema del database tranne lo schema information e gli schemi i cui nomi iniziano con il prefisso pg_. Puoi elencare tutti gli schemi di database con il \dn meta-comando.
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 di database che hai preparato nella sezione Prima di iniziare.
Connettiti a tutti gli altri database dell'istanza e ripeti i passaggi 2, 3 e 4.
- Puoi elencare tutti i database dell'istanza con il \list meta-comando.
- Puoi passare a un altro database senza reimpostare la connessione del client psql utilizzando il \connect {database_name_here} comando.
Ripeti questa procedura per ogni istanza del cluster AlloyDB di origine.

Eseguire la migrazione in Database Migration Service