Failover di un'istanza DB Multi-AZ per Amazon RDS - Amazon Relational Database Service

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

Failover di un'istanza DB Multi-AZ per Amazon RDS

Se un'interruzione pianificata o non pianificata dell'istanza DB Multi-AZ deriva da un difetto dell'infrastruttura, RDS Amazon passa automaticamente a una replica in standby in un'altra zona di disponibilità.

Il tempo necessario per il completamento del failover varia in base all'attività del database e ad altre condizioni presenti quando l'istanza database principale diventa non disponibile. Il failover richiede in genere da 60 a 120 secondi, tempo che può tuttavia aumentare in caso di transazioni di grandi dimensioni o di un processo di ripristino di lunga durata. Una volta completato il failover, può essere necessario più tempo prima che la console rifletta la RDS nuova zona di disponibilità.

Nota

È possibile forzare un failover manualmente quando si riavvia un'istanza DB Multi-AZ. Per ulteriori informazioni, consulta Riavvio di un'istanza database.

Amazon RDS gestisce automaticamente i failover in modo da poter riprendere le operazioni del database il più rapidamente possibile senza interventi amministrativi. L'istanza database principale passa automaticamente alla replica di standby qualora si verifichi una delle condizioni riportate nella seguente tabella. Puoi visualizzare questi motivi di failover nel log di eventi.

Motivo del failover Descrizione
Il sistema operativo alla base dell'istanza del RDS database viene patchato durante un'operazione offline.

È stato attivato un failover durante la finestra di manutenzione per una patch del sistema operativo o un aggiornamento di sicurezza.

Per ulteriori informazioni, consulta Manutenzione di un'istanza database.

L'host principale dell'istanza RDS Multi-AZ non è integro. L’implementazione istanza database Multi-AZ ha rilevato un'istanza database primaria compromessa e ha attivato il failover.
L'host principale dell'istanza RDS Multi-AZ non è raggiungibile a causa della perdita di connettività di rete.

RDSil monitoraggio ha rilevato un errore di raggiungibilità della rete sull'istanza DB principale e ha attivato un failover.

L'RDSistanza è stata modificata dal cliente.

Una modifica dell'istanza RDS DB ha innescato un failover.

Per ulteriori informazioni, consulta Modifica di un'istanza Amazon RDS DB.

L'istanza primaria RDS Multi-AZ è occupata e non risponde.

L'istanza database primaria non risponde. Ti consigliamo anche di completare le seguenti operazioni:

Per ulteriori informazioni su queste raccomandazioni, consulta Strumenti di monitoraggio per Amazon RDS Amazon e Le migliori pratiche per Amazon RDS.

Il volume di storage sottostante l'host principale dell'istanza RDS Multi-AZ ha subito un errore. L’implementazione dell’istanza database Multi-AZ ha rilevato un problema di archiviazioine nell'istanza DB principale e ha avviato il failover.
L'utente ha richiesto un failover dell'istanza database.

È stata riavviata l'istanza database ed è stata scelta l’opzione Riavvia con failover.

Per ulteriori informazioni, consulta Riavvio di un'istanza database.

Per determinare se l’istanza database Multi-AZ è soggetta a failover, è possibile eseguire le seguenti operazioni:

  • Configura gli abbonamenti agli eventi DB per avvisarti via e-mail dell'SMSavvio di un failover. Per ulteriori informazioni sugli eventi di , consulta Utilizzo delle notifiche di RDS eventi di Amazon.

  • Visualizza gli eventi del database utilizzando la RDS console o le operazioni. API

  • Visualizza lo stato attuale della distribuzione dell'istanza DB Multi-AZ utilizzando la RDS console o API le operazioni.

Per informazioni su come rispondere ai failover, ridurre i tempi di ripristino e altre best practice per AmazonRDS, consulta. Le migliori pratiche per Amazon RDS

Impostazione delle ricerche JVM TTL per i nomi DNS

Il meccanismo di failover modifica automaticamente il record Domain Name System (DNS) dell'istanza DB in modo che punti all'istanza DB in standby. Di conseguenza, sarà necessario ristabilire le connessioni esistenti alla propria istanza database. In un ambiente Java virtual machine (JVM), a causa del funzionamento del meccanismo di DNS caching Java, potrebbe essere necessario riconfigurare le impostazioni. JVM

Le ricerche dei JVM nomi delle cache. DNS Quando JVM risolve un nome host in un indirizzo IP, memorizza l'indirizzo IP nella cache per un periodo di tempo specificato, noto come (). time-to-liveTTL

Poiché AWS le risorse utilizzano voci di DNS nome che cambiano di tanto in tanto, si consiglia di configurare il file JVM con un TTL valore non superiore a 60 secondi. In questo modo, quando l'indirizzo IP di una risorsa cambia, l'applicazione può ricevere e utilizzare il nuovo indirizzo IP della risorsa richiedendo il. DNS

In alcune configurazioni Java, l'JVMimpostazione predefinita TTL è impostata in modo che non aggiorni mai le DNS voci fino al riavvio di. JVM Pertanto, se l'indirizzo IP di una AWS risorsa cambia mentre l'applicazione è ancora in esecuzione, non può utilizzare quella risorsa finché non si riavvia manualmente JVM e le informazioni IP memorizzate nella cache non vengono aggiornate. In questo caso, è fondamentale impostare i in TTL modo che JVM aggiorni periodicamente le informazioni IP memorizzate nella cache.

Puoi ottenere l'JVMimpostazione predefinita TTL recuperando il valore della proprietà: networkaddress.cache.ttl

String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
Nota

L'impostazione predefinita TTL può variare a seconda della versione JVM e dell'installazione o meno di un gestore della sicurezza. Molti JVMs forniscono un valore predefinito TTL inferiore a 60 secondi. Se utilizzi tale strumento JVM e non utilizzi un gestore della sicurezza, puoi ignorare il resto di questo argomento. Per ulteriori informazioni sui security manager in Oracle, consulta The Security Manager nella documentazione di Oracle.

Per modificare gli JVM 's'TTL, imposta il valore della networkaddress.cache.ttl proprietà. Utilizza uno dei seguenti metodi, a seconda delle esigenze:

  • Per impostare il valore della proprietà a livello globale per tutte le applicazioni che utilizzano laJVM, networkaddress.cache.ttl impostatela nel $JAVA_HOME/jre/lib/security/java.security file.

    networkaddress.cache.ttl=60
  • Per impostare la proprietà localmente solo per l'applicazione, imposta networkaddress.cache.ttl nel codice di inizializzazione dell'applicazione prima che venga stabilita qualsiasi connessione.

    java.security.Security.setProperty("networkaddress.cache.ttl" , "60");