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

Questa pagina descrive in dettaglio la procedura di AlloyDB per PostgreSQL per aggiornare le versioni del server database e spiega come eseguire la migrazione dei dati a un cluster compatibile con una versione successiva di PostgreSQL.

Per ulteriori informazioni su come creare un cluster, consulta Creare un cluster e la relativa istanza principale.

Cluster e compatibilità delle versioni PostgreSQL

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

AlloyDB esegue upgrade automatici delle versioni secondarie del database durante la manutenzione periodica. Ad esempio, se hai creato un cluster con compatibilità 15, AlloyDB mantiene aggiornato il database alla versione secondaria più recente di 15.

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

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

  1. Un upgrade in place della versione principale che consigliamo di utilizzare.
  2. Eseguire la migrazione dei dati con un'esportazione dei dati basata su file.
  3. 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
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 dati mancanti nel nuovo cluster.
Puoi continuare a lavorare sul cluster durante la fase di pre-upgrade. L'applicazione presenta un tempo di riposo più lungo che inizia quando esportate i dati. Non puoi accettare le scritture nel database nel cluster originale fino a quando il nuovo cluster non è completamente operativo. Il tempo di riposo dell'applicazione è più breve e inizia quando vuoi impostare l'utilizzo del nuovo cluster.
Durante la procedura di upgrade, puoi prevedere un tempo di riposo di circa 20 minuti o più, a seconda dello schema. 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 cluster. Non puoi scegliere di escludere determinate tabelle o visualizzazioni dai dati di migrazione.
Nel cluster può essere attivata la modalità di applicazione SSL. Per la migrazione, Database Migration Service richiede di disattivare la modalità di applicazione SSL nel cluster di origine.


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

Upgrade in loco della versione principale

In questo modo, l'upgrade avviene senza problemi e non è richiesta la configurazione di cluster aggiuntivi. Per ulteriori informazioni, vedi Eseguire l'upgrade in situ di una versione principale del database.

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

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

Segui questi passaggi:

  1. Crea un cluster configurato con la versione principale della compatibilità PostgreSQL che vuoi utilizzare. Crea il cluster nella stessa regione del cluster attuale.

  2. Configura il nuovo cluster con la nuova versione principale in modo che corrisponda alla configurazione del cluster corrente:

    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 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 corrente.

    4. Attiva tutte le estensioni di cui hanno bisogno le tue applicazioni.

  3. Esportare i dati dal vecchio cluster in file utilizzando psql o pg_dump.

  4. Importa i dati dai file nel nuovo cluster.

Ora le tue applicazioni possono connettersi alle istanze del nuovo cluster ai relativi 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 per le 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 situ e comporta la creazione di un nuovo cluster con un indirizzo IP diverso. Ti consigliamo innanzitutto di clonare il cluster e di eseguire una migrazione di prova 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.
  • Non puoi eseguire aggiornamenti delle istanze o richieste di failover sul cluster di origine durante la migrazione. Queste operazioni possono causare il fallimento 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
Per alcuni tipi di dati, come gli oggetti di grandi dimensioni, non viene eseguita la migrazione. Per l'elenco completo dei dati supportati, consulta Precisione della migrazione nella documentazione di Database Migration Service.
Blocco e tempo di riposo 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 dei dati iniziali.

Al termine della migrazione, devi interrompere tutte le scritture sul database di origine prima di poter spostare l'applicazione nel nuovo cluster. Questa procedura richiede un breve 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 di rilevamento dei dati modificati (CDC), Database Migration Service esegue la replica continua dei nuovi dati scritti nei database di origine.

Per le tabelle senza chiavi primarie, solo le istruzioni INSERT vengono replicate durante la fase CDC. Eventuali 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

  1. Enable the Database Migration Service API.

    Enable the API

  2. 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 accesso.

    4. Nel campo Nuovi principali, 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.
    8. Assicurati che la rete VPC nel progetto Google Cloud che stai utilizzando sia configurata per l'accesso privato ai servizi ad AlloyDB.
    9. 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.
    10. Prepara un utente del database che vuoi connettere al tuo cluster ed esegui 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 di designarlo specificamente per 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:

    1. Configura i flag di database su ogni istanza del cluster di origine. Utilizza i seguenti valori:
      Bandiera Valore
      alloydb.logical_decoding Impostato su on.
      alloydb.enable_pglogical Impostato su on.
      max_replication_slots Questo flag definisce il numero massimo di slot di replica supportati dall'istanza di origine. Il valore minimo per questo indicatore è 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 nel tuo codice sorgente.
      • 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 debe essere almeno 70, calcolato come 30 * 2 + 10 + 0.
      max_wal_senders Imposta questo flag su un valore almeno 10 superiore al valore 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 su almeno il 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 di lavoro, imposta questo flag su 30.
    2. Disattiva la modalità di applicazione 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:

    1. Connettiti al database postgres predefinito utilizzando il client psql.

    2. Installa l'estensione pglogical eseguendo il seguente comando:

      CREATE EXTENSION IF NOT EXISTS pglogical;

    3. Concedi le autorizzazioni all'utente del 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 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 tranne lo schema information e gli schemi i cui nomi iniziano con il prefisso pg_. Puoi elencare tutti gli schemi di database con il metacomando \dn.

    4. 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.

    5. Connettiti a tutti gli altri database dell'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 del client psql utilizzando il comando \connect {database_name_here}.

    6. Ripeti questa procedura per ogni istanza nel cluster AlloyDB di origine.

    Esegui la migrazione in Database Migration Service

    Segui questi passaggi:

    1. Crea un profilo di connessione di origine per il tuo cluster AlloyDB. Utilizza i seguenti valori:

      • Motore del database: seleziona PostgreSQL.
      • Nome host/IP: utilizza l'indirizzo IP dell'istanza principale del cluster.
      • Nome utente/password: inserisci le credenziali per l'utente del database che hai preparato nella sezione Prima di iniziare.
      • Porta: inserisci 5432.
      • Regione: seleziona la regione in cui si trova il cluster di destinazione.
      • Tipo di crittografia: seleziona Nessuna.

    2. Crea ed esegui il job di migrazione.

      Puoi creare il nuovo cluster AlloyDB in anticipo o lasciare che sia Database Migration Service a crearlo durante la configurazione del job di migrazione. Per ulteriori informazioni, consulta Panoramica dei job di migrazione nella documentazione di Database Migration Service.

      Se vuoi che sia Database Migration Service a creare il cluster di destinazione durante la configurazione del job di migrazione, segui i passaggi descritti nella procedura Creare un job di migrazione in una nuova istanza di destinazione.

      Se vuoi creare il cluster di destinazione all'esterno di Database Migration Service, segui i passaggi descritti nella procedura Creare un job di migrazione in un'istanza di destinazione esistente.

    3. Quando lo stato del job di migrazione diventa CDC, promuovi il job di migrazione. Puoi controllare lo stato del job di migrazione nella pagina Panoramica della migrazione. Consulta Esaminare un job di migrazione nella documentazione di Database Migration Service.

      Questa azione fa uscire il cluster di destinazione dalla modalità di bootstrap, ovvero il cluster AlloyDB di destinazione non è più in stato di sola lettura.

    4. (Facoltativo) Controlla se mancano istruzioni nelle tabelle che non hanno chiavi primarie.

      Se i database AlloyDB di origine contengono tabelle che non hanno chiavi primarie, potrebbe essere necessario eseguire manualmente la migrazione delle eventuali istruzioni UPDATE o DELETE mancanti. Consulta Eseguire la migrazione delle operazioni UPDATE e DELETE per le chiave primaria non primarie nella documentazione di Database Migration Service.

    5. Passa l'applicazione al nuovo cluster. Ora le tue applicazioni possono connettersi alle istanze del nuovo cluster ai relativi nuovi indirizzi IP.