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 Amazon DocumentDB
Amazon DocumentDB esegue periodicamente due tipi di manutenzione:
+ La **manutenzione del cluster** aggiorna il motore del database. Gli aggiornamenti del motore includono correzioni di sicurezza, correzioni di bug, nuove funzionalità e altri miglioramenti del motore.
+ La **manutenzione dell'istanza** aggiorna il sistema operativo (OS) sull'istanza.
Le patch del motore e gli aggiornamenti del sistema operativo utilizzano le stesse tre categorie del ciclo di vita, *facoltative*, *obbligatorie* e *forzate*, con lo stesso comportamento di notifica e applicazione per ciascuna categoria. Le versioni del motore hanno anche una quarta categoria: *le versioni secondarie*, a cui si esegue l'aggiornamento manualmente. Le categorie sono:
+ **Facoltativo**: contiene miglioramenti non critici. Nessuna data di applicazione automatica e nessuna notifica AHD; applica quando preferisci. (Per gli aggiornamenti del sistema operativo, puoi abbonarti `RDS-EVENT-0230` per ricevere una notifica quando uno sarà disponibile.)
+ **Obbligatorio**: contiene correzioni di sicurezza e altre correzioni critiche. Riceverai una notifica tramite Health Dashboard (AHD) ed e-mail. Un'azione richiesta si applica automaticamente durante la finestra di manutenzione del cluster o dell'istanza successiva. `AutoAppliedAfterDate` È possibile differire modificando la finestra di manutenzione prima di tale data.
+ **Forzata**: una correzione rara e molto critica. Auto-applies fuori dalla finestra di manutenzione dopo la sua`ForcedApplyDate`. Amazon DocumentDB indica un'azione forzata solo quando non sono disponibili altre opzioni.
+ **Versione secondaria** (solo versioni del motore): una versione numerata del motore che si aggiunge a una versione principale (ad esempio,). `5.0.1` User-driven: si esegue l'aggiornamento modificando la versione del motore del cluster. Non si applica mai automaticamente; nessuna notifica AHD. Le versioni secondarie non vengono pubblicate per le versioni principali precedenti alla 5.0.
Le patch del motore vengono rilasciate in un'unica categoria (facoltative, obbligatorie o forzate) e rimangono invariate. Gli aggiornamenti del sistema operativo progrediscono: la maggior parte inizia come facoltativa e, se non viene applicata, passa a quella obbligatoria e infine forzata. La tempistica esatta dipende dalla patch e viene pubblicata nella notifica AHD e nei campi della data restituiti da `describe-pending-maintenance-actions` (vedi[Applica le date](#db-instance-updates-apply-date)). Le [note di rilascio](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) di Amazon DocumentDB utilizzano questi nomi di categoria per annunciare le modifiche al motore.
L'applicazione di qualsiasi patch al motore porta il cluster offline per un breve periodo. Il resto di questo argomento illustra come funzionano le finestre di manutenzione, come trovare i lavori in sospeso, come applicare le patch del motore e le versioni secondarie, come funzionano gli aggiornamenti del sistema operativo e la gestione speciale per i cluster globali.
**Topics**
+ [Numerazione delle versioni del motore](#engine-version-numbering)
+ [Gestione delle finestre di manutenzione di Amazon DocumentDB](#maintenance-window)
+ [Notifiche per le patch del motore Amazon DocumentDB](#patch-notifications)
+ [Visualizzazione delle azioni di manutenzione in sospeso di Amazon DocumentDB](#view-pending-maintenance)
+ [Aggiornamenti del motore Amazon DocumentDB](#db-instance-updates-apply)
+ [Aggiornamenti a versioni secondarie](#minor-version-upgrades)
+ [Aggiornamenti del sistema operativo Amazon DocumentDB](#os-system-updates)
+ [User-initiated aggiornamenti](#user-initiated-updates)
+ [Applicazione di patch ai cluster globali](#global-clusters-patching)
## Numerazione delle versioni del motore
Amazon DocumentDB utilizza due identificatori di versione separati:
+ **Versione del motore**: un numero composto da tre parti nel modulo `{{major}}.{{major}}.{{minor}}` (ad esempio, o). `5.0.0` `5.0.1` Le prime due parti (`5.0`) sono la versione compatibile con MongoDB; la terza parte è la versione secondaria, incrementata quando Amazon DocumentDB pubblica una versione secondaria contenente correzioni di bug e miglioramenti senza interruzioni. Questa è la versione specificata durante la creazione o l'aggiornamento di un cluster.
+ **Versione della patch del motore**: un numero separato in tre parti nel modulo `{{major}}.0.{{patch}}` (ad esempio,`3.0.17983`) che identifica il livello di patch applicato al cluster. La cifra centrale è sempre. `0` Le versioni patch contengono correzioni critiche di sicurezza e stabilità.
È possibile determinare la versione del motore dal prefisso della versione della patch del motore, come mostrato nella tabella seguente.
| Prefisso della versione della patch del motore | Versione del motore Amazon DocumentDB |
| --- | --- |
| 1.0.{{x}} | 3.6 |
| 2.0.{{x}} | 4.0 |
| 3.0.{{x}} | 5.0 |
| 4.0.{{x}} | 8.0 |
Per verificare la versione della patch in esecuzione sul cluster, connettiti ed `db.runCommand({getEngineVersion: 1})` esegui.
Per l'elenco delle versioni delle patch del motore rilasciate e il contenuto di ciascuna di esse, consulta[Note di rilascio](release-notes.md).
## Gestione delle finestre di manutenzione di Amazon DocumentDB
Ogni cluster e ogni istanza hanno una propria finestra di manutenzione settimanale di 30 minuti, il periodo in cui vengono eseguite le modifiche pianificate e le patch software. La maggior parte degli eventi viene completata entro 30 minuti; quelli più grandi possono durare più a lungo.
Se non scegli una finestra durante la creazione della risorsa, Amazon DocumentDB ne assegna una a caso all'interno di un blocco giornaliero di 8 ore definito per la regione, in un giorno selezionato casualmente. Scegli finestre che riducano al minimo l'impatto sulla tua applicazione, ad esempio la sera o nei fine settimana.
Per gli aggiornamenti del motore di database, Amazon DocumentDB utilizza la finestra del cluster, non le finestre delle singole istanze.
La tabella seguente mostra i blocchi temporali predefiniti per regione.
| Nome della regione | Regione | Blocco di tempo UTC |
| --- | --- | --- |
| Stati Uniti orientali (Ohio) | us-east-2 | 03:00-11:00 |
| Stati Uniti orientali (Virginia settentrionale) | us-east-1 | 03:00-11:00 |
| Stati Uniti occidentali (Oregon) | us-west-2 | 06:00-14:00 |
| Africa (Città del Capo) | af-south-1 | 03:00 — 11:00 |
| Asia Pacific (Hong Kong) | ap-east-1 | 06:00-14:00 |
| Asia Pacifico (Hyderabad) | ap-south-2 | 06:30 — 14:30 |
| Asia Pacifico (Malesia) | ap-southeast-5 | 13:00-21:00 |
| Asia Pacifico (Mumbai) | ap-south-1 | 06:00-14:00 |
| Asia Pacifico (Osaka-Locale) | ap-northeast-3 | 12:00-20:00 |
| Asia Pacific (Seoul) | ap-northeast-2 | 13:00-21:00 |
| Asia Pacifico (Singapore) | ap-southeast-1 | 14:00-22:00 |
| Asia Pacifico (Sydney) | ap-southeast-2 | 12:00-20:00 |
| Asia Pacifico (Giacarta) | ap-southeast-3 | 08:00-16:00 |
| Asia Pacifico (Melbourne) | ap-southeast-4 | 11:00-19:00 |
| Asia Pacifico (Thailandia) | ap-southeast-7 | 15:00-23:00 |
| Asia Pacifico (Tokyo) | ap-northeast-1 | 13:00-21:00 |
| Canada (Centrale) | ca-central-1 | 03:00-11:00 |
| Canada occidentale (Calgary) | ca-west-1 | 18:00-02:00 |
| Cina (Pechino) | cn-north-1 | 06:00-14:00 |
| China (Ningxia) | cn-northwest-1 | 06:00-14:00 |
| Europa (Francoforte) | eu-central-1 | 21:00-05:00 |
| Europa (Zurigo) | eu-central-2 | 02:00-10:00 |
| Europa (Irlanda) | eu-west-1 | 22:00-06:00 |
| Europe (London) | eu-west-2 | 22:00-06:00 |
| Europe (Milan) | eu-south-1 | 02:00-10:00 |
| Europa (Parigi) | eu-west-3 | 23:59-07:29 |
| Europa (Spagna) | eu-south-2 | 02:00 — 10:00 |
| Europa (Stoccolma) | eu-north-1 | 04:00 — 12:00 |
| Messico (Centrale) | mx-central-1 | 03:00-11:00 |
| Medio Oriente (Emirati Arabi Uniti) | me-central-1 | 05:00 — 13:00 |
| Sud America (San Paolo) | sa-east-1 | 00:00-08:00 |
| Israele (Tel Aviv) | il-central-1 | 04:00-12:00 |
| AWS GovCloud (US-East) | us-gov-east-1 | 17:00-01:00 |
| AWS GovCloud (US-West) | us-gov-west-1 | 06:00-14:00 |
### Modifica delle finestre di manutenzione di Amazon DocumentDB
Scegliete la finestra con il traffico più basso possibile e modificatela nel tempo man mano che i modelli di traffico cambiano. Il cluster o l'istanza non sono disponibili durante la finestra solo se una modifica del sistema, ad esempio un'operazione di storage su scala o una modifica della classe dell'istanza, richiede un'interruzione e solo per il tempo effettivamente necessario.
**Per modificare la finestra di manutenzione**
+ Per un cluster: consulta [Modifica di un cluster Amazon DocumentDB](db-cluster-modify.md)
+ Per un'istanza: consulta [Modifica di un'istanza Amazon DocumentDB](db-instance-modify.md).
## Notifiche per le patch del motore Amazon DocumentDB
Quando una patch del motore *richiesta* diventa disponibile in una AWS regione, ogni AWS account con un cluster Amazon DocumentDB interessato in quella regione riceve una notifica tramite Health Dashboard (AHD) e tramite e-mail (inviata all'indirizzo utente root dell' AWS account). Viene inviata una notifica per ogni versione del motore Amazon DocumentDB interessata. Puoi trovarle nella sezione **Modifiche pianificate** nell'AHD. Ogni notifica elenca i tempi di disponibilità delle patch, la pianificazione dell'applicazione automatica, i cluster interessati e le note di rilascio.
Le notifiche vengono inviate circa due giorni prima dell'apertura della finestra di applicazione automatica. Ad esempio, una patch obbligatoria rilasciata lunedì alle 00:00 UTC diventa idonea per l'applicazione automatica mercoledì alle 00:00 UTC. Se la finestra di manutenzione del cluster è mercoledì alle 12:00 UTC, la patch si applica automaticamente quel mercoledì, circa 12 ore dopo l'apertura della finestra di applicazione automatica. Se la finestra di manutenzione è martedì alle 12:00 UTC, la patch attende un'intera settimana prima di applicarsi automaticamente.
Hai due opzioni dopo aver ricevuto la notifica: applicare automaticamente la patch prima della data di applicazione automatica o attendere che si applichi automaticamente durante una finestra di manutenzione imminente (impostazione predefinita). Per applicarla automaticamente, apri la scheda **Manutenzione e backup del cluster e** cerca la voce «type». `system-update`
**Nota**
**Lo stato** della notifica nell'AHD rimane **costante** fino a quando Amazon DocumentDB non rilascia un'altra patch del motore con una nuova versione della patch.
Dopo l'applicazione della patch, la versione della patch del motore del cluster si aggiorna in modo che corrisponda alla versione indicata nella notifica. Verifica la nuova versione eseguendo`db.runCommand({getEngineVersion: 1})`.
Le patch opzionali e le nuove versioni secondarie non generano AHD o notifiche e-mail. Per tenerne traccia, consulta le note di [rilascio](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) di Amazon DocumentDB.
Le patch forzate (la categoria più rara, riservata alle correzioni di sicurezza più critiche) vengono annunciate anche tramite AHD ed e-mail. A differenza delle patch obbligatorie, si applicano al di fuori della finestra di manutenzione, quindi l'esempio di tempistica di applicazione automatica sopra riportato non è applicabile.
### Reagire alle notifiche delle patch in modo programmatico
AWS Health si integra con Amazon EventBridge, che consente di creare applicazioni basate sugli eventi su più di 20 destinazioni, tra cui Amazon AWS Lambda Simple Queue Service (SQS). Per reagire alla disponibilità delle patch del motore in modo programmatico, esegui la configurazione in base all'evento. EventBridge `AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_SCHEDULED` Da lì puoi acquisire dati sugli eventi, generare eventi aggiuntivi, inviare notifiche push tramite o intraprendere qualsiasi altra azione necessaria. AWS Console Mobile Application
Se Amazon DocumentDB annulla una patch (rara), ricevi una notifica AHD e un'e-mail sull'annullamento. Usa il codice `AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_CANCELLED` evento con Amazon EventBridge per gestire questo caso. Per ulteriori informazioni sulla scrittura delle regole, consulta la [Amazon EventBridge User Guide](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html).
## Visualizzazione delle azioni di manutenzione in sospeso di Amazon DocumentDB
Usa Console di gestione AWS o il AWS CLI per verificare quale manutenzione è in sospeso per un cluster o un'istanza.
Gli aggiornamenti in sospeso vengono visualizzati con il tipo di azione`system-update`, che copre sia le patch del motore che gli aggiornamenti del sistema operativo.
Quando un aggiornamento è in sospeso, puoi:
+ Applicalo immediatamente.
+ Pianificalo per la prossima finestra di manutenzione.
+ Rimandala (solo patch del motore e aggiornamenti del sistema operativo) modificando prima la finestra di manutenzione. `AutoAppliedAfterDate` Una volta trascorsa tale data, l'azione verrà applicata automaticamente durante la finestra di manutenzione successiva. Una volta `ForcedApplyDate` approvata, non è possibile alcun ulteriore rinvio.
**Nota**
Se non intraprendi alcuna azione, le azioni di manutenzione richieste, come le patch necessarie al motore, si applicano automaticamente durante una finestra di manutenzione imminente. Le patch opzionali e le versioni secondarie non si applicano mai automaticamente.
La finestra di manutenzione controlla quando *iniziano* le operazioni in sospeso, non il tempo necessario per completarle.
------
#### [ Using the Console di gestione AWS ]
1. Accedi a e apri Console di gestione AWS la console Amazon DocumentDB all'indirizzo. [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb)
1. Nel pannello di navigazione scegliere **Cluster**.
1. La colonna **Manutenzione** del cluster mostra **Available**, **Required** o **Next Window** quando un aggiornamento è in sospeso.
1. Apri il cluster, quindi scegli **Manutenzione e backup** per visualizzare gli elementi di **manutenzione in sospeso** e agire di conseguenza.
------
#### [ Using the AWS CLI ]
Esegui `describe-pending-maintenance-actions` per vedere cosa c'è in sospeso. L'esempio seguente mostra un account senza azioni in sospeso.
```
aws docdb describe-pending-maintenance-actions
```
L'aspetto dell'output di questa operazione è simile al seguente (formato JSON).
```
{
"PendingMaintenanceActions": []
}
```
Un account con un'azione in sospeso restituisce un output simile al seguente:
```
{
"PendingMaintenanceActions": [
{
"ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:cluster:sample-cluster",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "db-version-upgrade",
"CurrentApplyDate": "2026-05-15T03:01:00Z",
"AutoAppliedAfterDate": "2026-05-15T03:01:00Z"
}
]
}
]
}
```
Puoi estendere l'elenco a cluster specifici con`--filters`, nel modulo. `Name={{filter-name}},Values={{resource-id}},...` Il filtro accettato `Name` è`db-cluster-id`, che richiede un elenco di identificatori di cluster o ARN.
**Example**
Per Linux, macOS o Unix:
```
aws docdb describe-pending-maintenance-actions \
--filters Name=db-cluster-id,Values={{sample-cluster1}},{{sample-cluster2}}
```
Per Windows:
```
aws docdb describe-pending-maintenance-actions ^
--filters Name=db-cluster-id,Values={{sample-cluster1}},{{sample-cluster2}}
```
------
### Applica le date
Ogni azione di manutenzione in sospeso prevede fino a tre date di applicazione. Vengono visualizzate nell' AWS CLI output di `describe-pending-maintenance-actions` e indicano quando verrà eseguita l'azione. I campi sono `null` per la manutenzione facoltativa.
+ **CurrentApplyDate**—quando è pianificata l'esecuzione dell'azione, ora o nella finestra di manutenzione successiva. Compilato per le azioni obbligatorie e forzate.
+ **AutoAppliedAfterDate**—la data dopo la quale inizia l'applicazione automatica durante la finestra di manutenzione del cluster o dell'istanza. Compilato per le azioni richieste.
+ **ForcedApplyDate**—la scadenza rigida. Dopo questa data l'azione viene eseguita automaticamente, indipendentemente dalla finestra di manutenzione. Popolato per azioni forzate.
Per rimandare un'azione in sospeso, sposta la finestra di manutenzione a un giorno successivo precedente. `AutoAppliedAfterDate` Una `AutoAppliedAfterDate` volta completata, l'azione verrà applicata automaticamente durante la finestra di manutenzione successiva. Una volta `ForcedApplyDate` approvata, non è possibile alcun ulteriore rinvio. L'esatta finestra di differimento varia a seconda della patch; le date sono pubblicate nella notifica AHD e nell'output. AWS CLI
## Aggiornamenti del motore Amazon DocumentDB
Una volta identificata una patch del motore in sospeso, utilizzate una delle seguenti procedure per applicarla o programmarla. È possibile eseguire queste procedure da Console di gestione AWS o da. AWS CLI
------
#### [ Using the Console di gestione AWS ]
**Per gestire un aggiornamento per un cluster**
1. Accedi a e apri Console di gestione AWS la console Amazon DocumentDB all'indirizzo. [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb)
1. Nel pannello di navigazione scegliere **Cluster**.
1. Seleziona il cluster che desideri aggiornare.
1. Dal menu **Azioni**, scegli una delle seguenti opzioni:
+ **Effettua subito l'upgrade**: esegui immediatamente la manutenzione in sospeso.
+ **Esegui l'aggiornamento alla finestra successiva**: eseguilo durante la successiva finestra di manutenzione del cluster.
Puoi anche utilizzare **Applica ora** o **Applica alla prossima finestra di manutenzione** dalla sezione **Manutenzione in sospeso** della scheda **Manutenzione e backup** del cluster (vedi). [Visualizzazione delle azioni di manutenzione in sospeso di Amazon DocumentDB](#view-pending-maintenance)
**Nota**
Se non c'è nulla in sospeso, tutte queste opzioni sono inattive.
------
#### [ Using the AWS CLI ]
Applica un aggiornamento in sospeso con. `apply-pending-maintenance-action`
**Parameters**
+ **--resource-identifier**—Amazon DocumentDB Amazon Resource Name (ARN) della risorsa a cui sono destinate le azioni in sospeso.
+ **--apply-action**—l'azione di manutenzione in sospeso da applicare. Valori validi: `system-update`, `db-upgrade`.
+ **--opt-in-type**—il tipo di richiesta di consenso o l'eventuale annullamento di una richiesta. Valori validi:
+ `immediate`—applica ora. Non può essere annullato una volta inviato.
+ `next-maintenance`: si applica durante la prossima finestra di manutenzione della risorsa.
+ `undo-opt-in`—annulla un opt-in esistente`next-maintenance`.
**Example**
Per Linux, macOS o Unix:
```
aws docdb apply-pending-maintenance-action \
--resource-identifier arn:aws:rds:us-east-1:{{123456789012}}:db:{{sample-cluster-instance-1}} \
--apply-action system-update \
--opt-in-type immediate
```
Per Windows:
```
aws docdb apply-pending-maintenance-action ^
--resource-identifier arn:aws:rds:us-east-1:{{123456789012}}:db:{{sample-cluster-instance-1}} ^
--apply-action system-update ^
--opt-in-type immediate
```
------
### Leggi la disponibilità durante l'applicazione delle patch
I motori Amazon DocumentDB 5.0 e 8.0 preservano la disponibilità di lettura durante l'applicazione delle patch quando il cluster ha più istanze. Amazon DocumentDB applica le patch alle istanze di Reader in tre gruppi, in modo che i lettori rimanenti continuino a servire il traffico. Lo scrittore non è disponibile per un breve periodo durante l'applicazione delle patch. Per azzerare i tempi di inattività in lettura, impostate le vostre preferenze di lettura in modo che le letture possano essere affidate all'autore: `secondaryPreferred` o `primaryPreferred` funzionino; `primary` oppure, `secondary` da sole, potrebbero verificarsi dei tempi di inattività in lettura.
| Modalità di preferenza di lettura | Durante l'aggiornamento dello scrittore | Durante l'aggiornamento del lettore | Numero minimo di lettori necessario per azzerare i tempi di inattività in lettura |
| --- | --- | --- | --- |
| primary | Read/write tempi di inattività | Nessun impatto | N/A |
| primaryPreferred | Annota i tempi di inattività | Nessun impatto | 1 |
| secondary | Annota i tempi di inattività | Interruzioni di lettura (se si tratta di un solo lettore) | 2 |
| secondaryPreferred | Annota i tempi di inattività | Nessun impatto | 1 |
| nearest | Annota i tempi di inattività | Nessun impatto | 1 |
Mentre i lettori stanno applicando le patch, la velocità di lettura complessiva del cluster diminuisce temporaneamente. Per mantenere costante la velocità di trasmissione, è necessario fornire lettori aggiuntivi prima dell'aggiornamento e rimuoverli una volta completato.
Sui motori 3.6 e 4.0, queste funzionalità di disponibilità di lettura non sono applicabili: una patch del motore causa tempi di inattività più lunghi che influiscono sia in lettura che in scrittura. Per eseguire l'aggiornamento a una versione principale che lo consenta, consulta. [Aggiornamento immediato della versione principale di Amazon DocumentDB](docdb-mvu.md)
### Durata del periodo di inattività delle patch
Engine-patch i tempi di inattività variano. I fattori principali sono l'utilizzo della CPU e la pressione della memoria sull'istanza al momento della patch, quindi il corretto dimensionamento delle istanze è importante. Per ridurre al minimo i tempi di inattività, esegui la versione più recente del motore principale di Amazon DocumentDB e distribuisci le istanze su più zone di disponibilità.
### Aggiornamenti e sostituzioni delle patch
Amazon DocumentDB monitora le patch dopo il rilascio. Nel raro caso in cui venga identificato un problema, Amazon DocumentDB sospende l'implementazione mentre prepara una versione aggiornata. Quando ciò accade, i cluster che non hanno ancora ricevuto la patch non la vedono più come un'azione di manutenzione disponibile e la corrispondente notifica di modifica pianificata in viene ritirata. Health Dashboard I cluster che già eseguono la versione interessata continuano a funzionare normalmente e non richiedono alcuna azione da parte dell'utente.
A breve seguirà una patch aggiornata. Quando sarà disponibile nella tua regione, riceverai una nuova notifica tramite Health Dashboard e e-mail, proprio come descritto in[Notifiche per le patch del motore Amazon DocumentDB](#patch-notifications).
## Aggiornamenti a versioni secondarie
Amazon DocumentDB pubblica versioni secondarie oltre alla versione principale 5.0 e successive (ad esempio,). `5.0.1` Le versioni secondarie non vengono pubblicate per le versioni principali precedenti alla 5.0. Le versioni minori si comportano in modo diverso dalle patch del motore obbligatorie e opzionali:
+ Non appaiono come azioni di manutenzione in sospeso e non vengono mai applicate automaticamente.
+ Non generano AHD o notifiche e-mail. Le nuove versioni minori sono annunciate nelle note di [rilascio](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) di Amazon DocumentDB.
+ Per eseguire l'aggiornamento, è necessario modificare la versione del motore del cluster (immediatamente o durante la successiva finestra di manutenzione). Gli aggiornamenti delle versioni minori richiedono brevi tempi di inattività e sono unidirezionali: non è possibile effettuare il downgrade a una versione secondaria precedente. Per i cluster globali, aggiorna i cluster secondari prima di quelli primari.
Per saperne di più:. [Aggiornamento della versione secondaria di Amazon DocumentDB](docdb-minor-version-upgrade.md)
## Aggiornamenti del sistema operativo Amazon DocumentDB
Le istanze richiedono occasionalmente aggiornamenti del sistema operativo. Amazon DocumentDB aggiorna il sistema operativo per migliorare le prestazioni e rafforzare la sicurezza. Gli aggiornamenti del sistema operativo lasciano invariate la versione del motore del cluster e la classe dell'istanza. Analogamente alle patch per i motori, gli aggiornamenti del sistema operativo utilizzano il ciclo di vita facoltativo /obbligatorio/forzato descritto all'inizio di questo argomento; a differenza delle patch per i motori, un aggiornamento del sistema operativo può passare da una categoria all'altra nel tempo se lo si rinvia. Applica gli aggiornamenti del sistema operativo non appena sono disponibili e imposta la finestra di manutenzione dell'istanza su un orario adatto alla tua attività.
Per ricevere un evento quando arriva un nuovo aggiornamento opzionale, iscriviti alla `RDS-EVENT-0230` categoria degli eventi di patch di sicurezza. Per maggiori dettagli, consulta [Sottoscrizione agli abbonamenti agli eventi di Amazon DocumentDB.](https://docs.aws.amazon.com/documentdb/latest/devguide/event-subscriptions.subscribe.html) Dopo aver ricevuto una notifica, puoi applicare automaticamente la patch del sistema operativo a ciascuna istanza.
Quando applichi una patch a un cluster, aggiorna prima le istanze del lettore e per ultimo l'autore. Evitate di applicare le patch a reader e writer contemporaneamente: un failover durante la patch può prolungare i tempi di inattività. La manutenzione sull'istanza principale attiva un failover, quindi esegui più di un'istanza per cluster per rimanere disponibile. Per informazioni dettagliate, vedi [Failover di Amazon DocumentDB](failover.md).
**Importante**
L'istanza Amazon DocumentDB va offline per l'aggiornamento del sistema operativo. Multi-instance i cluster riducono al minimo l'impatto. Se si esegue un cluster a istanza singola, è possibile aggiungere temporaneamente un cluster secondario per l'aggiornamento e rimuoverlo successivamente. Il secondario comporta i normali costi finché esiste.
**Nota**
Per motivi di conformità potrebbe essere necessario mantenersi aggiornati sugli aggiornamenti facoltativi e obbligatori. Applica regolarmente gli aggiornamenti disponibili durante le finestre di manutenzione.
Gli aggiornamenti del sistema operativo sono legati a versioni del motore e classi di istanze specifiche, quindi istanze diverse diventano idonee in momenti diversi. Quando un'istanza è idonea, l'aggiornamento viene visualizzato nella console; puoi anche visualizzarlo tramite il AWS CLI `describe-pending-maintenance-actions` comando o l'`DescribePendingMaintenanceActions`API.
**Nota**
Se il cluster non utilizza l'ultima versione di patch del motore Amazon DocumentDB, un aggiornamento del sistema operativo potrebbe non apparire come disponibile. Applica prima la patch più recente al motore, quindi ricontrolla.
Usa Console di gestione AWS o AWS CLI per verificare se è disponibile un aggiornamento.
------
#### [ Using the Console di gestione AWS ]
Per verificare la disponibilità di un aggiornamento del sistema operativo dalla console:
1. Accedi a e apri Console di gestione AWS la console Amazon DocumentDB all'indirizzo. [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb)
1. Nel pannello di navigazione scegliere **Cluster**. **L'elenco mostra sia i cluster che le istanze al loro interno, distinti dalla colonna Ruolo.**
1. Seleziona la riga il cui **ruolo** è **Istanza** (non la riga del cluster). Gli aggiornamenti del sistema operativo si applicano alle istanze, non ai cluster.
1. **Scegli Manutenzione.**
1. Consulta la sezione **Manutenzione in sospeso** per l'aggiornamento del sistema operativo.
Dalla sezione **Manutenzione in sospeso**, seleziona l'aggiornamento del sistema operativo e scegli **Applica ora o Applica** **alla prossima** finestra di manutenzione. Se il valore di manutenzione è **nella finestra successiva**, puoi posticipare l'aggiornamento con **Defer upgrade** purché non sia ancora iniziato.
**Puoi farlo anche dall'elenco dei cluster: nel riquadro di navigazione, scegli **Cluster**, seleziona la riga il cui **ruolo** è **Istanza** e scegli **Applica ora o Applica** **alla prossima finestra di manutenzione** dal menu Azioni.**
------
#### [ Using the AWS CLI ]
Da AWS CLI, `describe-pending-maintenance-actions` esegui:
```
aws docdb describe-pending-maintenance-actions
```
```
{
"PendingMaintenanceActions": [
{
"ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:db:sample-cluster-instance-1",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "New Operating System update is available"
}
]
}
]
}
```
------
## User-initiated aggiornamenti
Alcune modifiche possono essere avviate autonomamente, ad esempio lo scambio di una classe di istanza con una classe con più o meno memoria o la modifica del gruppo di parametri del cluster. Amazon DocumentDB li tratta in modo diverso dagli aggiornamenti che avvia. Per maggiori dettagli, consulta:
+ [Modifica di un cluster Amazon DocumentDB](db-cluster-modify.md)
+ [Modifica di un'istanza Amazon DocumentDB](db-instance-modify.md)
Per elencare le modifiche avviate dall'utente che sono ancora in sospeso:
**Example**
**Per elencare le modifiche in sospeso avviate dall'utente per le tue istanze**
Per Linux, macOS o Unix:
```
aws docdb describe-db-instances \
--query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'
```
Per Windows:
```
aws docdb describe-db-instances ^
--query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'
```
L'aspetto dell'output di questa operazione è simile al seguente (formato JSON).
In questo esempio, `sample-cluster-instance` ha una modifica in sospeso a; nessuna. `db.r5.xlarge` `sample-cluster-instance-2`
```
[
[
"sample-cluster",
"sample-cluster-instance",
{
"DBInstanceClass": "db.r5.xlarge"
}
],
[
"sample-cluster",
"sample-cluster-instance-2",
{}
]
]
```
## Applicazione di patch ai cluster globali
In un cluster globale, ogni cluster membro, primario e secondario, viene aggiornato durante la propria finestra di manutenzione. Quando una patch necessaria per il motore è disponibile in ogni regione, si riceve una notifica AHD e via e-mail. Le patch opzionali e le nuove versioni secondarie non generano notifiche; consulta le note di [rilascio di Amazon DocumentDB](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) per scoprirle.
Se lo applichi automaticamente, applica sempre prima le patch secondarie e per ultima quelle primarie. Questo ordine mantiene disponibili il failover e lo switchover per tutta la durata dell'implementazione.
**Importante**
Se per errore installi prima la patch principale, aggiorna tutte le versioni secondarie alla stessa versione il prima possibile. Il failover e lo switchover rimangono disattivati finché tutti i cluster non utilizzano la stessa versione.
Se non intraprendi alcuna azione, la patch si applica automaticamente durante la successiva finestra di manutenzione di ogni cluster: prima i secondari, poi il primario nella relativa finestra una volta completate le operazioni secondarie.
Mantieni i cluster DB primari e secondari sulla stessa versione. Il failover gestito tra regioni funziona solo su un database globale quando ogni cluster condivide la stessa versione del motore e lo stesso livello di patch. Lo stesso vale se aggiungi un nuovo secondario che utilizza una versione del motore più recente rispetto a quella principale: crea nuovi secondari sulla versione principale prima di unirli al database globale.
Dopo una notifica di patch, aggiorna la versione principale e secondaria alla versione più recente il prima possibile per mantenere funzionanti il failover e lo switchover. Se una richiesta di failover o switchover viene rifiutata, confronta le versioni delle patch del motore tra i cluster; se non corrispondono, applica la patch disponibile sui cluster in ritardo.