I cluster e le istanze AlloyDB si basano su molte risorseGoogle Cloud interne di basso livello. Questi includono le istanze di macchine virtuali (VM) che fungono da nodi e bilanciatori del carico AlloyDB e i volumi di archiviazione che contengono i tuoi dati. Poiché AlloyDB è un servizio gestito, Google si occupa di mantenere aggiornate queste risorse interne. In questo modo i tuoi cluster e le tue istanze AlloyDB rimangono affidabili, efficienti e sicuri.
La maggior parte di questi aggiornamenti non richiede tempi di inattività, ma alcuni aggiornamenti di sistema richiedono una breve interruzione del servizio. Ci riferiamo a questi aggiornamenti come manutenzione. Poiché questi aggiornamenti richiedono il riavvio del nodo interessato, possono causare tempi di inattività.
Le operazioni di manutenzione non disruptive di AlloyDB limitano il tempo di inattività a meno di 1 secondo per le istanze principali e secondarie e a zero secondi per i pool di lettura. Questo tempo di inattività quasi nullo e nullo viene ottenuto preparando un server di sostituzione con gli aggiornamenti e poi cambiando il server di database. Come puoi vedere nei log, il tempo di funzionamento è più lungo del tempo di inattività.
Motivi della manutenzione
Gli aggiornamenti di manutenzione possono essere eseguiti per i seguenti motivi:
Nuove funzionalità di AlloyDB. Per lanciare nuove funzionalità, Google deve aggiornare il software AlloyDB in esecuzione sui nodi all'interno del cluster. Potrebbe anche essere necessario aggiornare le estensioni PostgreSQL incluse in AlloyDB o installare nuove estensioni.
Upgrade della compatibilità del database. La community PostgreSQL rilascia regolarmente aggiornamenti delle versioni secondarie per le versioni principali supportate di PostgreSQL. Google incorpora questi aggiornamenti in AlloyDB e li applica ai cluster configurati per la compatibilità con la versione principale interessata. Per saperne di più, consulta le norme relative alle versioni del database.
Patch del sistema operativo. Google monitora costantemente le vulnerabilità di sicurezza nei sistemi operativi in esecuzione sulle risorse interne che costituiscono i cluster AlloyDB. Una volta rilevati, applichiamo patch ai sistemi operativi delle risorse per proteggerti da nuovi rischi.
Tempistica e preferenze di manutenzione
Puoi impostare periodi di manutenzione per i cluster AlloyDB principali e secondari. Per impostazione predefinita, non è impostato alcun periodo di manutenzione su un cluster AlloyDB. La manutenzione non di emergenza per un cluster AlloyDB senza finestre di manutenzione configurate può essere eseguita in qualsiasi momento, ad eccezione delle ore tra le 6:00 e le 22:00 nei giorni feriali, nell'ora locale della regione in cui si trova il cluster.
Puoi anche specificare un periodo di manutenzione. Un periodo di manutenzione definisce l'ora del giorno e il giorno della settimana preferiti per l'inizio degli eventi di manutenzione del cluster. Ad esempio, puoi impostare un cluster in modo che abbia un periodo di manutenzione che inizia alle 11:00 di domenica (UTC).
Se imposti un periodo di manutenzione, AlloyDB pianifica gli eventi di manutenzione non di emergenza futuri in modo che inizino al massimo un'ora dopo l'ora specificata. Inoltre, se accetti di ricevere notifiche via email sugli eventi di manutenzione di AlloyDB imminenti, riceverai una notifica automatica sull'evento non appena viene pianificato. Gli eventi di manutenzione vengono programmati con almeno una settimana di anticipo.
Non puoi impostare l'ora di fine di un periodo di manutenzione, poiché il tempo totale richiesto per un singolo evento di manutenzione può variare a seconda della complessità del cluster, ovvero del numero di istanze del pool di lettura che richiedono l'aggiornamento, e della natura dell'aggiornamento. Sebbene il tempo di inattività richiesto per ogni singola istanza possa essere molto breve, l'intera manutenzione potrebbe richiedere ore. Per questo motivo, puoi utilizzare un periodo di manutenzione per controllare l'ora generale del giorno in cui le istanze del cluster subiscono tempi di inattività per la manutenzione, ma non puoi specificare un periodo di inattività al minuto per nessuna istanza.
Gli eventi di manutenzione di emergenza, come l'applicazione di patch di sicurezza urgenti, potrebbero verificarsi al di fuori degli orari di manutenzione predefiniti o dei periodi di manutenzione configurati, inclusi i periodi di manutenzione negata.
Best practice per il periodo di manutenzione
Ti consigliamo di impostare periodi di manutenzione sui cluster di produzione e non impostarne uno sui cluster non di produzione. Ciò è dovuto al seguente ordine generale di eventi relativi a un aggiornamento di manutenzione:
- Innanzitutto, Google aggiorna tutti i cluster che non hanno finestre di manutenzione.
- Successivamente, Google pianifica gli aggiornamenti per tutti i cluster che hanno finestre di manutenzione. Questi aggiornamenti hanno un lead time di almeno una settimana.
- Se hai attivato la ricezione di comunicazioni sugli eventi di manutenzione AlloyDB imminenti, Google ti invia un'email con la notifica relativa alla manutenzione pianificata.
- Google esegue gli aggiornamenti di manutenzione negli orari pianificati.
Pertanto, una notifica di manutenzione imminente significa anche che gli stessi aggiornamenti sono già stati applicati a tutti i tuoi cluster senza periodi di manutenzione impostati. Se lasci i cluster non di produzione senza finestre di manutenzione, puoi garantire che ricevano prima gli aggiornamenti di sistema e puoi utilizzare le notifiche di manutenzione imminente come prompt per testare o visualizzare in anteprima gli aggiornamenti in un ambiente non di produzione.