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) dell'istanza.
Le patch del motore e gli aggiornamenti del sistema operativo utilizzano le stesse tre categorie del ciclo di vita * (facoltativa **, * obbligatoria e * forzata*) con lo stesso comportamento di notifica e applicazione per ciascuna categoria. Le versioni del motore hanno anche una quarta categoria: le versioni * secondarie*, alle quali è possibile eseguire 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 per `RDS-EVENT-0230` ricevere una notifica quando ne sarà disponibile uno.)
+ **Obbligatorio**: contiene correzioni di sicurezza e altre correzioni critiche. Riceverai una notifica tramite Dashboard Health (AHD) ed e-mail. Un'azione richiesta si applica automaticamente durante la finestra di manutenzione del cluster o dell'istanza successiva. `AutoAppliedAfterDate` Puoi differire modificando la finestra di manutenzione prima di tale data.
+ **Forzato**: una correzione rara e molto critica. Auto-applies fuori dalla finestra di manutenzione dopo la sua `ForcedApplyDate` scadenza. Amazon DocumentDB indica un'azione forzata solo quando nessun'altra opzione è disponibile.
+ **Versione secondaria ** (solo versioni del motore): una versione numerata del motore sopra una versione principale (ad esempio). `5.0.1` User-driven: si esegue l'upgrade 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 (opzionale, obbligatoria o forzata) e vi rimangono. Progresso degli aggiornamenti del sistema operativo: la maggior parte viene avviata come facoltativa e, se non applicata, diventa obbligatoria e infine forzata. La tempistica esatta dipende dalla patch ed è 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 di Amazon DocumentDB ](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) utilizzano questi nomi di categoria quando annunciano le modifiche al motore.
L'applicazione di qualsiasi patch del motore porta il cluster offline per un breve periodo. Il resto di questo argomento illustra come funzionano le finestre di manutenzione, come trovare il lavoro in sospeso, come applicare le patch del motore e le versioni secondarie, come funzionano gli aggiornamenti del sistema operativo e la gestione speciale dei cluster globali.
**Topics**
+ [Azioni di manutenzione per Amazon DocumentDB](#maintenance-actions)
+ [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 di Amazon DocumentDB in sospeso](#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)
## Azioni di manutenzione per Amazon DocumentDB
Le seguenti azioni di manutenzione si applicano ai cluster Amazon DocumentDB:
+ `system-update`— Aggiorna la patch del motore per il cluster Amazon DocumentDB. Per ulteriori informazioni, consulta [Aggiornamenti del motore Amazon DocumentDB](#db-instance-updates-apply).
+ `os-upgrade`— Aggiorna i sistemi operativi di tutte le istanze DB nel cluster Amazon DocumentDB, utilizzando aggiornamenti continui. Per ulteriori informazioni, consulta [Aggiornamenti del sistema operativo Amazon DocumentDB](#os-system-updates).
Le seguenti azioni di manutenzione si applicano alle istanze Amazon DocumentDB:
+ `system-update`— Aggiorna il sistema operativo dell'istanza Amazon DocumentDB. Ti consigliamo invece di utilizzare l'azione di `os-upgrade` manutenzione a livello di cluster. Per ulteriori informazioni, consulta [Aggiornamenti del sistema operativo Amazon DocumentDB](#os-system-updates).
## 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 di compatibilità con MongoDB; la terza parte è la versione secondaria, incrementata quando Amazon DocumentDB pubblica una versione secondaria contenente correzioni di bug e miglioramenti continui. 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 delle 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 rilasciate delle patch del motore 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 ha una propria finestra di manutenzione settimanale di 30 minuti, ovvero 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 entro un blocco giornaliero di 8 ore definito per la regione, in un giorno selezionato a caso. Scegli finestre che riducano al minimo l'impatto sulla tua applicazione, ad esempio di 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 | DALLE 06:30 ALLE 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 | DALLE 02:00 ALLE 10:00 |
| Europa (Stoccolma) | eu-north-1 | DALLE 04:00 ALLE 12:00 |
| Messico (Centrale) | mx-central-1 | 03:00-11:00 |
| Medio Oriente (Emirati Arabi Uniti) | me-central-1 | DALLE 05:00 ALLE 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
Scegli la finestra di traffico più bassa possibile e modificala nel tempo man mano che i tuoi schemi 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 scalabilità dello storage o una modifica della classe di istanza, richiede un'interruzione e solo per il tempo effettivamente necessario a tale modifica.
**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 Dashboard Health (AHD) e tramite e-mail (inviata all'indirizzo utente principale dell' AWS account). Viene inviata una notifica per versione del motore Amazon DocumentDB interessata. Li puoi trovare in 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 patch del motore richieste seguono un unico lead time di circa 30 giorni. Quando una patch diventa disponibile nella tua regione, Amazon DocumentDB invia la notifica sopra descritta. A quel punto, la patch `AutoAppliedAfterDate` è impostata circa 30 giorni dopo. Fino a tale data, la patch rimane in sospeso: puoi applicarla in qualsiasi momento o posticiparla spostando la finestra di manutenzione del cluster a un giorno successivo. Il giorno o dopo`AutoAppliedAfterDate`, la patch si applica automaticamente durante la successiva finestra di manutenzione del cluster.
Ad esempio, una patch richiesta che diventa disponibile il 1° giugno 2026 ha una durata approssimativa `AutoAppliedAfterDate` del 1° luglio 2026. Riceverai la notifica il 1° giugno 2026 e, se non intraprendi alcuna azione, la patch si applica automaticamente durante la prima finestra di manutenzione del cluster, a partire dal 1° luglio 2026.
Dopo aver ricevuto la notifica, hai due opzioni: applicare automaticamente la patch prima della data di applicazione automatica o attendere che si applichi automaticamente durante una prossima finestra di manutenzione (impostazione predefinita). Per applicarla automaticamente, apri la ** scheda ** Manutenzione e backup del cluster e cerca la voce relativa al tipo. `system-update`
**Nota**
**Lo stato della notifica nell'AHD rimane ** in ** corso ** 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 da corrispondere alla versione nella notifica. Verifica la nuova versione eseguendo`db.runCommand({getEngineVersion: 1})`.
Le patch opzionali e le nuove versioni secondarie non generano notifiche AHD o e-mail. Per tenerne traccia, guarda le note di [ rilascio di Amazon DocumentDB. ](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html)
Le patch forzate (la categoria più rara, riservata alle correzioni di sicurezza più critiche) vengono inoltre annunciate tramite AHD ed e-mail. A differenza delle patch obbligatorie, queste si applicano al di fuori della finestra di manutenzione, quindi l'esempio di tempistica dell'applicazione automatica riportato sopra non si applica.
### Reazione programmatica alle notifiche delle patch
AWS Health si integra con Amazon EventBridge, che consente di creare applicazioni basate sugli eventi su più di 20 destinazioni, tra cui Amazon Simple AWS Lambda Queue Service (SQS). Per reagire in modo programmatico alla disponibilità delle patch del motore, esegui la configurazione in base all'evento. EventBridge `AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_SCHEDULED` Da lì puoi acquisire i dati degli eventi, generare eventi aggiuntivi, inviare notifiche push tramite il AWS Console Mobile Application o intraprendere qualsiasi altra azione di cui hai bisogno.
Se Amazon DocumentDB annulla una patch (cosa rara), riceverai una notifica AHD e un'e-mail relativa all'annullamento. Usa il codice `AWS_DOCDB_DB_PATCH_UPGRADE_MAINTENANCE_CANCELLED` dell'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 di Amazon DocumentDB in sospeso
Usa Console di gestione AWS o the AWS CLI per verificare la 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.
+ Rinvialo (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 successiva finestra di manutenzione. Una volta `ForcedApplyDate` trascorsa, non è possibile alcun ulteriore rinvio.
**Nota**
Se non intraprendi alcuna azione, le azioni di manutenzione necessarie, come le patch necessarie al motore, si applicano automaticamente durante una prossima finestra di manutenzione. Le patch opzionali e le versioni secondarie non si applicano mai automaticamente.
La finestra di manutenzione controlla quando * iniziano le operazioni in sospeso*, non quanto tempo occorre 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 intervenire su di essi.
------
#### [ Using the AWS CLI ]
Esegui `describe-pending-maintenance-actions` per vedere cosa è 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 assegnare l'elenco a cluster specifici con`--filters`, nel modulo. `Name={{filter-name}},Values={{resource-id}},...` Il filtro accettato `Name` è`db-cluster-id`, che contiene 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. Compaiono nell' AWS CLI output di `describe-pending-maintenance-actions` e indicano quando verrà eseguita l'azione. I campi sono `null` destinati alla manutenzione opzionale.
+ **CurrentApplyDate**—quando è pianificata l'esecuzione dell'azione, adesso o nella successiva finestra di manutenzione. 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 posticipare un'azione in sospeso, sposta la finestra di manutenzione a un altro giorno prima. `AutoAppliedAfterDate` Una volta `AutoAppliedAfterDate` completata, l'azione verrà applicata automaticamente durante la successiva finestra di manutenzione. Una volta `ForcedApplyDate` superato, non è possibile alcun ulteriore rinvio. L'esatta finestra di rinvio varia a seconda della patch; le date sono pubblicate nella notifica AHD e nell'output. AWS CLI
## Aggiornamenti del motore Amazon DocumentDB
Dopo aver identificato una patch del motore in sospeso, utilizza una delle seguenti procedure per applicarla o pianificarla. È 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 nella 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 di Amazon DocumentDB in sospeso](#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 si rivolge l'azione in sospeso.
+ **--apply-action**—l'azione di manutenzione in sospeso da applicare. `system-update`Da utilizzare per applicare una patch al motore.
+ **--opt-in-type**—il tipo di richiesta di opt-in o se annullarne una. Valori validi:
+ `immediate`—applica ora. Non può essere annullato una volta inviato.
+ `next-maintenance`—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
```
------
### Disponibilità della lettura 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 corregge le istanze dei lettori in modo continuativo, in tre gruppi, in modo che i lettori rimanenti continuino a erogare traffico. L'autore non è disponibile per un breve periodo durante l'aggiornamento. Per azzerare i tempi di inattività di lettura, impostate le vostre preferenze di lettura in modo che le letture possano ricadere sullo scrittore, `secondaryPreferred` oppure `primaryPreferred` lavorare, oppure, `secondary` da sole, comportare tempi di inattività di lettura. `primary`
| 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à di 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à | Tempo di inattività della lettura (se c'è 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 il throughput, fornisci lettori aggiuntivi prima dell'aggiornamento e rimuovili una volta completato.
Sui motori 3.6 e 4.0, queste funzionalità di disponibilità della lettura non sono applicabili: una patch al motore causa tempi di inattività più lunghi che influiscono sia sulle letture che sulle scritture. Per eseguire l'aggiornamento a una versione principale che lo fa, consulta. [Aggiornamento della versione principale in-place di Amazon DocumentDB](docdb-mvu.md)
### Durata dei tempi 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 è importante dimensionare correttamente le istanze. Per ridurre al minimo i tempi di inattività, esegui l'ultima versione principale del motore 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 Dashboard Health . 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 e-mail, come descritto in[Notifiche per le patch del motore Amazon DocumentDB](#patch-notifications). Dashboard Health
## Aggiornamenti a versioni secondarie
Amazon DocumentDB pubblica versioni secondarie in aggiunta 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 secondarie si comportano diversamente dalle patch del motore obbligatorie e opzionali:
+ Non appaiono come un'azione di manutenzione in sospeso e non si applicano mai automaticamente.
+ Non generano notifiche AHD o e-mail. Le nuove versioni secondarie sono annunciate nelle note [ di ](https://docs.aws.amazon.com/documentdb/latest/devguide/release-notes.html) rilascio di Amazon DocumentDB.
+ Per eseguire l'aggiornamento, modifichi la versione del motore del cluster (immediatamente o durante la successiva finestra di manutenzione). Gli aggiornamenti delle versioni minori richiedono tempi di inattività brevi 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 necessitano occasionalmente di 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 di istanza. Analogamente alle patch del motore, gli aggiornamenti del sistema operativo utilizzano il ciclo di vita facoltativo/richiesto/forzato descritto all'inizio di questo argomento; a differenza delle patch del motore, un aggiornamento del sistema operativo può passare da una categoria all'altra nel tempo se viene posticipato. Applica gli aggiornamenti del sistema operativo non appena sono disponibili e imposta le finestre di manutenzione del cluster e delle istanze in base agli orari adatti alle esigenze aziendali.
Utilizza l'azione di `os-upgrade` manutenzione a livello di cluster per applicare gli aggiornamenti del sistema operativo a tutte le istanze di un cluster. Amazon DocumentDB aggiorna le istanze in modo continuativo, alcune alla volta, e aggiorna l'istanza principale per ultima per ridurre al minimo i failover. L'aggiornamento viene eseguito durante la finestra di manutenzione del cluster, non la finestra di manutenzione delle singole istanze, che configuri.
Dopo che un'istanza riceve un aggiornamento del sistema operativo, la cache del buffer inizia a essere vuota. Fino a quando il working set non viene ripopolato dal volume di archiviazione, le query su quell'istanza possono avere una latenza maggiore e una minore. `BufferCacheHitRatio`
Quando Amazon DocumentDB aggiorna l'istanza primaria, un failover promuove una replica come nuova istanza primaria. Usa l'endpoint del cluster in modo che la tua applicazione lo gestisca in modo trasparente. Per mantenere la disponibilità di lettura durante l'aggiornamento delle istanze, imposta la preferenza di lettura su `secondaryPreferred` o `primaryPreferred` in modo che le letture possano tornare a un'istanza disponibile. Mantieni le potenziali destinazioni di failover (repliche con il livello di priorità più alto) nella stessa classe di istanza dell'istanza primaria. Ciò evita il peggioramento delle prestazioni di scrittura dopo la promozione. Per informazioni dettagliate, vedi [Failover di Amazon DocumentDB](failover.md).
Le azioni a livello di cluster `os-upgrade` e a livello di istanza potrebbero essere visualizzate contemporaneamente tra le azioni disponibili`system-update`. `describe-pending-maintenance-actions` Tuttavia, non è possibile pianificarle entrambe contemporaneamente. Se `system-update` le azioni a livello di istanza sono pianificate attivamente su qualsiasi istanza, è necessario annullarle o completarle prima di pianificare l'azione a livello di cluster `os-upgrade` e viceversa.
**Importante**
La tua istanza Amazon DocumentDB va offline per l'aggiornamento del sistema operativo. Multi-instance i cluster riducono al minimo l'impatto. Se esegui un cluster a istanza singola, puoi aggiungere temporaneamente un cluster secondario per l'aggiornamento e rimuoverlo in seguito. Il secondario comporta i normali costi finché esiste.
**Nota**
L'`system-update`azione a livello di istanza è ancora disponibile per la compatibilità con le versioni precedenti. Se è necessario utilizzarla, aggiorna prima le repliche e per ultima quella principale: evita di applicarle contemporaneamente, poiché un failover durante la patch può prolungare i tempi di inattività.
Per ricevere un evento quando arriva un nuovo aggiornamento opzionale del sistema operativo, iscriviti alla categoria degli eventi relativi alle patch di sicurezza`RDS-EVENT-0230`. Per ulteriori informazioni, consulta [Iscrizione agli eventi di Amazon DocumentDB](event-subscriptions.subscribe.md).
**Nota**
Rimanere aggiornati sugli aggiornamenti facoltativi e obbligatori potrebbe essere necessario per garantire la conformità. Applica `os-upgrade` le azioni regolarmente durante le finestre di manutenzione.
Gli aggiornamenti del sistema operativo sono legati a classi di istanze specifiche, pertanto istanze diverse diventano idonee in momenti diversi. Se sul cluster non è installata l'ultima patch del motore, l'aggiornamento del sistema operativo potrebbe non essere visualizzato: applica prima la patch del motore più recente (vedi). [Aggiornamenti del motore Amazon DocumentDB](#db-instance-updates-apply)
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, scegli ** Clusters**, quindi seleziona il nome del cluster.
1. Scegli la scheda ** Manutenzione e backup. **
1. In Manutenzione ** in sospeso**, l'`os-upgrade`azione viene visualizzata se è disponibile un aggiornamento del sistema operativo.
1. Seleziona l'`os-upgrade`azione e scegli ** Applica ora ** o ** Applica alla prossima finestra di manutenzione. ** Se il valore è la finestra ** successiva**, puoi posticipare l'aggiornamento con ** Refer upgrade ** fino a quando l'azione non è iniziata.
------
#### [ Using the AWS CLI ]
Verifica la presenza di un aggiornamento del sistema operativo in sospeso:
```
aws docdb describe-pending-maintenance-actions
```
```
{
"PendingMaintenanceActions": [
{
"ResourceIdentifier": "arn:aws:rds:aa-example-1:111122223333:cluster:sample-cluster",
"PendingMaintenanceActionDetails": [
{
"Action": "os-upgrade",
"Description": "New Operating System update is available"
}
]
},
{
"ResourceIdentifier": "arn:aws:rds:aa-example-1:111122223333:db:sample-cluster-instance-1",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "New Operating System update is available"
}
]
},
{
"ResourceIdentifier": "arn:aws:rds:aa-example-1:111122223333:db:sample-cluster-instance-2",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "New Operating System update is available"
}
]
}
]
}
```
Gli aggiornamenti del sistema operativo vengono visualizzati a livello di cluster as `os-upgrade` e a livello di istanza as`system-update`. Usa l'azione a livello di cluster`os-upgrade`.
**Example**
L'esempio seguente applica immediatamente l'aggiornamento del sistema operativo.
Per Linux, macOS o Unix:
```
aws docdb apply-pending-maintenance-action \
--resource-identifier arn:aws:rds:{{aa-example-1}}:{{111122223333}}:cluster:{{sample-cluster}} \
--apply-action os-upgrade \
--opt-in-type immediate
```
Per Windows:
```
aws docdb apply-pending-maintenance-action ^
--resource-identifier arn:aws:rds:{{aa-example-1}}:{{111122223333}}:cluster:{{sample-cluster}} ^
--apply-action os-upgrade ^
--opt-in-type immediate
```
------
## User-initiated aggiornamenti
Alcune modifiche vengono eseguite autonomamente, ad esempio sostituendo una classe di istanza con una con più o meno memoria o modificando il 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 in; non ne ha. `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, si aggiorna durante la propria finestra di manutenzione. Quando una patch del motore richiesta è disponibile in ogni regione, riceverai 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 ti applichi da solo, applica sempre le patch secondarie per prime e le primarie per ultime. Questo ordine mantiene il failover e lo switchover disponibili per tutta la durata del rollout.
**Importante**
Se correggi per errore la prima versione principale, ripristina 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 ciascun cluster: prima i secondari, poi quelli primari nella relativa finestra una volta completati i secondari.
Mantieni i cluster DB primario e secondario sulla stessa versione. Il failover interregionale gestito 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 nella versione del primario prima di unirli al database globale.
Dopo la notifica di una patch, aggiorna la versione principale e secondaria alla versione più recente non appena possibile per far funzionare 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.