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à.
# Implementazioni di istanze database Multi-AZ per Amazon RDS
Amazon RDS offre disponibilità elevata e supporto per il failover per le istanze database tramite le implementazioni Multi-AZ con una singola istanza database in standby. Questo tipo di implementazione è chiamato una *implementazione di istanza database Multi-AZ*. Amazon RDS utilizza varie tecnologie differenti per garantire il supporto per tale failover. Le implementazioni Multi-AZ per le istanze database MariaDB, MySQL, Oracle, PostgreSQL e RDS Custom per SQL Server utilizzano la tecnologia di failover di Amazon. Le istanze DB di Microsoft SQL Server utilizzano SQL Server Database Mirroring (DBM) o Always On Availability Groups (). AGs Per informazioni sul supporto della versione di SQL Server per Multi-AZ, consulta [Implementazioni Multi-AZ per Amazon RDS for Microsoft SQL Server](USER_SQLServerMultiAZ.md). Per informazioni sull'utilizzo di RDS Custom per SQL Server per le implementazioni Multi-AZ, consulta [Gestione di un'implementazione Multi-AZ per RDS Custom per SQL Server](custom-sqlserver-multiaz.md).
In un'implementazione istanza database Multi-AZ, Amazon RDS effettua automaticamente il provisioning e mantiene una replica in standby sincrona in un'altra zona di disponibilità. L'istanza database primaria viene replicata in modo sincrono nelle zone di disponibilità su una replica in standby per fornire ridondanza dati e ridurre al minimo i picchi di latenza durante i backup di sistema. L’esecuzione di un'istanza database con disponibilità elevata può migliorare la disponibilità durante la manutenzione pianificata del sistema. Consente inoltre di proteggere i database da errori dell'istanza database e interruzioni relative alle zone di disponibilità. Per ulteriori informazioni sulle zone di disponibilità, consulta [Regioni, zone di disponibilità e Local Zones ](Concepts.RegionsAndAvailabilityZones.md).
**Nota**
L'opzione di disponibilità elevata non è una soluzione di dimensionamento per scenari di sola lettura. Non è possibile utilizzare una replica in standby per gestire il traffico di lettura. Per utilizzare il traffico di sola lettura, utilizzare invece un cluster di database Multi-AZ o una replica di lettura. Per ulteriori informazioni sui cluster di database Multi-AZ, consulta [Implementazioni di cluster di database Multi-AZ per Amazon RDS](multi-az-db-clusters-concepts.md). Per ulteriori informazioni sulle repliche di lettura, consulta [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md).
![\[Scenario di alta disponibilità\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/con-multi-AZ.png)
Utilizzando la console RDS, puoi creare un'implementazione istanza database Multi-AZ semplicemente specificando Multi-AZ durante la creazione di un'istanza database. Puoi utilizzare la console per convertire le istanze database esistenti in implementazioni istanza database Multi-AZ, modificando l'istanza database e specificando l'opzione Multi-AZ. Puoi anche specificare una distribuzione di istanze DB Multi-AZ con l'API AWS CLI o Amazon RDS. Utilizza il comando [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)o [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI o l'operazione [Create DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) or [Modify DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API.
La console RDS mostra la zona di disponibilità della replica di standby, (denominata zona di disponibilità secondaria). Puoi anche utilizzare il comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)CLI o l'operazione [Descrivi DBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) API per trovare la AZ secondaria.
Le istanze database che utilizzano implementazioni Multi-AZ possono avere una latenza di scrittura e di commit maggiore rispetto a un'implementazione Single-AZ. Ciò può accadere a causa della replica sincrona dei dati che si verifica. È possibile che si verifichi una modifica della latenza se la distribuzione fallisce nella replica di standby, sebbene AWS sia progettata con connettività di rete a bassa latenza tra le zone di disponibilità. Per carichi di lavoro di produzione, è consigliabile utilizzare IOPS con provisioning (input/output operations per second, operazioni di input/output al secondo) per prestazioni veloci e coerenti. Per maggiori informazioni sulle classi di istanza database, consulta [Classi di istanze DB ](Concepts.DBInstanceClass.md).
# Trasformazione di un’istanza database in implementazione Multi-AZ per Amazon RDS
La trasformazione di un’istanza database in implementazione Multi-AZ migliora la disponibilità aggiungendo un’istanza database in standby in un’altra zona di disponibilità. Il processo prevede tempi di inattività minimi e richiede un’attenta pianificazione degli impatti sull’archiviazione e sulle prestazioni. Questa modifica migliora la tolleranza ai guasti e riduce i tempi di ripristino in caso di errore ed è per questo ideale per ambienti a disponibilità elevata.
Se si dispone di un’istanza database in un’implementazione Single-AZ e la si modifica in un’implementazione di istanze database Multi-AZ, Amazon RDS esegue le azioni descritte di seguito:
1. Creazione di uno snapshot dei volumi Amazon Elastic Block Store (EBS) dell'istanza database primaria.
1. Creazione di nuovi volumi per la replica in standby basati sullo snapshot. Questi volumi vengono inizializzati in background e le massime prestazioni del volume vengono raggiunte dopo la completa inizializzazione dei dati.
1. Attivazione della replica sincrona a livello di blocco tra i volumi delle repliche primarie e in standby.
**Importante**
La creazione di un’istanza database in standby da un’istantanea durante una conversione da Single-AZ a Multi-AZ evita i tempi di inattività, ma potrebbe influire sulle prestazioni, in particolare per i carichi di lavoro sensibili alla scrittura. La replica sincrona può aumentare la I/O latenza, influendo sulle prestazioni del database. Come best practice, evita di convertire un’istanza database di produzione in un’istanza database Multi-AZ.
Crea invece una replica di lettura, abilita i backup su di essa, convertila in Multi-AZ, carica i dati nei suoi volumi, quindi promuovila come istanza database primaria. Per ulteriori informazioni, consulta [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md).
Sono disponibili due modi per modificare un'istanza database in un'implementazione di istanza database multi-AZ:
**Topics**
+ [Conversione in implementazione di istanza database multi-AZ mediante la console RDS](#Concepts.MultiAZ.Migrating.Convert)
+ [Trasformazione di un'istanza database in implementazione d’istanza database Multi-AZ](#Concepts.MultiAZ.Migrating.Modify)
## Conversione in implementazione di istanza database multi-AZ mediante la console RDS
Puoi utilizzare la console RDS per convertire un'istanza database in un'implementazione di istanza database multi-AZ.
Per completare la conversione puoi usare solo la console. Per utilizzare la nostra AWS CLI API RDS, segui le istruzioni riportate in. [Trasformazione di un'istanza database in implementazione d’istanza database Multi-AZ](#Concepts.MultiAZ.Migrating.Modify)
**Per convertire in implementazione di istanza database multi-AZ mediante la console RDS**
1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel riquadro di navigazione, scegliere **Databases (Database)** e selezionare l'istanza database da modificare.
1. In **Actions** (Operazioni) scegli **Convert to Multi-AZ deployment** (Converti in implementazione multi-AZ).
1. Per applicare le modifiche immediatamente, scegli l'opzione **Apply immediately** (Applica immediatamente) nella pagina di conferma. La scelta di questa opzione non causa tempi di inattività, ma è possibile riscontrare un impatto sulle prestazioni. In alternativa, puoi scegliere di applicare l'aggiornamento durante la successiva finestra di manutenzione. Per ulteriori informazioni, consulta [Utilizzo dell’impostazione della pianificazione delle modifiche](USER_ModifyInstance.ApplyImmediately.md).
1. Scegli **Convert to Multi-AZ** (Converti in multi-AZ).
## Trasformazione di un'istanza database in implementazione d’istanza database Multi-AZ
Puoi convertire un’istanza database in un’implementazione di un’istanza database Multi-AZ nei seguenti modi:
+ Utilizzando la console RDS, modifica l'istanza database e imposta **Multi-AZ deployment** (Implementazione multi-AZ su **Yes** (Sì).
+ Utilizzando AWS CLI, richiama il [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)comando e imposta l'`--multi-az`opzione.
+ Utilizzando l'API RDS, richiamate l'DBInstanceoperazione di [modifica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) e impostate il `MultiAZ` parametro su. `true`
Per ulteriori informazioni sulla modifica di un’istanza di database, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md). Una volta completata la modifica, Amazon RDS attiva un evento (RDS-EVENT-0025) che indica che il processo è completo. Puoi monitorare gli eventi Amazon RDS. Per ulteriori informazioni sugli eventi di , consulta [Utilizzo della notifica degli eventi di Amazon RDS](USER_Events.md).
# Failover per un’istanza database Multi-AZ per Amazon RDS
Se un’interruzione pianificata o non pianificata dell’istanza database Multi-AZ comporta un defect dell’infrastruttura, Amazon RDS 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. Al termine del failover, la modifica della console RDS in base alla nuova zona di disponibilità può richiedere ulteriore tempo.
**Nota**
Puoi forzare un failover manualmente quando riavvii un’istanza database Multi-AZ. Per ulteriori informazioni, consulta [Riavvio di un'istanza DB DB](USER_RebootInstance.md).
Amazon RDS gestisce i failover automaticamente, in modo da consentirti di riprendere le operazioni database il più rapidamente possibile, senza alcun intervento amministrativo. 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 |
| --- | --- |
| Al sistema operativo sottostante l'istanza del database RDS viene aggiunta una patch in 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](USER_UpgradeDBInstance.Maintenance.md). |
| L' host primario dell'istanza Multi-AZ di RDS 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 Multi-AZ RDS non è raggiungibile a causa della perdita di connettività di rete. | Il monitoraggio RDS ha rilevato un errore di raggiungibilità della rete per l'istanza database primaria e ha attivato un failover. |
| L' istanza RDS è stata modificata dal cliente. | Una modifica dell'istanza database RDS ha attivato un failover. Per ulteriori informazioni, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md). |
| L' istanza principale Multi-AZ RDS è occupata e non risponde. | L'istanza database primaria non risponde. Ti consigliamo anche di completare le seguenti operazioni: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.Failover.html) Per ulteriori informazioni su queste raccomandazioni, consulta [Strumenti di monitoraggio di Amazon RDS](MonitoringOverview.md) e [Best practice per Amazon RDS](CHAP_BestPractices.md). |
| Il volume di storage sottostante l'host principale dell'istanza Multi-AZ RDS ha riportato 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 DB DB](USER_RebootInstance.md). |
Per determinare se l’istanza database Multi-AZ è soggetta a failover, è possibile eseguire le seguenti operazioni:
+ 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](USER_Events.md).
+ Visualizza gli eventi database utilizzando la console RDS o le operazioni dell'API.
+ Visualizza lo stato corrente dell'implementazione dell’istanza database Multi-AZ utilizzando la console RDS o le chiamate API.
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](CHAP_BestPractices.md).
## 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 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 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é le risorse AWS utilizzano voci del nome DNS che occasionalmente cambiano, ti consigliamo di configurare la 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 risorsa AWS cambia mentre l'applicazione è ancora in esecuzione, tale risorsa non può essere utilizzata finché la JVM non viene riavviata manualmente 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.
È possibile ottenere il TTL predefinito della JVM recuperando il valore della proprietà [https://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html](https://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html):
```
String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
```
**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](https://docs.oracle.com/javase/tutorial/essential/environment/security.html) 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");
```
# Failover Multi-AZ con volumi di storage aggiuntivi
Le implementazioni Multi-AZ supportano istanze DB con volumi di storage aggiuntivi. Durante un failover, RDS esegue automaticamente il failover sull'istanza di standby con eventuali volumi di storage aggiuntivi collegati all'istanza DB. Questo processo garantisce la coerenza e la disponibilità dei dati.
Quando configuri una distribuzione Multi-AZ per un'istanza DB con volumi di storage aggiuntivi, Amazon RDS replica automaticamente tutti i volumi nell'istanza di standby in una zona di disponibilità diversa. Lo storage replicato include:
+ Il volume di storage principale
+ Tutti i volumi di storage aggiuntivi collegati all'istanza DB
Durante un failover, Amazon RDS promuove l'istanza di standby e garantisce che tutti i volumi di storage siano disponibili e coerenti. Il failover mantiene la stessa configurazione di storage, inclusi i nomi dei volumi, i tipi di storage e le caratteristiche prestazionali.
Dopo un failover riuscito, è possibile verificare che tutti i volumi di storage siano collegati correttamente e accessibili visualizzando i dettagli della configurazione di archiviazione. Per ulteriori informazioni, consulta [Visualizzazione dei dettagli del volume di archiviazione per l'istanza DB](rds-storage-viewing.md).
Il tempo di failover per le istanze DB con volumi di storage aggiuntivi è simile a quello delle istanze DB con solo storage principale.