Estensioni e oggetti di replica logica da esaminare

Prima di procedere all'aggiornamento, verificare i seguenti punti:

pg_repack

Eliminare la directory pg_repack prima dell'aggiornamento e ricrearla dopo l'aggiornamento. pg_repack utilizza un'estensione specifica per la versione e componenti client/server che devono corrispondere alla versione principale di PostgreSQL.

DROP EXTENSION pg_repack;

Ricrea l'estensione dopo l'aggiornamento solo se il tuo carico di lavoro lo richiede ancora.

CREATE EXTENSION pg_repack;

old_snapshot

Prima dell'aggiornamento, eliminare la cartell old_snapshot. PostgreSQL NON ricrearlo dopo l'aggiornamento a Windows 18, poiché non è più supportato.

DROP EXTENSION old_snapshot;

wal2json slot di replica

Se si utilizza " wal2json " per la decodifica logica, è necessario eliminare tutti gli slot di replica associati prima dell'aggiornamento. L'utilità pg_upgrade vieta categoricamente l'aggiornamento alla versione principale finché sono presenti slot di replica; in tal caso, genererà un errore critico e interromperà l'aggiornamento.

Prima dell'aggiornamento:

1. Assicurarsi che tutti i dati WAL in sospeso siano stati elaborati.
2. Chiudi l'applicazione che utilizza lo slot di replica.
3. Eliminare gli slot di replica:

SELECT pg_drop_replication_slot('your_slot_name');

Dopo l'aggiornamento, è possibile ricreare gli slot di replica secondo necessità. Si noti che wal2json non viene installato tramite CREATE EXTENSION, ma viene configurato tramite i parametri del database (wal_level, max_replication_slots, max_wal_senders) e le autorizzazioni delle tabelle, che non impediscono gli aggiornamenti.

anon

Rimuovi l'estensione " anon " prima dell'aggiornamento e riattivala dopo l'aggiornamento, se ne hai ancora bisogno. Prima di disattivare anon sono necessari alcuni passaggi aggiuntivi.

Se è installata l'estensione " anon ", seguire la procedura riportata di seguito ed eseguire i comandi come utente amministratore prima di procedere all'aggiornamento.

1. Rimuovere tutte le regole di mascheramento (se abilitate).

   SELECT anon.remove_masks_for_all_columns();
   

2. Disattivare il mascheramento dei ruoli (l'aggiornamento potrebbe fallire se alcuni ruoli sono contrassegnati come mascherati).

   SECURITY LABEL FOR anon ON ROLE <role_name> IS NULL;
   

3. Eliminare l'estensione anon con l'opzione cascata.

   DROP EXTENSION anon CASCADE;
   

4. Se l'estensione " anon " è installata in più database all'interno di un'istanza, eseguire i passaggi indicati per ciascun database.

5. Al termine dell'aggiornamento, riabilitare l'estensione anon e riapplicare le regole di mascheramento come richiesto.

Si consiglia vivamente di convalidare i dati prima e dopo aver eliminato l'estensione per garantire la coerenza del mascheramento prima di eseguire l'aggiornamento.

PostGIS

Se utilizzi PostGIS,, esegui prima l'aggiornamento di PostGIS prima di aggiornare PostgreSQL.

SELECT postgis_extensions_upgrade();

Utilizzare la seguente query per convalidare l'aggiornamento dell'estensione PostGIS.

SELECT postgis_full_version();

Logical replication slots

Eliminare tutti gli slot di replica logica prima dell'aggiornamento e ricrearli dopo l'aggiornamento. Gli slot logici sono legati allo stato del server di origine e devono essere ricreati da zero sull'istanza aggiornata.

SELECT pg_drop_replication_slot('<slot_name>');

Prima di iniziare

Prima di avviare la procedura di aggiornamento, considerare i seguenti aspetti.

• Verifica se è disponibile un aggiornamento per la versione della tua distribuzione controllando le informazioni sulle funzionalità di distribuzione tramite l'interfaccia utente, l'API, la CLI o Terraform.

  Esempio: come consultare le informazioni sull'aggiornamento della versione tramite CLI:

  ibmcloud cdb capability-show versions postgresql
  

• Assicurati di consultare i requisiti relativi al precheck descritti in questa sezione prima di avviare l'IPU. IPU viene eseguito direttamente sull'ambiente di origine e non crea una nuova istanza. Per garantire la sicurezza dei clienti, il servizio esegue dei controlli preliminari prima dell'avvio dell'aggiornamento e blocca l'operazione qualora venga rilevato un rischio. In particolare, verificare i seguenti punti:

  • La tua distribuzione conta al massimo 3 membri.
  • La tua distribuzione è in buono stato.
  • La tua distribuzione dispone di almeno il 10% di spazio libero su disco. L'utilizzo massimo consentito di default del disco per i controlli preliminari IPU è pari al 90%.
  • La tua distribuzione non è sottoposta a un carico elevato di operazioni di I/O. Il valore predefinito massimo consentito per l'utilizzo dell'I/O nel precheck dell'IPU è del 90%.
  • Le dimensioni dello schema e il numero di oggetti rientrano nelle soglie predefinite del controllo preliminare. Per impostazione predefinita, nessun singolo schema può superare i 100 GB e il numero totale di indici e sequenze deve rimanere inferiore a 50.000.
  • Prima dell'aggiornamento, hai completato tutte le operazioni necessarie di pulizia delle estensioni e degli slot di replica logica.

• Ogni versione principale contiene alcune funzionalità che potrebbero non essere retrocompatibili con le versioni precedenti. Controlla le note di rilascio fornite dal fornitore del database per verificare se ci sono modifiche che potrebbero influire sulle tue applicazioni.

• Il downgrade di una distribuzione a una versione precedente non è supportato.

• Una volta avviato, l'aggiornamento alla versione principale in loco non può essere annullato.

• Se non disponi di un backup recente, ti consigliamo di crearne uno prima di procedere all'aggiornamento.

Si noti inoltre che, una volta completato l'aggiornamento, il database funzionerà con una nuova versione principale di PostgreSQL. Poiché PostgreSQL memorizza i dati in formati specifici per ciascuna versione, i backup e i punti PITR precedenti all'aggiornamento appartengono alla cronologia della versione precedente e non possono essere ripristinati nella versione aggiornata. Per garantire il ripristino completo e le funzionalità PITR (Point-in-Time Recovery) nella nuova versione, eseguire un nuovo backup subito dopo il completamento dell'aggiornamento. Quel backup diventa il punto di riferimento per le future operazioni di ripristino sulla linea temporale della nuova versione.

Se l'IPU non dovesse funzionare, è comunque possibile utilizzare i backup validi precedenti all'aggiornamento con la funzione PITR per ripristinare la versione precedente di PostgreSQL su una nuova istanza.

Risoluzione dei problemi

Se le tue applicazioni presentano problemi imprevisti dopo un aggiornamento alla versione principale in loco riuscito e devi tornare alla versione PostgreSQL precedente, contatta il nostro team di assistenza per ricevere assistenza. Si raccomanda di non avviare autonomamente una procedura PITR né di ripristinare un backup, poiché ciò potrebbe complicare il processo di ripristino.

Un aggiornamento importante in loco non verrà eseguito finché tutti i controlli preliminari non saranno stati superati. Queste misure di sicurezza sono state predisposte per proteggere la tua distribuzione, poiché l'aggiornamento viene eseguito direttamente sull'istanza di origine. Se l'aggiornamento è bloccato, controlla le seguenti aree:

• Numero di membri: l'aggiornamento della versione principale in loco supporta distribuzioni con un massimo di 3 membri. Se la tua distribuzione conta più di 3 membri, i controlli preliminari bloccano l'aggiornamento. I membri non possono essere rimossi tramite il ridimensionamento orizzontale, pertanto è necessario aprire un ticket di assistenza presso il supporto di IBM Cloud per ridurre il numero di membri prima di riprovare ad eseguire l'aggiornamento.
• Stato del cluster: assicurarsi che il cluster Patroni sia in buono stato e che vi sia una chiara distinzione tra leader e repliche. Gli aggiornamenti non possono essere eseguiti se Patroni segnala condizioni di instabilità o failover.
• Spazio su disco: verificare che sia disponibile spazio libero sufficiente. Il processo utilizza la pg_upgrade modalità link, che richiede un headroom adeguato. Se l'utilizzo del disco supera il limite configurato (impostazione predefinita: 90%), liberare spazio prima di riprovare.
• Carico I/O del disco: verificare l'utilizzo corrente dell'I/O e gli IOPS. Gli aggiornamenti vengono sospesi quando il sistema è sottoposto a un carico elevato, al fine di evitare un calo delle prestazioni o il fallimento dell'aggiornamento.
• Dimensioni dello schema e numero di oggetti: come già detto, le dimensioni dello schema influiscono direttamente sulla durata di un aggiornamento maggiore in loco. Assicurarsi che nessuno schema individuale superi la dimensione massima (impostazione predefinita: 100 GB) e che il numero totale di oggetti indice e sequenza rimanga al di sotto del limite (impostazione predefinita: 50.000). Schemi di grandi dimensioni o un numero di oggetti insolitamente elevato potrebbero richiedere una pulizia o un'ottimizzazione prima di procedere con l'aggiornamento. pg_upgrade esegue aggiornamenti rapidi creando nuove tabelle di sistema e riutilizzando semplicemente i vecchi file di dati utente. Il tempo necessario per creare queste tabelle di sistema varia in base al numero di oggetti del database. Il consumo delle risorse può essere valutato utilizzando l 'integrazione del monitoraggio. Se non tutti i componenti del database sono disponibili per l'aggiornamento, l'operazione di aggiornamento non va a buon fine. Questo può verificarsi a causa della manutenzione. Le attività che non sono state completate a causa di controlli di integrità non riusciti possono essere riprovate in un secondo momento. Se l'operazione continua a non riuscire, apri un ticket di assistenza con IBM Cloud support. Se alcuni controlli non sono rilevanti per il tuo ambiente e l'aggiornamento è ancora bloccato, crea un ticket di assistenza per ulteriore supporto.

Esecuzione a secco della promozione e dell'aggiornamento

Per valutare gli effetti degli aggiornamenti delle versioni principali, attivare una prova a secco. Una esecuzione a secco simula la promozione e l'aggiornamento, con i risultati stampati nei log del database. Accedete e visualizzate i registri del vostro database attraverso l'integrazione Analisi dei registri. Ciò garantisce che la versione che si sta attualmente eseguendo con le relative estensioni possa essere aggiornata correttamente alla versione desiderata.

L'esecuzione a secco deve essere eseguita con skip_initial_backup impostato su false e version definito.

Il comando è simile al seguente:

curl -X POST \
  https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/remotes/promotion \
  -H 'Authorization: Bearer <>'  \
 -H 'Content-Type: application/json' \
 -d '{
    "promotion": {
        "version": "14",
        "skip_initial_backup": false,
        "dry_run": true
    }
}' \