Come eseguire un aggiornamento della versione principale di RDS per PostgreSQL

Disponibile gruppo di parametri compatibile con la versione – Se si sta utilizzando un gruppo di parametri personalizzato, sono disponibili due opzioni. È possibile specificare un gruppo di parametri predefinito per la nuova versione del motore database. Oppure è possibile creare un gruppo di parametri personalizzato per la nuova versione del motore database. Per ulteriori informazioni, consultare Gruppi di parametri per RDS e Utilizzo di gruppi di parametri cluster di database per cluster database Multi-AZ.

Verifica della presenza di classi di database non supportate: verifica che la classe di istanza del database sia compatibile con la versione PostgreSQL a cui si sta eseguendo l'aggiornamento. Per ulteriori informazioni, consulta Motori DB supportati per classi di istanza database.

Controllare l'utilizzo non supportato:

Verifica la presenza di database non validi:

Per ulteriori informazioni sui database non validi, vedere Comprensione del comportamento dell'autovacuum con database non validi.

Gestione degli slot di replica logica: non è possibile eseguire un aggiornamento se il database dispone di slot di replica logica. Gli slot di replica logica vengono generalmente utilizzati per la migrazione AWS DMS e la replica di tabelle dal database a data lake, strumenti di BI e altre destinazioni. Prima di eseguire l'aggiornamento, assicurati di conoscere lo scopo di qualsiasi slot di replica logica in uso e verifica che sia corretto eliminarli. Se gli slot di replica logica sono ancora in uso, non devono essere eliminati e non è possibile procedere con l'aggiornamento.

Se gli slot di replica logica non sono necessari, è possibile eliminarli utilizzando il seguente SQL:

SELECT * FROM pg_replication_slots WHERE slot_type NOT LIKE 'physical';
SELECT pg_drop_replication_slot(slot_name);

È inoltre necessario rimuovere gli slot nelle configurazioni di replica logica che utilizzano l'estensione pglogical per un corretto aggiornamento della versione principale. Per informazioni su come identificare e rimuovere gli slot creati utilizzando l'estensione pglogical, consulta Gestione degli slot di replica logica per Postgre per Postgre SQL.

Gestione delle repliche di lettura: un aggiornamento di un'istanza database single-AZ o di una implementazione multi-AZ di un'istanza database aggiorna anche le repliche di lettura nella regione assieme all'istanza database primaria. Amazon RDS non aggiorna le repliche di lettura del cluster database multi-AZ.

Non è possibile aggiornare le repliche di lettura separatamente. Se fosse consentito, si potrebbero verificare situazioni in cui i database primari e di replica hanno versioni principali PostgreSQL diverse. Tuttavia, gli aggiornamenti delle repliche di lettura potrebbero aumentare i tempi di inattività sull'istanza database primaria. Per impedire un aggiornamento della replica di lettura, promuovi la replica a un'istanza autonoma o eliminala prima di avviare il processo di aggiornamento.

Il processo di aggiornamento ricrea il gruppo di parametri della replica di lettura in base al gruppo di parametri corrente della replica de lettura. Puoi applicare un gruppo di parametri personalizzato a una replica di lettura solo dopo il completamento dell'aggiornamento modificando la replica di lettura. Per ulteriori informazioni sulle repliche di lettura, consulta Utilizzo delle repliche di lettura per Amazon RDS per PostgreSQL.

Gestisci le integrazioni zero-ETL: se disponi di un'integrazione zero-ETL esistente, eliminala prima di eseguire un aggiornamento della versione principale. Quindi, dopo aver completato l'aggiornamento, ricrea l'integrazione.

Eseguire un backup – Si consiglia di eseguire un backup prima di eseguire un aggiornamento della versione principale in modo da avere un punto di ripristino noto per il database. Se il periodo di conservazione dei backup è maggiore di 0, il processo di aggiornamento crea snapshot database del database prima e dopo un aggiornamento. Per cambiare il periodo di conservazione dei backup, consulta Modifica di un'istanza Amazon RDS DB e Modifica di un cluster DB Multi-AZ per Amazon RDS.

Per eseguire un backup manuale, consulta Creazione di uno snapshot DB per un'istanza DB Single-AZ per Amazon RDS e Creazione di uno snapshot del cluster DB Multi-AZ per Amazon RDS.

Aggiorna determinate estensioni prima dell'aggiornamento della versione principale: se intendi ignorare una versione principale durante l'aggiornamento, è necessario aggiornare alcune estensioni prima di eseguire l’aggiornamento della versione principale. Ad esempio, l'aggiornamento dalle versioni 9.5.x o 9.6.x alla versione 11.x salta una versione principale. Le estensioni da aggiornare includono PostGIS e le relative estensioni per l'elaborazione dei dati spaziali.

Non è possibile eseguire l'aggiornamento diretto alla versione 17 di PostgreSQL se si rdkit utilizza la versione 4.6.0 e precedenti e PostgreSQL versione 16 e precedenti, a causa di incompatibilità. rdkit Di seguito sono elencate le opzioni di aggiornamento:

Esegui il comando seguente per ogni estensione in uso:

ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';

Per ulteriori informazioni, consulta Aggiornamento delle SQL estensioni Postgre nei database Postgre RDS SQL. Per ulteriori informazioni sull'aggiornamento di PostGIS, consulta Passaggio 6: Aggiorna l'GISestensione Post.

Rimuovere alcune estensioni prima dell'aggiornamento alla versione principale – Un aggiornamento che ignora una versione principale per passare direttamente alla versione 11.x non supporta l'aggiornamento dell'estensione pgRouting. L'aggiornamento dalle versioni 9.4.x, 9.5.x o 9.6.x alle versioni 11.x ignora una versione principale. È possibile rimuovere senza conseguenze l'estensione pgRouting e reinstallarla con una versione compatibile dopo l'aggiornamento. Per le versioni dell'estensione aggiornabili, consultare Versioni di estensione Postgre SQL supportate.

Le estensioni tsearch2 e chkpass non sono più supportate per PostgreSQL 11 o versioni successive. Se si esegue l'aggiornamento alla versione 11.x, rimuovere le estensioni tsearch2 e chkpass prima dell'aggiornamento.

Eliminare tipi di dati sconosciuti – Eliminare i tipi di dati unknown a seconda della versione di destinazione.

PostgreSQL versione 10 ha smesso di supportare il tipo di dati unknown. Se un database versione 9.6 utilizza il tipo di dati unknown, un aggiornamento a una versione 10 mostra un messaggio di errore del tipo seguente:

Database instance is in a state that cannot be upgraded: PreUpgrade checks failed:
The instance could not be upgraded because the 'unknown' data type is used in user tables.
Please remove all usages of the 'unknown' data type and try again."

Per trovare il tipo di dati unknown nel database in modo da poter rimuovere la colonna danneggiata o modificarla in un tipo di dati supportato, utilizza il seguente codice SQL:

SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';

Eseguire un test di aggiornamento – Si consiglia fortemente di testare l'aggiornamento alla versione principale su un duplicato del database di produzione prima di provare l'aggiornamento sul database effettivo. È possibile monitorare i piani di esecuzione sul database di test duplicato per eventuali regressioni del piano di esecuzione e valutarne le prestazioni. Per creare un'istanza di test duplicata, puoi ripristinare il database da un'istantanea recente o ripristinare il database all'ultima data di ripristino. point-in-time

Per ulteriori informazioni, consulta Ripristino da uno snapshot o Ripristino di un'istanza DB a un'ora specificata per Amazon RDS. Per i cluster multi-AZ, consulta Ripristino da uno snapshot a un cluster di database Multi-AZ o Ripristino di un cluster di database Multi-AZ a un determinato momento.

Per i dettagli sull'esecuzione dell'aggiornamento, consulta Aggiornamento manuale della versione del motore.

Durante l'aggiornamento di un database dalla versione 9.6 alla versione 10, tieni presente che in PostgreSQL 10 le query parallele sono abilitate per impostazione predefinita. Puoi testare l'impatto del parallelismo prima dell'aggiornamento modificando il parametro max_parallel_workers_per_gather sul tuo database di test impostandolo su 2.

Per ulteriori informazioni, consulta Parallel Query (Query parallela) nella documentazione di PostgreSQL. Per disabilitare il parallelismo sulla versione 10, imposta il parametro max_parallel_workers_per_gather su 0.

Durante l'aggiornamento della versione principale, i database public e template1, nonché lo schema public in ciascun database vengono rinominati temporaneamente. Questi oggetti vengono riportati nei log con il loro nome originale e con l'aggiunta di una stringa casuale. La stringa viene aggiunta in modo che, durante l'aggiornamento alla versione principale, vengano preservate le impostazioni personalizzate come locale e owner. Al termine dell'aggiornamento gli oggetti vengono rinominati con i loro nomi originali.

Se un aggiornamento restituisce errori durante la procedura di controllo preliminare, risolvere i problemi – Durante l'aggiornamento alla versione principale, Amazon RDS for PostgreSQL esegue una procedura di controllo preliminare per identificare eventuali problemi che potrebbero impedire l'aggiornamento. La procedura di controllo preliminare verifica tutte le condizioni potenzialmente incompatibili in tutti i database dell'istanza.

Se il controllo preliminare rileva un problema, crea un evento di log che indica che il controllo preliminare dell'aggiornamento non è riuscito. I dettagli del processo di controllo preliminare si trovano in un log dell'aggiornamento denominato pg_upgrade_precheck.log per tutti i database. Amazon RDS aggiunge un timestamp al nome file. Per ulteriori informazioni sulla visualizzazione dei log, consultare Monitoraggio dei file di log di RDSAmazon.

Se un aggiornamento della replica di lettura non riesce al controllo preliminare, la replica della replica di lettura non riuscita viene interrotta e la replica di lettura viene messa nello stato terminato. Elimina la replica di lettura e ricrea una nuova replica di lettura in base all'istanza primaria aggiornata.

Risolvere tutti i problemi rilevati nel log di controllo preliminare, quindi riprovare l'aggiornamento alla versione principale. Nell'esempio seguente viene mostrato un esempio di log di controllo preliminare.

------------------------------------------------------------------------
Upgrade could not be run on Wed Apr 4 18:30:52 2018
-------------------------------------------------------------------------
The instance could not be upgraded from 9.6.11 to 10.6 for the following reasons.
Please take appropriate action on databases that have usage incompatible with the requested major engine version upgrade and try the upgrade again.

* There are uncommitted prepared transactions. Please commit or rollback all prepared transactions.* One or more role names start with 'pg_'. Rename all role names that start with 'pg_'.

* The following issues in the database 'my"million$"db' need to be corrected before upgrading:** The ["line","reg*"] data types are used in user tables. Remove all usage of these data types.
** The database name contains characters that are not supported by RDS for PostgreSQL. Rename the database.
** The database has extensions installed that are not supported on the target database version. Drop the following extensions from your database: ["tsearch2"].

* The following issues in the database 'mydb' need to be corrected before upgrading:** The database has views or materialized views that depend on 'pg_stat_activity'. Drop the views.

Se un aggiornamento della replica di lettura non riesce durante l'aggiornamento del database, risolvi il problema: lo stato di una replica di lettura non riuscita viene impostato su incompatible-restore e la replica viene terminata sul database. Elimina la replica di lettura e ricrea una nuova replica di lettura in base all'istanza primaria aggiornata.

L'aggiornamento della replica di lettura potrebbe non riuscire per i seguenti motivi:

Aggiornamento del database di produzione: se l'esecuzione dell'aggiornamento della versione principale ha esito positivo, dovresti essere in grado di eseguire l'aggiornamento del database di produzione senza problemi. Per ulteriori informazioni, consulta Aggiornamento manuale della versione del motore.

Eseguire l'operazione ANALYZE per aggiornare la tabella pg_statistic. È necessario farlo per ogni database su tutti i database PostgreSQL. Le statistiche di ottimizzazione non vengono trasferite durante un aggiornamento della versione principale, quindi è necessario rigenerare tutte le statistiche per evitare problemi di prestazioni. Esegui il comando senza parametri per generare statistiche per tutte le tabelle regolari del database corrente, come segue:

ANALYZE VERBOSE;

Il flag VERBOSE è facoltativo, ma usandolo viene mostrato lo stato di avanzamento. Per ulteriori informazioni, consulta ANALYZE nella documentazione di PostgreSQL.

Quando analizzi tabelle specifiche invece di utilizzare ANALYZE VERBOSE, esegui il comando ANALYZE per ogni tabella come segue:

ANALYZE table_name;

Per le tabelle partizionate, analizzate sempre la tabella principale. Questo processo:

Sebbene le tabelle principali non memorizzino dati effettivi, la loro analisi è fondamentale per l'ottimizzazione delle query. L'esecuzione di ANALYZE solo su singole partizioni può portare a prestazioni di query scadenti poiché l'ottimizzatore non disporrà delle statistiche complete necessarie per una pianificazione efficiente tra le partizioni.