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à.
Aggiornamento del motore Postgree SQL DB per Amazon RDS
Esistono due tipi di aggiornamenti che puoi gestire per il tuo database Postgre: SQL
-
Aggiornamenti del sistema operativo: occasionalmente, Amazon RDS potrebbe dover aggiornare il sistema operativo sottostante del database per applicare correzioni di sicurezza o modifiche al sistema operativo. Puoi decidere quando Amazon RDS applicare gli aggiornamenti del sistema operativo utilizzando la RDS console, AWS Command Line Interface (AWS CLI) o RDSAPI. Per ulteriori informazioni sugli aggiornamenti del sistema operativo, consulta Applicazione di aggiornamenti a un'istanza database.
-
Aggiornamenti del motore di database: quando Amazon RDS supporta una nuova versione di un motore di database, puoi aggiornare i database alla nuova versione.
Un database in questo contesto è un'istanza SQL DB RDS per Postgre o un cluster DB Multi-AZ.
Esistono due tipi di aggiornamenti del motore per i SQL database Postgre: aggiornamenti delle versioni principali e aggiornamenti delle versioni secondarie.
- Aggiornamenti di una versione principale
-
Gli aggiornamenti di versione principali possono contenere modifiche al database non compatibili con le versioni precedenti delle applicazioni esistenti. Ne risulta che è necessario eseguire manualmente gli aggiornamenti della versione principale per i propri database. Puoi avviare manualmente un aggiornamento della versione principale modificando l'istanza database o il cluster database multi-AZ. Prima di eseguire un aggiornamento della versione principale, ti consigliamo di seguire i passaggi descritti in. Scelta di un aggiornamento della versione principale di Postgre SQL
Se stai aggiornando un'istanza DB con repliche di lettura locali, RDS Amazon aggiorna le repliche insieme all'istanza DB principale.
Amazon RDS non aggiorna le repliche di lettura del cluster DB Multi-AZ. Se esegui un aggiornamento di versione principale di un cluster DB Multi-AZ, lo stato di replica delle relative repliche di lettura diventa terminato. Devi eliminare e ricreare manualmente le repliche di lettura al completamento dell'aggiornamento.
Suggerimento
È possibile ridurre al minimo i tempi di inattività necessari per l'aggiornamento di una versione principale utilizzando una distribuzione blu/verde. Per ulteriori informazioni, consulta Utilizzo di Amazon RDS Blue/Green Deployments per gli aggiornamenti del database.
- Aggiornamenti della versione secondaria
-
Al contrario, gli aggiornamento secondari a una versione includono solo modifiche compatibili con le versioni precedenti delle applicazioni esistenti. Puoi avviare manualmente un aggiornamento della versione secondaria modificando il cluster di database. In alternativa, è possibile abilitare l'opzione di aggiornamento automatico della versione secondaria durante la creazione o la modifica di un database. Ciò significa che Amazon aggiorna RDS automaticamente il tuo database dopo aver testato e approvato la nuova versione. Se il tuo SQL database Postgre utilizza repliche di lettura, devi prima aggiornare tutte le repliche di lettura prima di aggiornare l'istanza o il cluster di origine.
Se il tuo database è una distribuzione di istanze DB Multi-AZ, Amazon aggiorna RDS contemporaneamente l'istanza primaria e tutte le istanze di standby. Pertanto, il database potrebbe non essere disponibile fino al completamento dell'aggiornamento. Se il tuo database è una distribuzione di cluster DB Multi-AZ, Amazon RDS aggiorna le istanze Reader DB una alla volta. Quindi, una delle istanze Reader DB diventa la nuova istanza DB Writer. Amazon aggiorna RDS quindi la vecchia istanza writer (che ora è un'istanza reader).
Nota
Il tempo di inattività per un aggiornamento di versione minore di un'implementazione di un'istanza DB Multi-AZ può durare diversi minuti. I cluster DB Multi-AZ in genere riducono i tempi di inattività degli aggiornamenti di versioni minori a circa 35 secondi. Se utilizzati con RDS Proxy, è possibile ridurre ulteriormente i tempi di inattività a un secondo o meno. Per ulteriori informazioni, consulta Utilizzo di Server proxy per Amazon RDS. In alternativa, è possibile utilizzare un proxy di database open source come Proxy
o AWS JDBCDriver for My SQL PgBouncer , SQL Per ulteriori informazioni, consulta Aggiornamenti automatici delle versioni secondarie per Postgre SQL. Per ulteriori informazioni sull'esecuzione manuale di un aggiornamento alla versione secondaria, consulta Aggiornamento manuale della versione del motore.
Per ulteriori informazioni sulle versioni dei motori di database e sulla politica per la deprecazione delle versioni dei motori di database, consulta Versioni dei motori di database in Amazon
Argomenti
- Panoramica sull'aggiornamento di Postgre SQL
- Numeri di versione di Postgre SQL
- Numero versione RDS
- Scelta di un aggiornamento della versione principale di Postgre SQL
- Come eseguire l'aggiornamento a una versione principale
- Aggiornamenti automatici delle versioni secondarie per Postgre SQL
- SQLAggiornamento delle estensioni Postgre
Panoramica sull'aggiornamento di Postgre SQL
Per aggiornare in sicurezza i tuoi database, Amazon RDS utilizza l'pg_upgradeutilità descritta nella documentazione di Postgre, SQL
Quando si utilizza AWS Management Console per aggiornare un database, mostra gli obiettivi di aggiornamento validi per il database. È inoltre possibile utilizzare il AWS CLI comando seguente per identificare gli obiettivi di aggiornamento validi per un database:
Per LinuxmacOS, oUnix:
aws rds describe-db-engine-versions \ --engine postgres \ --engine-versionversion-number\ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
Per Windows:
aws rds describe-db-engine-versions ^ --engine postgres ^ --engine-versionversion-number^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
Ad esempio, per identificare gli obiettivi di aggiornamento validi per un database Postgre SQL versione 12.13, esegui il comando seguente: AWS CLI
PerLinux, o: macOS Unix
aws rds describe-db-engine-versions \ --engine postgres \ --engine-version 12.13 \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
Per Windows:
aws rds describe-db-engine-versions ^ --engine postgres ^ --engine-version 12.13 ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
Se il periodo di conservazione del backup è superiore a 0, Amazon RDS esegue due snapshot DB durante il processo di aggiornamento. Il primo snapshot database è relativo al database prima delle modifiche associate all'aggiornamento. Se l'aggiornamento dei database ha esito negativo, puoi ripristinare questo snapshot per creare un database che esegue la versione precedente. Il secondo snapshot DB viene acquisito al termine dell'aggiornamento.
Nota
Amazon RDS scatta istantanee DB durante il processo di aggiornamento solo se hai impostato il periodo di conservazione dei backup per il tuo database su un numero maggiore di 0. Per modificare il periodo di conservazione dei backup per un'istanza database, consulta Modifica di un'istanza database Amazon RDS. Non è possibile configurare un periodo di conservazione dei backup personalizzato per un cluster database multi-AZ.
Quando aggiorni la versione principale di un'istanza database, tutte le repliche di lettura nella regione vengono aggiornate automaticamente. Dopo l'avvio del flusso di lavoro di aggiornamento, le istanze di repliche di lettura attendono che pg_upgrade venga completato correttamente sull'istanza database primaria. Quindi l'aggiornamento dell'istanza database primaria attende il completamento degli aggiornamenti di replicche di lettura. Finché l'aggiornamento non è completato, si verifica un'interruzione. Quando esegui l'aggiornamento della versione principale di un cluster database multi-AZ, lo stato delle relative repliche di lettura cambia in Terminato.
Al completamento di un aggiornamento, non è possibile ripristinare la versione precedente del motore di database. Se desideri ripristinare la versione precedente, ripristina lo snapshot database acquisito prima dell'aggiornamento per creare un nuovo database.
Numeri di versione di Postgre SQL
La sequenza di numerazione delle versioni per il motore di SQL database Postgre è la seguente:
-
Per le SQL versioni 10 e successive di Postgre, il numero di versione del motore è nel formato major.minor. Il numero di versione principale è la parte intera del numero di versione. Il numero di versione secondaria è la parte frazionaria del numero di versione.
Un aggiornamento della versione principale incrementa la parte intera del numero di versione, ad esempio l'aggiornamento da 10.secondario a 11.secondario.
-
Per le SQL versioni di Postgre precedenti alla 10, il numero di versione del motore è nel formato major.major.minor. Il numero di versione principale del motore è il numero intero che la prima parte frazionaria del numero di versione. Ad esempio, 9.6 è una versione principale. Il numero di versione secondaria è la terza parte del numero di versione. Ad esempio, per la versione 9.6.12, 12 è il numero della versione secondaria.
Un aggiornamento della versione principale incrementa la parte principale del numero di versione. Ad esempio, un aggiornamento da 9.6.12 a 11.14 è un aggiornamento della versione principale, in cui 9.6 e 11 sono i numeri delle versioni principali.
Per informazioni sulla numerazione delle versioni di RDS Extended Support, vedereDenominazione delle versioni di Amazon RDS Extended Support.
Numero versione RDS
RDSi numeri di versione utilizzano lo schema di major.minor.patch
Per identificare il numero di RDS versione Amazon del tuo database, devi prima creare l'rds_toolsestensione utilizzando il seguente comando:
CREATE EXTENSION rds_tools;
A partire dal rilascio della SQL versione 15.2-R2 di Postgre, puoi scoprire il numero di RDS versione del tuo database RDS for SQL Postgre con la seguente query: SQL
postgres=>SELECT rds_tools.rds_version();
Ad esempio, l'interrogazione di un RDS database per Postgre 15.2 restituisce quanto segue: SQL
rds_version ---------------- 15.2.R2 (1 row)
Scelta di un aggiornamento della versione principale di Postgre SQL
È possibile che gli aggiornamenti a una versione principale contengano modifiche non compatibili con le versioni precedenti del database. La nuova funzionalità può causare l'interruzione del funzionamento corretto delle applicazioni esistenti. Per questo motivo, Amazon RDS non applica automaticamente gli aggiornamenti delle versioni principali. Per eseguire un aggiornamento della versione principale, modifica il database manualmente. Accertati di testare in modo approfondito qualsiasi aggiornamento per verificare che le tue applicazioni funzionino correttamente prima di applicare l'aggiornamento ai database di produzione. Quando esegui un aggiornamento della versione SQL principale di Postgre, ti consigliamo di seguire i passaggi descritti in. Come eseguire l'aggiornamento a una versione principale
Quando si aggiorna un'istanza DB Postgre SQL Single-AZ o una distribuzione di un'istanza DB Multi-AZ alla versione principale successiva, anche tutte le repliche di lettura associate al database vengono aggiornate alla versione principale successiva. In alcuni casi, è possibile passare a una versione principale successiva durante l'aggiornamento. Se l'aggiornamento ignora una versione principale, anche le repliche di lettura vengono aggiornate alla versione principale di destinazione. Gli aggiornamenti alla versione 11 che ignorano altre versioni principali presentano alcune limitazioni. È possibile trovare i dettagli nei passaggi descritti in Come eseguire l'aggiornamento a una versione principale.
La maggior parte delle SQL estensioni Postgre non viene aggiornata durante un aggiornamento del motore Postgre. SQL Queste devono essere aggiornate separatamente. Per ulteriori informazioni, consulta SQLAggiornamento delle estensioni Postgre.
Puoi scoprire quali versioni principali sono disponibili per il tuo database RDS per Postgre SQL eseguendo la seguente query: AWS CLI
aws rds describe-db-engine-versions --engine postgres --engine-versionyour-version--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
La tabella riportata di seguito riepiloga i risultati di questa query per tutte le versioni disponibili. Un asterisco (*) sul numero di versione indica che la versione non è più supportata. Se la versione corrente non è supportata, si consiglia di eseguire l'aggiornamento alla versione secondaria più recente o a una delle altre destinazioni di aggiornamento disponibili per quella versione.
* Questa versione non è più supportata.
Come eseguire l'aggiornamento a una versione principale
Consigliamo la seguente procedura quando esegui un aggiornamento di una versione principale su un database Amazon RDS for Postgre: SQL
-
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.
-
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.
-
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
regtypeeregclass, 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');
-
-
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
pglogicalper un corretto aggiornamento della versione principale. Per informazioni su come identificare e rimuovere gli slot creati utilizzando l'estensionepglogical, consulta Gestione degli slot di replica logica per RDS per PostgreSQL. -
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.
-
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 database Amazon RDS e Modifica di un cluster di database Multi-AZ.
Per eseguire un backup manuale, consulta Creazione di uno snapshot DB per un'istanza DB Single-AZ e Creazione di uno snapshot di un cluster di database Multi-AZ.
-
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 EXTENSIONPostgreSQL-extensionUPDATE TO 'new-version';Per ulteriori informazioni, consulta SQLAggiornamento delle estensioni Postgre. 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'estensionepgRoutinge reinstallarla con una versione compatibile dopo l'aggiornamento. Per le versioni dell'estensione aggiornabili, consultare Versioni di estensione Postgre supportate SQL.Le
chkpassestensionitsearch2and non sono più supportate per le SQL versioni 11 o successive di Postgre. Se si esegue l'aggiornamento alla versione 11.x, rimuovere le estensionitsearch2echkpassprima dell'aggiornamento. -
Eliminare tipi di dati sconosciuti – Eliminare i tipi di dati
unknowna seconda della versione di destinazione.La SQL versione 10 di Postgre ha smesso di supportare il tipo di dati.
unknownSe un database versione 9.6 utilizza il tipo di datiunknown, 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
unknowndati 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: SQLSELECT 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 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 a un'ora specifica per un'istanza database. 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_gathersul tuo database di test impostandolo su 2.Nota
Il valore di default per il parametro
max_parallel_workers_per_gathernel gruppo parametri del databasedefault.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_gathersu 0.Durante l'aggiornamento della versione principale, i database
publicetemplate1, nonché lo schemapublicin 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 comelocaleeowner. 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.
-
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.logper 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. -
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-restoree 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.
-
-
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
ANALYZEper aggiornare la tabellapg_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 SQLAggiornamento delle estensioni Postgre.
-
Facoltativamente, usa Amazon RDS per visualizzare due log prodotti dall'
pg_upgradeutilità. Questi sonopg_upgrade_internal.logepg_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.
Aggiornamenti automatici delle versioni secondarie per Postgre SQL
Se abiliti l'opzione Aggiornamento automatico versione secondaria quando crei o modifichi un'istanza database o un cluster database multi-AZ, il database viene aggiornato automaticamente.
RDSPer ciascuna versione SQL principale di Postgre, una versione secondaria viene designata RDS come versione di aggiornamento automatico. Dopo che una versione secondaria è stata testata e approvata da AmazonRDS, l'aggiornamento della versione secondaria avviene automaticamente durante la finestra di manutenzione. RDSnon imposta automaticamente le versioni secondarie rilasciate più recenti come versione di aggiornamento automatico. Prima di RDS designare una nuova versione di aggiornamento automatico, vengono presi in considerazione diversi criteri, come i seguenti:
-
Problemi di sicurezza noti
-
Bug nella versione della community di Postgre SQL
-
Stabilità generale del parco istanze da quando la versione secondaria è stata rilasciata
È possibile utilizzare il seguente AWS CLI comando per determinare l'attuale versione di destinazione dell'aggiornamento secondario automatico per una versione SQL secondaria di Postgre specificata in una specifica. Regione AWS
PerLinux, omacOS: Unix
aws rds describe-db-engine-versions \ --engine postgres \ --engine-versionminor-version\ --regionregion\ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \ --output text
Per Windows:
aws rds describe-db-engine-versions ^ --engine postgres ^ --engine-versionminor-version^ --regionregion^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^ --output text
Ad esempio, il AWS CLI comando seguente determina l'obiettivo di aggiornamento secondario automatico per la versione SQL secondaria Postgre 12.13 negli Stati Uniti orientali (Ohio) (us-east-2). Regione AWS
Per, oUnix: Linux macOS
aws rds describe-db-engine-versions \ --engine postgres \ --engine-version 12.13 \ --region us-east-2 \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \ --output table
Per Windows:
aws rds describe-db-engine-versions ^ --engine postgres ^ --engine-version 12.13 ^ --region us-east-2 ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^ --output table
L'output è simile a quello riportato di seguito.
---------------------------------- | DescribeDBEngineVersions | +--------------+-----------------+ | AutoUpgrade | EngineVersion | +--------------+-----------------+ | True | 12.14 | | False | 12.15 | | False | 13.9 | | False | 13.10 | | False | 13.11 | | False | 14.6 | +--------------+-----------------+
In questo esempio, il AutoUpgrade valore è True per la SQL versione 12.14 di Postgre. Quindi, l'obiettivo dell'aggiornamento secondario automatico è la SQL versione 12.14 di Postgre, evidenziata nell'output.
Un SQL database Postgre viene aggiornato automaticamente durante la finestra di manutenzione se vengono soddisfatti i seguenti criteri:
-
Nel database è abilitata l'opzione Aggiornamento automatico versione secondaria.
-
Il database esegue una versione del motore di database secondaria rispetto a una versione secondaria automatica dell'aggiornamento corrente.
Per ulteriori informazioni, consulta Aggiornamento automatico della versione secondaria del motore.
Nota
Un aggiornamento di Postgre non SQL aggiorna le estensioni di Postgre. SQL Per aggiornare le estensioni, consulta SQLAggiornamento delle estensioni Postgre.
SQLAggiornamento delle estensioni Postgre
Un aggiornamento del SQL motore Postgre non aggiorna la maggior parte delle estensioni Postgre. SQL Per aggiornare un'estensione dopo un aggiornamento a una versione, utilizza il comando ALTER
EXTENSION UPDATE.
Nota
Per informazioni sull'aggiornamento dell'GISestensione Post, vedete (). Gestione dei dati spaziali con l'estensione Post GIS Passaggio 6: Aggiorna l'GISestensione Post
Per aggiornare l'estensione pg_repack, rimuovi l'estensione e quindi crea la nuova versione nel database aggiornato. Per ulteriori informazioni, consulta pg_repack installationpg_repack.
Per aggiornare un'estensione, utilizza il comando seguente.
ALTER EXTENSIONextension_nameUPDATE TO 'new_version';
Per l'elenco delle versioni supportate delle SQL estensioni Postgre, consulta. Versioni di estensione Postgre supportate SQL
Per elencare le estensioni attualmente installate, usa il catalogo Postgre SQL pg_extension
SELECT * FROM pg_extension;
SELECT * FROM pg_available_extension_versions;
