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à.
In caso di interruzione pianificata o non pianificata dell'istanza DB writer in un cluster DB Multi-AZ, Amazon RDS esegue automaticamente il failover su un'istanza DB reader in una zona di disponibilità diversa. Ciò garantisce un'elevata disponibilità con interruzioni minime. I failover possono verificarsi durante guasti hardware, problemi di rete o richieste manuali. L'argomento descrive il rilevamento automatico degli errori, la sequenza degli eventi durante il failover e il relativo impatto sulle operazioni di lettura e scrittura. Fornisce inoltre le migliori pratiche per il monitoraggio e la riduzione al minimo dei tempi di failover.
Il tempo necessario per il completamento del failover varia in base all'attività del database e ad altre condizioni presenti quando l'istanza database in scrittura diventa non disponibile. Il failover richiede in genere meno di 35 secondi. Il failover viene completato quando entrambe le istanze database del lettore hanno applicato transazioni in sospeso dallo scrittore in errore. Una volta completato il failover, può essere necessario più tempo prima che la RDS console rifletta la nuova zona di disponibilità.
Argomenti
Failover automatici
Amazon RDS gestisce automaticamente i failover in modo da poter riprendere le operazioni del database il più rapidamente possibile senza interventi amministrativi. Per eseguire il failover, l'istanza database del scrittore passa automaticamente a un'istanza database del lettore.
Failing manuale su un cluster di database Multi-AZ
Se esegui manualmente il failover di un cluster DB Multi-AZ, termina RDS innanzitutto l'istanza DB principale. Quindi, il sistema di monitoraggio interno rileva che l'istanza DB principale non è integra e promuove un'istanza DB di replica leggibile. Il failover richiede in genere meno di 35 secondi.
È possibile eseguire il failover di un cluster DB Multi-AZ manualmente utilizzando il AWS Management Console, il, o il. AWS CLI RDS API
Per eseguire un fail over manuale per un cluster di database Multi-AZ
Accedi a AWS Management Console e apri la RDS console Amazon all'indirizzo https://console.aws.amazon.com/rds/
. -
Nel riquadro di navigazione, scegli Databases (Database).
-
Scegliere il cluster di database Multi-AZ che si desidera ripristinare.
-
Per Actions (Operazioni), scegliere Failover.
Viene visualizzata la pagina del cluster Failover DB.
-
Scegliere Failover per confermare il failover manuale.
Per eseguire manualmente il failover di un cluster DB Multi-AZ, utilizzare il AWS CLI comando. failover-db-cluster
aws rds failover-db-cluster --db-cluster-identifiermymultiazdbcluster
Per eseguire manualmente il failover di un cluster DB Multi-AZ, chiama Amazon RDS API F ailoverDBCluster e specifica ilDBClusterIdentifier.
Determinare se un cluster di database Multi-AZ ha effettuate un fail over
Per determinare se il cluster database Multi-AZ è soggetto 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 i tuoi eventi DB utilizzando la RDS console o API le operazioni Amazon.
Visualizza lo stato attuale del tuo cluster DB Multi-AZ utilizzando la RDS console Amazon AWS CLI, il e il RDSAPI.
Per informazioni su come rispondere ai failover, ridurre i tempi di ripristino e altre best practice per AmazonRDS, consulta. Best practice 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 del lettore. 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 JVM riconfigurare le impostazioni.
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.
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
Per modificare gli JVM 's'TTL, imposta il valore della networkaddress.cache.ttl
-
Per impostare il valore della proprietà a livello globale per tutte le applicazioni che utilizzano laJVM,
networkaddress.cache.ttlimpostatela nel$JAVA_HOME/jre/lib/security/java.securityfile.networkaddress.cache.ttl=60 -
Per impostare la proprietà localmente solo per l'applicazione, imposta
networkaddress.cache.ttlnel codice di inizializzazione dell'applicazione prima che venga stabilita qualsiasi connessione.java.security.Security.setProperty("networkaddress.cache.ttl" , "60");
