Come eseguire un aggiornamento della versione principale di RDS Postgre SQL - Amazon Relational Database Service

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Come eseguire un aggiornamento della versione principale di RDS Postgre SQL

Consigliamo la seguente procedura quando esegui un aggiornamento di una versione principale su un database Amazon RDS for Postgre: SQL

  1. 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, consulta Gruppi di parametri per RDS e Utilizzo di gruppi di parametri cluster di database per cluster database Multi-AZ.

  2. Verifica la presenza di classi di database non supportate: verifica che la classe di istanza del database sia compatibile con la SQL versione di Postgre a cui stai effettuando l'aggiornamento. Per ulteriori informazioni, consulta Motori DB supportati per classi di istanza database.

  3. Controllare l'utilizzo non supportato:

    • Transazioni preparate – Eseguire il commit o il rollback di tutte le transazioni preparate prima di provare a eseguire un aggiornamento.

      È possibile utilizzare la seguente query per verificare che sull'istanza non siano presenti transazioni preparate aperte. 

      SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

    • Tipi di dati Reg* – Rimuovere tutti gli utilizzi dei tipi di dati reg* prima di tentare un aggiornamento. Ad eccezione di regtype e regclass, non è possibile aggiornare i tipi di dati reg*. L'pg_upgradeutilità non può mantenere questo tipo di dati, che viene utilizzato da Amazon RDS per eseguire l'aggiornamento.

      Per verificare che non siano presenti utilizzi di tipi di dati reg* non supportati, utilizzare la query seguente per ogni database. 

      
SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a
  WHERE c.oid = a.attrelid
      AND NOT a.attisdropped
      AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype,
                         'pg_catalog.regprocedure'::pg_catalog.regtype,
                         'pg_catalog.regoper'::pg_catalog.regtype,
                         'pg_catalog.regoperator'::pg_catalog.regtype,
                         'pg_catalog.regconfig'::pg_catalog.regtype,
                         'pg_catalog.regdictionary'::pg_catalog.regtype)
      AND c.relnamespace = n.oid
      AND n.nspname NOT IN ('pg_catalog', 'information_schema');

  4. Verifica la presenza di database non validi:

    • Assicurati che non ci siano database non validi. La datconnlimit colonna del pg_database catalogo include il valore -2 per contrassegnare come non validi i database che sono stati interrotti durante un'operazione. DROP DATABASE

      Utilizzate la seguente query per verificare la presenza di database non validi:

      SELECT datname FROM pg_database WHERE datconnlimit = - 2;

    • La query precedente restituisce nomi di database non validi. È possibile utilizzare DROP DATABASE invalid_db_name; per eliminare database non validi. Puoi anche usare il seguente comando per eliminare i database non validi:

      SELECT 'DROP DATABASE ' || quote_ident(datname) || ';' FROM pg_database WHERE datconnlimit = -2 \gexec

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

  5. 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, puoi eliminarli utilizzando quanto segue: SQL

    SELECT * FROM pg_replication_slots;
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.

  6. 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 DB Multi-AZ.

    Non è possibile aggiornare le repliche di lettura separatamente. Se potessi, ciò potrebbe portare a situazioni in cui i database primari e quelli di replica hanno versioni principali di SQL Postgre 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 for Postgre SQL.

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

  8. 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 Post GIS e le estensioni correlate per l'elaborazione dei dati spaziali.

    • address_standardizer

    • address_standardizer_data_us

    • postgis_raster

    • postgis_tiger_geocoder

    • postgis_topology

    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

  9. 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 chkpass estensioni tsearch2 and non sono più supportate per le SQL versioni 11 o successive di Postgre. Se si esegue l'aggiornamento alla versione 11.x, rimuovere le estensioni tsearch2 e chkpass prima dell'aggiornamento.

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

    La SQL versione 10 di Postgre 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 unknown dati nel tuo database in modo da poter rimuovere la colonna che causa l'errore o cambiarla con un tipo di dati supportato, usa quanto segue: SQL

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

  11. 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 uno snapshot recente o point-in-time ripristinare il database all'ultima data di ripristino.

    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.

    Nell'aggiornare un database dalla versione 9.6 alla versione 10, tieni presente che Postgre SQL 10 abilita le query parallele 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.

    Nota

    Il valore di default per il parametro max_parallel_workers_per_gather nel gruppo parametri del database default.postgresql10 è 2.

    Per ulteriori informazioni, vedete Parallel Query nella documentazione di Postgre. SQL 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.

    Nota

    Durante il processo di aggiornamento della versione principale, non è possibile eseguire un point-in-time ripristino dell'istanza DB o del cluster DB Multi-AZ. Dopo che Amazon ha eseguito l'aggiornamento, RDS esegue un backup automatico del database. Puoi eseguire un point-in-time ripristino ai tempi precedenti all'inizio dell'aggiornamento e dopo il completamento del backup automatico del database.

  12. Se un aggiornamento non riesce a causa di errori nella procedura di precontrollo, risolvi i problemi: durante il processo di aggiornamento della versione principale, Amazon RDS for Postgre esegue SQL innanzitutto una procedura di precontrollo per identificare eventuali problemi che potrebbero causare il fallimento dell'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 del 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.

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

    Nota

    Amazon RDS non aggiorna le repliche di lettura per i cluster DB Multi-AZ. Se esegui un aggiornamento di versione principale su un cluster DB Multi-AZ, lo stato di replica delle relative repliche di lettura diventa terminato.

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

    • Non è stato in grado di recuperare il ritardo con l'istanza database primaria anche dopo un tempo di attesa.

    • Il terminale o lo stato del ciclo di vita è incompatibile, come ad esempio spazio di storage esaurito, ripristino incompatibile e così via.

    • Quando l'aggiornamento dell'istanza database principale è stato avviato, nella replica di lettura era in esecuzione un aggiornamento di versione secondaria separata.

    • La replica di lettura ha utilizzato parametri incompatibili.

    • La replica di lettura non è in grado di comunicare con l'istanza database primaria per sincronizzare la cartella dati.

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

  15. Eseguire l'operazione ANALYZE per aggiornare la tabella pg_statistic. Dovresti farlo per ogni database su tutti i tuoi database Postgre. SQL 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 la documentazione ANALYZEdi SQL Postgre.

    Nota

    Eseguilo ANALYZE sul tuo sistema dopo l'aggiornamento per evitare problemi di prestazioni.

Al termine dell'aggiornamento alla versione principale, è consigliabile:

  • Un aggiornamento di Postgre non SQL aggiorna alcuna estensione SQL Postgre. Per aggiornare le estensioni, consulta Aggiornamento delle SQL estensioni Postgre nei database Postgre RDS SQL.

  • Facoltativamente, usa Amazon RDS per visualizzare due log prodotti dall'pg_upgradeutilità. Questi sono pg_upgrade_internal.log e pg_upgrade_server.log. Amazon RDS aggiunge un timestamp al nome del file per questi log. Puoi visualizzare questi log come qualsiasi altro log. Per ulteriori informazioni, consulta Monitoraggio dei file di log di RDSAmazon.

    Puoi anche caricare i log di aggiornamento su Amazon CloudWatch Logs. Per ulteriori informazioni, consulta Pubblicazione dei log di Postgre su SQL Amazon Logs CloudWatch .

  • Per verificare che tutto funzioni come previsto, testa l'applicazione sul database aggiornato con un carico di lavoro analogo. Dopo la verifica dell'aggiornamento è possibile eliminare l'istanza di test.