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à.
# Manutenzione di un cluster di database Amazon Aurora
Periodicamente, Amazon RDS esegue la manutenzione delle risorse Amazon RDS. I seguenti argomenti descrivono queste azioni di manutenzione e come applicarle.
## Panoramica degli aggiornamenti di manutenzione dei cluster di database
La manutenzione spesso comporta aggiornamenti alle seguenti risorse del cluster database:
+ Hardware sottostante
+ Sistema operativo (OS) sottostante
+ Versione del motore del database
Gli aggiornamenti al sistema operativo si verificano generalmente per problemi di sicurezza. Consigliamo di eseguirli il prima possibile. Per ulteriori informazioni sugli aggiornamenti del sistema operativo, consulta [Aggiornamenti del sistema operativo per i cluster Aurora DB](#Aurora_OS_updates).
**Topics**
+ [Risorse offline durante gli aggiornamenti di manutenzione](#USER_UpgradeDBInstance.Maintenance.Overview.offline)
+ [Modifiche differite dell'istanza DB e del cluster DB](#USER_UpgradeDBInstance.Maintenance.Overview.Deferred)
+ [Eventuale coerenza per l'API DescribePendingMaintenanceActions](#USER_UpgradeDBInstance.Maintenance.Overview.eventual-consistency)
### Risorse offline durante gli aggiornamenti di manutenzione
Per alcune operazioni di manutenzione, Amazon RDS deve portare offline il cluster di database per un breve intervallo di tempo. Tra le operazioni di manutenzione che richiedono l’impostazione offline di una risorsa si annovera l’applicazione delle patch necessarie al sistema operativo o al database. L’applicazione delle patch necessarie viene pianificata automaticamente solo per le patch correlate alla sicurezza e all’affidabilità dell’istanza. Tali patch si verificano raramente, in genere una volta ogni pochi mesi. Raramente richiedono più di una frazione del periodo di manutenzione.
### Modifiche differite dell'istanza DB e del cluster DB
Le modifiche dell’istanza e del cluster di database differite che si è scelto di non applicare immediatamente vengono applicate durante la finestra di manutenzione. Ad esempio, è possibile scegliere di modificare le classi di istanza database o i gruppi di parametri cluster o database durante la finestra di manutenzione. Le modifiche specificate utilizzando l’impostazione di **riavvio in sospeso** non vengono visualizzate nell’elenco **Manutenzione in sospeso** . Per ulteriori informazioni sulla modifica di un cluster database, consulta [Modifica di un cluster database Amazon Aurora](Aurora.Modifying.md).
Per vedere le modifiche in sospeso per la prossima finestra di manutenzione, usa il [describe-db-clusters](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/describe-db-clusters.html) AWS CLI comando e controlla il campo. `PendingModifiedValues`
### Eventuale coerenza per l'API DescribePendingMaintenanceActions
L’API `DescribePendingMaintenanceActions` di Amazon RDS segue un modello di consistenza finale. Ciò significa che il risultato dell’esecuzione del comando `DescribePendingMaintenanceActions` potrebbe non essere immediatamente visibile a tutti i comandi successivi di RDS. Tienilo a mente quando utilizzi `DescribePendingMaintenanceActions` immediatamente dopo aver utilizzato un comando API precedente.
L’eventuale coerenza può influire sul modo in cui hai gestito gli aggiornamenti di manutenzione. Ad esempio, se si esegue il comando `ApplyPendingMaintenanceActions` per aggiornare la versione del motore di database per un cluster di database, alla fine sarà visibile a `DescribePendingMaintenanceActions`. In questo scenario, `DescribePendingMaintenanceActions` potrebbe mostrare che l’azione di manutenzione non è stata applicata anche nel caso lo sia stata.
Per gestire la coerenza finale, procedi nel modo seguente:
+ Conferma lo stato di cluster di database prima di eseguire un comando per modificarlo. Esegui il comando `DescribePendingMaintenanceActions` appropriato utilizzando un algoritmo di backoff esponenziale per assicurarti di concedere tempo sufficiente per la propagazione del comando precedente nel sistema. A tale scopo, esegui il comando `DescribePendingMaintenanceActions` ripetutamente, iniziando con un paio di secondi di attesa e aumentando gradualmente fino a cinque minuti di attesa.
+ Aggiungi il tempo di attesa tra i comandi successivi, anche se un comando `DescribePendingMaintenanceActions` restituisce una risposta accurata. Applica un algoritmo di backoff esponenziale a partire da un paio di secondi di attesa e aumenta gradualmente fino a circa cinque minuti di attesa.
## Visualizzazione degli aggiornamento di manutenzione in sospeso
Verifica se è disponibile un aggiornamento di manutenzione per il tuo cluster di DB utilizzando la console RDS, l'API RDS o l' AWS CLI API RDS. Se è disponibile un aggiornamento, viene indicato nella colonna **Manutenzione** per il cluster di database nella console Amazon RDS, come illustrato in questa figura.
![\[L’azione di manutenzione è disponibile e verrà applicata nella finestra di manutenzione successiva.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/offlinepatchavailable.png)
Se non è disponibile alcun aggiornamento di manutenzione per il cluster di un’ database, il valore della colonna corrispondente è **none (nessuno)**.
Se è disponibile un aggiornamento di manutenzione per il cluster di un’ database, la colonna può avere i seguenti valori:
+ **richiesto** – L’operazione di manutenzione sarà applicata alla risorsa e non può essere a tempo indeterminato.
+ **disponibile** – L’operazione di manutenzione è disponibile ma non sarà automaticamente applicata alla risorsa. Puoi applicarla manualmente.
+ **finestra successiva** – L’operazione di manutenzione sarà applicata alla risorsa durante la finestra di manutenzione successiva.
+ **In corso** – L’operazione di manutenzione è in fase di applicazione alla risorsa.
Se è disponibile un aggiornamento, puoi scegliere una di queste operazioni:
+ Se il valore di manutenzione è **finestra successiva**, posticipare le azioni di manutenzione scegliendo **Posticipa aggiornamento** da **Operazioni**. Non puoi rinviare un’azione di manutenzione che è già stata avviata.
+ Applica immediatamente le operazioni di manutenzione.
+ Applica le azioni di manutenzione durante la successiva finestra di manutenzione.
+ Non eseguire alcuna operazione.
**Per eseguire un'azione utilizzando il Console di gestione AWS**
1. Scegli il nome dell’istanza o del cluster di database per visualizzarne i dettagli.
1. Scegliere **Manutenzione e backup**. Vengono visualizzate le azioni di manutenzione in attesa.
1. Scegli l’azione da intraprendere, quindi scegli quando applicarla.
![\[Elemento di manutenzione in sospeso per un’istanza database Aurora.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/pending_maintenance_aurora_instance.png)
La finestra di manutenzione determina l’avvio delle operazioni in sospeso, ma non limita il tempo di esecuzione totale di tali operazioni. Non è garantito che le operazioni di manutenzione terminino prima della fine della finestra di manutenzione e potrebbero continuare oltre l’ora di fine specificata. Per ulteriori informazioni, consulta [Finestra di manutenzione Amazon RDS](#Concepts.DBMaintenance).
È inoltre possibile verificare se è disponibile un aggiornamento di manutenzione per il cluster di DB eseguendo il [describe-pending-maintenance-actions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-pending-maintenance-actions.html) AWS CLI comando.
Per informazioni sull’applicazione degli aggiornamenti di manutenzione, consulta [Applicazione degli aggiornamenti a un cluster di DB](#USER_UpgradeDBInstance.OSUpgrades).
### Azioni di manutenzione per Amazon Aurora
Le seguenti azioni di manutenzione si applicano ai cluster di database Aurora:
+ `os-upgrade` - Aggiorna i sistemi operativi di tutte le istanze database nel cluster di database, utilizzando aggiornamenti a rotazione. Per ulteriori informazioni, consulta [Aggiornamenti del sistema operativo per i cluster Aurora DB](#Aurora_OS_updates).
+ `system-update`— Esegui patch del motore database per Aurora PostgreSQL.
Le seguenti azioni di manutenzione si applicano alle istanze database Aurora:
+ `ca-certificate-rotation`: aggiorna il certificato Amazon RDS Certificate Authority per l’istanza database.
+ `hardware-maintenance`: esegue la manutenzione sull’hardware sottostante per l’istanza database.
+ `system-update`— Aggiorna il sistema operativo per l’istanza database.
## Scelta della frequenza degli aggiornamenti di manutenzione di Aurora MySQL
Puoi scegliere con quale frequenza eseguire gli aggiornamenti di Aurora MySQL per ogni cluster di database. La scelta migliore dipende dall’utilizzo di Aurora MySQL e dalle priorità delle applicazioni eseguite in Aurora. Per informazioni sulle versioni con supporto a lungo termine (LTS) di Aurora MySQL che richiedono aggiornamenti meno frequenti, consultare [Versioni con supporto a lungo termine (Long-Term Support, LTS) di Aurora MySQL](AuroraMySQL.Update.SpecialVersions.md#AuroraMySQL.Updates.LTS).
Puoi scegliere di aggiornare un cluster Aurora MySQL più raramente se alcune o tutte le condizioni seguenti sono applicabili al tuo scenario:
+ Il ciclo di test per l’applicazione richiede molto tempo per ogni aggiornamento al motore di database di Aurora MySQL.
+ Hai molti cluster di database o molte applicazioni, tutti in esecuzione sulla stessa versione di Aurora MySQL. Preferisci aggiornare tutti i cluster di database e le applicazioni associate contemporaneamente.
+ Utilizzi Aurora MySQL e RDS per MySQL e preferisci mantenere i cluster Aurora MySQL e le istanze database RDS per MySQL compatibili con lo stesso livello di MySQL.
+ L’applicazione Aurora MySQL è in produzione o è comunque una risorsa business-critical. Non puoi avere tempi di inattività dovuti agli aggiornamenti, ad eccezione di rari casi per la distribuzione di patch critiche.
+ L’applicazione Aurora MySQL non è limitata da problemi di prestazioni o da carenze nella funzionalità risolti nelle versioni di Aurora MySQL successive.
Se i fattori precedenti si applicano alla tua situazione, puoi limitare il numero di aggiornamenti forzati per un cluster di database Aurora MySQL. Per farlo, scegli una versione di Aurora MySQL specifica, nota come versione con supporto a lungo termine ("Long-Term Support", LTS) quando crei o aggiorni il cluster di database. In questo modo, riduci il numero di cicli di aggiornamenti, cicli di test e interruzioni correlate agli aggiornamenti per lo specifico cluster di database.
Puoi scegliere di aggiornare un cluster Aurora MySQL più spesso, se alcune o tutte le condizioni seguenti sono applicabili al tuo scenario:
+ Il ciclo di test per l’applicazione è semplice e breve.
+ L’applicazione è ancora in fase di sviluppo.
+ L’ambiente del database utilizza diverse versioni di Aurora MySQL oppure versioni di Aurora MySQL e di RDS per MySQL. Ogni cluster Aurora MySQL ha il proprio ciclo di aggiornamento.
+ Sei in attesa di determinati miglioramenti alle prestazioni o alle funzionalità per poter aumentare il tuo utilizzo di Aurora MySQL.
Se i fattori precedenti si applicano alla tua situazione, puoi abilitare Aurora per eseguire più spesso gli aggiornamenti importanti. Per farlo, esegui l’aggiornamento di un cluster database Aurora MySQL a una versione di Aurora MySQL più recente rispetto alla versione LTS. In questo modo, i miglioramenti alle prestazioni, le correzioni di bug e le funzionalità più recenti vengono resi disponibili più rapidamente.
## Finestra di manutenzione Amazon RDS
La finestra di manutenzione è un intervallo di tempo settimanale durante il quale vengono applicate le modifiche al sistema. Ogni cluster di database ha una finestra di manutenzione settimanale. La finestra di manutenzione può essere considerata come un’opportunità per controllare quando vengono applicate le modifiche e le patch del software. Per ulteriori informazioni per regolare la finestra di manutenzione, consulta [Impostazione della finestra di manutenzione preferita del cluster database](#AdjustingTheMaintenanceWindow.Aurora).
Durante l’esecuzione delle attività di manutenzione, RDS utilizza alcune risorse del cluster database. Ciò potrebbe influire, in modo minimo, sulle prestazioni. Per un’istanza database, in rari casi, potrebbe essere necessario un failover Multi-AZ per il completamento di un aggiornamento di manutenzione.
Se un evento di manutenzione è pianificato per una settimana specifica, viene avviato durante la finestra di manutenzione di 30 minuti indicata. La maggior parte degli eventi di manutenzione viene completata durante la finestra di manutenzione di 30 minuti, tuttavia l’esecuzione degli eventi di manutenzione di dimensioni maggiori può richiedere più di 30 minuti per il completamento. La finestra di manutenzione viene sospesa quando l’istanza di database viene arrestata/o.
La finestra di manutenzione di 30 minuti è selezionata a caso da un blocco di tempo di 8 ore per regione. Se non specifichi una finestra di manutenzione quando crei il cluster database, Amazon RDS assegna una finestra di manutenzione di 30 minuti in un giorno della settimana selezionato in modo casuale.
La tabella seguente mostra i blocchi temporali per ciascuno Regione AWS dei quali vengono assegnate le finestre di manutenzione predefinite.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html)
**Topics**
+ [Impostazione della finestra di manutenzione preferita del cluster database](#AdjustingTheMaintenanceWindow.Aurora)
### Impostazione della finestra di manutenzione preferita del cluster database
La finestra di manutenzione del cluster database Aurora deve essere impostata nel periodo di minore utilizzo e quindi potrebbe essere necessario apportare modifiche di tanto in tanto. Durante questo intervallo di tempo il cluster database non è disponibile solo se gli aggiornamenti applicati richiedono un’interruzione. L’interruzione dura il minimo necessario per apportare gli aggiornamenti richiesti.
**Nota**
Per gli aggiornamenti al motore di database, Amazon Aurora gestisce la finestra di manutenzione preferita per un cluster database e non per le singole istanze.
#### Console
**Per impostare la finestra di manutenzione preferita del cluster database**
1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel pannello di navigazione, seleziona **Database**.
1. Scegliere il cluster database per cui si desidera modificare la finestra di manutenzione.
1. Scegliere **Modify (Modifica)**.
1. Nella sezione **Manutenzione** aggiornare a finestra di manutenzione.
1. Scegli **Continue (Continua)**.
Nella pagina di conferma esaminare le modifiche.
1. Per applicare immediatamente le modifiche alla finestra di manutenzione, scegli **Immediately (Immediatamente)** nella sezione **Schedule of modifications (Pianificazione delle modifiche)**.
1. Scegliere **Modify cluster (Modifica cluster)** per salvare le modifiche.
In alternativa, scegliere **Back (Indietro)** per cambiare le modifiche o **Cancel (Annulla)** per annullare le modifiche.
#### AWS CLI
Per regolare la finestra di manutenzione preferita del cluster DB, usa il AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)comando con i seguenti parametri:
+ `--db-cluster-identifier`
+ `--preferred-maintenance-window`
**Example**
Nell’esempio di codice seguente la finestra di manutenzione viene impostata su martedì dalle 4:00 –alle 4:30.
Per Linux, macOS o Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier my-cluster \
--preferred-maintenance-window Tue:04:00-Tue:04:30
```
Per Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier my-cluster ^
--preferred-maintenance-window Tue:04:00-Tue:04:30
```
#### API RDS
Per impostare la finestra di manutenzione del cluster database preferita, utilizzare l’operazione API Amazon RDS [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) con i parametri seguenti:
+ `DBClusterIdentifier`
+ `PreferredMaintenanceWindow`
## Applicazione degli aggiornamenti a un cluster di DB
Con Amazon RDS, puoi scegliere quando eseguire le operazioni di manutenzione. Puoi decidere quando Amazon RDS applicare gli aggiornamenti utilizzando l'API Console di gestione AWS AWS CLI, o RDS.
### Console
**Per gestire un aggiornamento per un cluster di database**
1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel pannello di navigazione, seleziona **Database**.
1. Scegliere il cluster dell’ database da aggiornare.
1. Per **Actions (Operazioni)**, scegliere una delle seguenti opzioni:
+ **Applica patch ora**
+ **Applica patch nella finestra successiva**
**Nota**
Se si sceglie **Applica patch nella finestra successiva** e successivamente si desidera ritardare l’aggiornamento, è possibile scegliere **Rinvia l’aggiornamento**. Non puoi rinviare un’azione di manutenzione se è già stata avviata.
Per annullare un'azione di manutenzione, modifica l'istanza database e disabilita **l'aggiornamento automatico della versione secondaria**.
### AWS CLI
Per applicare un aggiornamento in sospeso a un cluster di DB, usa il [apply-pending-maintenance-action](https://docs.aws.amazon.com/cli/latest/reference/rds/apply-pending-maintenance-action.html) AWS CLI comando.
**Example**
Per Linux, macOS o Unix:
```
aws rds apply-pending-maintenance-action \
--resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db \
--apply-action system-update \
--opt-in-type immediate
```
Per Windows:
```
aws rds apply-pending-maintenance-action ^
--resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db ^
--apply-action system-update ^
--opt-in-type immediate
```
**Nota**
Per rinviare un’azione di manutenzione, specificare `undo-opt-in` per `--opt-in-type`. Non è possibile specificare `undo-opt-in` per `--opt-in-type` se l’operazione di manutenzione è già stata avviata.
Per annullare un'azione di manutenzione, esegui il [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) AWS CLI comando e specifica`--no-auto-minor-version-upgrade`.
Per restituire un elenco di risorse con almeno un aggiornamento in sospeso, usa il [describe-pending-maintenance-actions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-pending-maintenance-actions.html) AWS CLI comando.
**Example**
Per Linux, macOS o Unix:
```
aws rds describe-pending-maintenance-actions \
--resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db
```
Per Windows:
```
aws rds describe-pending-maintenance-actions ^
--resource-identifier arn:aws:rds:us-west-2:001234567890:db:mysql-db
```
È inoltre possibile restituire un elenco di risorse per un cluster di DB specificando il `--filters` parametro del `describe-pending-maintenance-actions` AWS CLI comando. Il formato del comando `--filters` è `Name=filter-name,Value=resource-id,...`.
Di seguito sono indicati i valori accettati per il parametro `Name` di un filtro:
+ `db-instance-id`— Accetta un elenco di identificatori di istanze DB o Amazon Resource Names (ARNs). L'elenco restituito include solo le azioni di manutenzione in sospeso per le istanze DB identificate da questi identificatori o. ARNs
+ `db-cluster-id`— Accetta un elenco di identificatori di cluster DB o ARNs per Amazon Aurora. L'elenco restituito include solo le azioni di manutenzione in sospeso per i cluster DB identificati da questi identificatori o. ARNs
L’esempio seguente restituisce le operazioni di manutenzione in sospeso per i cluster database `sample-cluster1` e `sample-cluster2`.
**Example**
Per Linux, macOS o Unix:
```
aws rds describe-pending-maintenance-actions \
--filters Name=db-cluster-id,Values=sample-cluster1,sample-cluster2
```
Per Windows:
```
aws rds describe-pending-maintenance-actions ^
--filters Name=db-cluster-id,Values=sample-cluster1,sample-cluster2
```
### API RDS
Per applicare un aggiornamento a un cluster database, chiamare l’operazione [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ApplyPendingMaintenanceAction.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ApplyPendingMaintenanceAction.html) dell’API Amazon RDS.
Per ottenere un elenco delle risorse con almeno un aggiornamento in sospeso, chiamare l’operazione API Amazon RDS [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribePendingMaintenanceActions.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribePendingMaintenanceActions.html).
## Aggiornamenti automatici delle versioni secondarie per i cluster di database Aurora
L’impostazione **Aggiornamento automatico versione secondaria** specifica se gli aggiornamenti Aurora vengono applicati automaticamente al cluster database. Questi aggiornamenti includono nuove versioni secondarie contenenti funzionalità aggiuntive e patch con correzioni di bug.
Gli aggiornamenti automatici delle versioni secondarie aggiornano periodicamente il database alle versioni recenti del motore di database. Tuttavia, l’aggiornamento potrebbe non includere sempre la versione più recente del motore di database. Se è necessario mantenere i database su versioni specifiche in momenti particolari, consigliamo di eseguire manualmente l’aggiornamento alle versioni del database necessarie in base alla pianificazione richiesta. In caso di problemi di sicurezza critici o quando una versione raggiunge la end-of-support data di scadenza, Amazon Aurora potrebbe applicare un aggiornamento della versione secondaria anche se non hai abilitato **l'opzione Aggiornamento automatico della versione secondaria**. Per ulteriori informazioni, consulta la Guida all’aggiornamento del database nella documentazione di Oracle.
Consulta [Aggiornamento della versione secondaria o del livello di patch di un cluster di database Aurora MySQL](AuroraMySQL.Updates.Patching.md) e [Esecuzione di un aggiornamento a una versione secondaria](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md).
**Nota**
Database globale Aurora non supporta aggiornamenti automatici a versioni secondarie.
Questa impostazione è attivata per impostazione predefinita. Per ogni nuovo cluster database, scegliere il valore appropriato per questa impostazione. Il valore si basa sull’importanza, sulla durata prevista e sulla quantità di test di verifica eseguiti dopo ogni aggiornamento.
Per istruzioni su come attivare o disattivare l’impostazione **Aggiornamento automatico versione secondaria**, consulta quanto segue:
+ [Abilitazione degli aggiornamenti automatici delle versioni secondarie per un cluster database Aurora](#aurora-amvu-cluster)
+ [Abilitazione degli aggiornamenti automatici delle versioni secondarie per singole istanze database in un cluster database Aurora](#aurora-amvu-instance)
**Importante**
Si consiglia vivamente di applicare questa impostazione ai cluster database nuovi ed esistenti e non alle singole istanze database nel cluster. Se un’istanza database nel cluster ha questa impostazione disattivata, il cluster database non viene aggiornato automaticamente.
La tabella seguente mostra come funziona l’impostazione **Aggiornamento automatico versione secondaria** quando viene applicata a livello di cluster e istanza.
| Azione | Impostazioni a livello di cluster | Impostazioni a livello di istanza | Il cluster è stato aggiornato automaticamente? |
| --- | --- | --- | --- |
| Impostazione su Vero a livello di cluster database. | True | Impostazione su Vero per tutte le istanze nuove ed esistenti | Sì |
| Impostazione su Falso a livello di cluster database. | False | Impostazione su Falso per tutte le istanze nuove ed esistenti | No |
| Precedente impostazione su Vero a livello di cluster database. Impostazione su Falso in almeno un’istanza database. | Impostazione modificata su Falso | Impostazione su Falso per una o più istanze | No |
| Precedente impostazione su Falso a livello di cluster database. Impostazione su Vero in almeno un’istanza database, ma non in tutte le istanze. | False | Impostazione su Vero in una o più istanze, ma non in tutte le istanze | No |
| Precedente impostazione su Falso a livello di cluster database. Impostazione su Vero in tutte le istanze database. | Impostazione modificata su Vero | Impostazione su Vero per tutte le istanze | Sì |
Gli aggiornamenti automatici delle versioni secondarie vengono comunicati in anticipo tramite un evento cluster database Amazon RDS con una categoria di `maintenance` e un ID di `RDS-EVENT-0156`. Per ulteriori informazioni, consulta [Categorie di eventi e messaggi di eventi di Amazon RDS per Aurora](USER_Events.Messages.md).
Gli aggiornamenti automatici vengono eseguiti durante le finestre di manutenzione. Se le singole istanze database nel cluster database hanno finestre di manutenzione diverse dalla finestra di manutenzione del cluster, la finestra di manutenzione del cluster ha la precedenza.
Per ulteriori informazioni sugli aggiornamenti del motore per Aurora PostgreSQL, consultare [Aggiornamenti del motore di database Amazon Aurora PostgreSQL per 02/06/2020](AuroraPostgreSQL.Updates.md).
Per ulteriori informazioni sull’impostazione di **Auto Minor Version Upgrade (Aggiornamento automatico minore della versione)** per Aurora MySQL, consulta [Abilitazione degli aggiornamenti automatici tra versioni secondarie di Aurora MySQL](AuroraMySQL.Updates.AMVU.md). Per ulteriori informazioni sugli aggiornamenti del motore per Aurora MySQL, consulta [Aggiornamenti del motore del database per Amazon Aurora MySQLVersioni beta e con supporto a lungo termine (LTS, Long-Term Support) di Amazon Aurora MySQL](AuroraMySQL.Updates.md).
**Topics**
### Abilitazione degli aggiornamenti automatici delle versioni secondarie per un cluster database Aurora
Eseguire la procedura generale descritta in [Modifica del cluster di database tramite la console, la CLI e l'API](Aurora.Modifying.md#Aurora.Modifying.Cluster).
**Console**
Nella pagina **Modifica il cluster DB**, nella sezione **Manutenzione** selezionare la casella di controllo **Abilita aggiornamento automatico versione secondaria**.
**AWS CLI**
Chiamare il comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI . Specificare il nome del cluster database per l’opzione `--db-cluster-identifier` e `true` per l’opzione `--auto-minor-version-upgrade`. Facoltativamente, specificare l’opzione `--apply-immediately` per attivare immediatamente questa impostazione per il cluster database.
**API RDS**
Richiama l'[operazione Modify DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) API e specifica il nome del cluster DB per il `DBClusterIdentifier` parametro e `true` per il `AutoMinorVersionUpgrade` parametro. Facoltativamente, impostare il parametro `ApplyImmediately` su `true` per attivare immediatamente questa impostazione per il cluster database.
### Abilitazione degli aggiornamenti automatici delle versioni secondarie per singole istanze database in un cluster database Aurora
Eseguire la procedura generale descritta in [Modifica di un'istanza database in un cluster database](Aurora.Modifying.md#Aurora.Modifying.Instance).
**Console**
Nella pagina **Modifica istanza database**, nella sezione **Manutenzione** selezionare la casella di controllo **Abilita aggiornamento automatico versione secondaria**.
**AWS CLI**
Chiamare il comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) AWS CLI . Specifica il nome dell’istanza database per l’opzione `--db-instance-identifier` e `true` per l’opzione `--auto-minor-version-upgrade`. Facoltativamente, specifica l’opzione `--apply-immediately` per attivare immediatamente questa impostazione per l’istanza database. Esegui un comando `modify-db-instance` separato per ogni istanza database presente nel cluster.
**API RDS**
Chiama [l'operazione Modify DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API e specifica il nome del cluster DB per il `DBInstanceIdentifier` parametro e `true` per il `AutoMinorVersionUpgrade` parametro. Facoltativamente, imposta il parametro `ApplyImmediately` su `true` per attivare immediatamente questa impostazione per l’istanza database. Chiama un’operazione `ModifyDBInstance` separata per ogni istanza database presente nel cluster.
È possibile utilizzare un comando CLI come il seguente per verificare lo stato dell’impostazione `AutoMinorVersionUpgrade` per tutte le istanze database nei cluster Aurora MySQL.
```
aws rds describe-db-instances \
--query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'
```
Questo comando genera un output simile al seguente:
```
[
{
"DBInstanceIdentifier": "db-writer-instance",
"DBClusterIdentifier": "my-db-cluster-57",
"AutoMinorVersionUpgrade": true
},
{
"DBInstanceIdentifier": "db-reader-instance1",
"DBClusterIdentifier": "my-db-cluster-57",
"AutoMinorVersionUpgrade": false
},
{
"DBInstanceIdentifier": "db-writer-instance2",
"DBClusterIdentifier": "my-db-cluster-80",
"AutoMinorVersionUpgrade": true
},
... output omitted ...
```
In questo esempio, l’impostazione **Abilita aggiornamento automatico versione secondaria** è disattivata per il cluster di database `my-db-cluster-57`, perché è disattivata per una delle istanze database del cluster.
## Aggiornamenti del sistema operativo per i cluster Aurora DB
Le istanze database nei cluster database Aurora MySQL e Aurora PostgreSQL richiedono occasionalmente aggiornamenti del sistema operativo. Amazon RDS aggiorna il sistema operativo a una versione più recente per migliorare le prestazioni del database e la posizione di sicurezza generale dei clienti. In genere, gli aggiornamenti richiedono circa 10 minuti. Gli aggiornamenti del sistema operativo non modificano la versione del motore database o la classe istanza database di un’istanza database.
Esistono due tipi di aggiornamenti del sistema operativo, differenziati dalla descrizione dell’azione di manutenzione in sospeso:
+ **Aggiornamento della distribuzione del sistema operativo**: utilizzato per eseguire la migrazione alla versione principale supportata più recente di Amazon Linux. La sua descrizione è `New Operating System upgrade is available`.
+ **Patch del sistema operativo**: utilizzata per applicare varie correzioni di sicurezza e talvolta per migliorare le prestazioni del database. La sua descrizione è `New Operating System patch is available`.
Gli aggiornamenti del sistema operativo possono essere facoltativi o obbligatori:
+ Un **aggiornamento facoltativo** può essere applicato in qualsiasi momento. Sebbene questi aggiornamenti siano facoltativi, ti consigliamo di applicarli periodicamente per mantenere aggiornato il parco istanze RDS. RDS *non* applica automaticamente questi aggiornamenti.
Per ricevere una notifica quando diventa disponibile una nuova patch facoltativa del sistema operativo, è possibile iscriversi a [RDS-EVENT-0230](USER_Events.Messages.md#RDS-EVENT-0230) nella categoria degli eventi di applicazione delle patch di sicurezza. Per informazioni sulla sottoscrizione agli eventi RDS, consulta [Sottoscrizione alle notifiche eventi di Amazon RDS](USER_Events.Subscribing.md).
**Nota**
`RDS-EVENT-0230` non si applica agli aggiornamenti di distribuzione del sistema operativo.
+ È richiesto un **aggiornamento obbligatorio**. Viene inviata una notifica prima dell’aggiornamento obbligatorio. La notifica potrebbe contenere una data di scadenza. Pianificare la programmazione dell’aggiornamento prima di questa data di scadenza. Dopo la data di scadenza specificata, Amazon RDS aggiorna automaticamente il sistema operativo per l’istanza database alla versione più recente durante una delle finestre di manutenzione assegnate.
Gli aggiornamenti della distribuzione del sistema operativo sono obbligatori.
**Nota**
Potrebbe essere necessario rimanere aggiornati su tutti gli aggiornamenti facoltativi e obbligatori per soddisfare vari obblighi di conformità. Si consiglia di applicare regolarmente tutti gli aggiornamenti resi disponibili da RDS durante le finestre di manutenzione.
Per i cluster Aurora database, è possibile utilizzare l’opzione di manutenzione a **livello di cluster** per eseguire aggiornamenti del sistema operativo (OS). Trova l’opzione per eseguire aggiornamenti a livello di cluster nella scheda **Manutenzione e backup** quando selezioni il nome del tuo cluster di database nella console `os-upgrade` o usi il comando in AWS CLI. Questo metodo preserva la disponibilità di lettura con aggiornamenti continui che applicano automaticamente gli aggiornamenti a poche istanze database di lettura alla volta. Per evitare failover multipli e ridurre tempo di inattività non necessario, Aurora aggiorna l’istanza database di scrittura per ultima.
Gli aggiornamenti del sistema operativo a livello di cluster vengono eseguiti durante la finestra di manutenzione specificata per il cluster. Questo garantisce aggiornamenti coordinati su tutto il cluster.
Per la compatibilità con le versioni precedenti, Aurora mantiene anche l’opzione di manutenzione **a livello di istanza**. Consigliamo, tuttavia, di utilizzare aggiornamenti a livello di cluster. Se è necessario utilizzare aggiornamenti a livello di istanza, aggiornare prima le istanze database di lettura in un cluster di database, quindi aggiornare l’istanza database di scrittura. Se aggiorni le istanze di lettura e scrittura contemporaneamente, aumenti la possibilità di tempi di inattività dovuti al failover. Trova l’opzione per eseguire aggiornamenti a livello di istanza nella scheda **Manutenzione e backup** quando selezioni il nome dell’istanza database nella console o utilizzi il comando `system-update` in AWS CLI.
Gli aggiornamenti del sistema operativo a livello di istanza avvengono durante la finestra di manutenzione specificata per ogni rispettiva istanza. Ad esempio, se un cluster e due istanze di lettura hanno orari di manutenzione diversi, un aggiornamento del sistema operativo a livello di cluster si allinea alla finestra di manutenzione del cluster.
È possibile utilizzare Console di gestione AWS o the AWS CLI per ottenere informazioni sul tipo di aggiornamento del sistema operativo.
### Console
**Per ottenere informazioni di aggiornamento, utilizzare Console di gestione AWS**
1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel riquadro di navigazione, seleziona **Databases** (Database), quindi scegli l’istanza database.
1. Scegliere **Manutenzione e backup**.
1. Nella sezione **Manutenzione in sospeso**, trova l’aggiornamento del sistema operativo e controlla il valore **Descrizione**.
Le immagini seguenti mostrano un cluster di database con un’istanza database di scrittura con una patch del sistema operativo disponibile.
![\[Patch del sistema operativo a livello di cluster.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/os-upgrade-cluster-minor.png)
![\[Patch del sistema operativo a livello di istanza.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/os-upgrade-writer-minor.png)
Le seguenti immagini mostrano un cluster di database con un’istanza database di scrittura e un’istanza database di lettura. L’istanza di scrittura dispone di un aggiornamento obbligatorio del sistema operativo. L’istanza di lettura dispone di una patch del sistema operativo.
![\[Aggiornamento della distribuzione del sistema operativo a livello di cluster.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/os-upgrade-cluster-major.png)
![\[Aggiornamento della distribuzione del sistema operativo a livello di istanza di scrittura.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/os-upgrade-writer-major.png)
![\[Patch del sistema operativo per istanze di lettura.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/os-upgrade-reader-minor.png)
### AWS CLI
Per ottenere informazioni di aggiornamento da AWS CLI, usa il [describe-pending-maintenance-actions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-pending-maintenance-actions.html)comando.
```
aws rds describe-pending-maintenance-actions
```
Il seguente output mostra un aggiornamento della distribuzione del sistema operativo per un cluster di database e un’istanza database.
```
{
"PendingMaintenanceActions": [
{
"ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:cluster:t3",
"PendingMaintenanceActionDetails": [
{
"Action": "os-upgrade",
"Description": "New Operating System upgrade is available"
}
]
},
{
"ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:db:t3-instance1",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "New Operating System upgrade is available"
}
]
},
]
}
```
Il seguente output mostra un patch del sistema operativo per un’istanza database.
```
{
"ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:db:mydb2",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "New Operating System patch is available"
}
]
}
```
### Disponibilità di aggiornamenti del sistema operativo
Gli aggiornamenti del sistema operativo sono specifici per la versione del motore database e la classe istanza database. Pertanto, le istanze database ricevono o richiedono aggiornamenti in momenti diversi. Se è disponibile un aggiornamento del sistema operativo per l’istanza database basato sulla versione del motore e sulla classe di istanza, l’aggiornamento viene visualizzato nella console. Può essere visualizzato anche eseguendo il [describe-pending-maintenance-actions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-pending-maintenance-actions.html) AWS CLI comando o chiamando l'operazione API [DescribePendingMaintenanceActions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribePendingMaintenanceActions.html)RDS. Se è disponibile un aggiornamento per l’istanza, puoi aggiornare il sistema operativo seguendo le istruzioni in [Applicazione degli aggiornamenti a un cluster di DB](#USER_UpgradeDBInstance.OSUpgrades).
# Utilizzo della politica di implementazione degli AWS Organizations aggiornamenti per gli aggiornamenti automatici delle versioni secondarie
Aurora supporta la politica di implementazione degli AWS Organizations aggiornamenti per gestire gli aggiornamenti automatici delle versioni secondarie su più risorse di database e. Account AWS Questa policy consente di implementare una strategia di aggiornamento controllata per i cluster mediante:
**Come funziona la politica di implementazione degli aggiornamenti**
Quando una nuova versione secondaria del motore diventa idonea per l'aggiornamento automatico, la policy controlla la sequenza di aggiornamento in base a ordini definiti:
+ Le risorse contrassegnate come [prime] (in genere ambienti di sviluppo) diventano idonee per gli aggiornamenti durante le rispettive finestre di manutenzione.
+ Dopo un determinato periodo di cottura, le risorse contrassegnate come [seconde] diventano idonee.
+ Dopo un altro periodo di cottura designato, le risorse contrassegnate come [ultime] (in genere ambienti di produzione) diventano idonee.
+ Monitoraggio dell'avanzamento dell'aggiornamento tramite notifiche AWS Health.
Puoi definire i tuoi ordini di upgrade in base a:
+ Politiche a livello di account: si applicano a tutte le risorse idonee in account specifici.
+ Tag delle risorse: si applicano a risorse specifiche in base ai tag.
**Nota**
Le risorse non configurate con una politica di aggiornamento o escluse dalla politica ricevono automaticamente un ordine di aggiornamento di [secondo].
**Prerequisiti**
+ Account AWS È necessario far parte di un'organizzazione in Organizzazioni con la politica di implementazione degli aggiornamenti abilitata
+ Abilita gli aggiornamenti automatici delle versioni secondarie per i tuoi cluster
+ I tag non sono strettamente necessari per la politica di implementazione degli aggiornamenti. Se desideri definire ordini di aggiornamento specifici per ambienti diversi (ad esempio sviluppo, test, controllo qualità, produzione), puoi utilizzare i tag. Se non includi le impostazioni dei tag nella tua politica, tutte le risorse soggette a tale politica seguono l'ordine di aggiornamento predefinito. Per le risorse Aurora, vengono utilizzati solo tag a livello di cluster per la politica di implementazione dell'aggiornamento, anche se i tag sono definiti a livello di istanza.
**Per etichettare le tue risorse**
1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel pannello di navigazione, seleziona **Database**.
1. Scegli il cluster a cui vuoi taggare.
1. Scegli **Azioni**, quindi scegli **Gestisci tag**.
1. Seleziona **Aggiungi tag**.
1. Inserisci la chiave del tag (ad esempio «Ambiente») e il valore (ad esempio, «Sviluppo»)
1. Scegli **Aggiungi tag**, quindi **Salva**.
Puoi anche aggiungere tag usando AWS CLI:
```
aws rds add-tags-to-resource \
--resource-name arn:aws:rds:region:account-number:cluster:cluster-name \
--tags Key=Environment,Value=Development
```
## Ordine e fasi di aggiornamento
La politica di implementazione dell'aggiornamento supporta tre ordini di aggiornamento:
+ [primo] - In genere utilizzato per ambienti di sviluppo o test
+ [secondo] - Utilizzato in genere per ambienti di controllo qualità. Ordine predefinito per le risorse se la politica non è configurata in modo specifico
+ [ultimo] - Solitamente riservato agli ambienti di produzione
Quando una nuova versione secondaria del motore diventa idonea per l'aggiornamento automatico:
+ Le risorse con ordine di aggiornamento [first] diventano idonee per gli aggiornamenti durante le finestre di manutenzione configurate.
+ Dopo un determinato periodo di attesa, le risorse con ordine di aggiornamento [secondo] diventano idonee per gli aggiornamenti durante i periodi di manutenzione.
+ Dopo un altro periodo di attesa prestabilito, le risorse con ordine di aggiornamento [ultimo] diventano idonee per gli aggiornamenti durante le rispettive finestre di manutenzione.
+ La campagna di aggiornamento automatico della versione secondaria si chiude dopo che tutte le risorse idonee con ordini di upgrade [primo], [secondo] e [ultimo] sono stati aggiornati o quando la campagna raggiunge la data di fine pianificata, a seconda di quale evento si verifica per primo.
**Nota**
Tutti gli aggiornamenti automatici delle versioni secondarie vengono eseguiti durante la finestra di manutenzione configurata di ciascun cluster per ridurre al minimo il potenziale impatto sulle applicazioni.
## Osservabilità
### AWS Health e monitoraggio
Ricevi notifiche AWS sanitarie:
+ Prima dell'inizio di una campagna automatica di aggiornamento di una versione secondaria
+ Transizione tra una fase e l'altra per tracciare e monitorare l'avanzamento dell'aggiornamento
+ Aggiornamenti sui progressi che mostrano il numero di risorse potenziate per tutta la flotta nella console AWS Health
Notifiche di eventi Amazon RDS:
+ Notifiche per le risorse abilitate per gli aggiornamenti automatici delle versioni secondarie, tra cui:
+ Quando la risorsa diventa idonea per l'aggiornamento in base al relativo ordine di aggiornamento ([primo], [secondo] o [ultimo])
+ Cronologia pianificata dell'aggiornamento durante la finestra di manutenzione
+ Stato di inizio e completamento dell'aggiornamento individuale del database
+ Iscriviti a questi eventi tramite Amazon EventBridge 0 per il monitoraggio automatizzato
### Considerazioni
Alcune considerazioni da tenere a mente:
+ La politica si applica a tutte le future campagne di aggiornamento automatico delle versioni secondarie, comprese le modifiche alle norme apportate durante le campagne attive.
+ Se partecipi a una campagna di upgrade in corso, le tue risorse seguono l'ordine di aggiornamento in corso e non attendono una politica configurata.
+ Le risorse non configurate con una politica di aggiornamento o escluse dalla politica ricevono automaticamente un ordine di aggiornamento di [secondo].
+ La policy prevede periodi di convalida tra le fasi di aggiornamento prima di passare alla fase successiva.
+ Le modifiche ai criteri o ai tag delle risorse richiedono tempo per propagarsi prima che venga applicato il nuovo ordine di aggiornamento.
+ La policy si applica solo alle risorse Aurora con aggiornamenti automatici delle versioni secondarie abilitati.
+ Se si rileva un problema all'interno di un ambiente, è possibile disattivare gli aggiornamenti automatici delle versioni secondarie per gli ambienti successivi o utilizzare il periodo di convalida per risolvere i problemi prima che gli aggiornamenti passino all'ordine di aggiornamento successivo.
Per ulteriori informazioni sull'etichettatura delle risorse RDS, vedere. [Etichettatura delle risorse Amazon Aurora e Amazon RDS](USER_Tagging.md) *Per istruzioni dettagliate sulla configurazione e l'utilizzo della politica di implementazione degli aggiornamenti, consulta [Guida introduttiva AWS Organizations nella Guida per l'](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started.html)AWS Organizations utente.*