View a markdown version of this page

Failover di un cluster Multi-AZ DB 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 cluster Multi-AZ DB per Amazon RDS

In caso di interruzione pianificata o non pianificata dell'istanza DB writer in un cluster Multi-AZ DB, Amazon RDS esegue automaticamente il failover su un'istanza DB reader in una zona di disponibilità diversa. In tal modo si garantisce una disponibilità elevata 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 anche le best practice per il monitoraggio e la riduzione 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. Al termine del failover, la modifica della console RDS in base alla nuova zona di disponibilità può richiedere ulteriore tempo.

Failover automatici

Amazon RDS gestisce i failover automaticamente, in modo da consentirti di riprendere le operazioni database il più rapidamente possibile, senza alcun intervento amministrativo. Per eseguire il failover, l'istanza database del scrittore passa automaticamente a un'istanza database del lettore.

Failing manuale su un cluster DB Multi-AZ

Se si esegue manualmente il failover di un cluster Multi-AZ DB, RDS interrompe innanzitutto l'istanza database principale. Successivamente, il sistema di monitoraggio interno rileva che l’istanza database primaria non è integra e promuove un’istanza database di replica leggibile. Il failover richiede in genere meno di 35 secondi.

È possibile eseguire il failover di un cluster Multi-AZ DB manualmente utilizzando l' Console di gestione AWS API AWS CLI, the o RDS.

Per eseguire il failover manuale di un cluster Multi-AZ DB
  1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

  2. Nel pannello di navigazione, seleziona Database.

  3. Scegli il cluster Multi-AZ DB di cui desideri eseguire il failover.

  4. Per Actions (Operazioni), scegliere Failover.

    Viene visualizzata la pagina Failover cluster di database.

  5. Scegliere Failover per confermare il failover manuale.

Per eseguire il failover manuale di un cluster Multi-AZ DB, utilizzare il AWS CLI comando failover-db-cluster.

Esempio
aws rds failover-db-cluster --db-cluster-identifier mymultiazdbcluster

Per eseguire manualmente il failover di un cluster Multi-AZ DB, chiama l'API Amazon RDS FailoverDBCluster e specifica il. DBClusterIdentifier

Determinare se un cluster Multi-AZ DB è stato sottoposto a failover

Per determinare se il cluster Multi-AZ DB ha subito il failover, puoi fare quanto segue:

  • Configura gli abbonamenti a eventi database per inviare una notifica tramite e-mail o SMS in caso di failover. Per ulteriori informazioni sugli eventi di , consulta Utilizzo della notifica degli eventi di Amazon RDS.

  • Visualizza gli eventi database utilizzando la console Amazon RDS o le operazioni dell'API.

  • Visualizza lo stato attuale del tuo cluster Multi-AZ DB utilizzando la console Amazon RDS AWS CLI, l'API RDS e l'API RDS.

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

Impostazione di JVM TTL per le ricerche del nome DNS

Il meccanismo di failover modifica automaticamente il record Domain Name System (DNS) dell'istanza database in modo da fare riferimento all'istanza database di lettura. 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 memorizzazione nella cache DNS Java, potrebbe essere necessario riconfigurare le impostazioni JVM.

La JVM memorizza nella cache le ricerche del nome DNS. Quando la JVM risolve un nome host in un indirizzo IP, memorizza nella cache l'indirizzo IP per un determinato periodo di tempo, noto come time-to-live (TTL).

Poiché AWS le risorse utilizzano voci di nome DNS che cambiano di tanto in tanto, ti consigliamo di configurare la tua JVM con un valore TTL non superiore a 60 secondi. Questo garantisce che 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, il TTL predefinito di JVM è impostato in modo da non aggiornare mai le voci DNS finché JVM non viene riavviato. Pertanto, se l'indirizzo IP di una AWS risorsa cambia mentre l'applicazione è ancora in esecuzione, non può utilizzare tale risorsa finché non si riavvia manualmente la JVM e le informazioni IP memorizzate nella cache non vengono aggiornate. In questo caso, è fondamentale impostare il valore TTL della JVM in modo che aggiorni periodicamente le informazioni IP memorizzate nella cache.

Nota

Il valore TTL predefinito può variare in base alla versione della JVM e a seconda che un security manager sia installato o meno. Molte JVM forniscono un TTL predefinito inferiore a 60 secondi. Se utilizzi una JVM di questo tipo e non utilizzi un security manager, 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 la TTL della JVM, imposta il valore della proprietà networkaddress.cache.ttl. Utilizza uno dei seguenti metodi, a seconda delle esigenze:

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

    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");