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-0230ricevere una notifica quando ne sarà disponibile uno.) -
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.
AutoAppliedAfterDatePuoi 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
ForcedApplyDatescadenza. 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.1User-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 (vediApplica le date). Le note di rilascio di Amazon DocumentDB 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.
Argomenti
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. -
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.
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 dios-upgrademanutenzione a livello di cluster. Per ulteriori informazioni, consulta Aggiornamenti del sistema operativo Amazon DocumentDB.
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.minor5.0.05.0.1Le 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.patch3.0.17983) che identifica il livello di patch applicato al cluster. La cifra centrale è sempre.0Le 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. |
3.6 |
2.0. |
4.0 |
3.0. |
5.0 |
4.0. |
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, consultaNote di rilascio.
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
-
Per un'istanza: consulta Modifica di un'istanza Amazon DocumentDB.
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 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 dopoAutoAppliedAfterDate, 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 eseguendodb.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.
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.
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 azionesystem-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.
AutoAppliedAfterDateUna volta trascorsa tale data, l'azione verrà applicata automaticamente durante la successiva finestra di manutenzione. Una voltaForcedApplyDatetrascorsa, 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.
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
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
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 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 e-mail, come descritto inNotifiche per le patch del motore Amazon DocumentDB. Health Dashboard
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 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
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.
Le azioni a livello di cluster os-upgrade e a livello di istanza potrebbero essere visualizzate contemporaneamente tra le azioni disponibilisystem-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-updateazione 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 sicurezzaRDS-EVENT-0230. Per ulteriori informazioni, consulta Iscrizione agli eventi di Amazon DocumentDB.
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
Usa Console di gestione AWS o AWS CLI per verificare se è disponibile un aggiornamento.
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:
Per elencare le modifiche avviate dall'utente che sono ancora in sospeso:
Esempio
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 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.
