Un cluster Amazon Aurora utilizza una singola istanza DB e l'applicazione usa l'endpoint dell'istanza sia per le letture che per le scritture. È pianificato un aggiornamento durante una finestra di manutenzione e il cluster deve rimanere disponibile con interruzioni minime. Cosa dovrebbe fare un ingegnere DevOps per soddisfare questo requisito?

L'opzione corretta è aggiungere un'istanza reader e aggiornare l'applicazione per utilizzare l'endpoint del cluster (writer) per le scritture e l'endpoint reader per le letture. Questo approccio consente di reindirizzare il traffico di lettura all'istanza reader durante la manutenzione dell'istanza writer, garantendo la disponibilità dell'applicazione e minimizzando le interruzioni. Le opzioni che propongono l'uso di un endpoint ANY personalizzato sono errate perché gli endpoint ANY personalizzati distribuiscono il traffico tra tutte le istanze del cluster, incluse quelle reader e writer, senza distinguere tra letture e scritture. Questo non garantisce che le scritture vengano sempre indirizzate all'istanza writer primaria, né che le letture possano essere reindirizzate efficacemente durante la manutenzione. L'abilitazione di Multi-AZ su un cluster Aurora non è applicabile nel senso tradizionale di un'istanza DB singola, poiché Aurora è intrinsecamente distribuito su più zone di disponibilità. La soluzione per la disponibilità in Aurora si basa sull'aggiunta di istanze reader.