Manutenzione di Amazon DocumentDB

Amazon DocumentDB esegue periodicamente due tipi di manutenzione:

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:

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.

Azioni di manutenzione per Amazon DocumentDB

Le seguenti azioni di manutenzione si applicano ai cluster Amazon DocumentDB:

Le seguenti azioni di manutenzione si applicano alle istanze Amazon DocumentDB:

Numerazione delle versioni del motore

Amazon DocumentDB utilizza due identificatori di versione separati:

È possibile determinare la versione del motore dal prefisso della versione della patch del motore, come mostrato nella tabella seguente.

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.

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.

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 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

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:

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.

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

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 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 inNotifiche per le patch del motore Amazon DocumentDB. 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:

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.

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.

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:

aws docdb describe-db-instances \
    --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'

aws docdb describe-db-instances ^
    --query 'DBInstances[*].[DBClusterIdentifier,DBInstanceIdentifier,PendingModifiedValues]'

[
    [
        "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.

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.