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à.
# Utilizzo di un'istanza di AWS DMS replica
Quando crei un'istanza di AWS DMS replica, la AWS DMS crea su un'istanza Amazon EC2 in un cloud privato virtuale (VPC) basato sul servizio Amazon VPC. Questa istanza di replica viene utilizzata per eseguire la migrazione del database. L'istanza di replica offre alta disponibilità e supporto per il failover con un'implementazione Multi-AZ se selezioni l'opzione **Multi-AZ**.
In una distribuzione Multi-AZ, effettua AWS DMS automaticamente il provisioning e mantiene una replica sincrona in standby dell'istanza di replica in una zona di disponibilità diversa. L'istanza di replica principale viene replicata in modo sincrono tra le zone di disponibilità in una replica di standby. Questo approccio fornisce la ridondanza dei dati, elimina I/O i blocchi e riduce al minimo i picchi di latenza.
![\[AWS Istanza di replica del Database Migration Service\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-conceptual2.png)
AWS DMS utilizza un'istanza di replica per connettersi al data store di origine, leggere i dati di origine e formattare i dati per l'utilizzo da parte del data store di destinazione. Un'istanza di replica, inoltre, carica i dati nel datastore di destinazione. La maggior parte di questo processo si verifica in memoria. Tuttavia, per le transazioni di grandi dimensioni potrebbe essere necessario il buffering su disco. Anche le transazioni e i file di log memorizzati nella cache vengono scritti su disco.
È possibile creare un'istanza AWS DMS di replica nelle seguenti AWS regioni.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_ReplicationInstance.html)
AWS DMS supporta una AWS regione speciale AWS GovCloud (US) denominata progettata per consentire alle agenzie governative e ai clienti degli Stati Uniti di spostare carichi di lavoro sensibili nel cloud. AWS GovCloud (US) soddisfa i requisiti normativi e di conformità specifici del governo degli Stati Uniti. Per ulteriori informazioni su AWS GovCloud (US), consulta [What is AWS GovCloud (US)?](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/whatis.html)
Di seguito sono riportati ulteriori dettagli sulle istanze di replica.
**Topics**
+ [Scelta dell'istanza di replica AWS DMS giusta per la migrazione](CHAP_ReplicationInstance.Types.md)
+ [Selezione della dimensione migliore per un'istanza di replica](CHAP_BestPractices.SizingReplicationInstance.md)
+ [Utilizzo delle versioni del motore di replica](CHAP_ReplicationInstance.EngineVersions.md)
+ [Istanze di replica pubbliche e private](CHAP_ReplicationInstance.PublicPrivate.md)
+ [Indirizzi IP e tipi di rete](CHAP_ReplicationInstance.IPAddressing.md)
+ [Configurazione di una rete per un'istanza di replica](CHAP_ReplicationInstance.VPC.md)
+ [Impostazione di una chiave di crittografia per un'istanza di replica](CHAP_ReplicationInstance.EncryptionKey.md)
+ [Creazione di un'istanza di replica](CHAP_ReplicationInstance.Creating.md)
+ [Modifica di un'istanza di replica](CHAP_ReplicationInstance.Modifying.md)
+ [riavvio di un'istanza di replica.](CHAP_ReplicationInstance.Rebooting.md)
+ [Eliminazione di un'istanza di replica.](CHAP_ReplicationInstance.Deleting.md)
+ [Utilizzo della finestra di AWS DMS manutenzione](CHAP_ReplicationInstance.MaintenanceWindow.md)
# Scelta dell'istanza di replica AWS DMS giusta per la migrazione
AWS DMS crea l'istanza di replica su un'istanza Amazon EC2. AWS DMS attualmente supporta le classi di istanze Amazon EC2 T3, C5, C6i, R5 e R6i per le istanze di replica:
+ Le istanze T3 sono il tipo di istanza per uso generico espandibile di nuova generazione. Questo tipo fornisce un livello base di prestazioni della CPU con la possibilità di espandere l'utilizzo della CPU in qualsiasi momento per tutto il tempo necessario. Le istanze T3 offrono un rapporto equilibrato tra calcolo, memoria e risorse di rete e sono progettate per i carichi di lavoro con un utilizzo moderato della CPU con picchi temporanei nell'uso. Le istanze T3 accumulano crediti CPU quando un carico di lavoro opera al di sotto della soglia di base. Ogni credito CPU guadagnato offre all'istanza T3 l'opportunità di sfruttare al massimo le prestazioni di un core CPU completo per un minuto, se necessario.
Le istanze T3 possono espandersi in qualsiasi momento per tutto il periodo necessario in modalità `unlimited`. Per ulteriori informazioni sulla modalità `unlimited`, consulta [Utilizzo della modalità illimitata per istanze a prestazioni espandibili](#CHAP_ReplicationInstance.Types.UnlimitedMode).
+ Le istanze C5 sono il tipo di istanza di nuova generazione che offre prestazioni elevate a costi contenuti a un basso rapporto tra spesa e potenza di calcolo per l'esecuzione di carichi di lavoro avanzati a uso intensivo delle capacità di calcolo. Sono inclusi i carichi di lavoro come server Web ad alte prestazioni, calcolo ad alte prestazioni (HPC), elaborazione in batch, pubblicazione di annunci, giochi multiplayer altamente dimensionabili e codifica video. Gli altri carichi di lavoro per cui sono adatte le istanze C5 includono la modellazione scientifica, l'analisi distribuita e l'inferenza di machine learning e deep learning. Le istanze C5 sono disponibili con una scelta di processori Intel e AMD.
+ Le istanze C6i offrono prestazioni di calcolo superiori in termini di prezzo fino al 15% rispetto alle istanze Gen5 comparabili per un'ampia varietà di carichi di lavoro e la crittografia della memoria sempre attiva. Le istanze C6i sono adatte per carichi di lavoro a uso intensivo delle capacità di calcolo quali elaborazione in batch, analisi distribuita, calcolo ad alte prestazioni (HPC), pubblicazione di annunci, giochi multiplayer altamente dimensionabili e codifica video.
+ Le istanze R5 sono la nuova generazione di tipi di istanze ottimizzate per la memoria per Amazon EC2. Le istanze R5 sono adatte per applicazioni con elevati requisiti di memoria quali database ad alte prestazioni, cache in memoria distribuite su scala Web, database in memoria di medie dimensioni, analisi dei big data in tempo reale e altre applicazioni aziendali. Le migrazioni o le repliche continue di sistemi di transazione ad alto throughput possono inoltre consumare grandi quantità di CPU e memoria. AWS DMS
+ Le istanze R6i offrono prestazioni di calcolo superiori in termini di prezzo fino al 15% rispetto alle istanze Gen5 comparabili per un'ampia varietà di carichi di lavoro e la crittografia della memoria sempre attiva. Le istanze R6i sono certificate SAP e sono ideali per carichi di lavoro come database SQL e NoSQL, cache in memoria distribuite su scala web come Memcached e Redis OSS, database in memoria come SAP HANA e analisi di big data in tempo reale come i cluster Hadoop e Spark.
+ Le istanze C7i offrono prestazioni di elaborazione migliori rispetto alle istanze comparabili della generazione precedente. Per quanto riguarda i AWS DMS carichi di lavoro, le istanze C7i eccellono nell'accelerare i processi di trasformazione dei dati, nella gestione di conversioni di schemi ad alta intensità di calcolo e nel mantenere un throughput costante durante le attività di migrazione ad alto volume. Queste istanze forniscono un equilibrio ideale tra le prestazioni di elaborazione che richiedono prestazioni sostenute della CPU.
+ Le istanze R7i offrono prestazioni di elaborazione migliori rispetto alle istanze comparabili della generazione precedente, combinate con un'elevata capacità di memoria per carichi di lavoro che richiedono molta memoria. Per i AWS DMS carichi di lavoro, le istanze R7i sono particolarmente adatte per attività che coinvolgono database di grandi dimensioni che elaborano volumi elevati di transazioni simultanee di database, consentendo una gestione efficiente di scenari di replica che richiedono un uso intensivo della memoria e processi di convalida dei dati complessi che richiedono buffer di memoria consistenti.
Ogni istanza di replica dispone di una specifica configurazione di memoria e di vCPU. La tabella seguente mostra la configurazione per ogni tipo di istanza di replica. Per informazioni sui prezzi, consulta la [pagina dei prezzi del servizio AWS Database Migration Service](https://aws.amazon.com/dms/pricing/).
**Tipi di istanze di replica per uso generico**
| Tipo | VPCU | Memoria (GiB) |
| --- | --- | --- |
| dms.t3.micro | 2 | 1 |
| dms.t3.small | 2 | 2 |
| dms.t3.medium | 2 | 4 |
| dms.t3.large | 2 | 8 |
**Tipi di istanze di replica ottimizzate per il calcolo**
| Tipo | VPCU | Memoria (GiB) |
| --- | --- | --- |
| dms.c5.large | 2 | 4 |
| dms.c5.xlarge | 4 | 8 |
| dms.c5.2xlarge | 8 | 16 |
| dms.c5.4xlarge | 16 | 32 |
| dms.c5.9xlarge | 36 | 72 |
| dms.c5.12xlarge | 48 | 96 |
| dms.c5.18xlarge | 72 | 144 |
| dms.c5.24xlarge | 96 | 192 |
| dms.c6i.large | 2 | 4 |
| dms.c6i.xlarge | 4 | 8 |
| dms.c6i.2xlarge | 8 | 16 |
| dms.c6i.4xlarge | 16 | 32 |
| dms.c6i.8xlarge | 32 | 64 |
| dms.c6i.12xlarge | 48 | 96 |
| dms.c6i.16xlarge | 64 | 128 |
| dms.c6i.24xlarge | 96 | 192 |
| dms.c6i.32xlarge | 128 | 256 |
| dms.c7i.large | 2 | 4 |
| dms.c7i.xlarge | 4 | 8 |
| dms.x7i.2xlarge | 8 | 16 |
| dms.x7i.4xlarge | 16 | 32 |
| dms.x7i.8xlarge | 32 | 64 |
| dms.x7i.12xlarge | 48 | 96 |
| dms.x7i.16xlarge | 64 | 128 |
| dms.x7i.24xlarge | 96 | 192 |
| dms.x7i.48xlarge | 192 | 384 |
**Tipi di istanze di replica ottimizzate per la memoria**
| Tipo | VPCU | Memoria (GiB) |
| --- | --- | --- |
| dms.r5.large | 2 | 16 |
| dms.r5.xlarge | 4 | 32 |
| dms.r5.2xlarge | 8 | 64 |
| dms.r5.4xlarge | 16 | 128 |
| dms.r5.8xlarge | 32 | 256 |
| dms.r5.12xlarge | 48 | 384 |
| dms.r5.16xlarge | 64 | 512 |
| dms.r5.24xlarge | 96 | 768 |
| dms.r6i.large | 2 | 16 |
| dms.r6i.xlarge | 4 | 32 |
| dms.r6i.2xlarge | 8 | 64 |
| dms.r6i.4xlarge | 16 | 128 |
| dms.r6i.8xlarge | 32 | 256 |
| dms.r6i.12xlarge | 48 | 384 |
| dms.r6i.16xlarge | 64 | 512 |
| dms.r6i.24xlarge | 96 | 768 |
| dms.r6i.32xlarge | 128 | 1.024 |
| dms.r7i.large | 2 | 16 |
| dms.r7i.xlarge | 4 | 32 |
| dms.r7i.2xlarge | 8 | 64 |
| dms.r7i.4xlarge | 16 | 128 |
| dms.r7i.8xlarge | 32 | 256 |
| dms.r7i.12xlarge | 48 | 384 |
| dms.r7i.16xlarge | 64 | 512 |
| dms.r7i.24xlarge | 96 | 768 |
| dms.r7i.48xlarge | 192 | 1536 |
Le tabelle precedenti elencano tutti i tipi di istanze di AWS DMS replica, ma i tipi disponibili nell'area geografica potrebbero variare. Per visualizzare i tipi di istanze di replica disponibili nella propria regione, è possibile eseguire il comando [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html) seguente:
```
aws dms describe-orderable-replication-instances --region your_region_name
```
**Topics**
+ [Decisione della classe di istanza da utilizzare](#CHAP_ReplicationInstance.Types.Deciding)
+ [Utilizzo della modalità illimitata per istanze a prestazioni espandibili](#CHAP_ReplicationInstance.Types.UnlimitedMode)
## Decisione della classe di istanza da utilizzare
Per aiutarti a determinare quale classe di istanza di replica potrebbe funzionare meglio per te, esaminiamo il processo CDC (Change Data Capture) utilizzato. AWS DMS
Supponiamo che tu stia eseguendo un'attività di caricamento completo \$1 CDC (caricamento in blocco \$1 replica continua). In questo caso, l'attività dispone di un proprio SQLite archivio in cui archiviare metadati e altre informazioni. Prima di AWS DMS iniziare un caricamento completo, vengono eseguiti i seguenti passaggi:
+ AWS DMS inizia ad acquisire le modifiche per le tabelle che sta migrando dal registro delle transazioni del motore di origine (le chiamiamo modifiche memorizzate nella *cache*). Una volta completato il caricamento completo, queste modifiche memorizzate nella cache vengono raccolte e applicate nella destinazione. In base al volume, queste modifiche memorizzate nelle cache possono essere applicate direttamente dalla memoria, dove vengono prima raccolte, fino a una soglia definita. In alternativa, possono essere applicate dal disco, dove le modifiche vengono scritte nel caso non possano essere conservate in memoria.
+ Dopo l'applicazione delle modifiche memorizzate nella cache, per impostazione predefinita AWS DMS avvia un processo di applicazione transazionale sull'istanza di destinazione.
Durante la fase di applicazione delle modifiche memorizzate nella cache e la fase di replica in corso, AWS DMS utilizza due buffer di flusso, uno ciascuno per i dati in entrata e in uscita. AWS DMS utilizza anche un componente importante chiamato *sorter*, che è un altro buffer di memoria. Di seguito sono riportati due utilizzi importanti del componente ordinatore (ne sono disponibili altri):
+ Monitora tutte le transazioni e verifica che al buffer in uscita vengano inoltrate solo le transazioni pertinenti.
+ Verifica che le transazioni vengano inoltrate nello stesso ordine di commit dell'origine.
Come puoi notare, sono presenti tre importanti buffer di memoria in questa architettura per CDC in AWS DMS. Un utilizzo elevato della memoria in uno di questi buffer può causare problemi di prestazioni e compromettere potenzialmente il sistema.
La memoria supplementare fornita dalle istanze R5 e R6i può risultare utile quando in questa architettura vengono associati pesanti carichi di lavoro con un numero elevato di transazioni al secondo (TPS). Puoi utilizzare le istanze R5 e R6i per conservare un numero elevato di transazioni in memoria e prevenire problemi di utilizzo elevato della memoria durante le repliche continue.
## Utilizzo della modalità illimitata per istanze a prestazioni espandibili
Un'istanza a prestazioni espandibili configurata come `unlimited`, ad esempio un'istanza T3, può sostenere un utilizzo elevato della CPU per tutto il tempo necessario in qualsiasi momento. Il prezzo orario dell'istanza può coprire automaticamente tutti i picchi di utilizzo della CPU se l'utilizzo medio della CPU dell'istanza corrisponde o è inferiore alla baseline per un periodo di 24 ore o la durata dell'istanza, a seconda di quale dei due è inferiore.
Per la grande maggioranza dei carichi di lavoro per scopi generici, le istanze configurate come `unlimited` offrono prestazioni elevate senza addebiti aggiuntivi. Se l'istanza viene eseguita a un utilizzo più elevato della CPU per un periodo di tempo prolungato, verrà applicata una tariffa fissa aggiuntiva all'ora vCPU. Per informazioni sui prezzi delle istanze T3, consulta "Crediti CPU T3" in [AWS Database Migration Service](https://aws.amazon.com/dms/pricing/).
*Per ulteriori informazioni sulla `unlimited` modalità per le istanze T3, consulta la sezione [Modalità illimitata per istanze con prestazioni espandibili nella Guida per l'](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html)utente di Amazon EC2.*
**Importante**
Se utilizzi un'istanza `dms.t3.micro` nell'ambito dell'offerta [Piano gratuito di AWS](https://aws.amazon.com/free/) in modalità `unlimited`, potrebbero essere applicati costi. In particolare, potrebbero essere applicati costi aggiuntivi se l'utilizzo medio in un periodo continuo di 24 ore supera l'utilizzo di base dell'istanza. Per ulteriori informazioni, consulta l'[utilizzo di base](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html#baseline_performance) nella Guida per l'utente di *Amazon EC2*.
Le istanze T3 si avviano come `unlimited` per impostazione predefinita. Se l'utilizzo medio della CPU per un periodo di 24 ore supera la baseline, vengono addebitati i costi per i crediti in eccedenza. In alcuni casi, è possibile avviare le istanze spot T3 come `unlimited` e pianificare di utilizzarle immediatamente e per un breve periodo. Se lo fai senza tempo di inattività per accumulare crediti CPU, vengono addebitati i costi per i crediti in eccedenza. Consigliamo di avviare le istanze spot T3 in modalità standard per evitare di sostenere costi maggiori. *Per ulteriori informazioni, consulta la sezione I [crediti in eccesso possono incorrere in addebiti, le istanze [Spot T3 e la modalità Standard per le istanze](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-limits.html#t3-spot-instances) con prestazioni espandibili nella Guida per l'utente](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html#unlimited-mode-surplus-credits) [di Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode.html) EC2.*
# Selezione della dimensione migliore per un'istanza di replica
La scelta dell'istanza di replica appropriata dipende da diversi fattori associati al caso d'uso. Per aiutarti a comprendere il modo in cui vengono utilizzate le risorse delle istanze di replica, consulta la seguente discussione. Copre lo scenario comune di un'attività di caricamento completo \$1 CDC.
Durante un'attività di caricamento completo, AWS DMS carica le tabelle singolarmente. Per impostazione predefinita, vengono caricate otto tabelle alla volta. AWS DMS acquisisce le modifiche in corso all'origine durante un'attività di caricamento completo in modo che le modifiche possano essere applicate successivamente sull'endpoint di destinazione. Le modifiche vengono memorizzate nella cache della memoria; quando la memoria disponibile è esaurita, le modifiche vengono memorizzate nella cache del disco. Quando viene completata un'attività di caricamento completo per una tabella, applica AWS DMS immediatamente le modifiche memorizzate nella cache alla tabella di destinazione.
Dopo l'applicazione di tutte le modifiche memorizzate nella cache in sospeso per una tabella, l'endpoint di destinazione è in uno stato coerente a livello di transazioni. A questo punto, la destinazione è sincronizzata con l'endpoint di origine rispetto alle ultime modifiche memorizzate nella cache. AWS DMS inizia quindi la replica continua tra l'origine e la destinazione. A tale scopo, AWS DMS prende le operazioni di modifica dai log delle transazioni di origine e le applica alla destinazione in modo transazionale coerente. (Questo processo presuppone che l'opzione Applicazione ottimizzata in batch non sia selezionata). AWS DMS trasmette le modifiche in corso attraverso la memoria sull'istanza di replica, se possibile. Altrimenti, AWS DMS scrive le modifiche su disco sull'istanza di replica fino a quando non possono essere applicate sulla destinazione.
È possibile controllare il modo in cui l'istanza di replica gestisce l'elaborazione delle modifiche e il modo in cui la memoria viene utilizzata in tale processo. Per ulteriori informazioni su come ottimizzare l'elaborazione delle modifiche, consulta [Impostazioni di ottimizzazione dell'elaborazione delle modifiche](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md).
## Fattori da considerare
La memoria e lo spazio su disco sono fattori chiave nella scelta dell'istanza di replica appropriata per il tuo caso d'uso. Di seguito, è disponibile una descrizione delle caratteristiche dei casi d'uso da analizzare per scegliere l'istanza di replica.
+ Dimensione di database e tabelle
Il volume di dati aiuta a determinare la configurazione dell'attività per ottimizzare le prestazioni del pieno carico. Ad esempio, per due schemi da 1 TB è possibile partizionare le tabelle in quattro attività da 500 GB ed eseguirle in parallelo. Il parallelismo dipende dalla risorsa CPU disponibile nell'istanza di replica. Ecco perché è una buona idea comprendere le dimensioni del database e delle tabelle per ottimizzare le prestazioni del pieno carico. Aiuta a determinare il numero di attività che è possibile svolgere.
+ Oggetti di grandi dimensioni
I tipi di dati presenti nell'ambito della migrazione possono influire sulle prestazioni. In particolare, gli oggetti di grandi dimensioni (LOBs) influiscono sulle prestazioni e sul consumo di memoria. Per migrare un valore LOB, AWS DMS esegue un processo in due fasi. Innanzitutto, AWS DMS inserisce la riga nella destinazione senza il valore LOB. In secondo luogo, AWS DMS aggiorna la riga con il valore LOB. Ciò ha un impatto sulla memoria, quindi è importante identificare le colonne LOB nell'origine e analizzarne le dimensioni.
+ Frequenza di caricamento e dimensione della transazione
La frequenza di caricamento e le transazioni al secondo (TPS) influiscono sull'utilizzo della memoria. Un numero elevato di attività TPS o DML (Data Manipulation Language) comporta un elevato utilizzo della memoria. Ciò accade perché DMS memorizza nella cache le modifiche finché non vengono applicate alla destinazione. Durante la CDC comporta lo swap (scrittura sul disco fisico a causa di un sovraccarico di memoria), che causa latenza.
+ Chiavi della tabella e integrità referenziale
Le informazioni sulle chiavi della tabella determinano la modalità CDC (applicazione in batch o applicazione transazionale) utilizzata per migrare i dati. In generale, l'applicazione transazionale è più lenta dell'applicazione in batch. Per le transazioni di lunga durata, la migrazione può includere molte modifiche. Quando si utilizza l'applicazione transazionale, AWS DMS potrebbe essere necessaria più memoria per archiviare le modifiche rispetto all'applicazione in batch. Se si esegue la migrazione delle tabelle senza chiavi primarie, l'applicazione in batch ha esito negativo e l'attività DMS passa alla modalità di applicazione transazionale. Quando l'integrità referenziale è attiva tra le tabelle durante il CDC, AWS DMS utilizza l'applicazione transazionale per impostazione predefinita. Per ulteriori informazioni sull'applicazione in batch rispetto all'applicazione transazionale, vedi [Come posso utilizzare la funzione di applicazione batch di DMS per migliorare le prestazioni di replica CDC?](https://aws.amazon.com/premiumsupport/knowledge-center/dms-batch-apply-cdc-replication/)
Utilizza i parametri indicati per determinare se è necessario che l'istanza di replica sia ottimizzata per il calcolo o la memoria.
## Problemi comuni
Durante la migrazione potrebbero verificarsi i seguenti problemi comuni che causano un conflitto di risorse sull'istanza di replica. Per informazioni sui parametri dell'istanza di replica, consulta [Parametri dell'stanza di replica](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.CloudWatch).
+ Se la memoria in un'istanza di replica diventa insufficiente, i dati vengono scritti sul disco. La lettura dal disco può causare latenza, che è possibile evitare dimensionando l'istanza di replica con memoria sufficiente.
+ La dimensione del disco assegnata all'istanza di replica può essere inferiore a quella richiesta. La dimensione del disco viene utilizzata quando lo spazio per i dati in memoria si esaurisce e anche per archiviare i log delle attività. Anche il numero massimo di IOPS dipende da questo.
+ L'esecuzione di più attività oppure di attività con elevato parallelismo influisce sul consumo di CPU dell'istanza di replica. Si rallenta l'elaborazione delle attività che si traduce in latenza.
## Best practice
Considera queste due best practice comuni per il dimensionamento di un'istanza di replica. Per ulteriori informazioni, consulta [Le migliori pratiche per AWS Database Migration Service](CHAP_BestPractices.md).
1. Dimensiona il tuo carico di lavoro e determina se richiede un uso intensivo delle capacità di calcolo o elevati requisiti di memoria. In base a ciò, puoi determinare la classe e la dimensione dell'istanza di replica:
+ AWS DMS processi in memoria. LOBs Questa operazione richiede una discreta quantità di memoria.
+ Il numero di attività e il numero di thread influiscono sul consumo della CPU. Evita di utilizzare più di otto `MaxFullLoadSubTasks` durante l'operazione di pieno carico.
1. Aumenta lo spazio su disco assegnato all'istanza di replica in caso di carico di lavoro elevato durante il pieno carico. In questo modo l'istanza di replica può utilizzare il numero massimo di IOPS ad essa assegnato.
Le linee guida precedenti non coprono tutti gli scenari possibili. È importante considerare le specifiche del tuo particolare caso d'uso quando stabilisci la dimensione dell'istanza di replica.
I test precedenti mostrano che CPU e memoria variano a seconda dei diversi carichi di lavoro. In particolare, LOBs influiscono sulla memoria e il conteggio delle attività o il parallelismo influiscono sulla CPU. Una volta che la migrazione è in esecuzione, monitora la CPU, la memoria liberabile, lo storage libero e gli IOPS dell'istanza di replica. In base ai dati raccolti, è possibile dimensionare l'istanza di replica in base alle esigenze.
# Utilizzo delle versioni del motore di replica
Il *motore di replica* è il AWS DMS software principale che viene eseguito sull'istanza di replica ed esegue le attività di migrazione specificate dall'utente. AWS rilascia periodicamente nuove versioni del software del motore di AWS DMS replica, con nuove funzionalità e miglioramenti delle prestazioni. Ogni versione del software del motore di replica dispone di un proprio numero di versione per distinguerlo dalle altre versioni.
Quando si avvia una nuova istanza di replica, viene eseguita la versione più recente del AWS DMS motore, a meno che non venga specificato diversamente. Per ulteriori informazioni, consulta [Utilizzo di un'istanza di AWS DMS replica](CHAP_ReplicationInstance.md).
Se disponi di un'istanza di replica attualmente in esecuzione, puoi aggiornarla a una versione del motore più recente. (AWS DMS non supporta il downgrade della versione del motore). Per ulteriori informazioni sulle versioni del motore di replica, consulta [AWS Note di rilascio DMS](CHAP_ReleaseNotes.md).
## Aggiornamento della versione del motore mediante la console
È possibile aggiornare un'istanza di AWS DMS replica utilizzando. Console di gestione AWS
**Per aggiornare un'istanza di replica utilizzando la console**
1. Aprire la AWS DMS console alla versione [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Nel riquadro di navigazione, scegli **Replication instances (Istanze di replica)**.
1. Scegli il motore di replica, quindi scegli **Modify (Modifica)**.
1. Per **Versione del motore** scegli il numero di versione desiderato, quindi scegli **Modifica**.
**Nota**
È consigliabile interrompere tutte le attività prima di aggiornare l'istanza di replica. Se non si interrompe l'operazione, la AWS DMS interromperà automaticamente prima dell'aggiornamento. Se interrompi l'attività manualmente, sarà necessario avviarla manualmente dopo il completamento dell'aggiornamento. L'aggiornamento dell'istanza di replica richiede alcuni minuti. Quando l'istanza è pronta, il relativo stato diventa **available (disponibile)**.
## Aggiornamento della versione del motore utilizzando il AWS CLI
È possibile aggiornare un'istanza di AWS DMS replica utilizzando AWS CLI, come segue.
**Per aggiornare un'istanza di replica utilizzando AWS CLI**
1. Determina l'Amazon Resource Name (ARN) dell'istanza di replica utilizzando il comando seguente.
```
aws dms describe-replication-instances \
--query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceArn,ReplicationInstanceClass]"
```
Nell'output, prendi nota dell'ARN dell'istanza di replica che desideri aggiornare, ad esempio: `arn:aws:dms:us-east-1:123456789012:rep:6EFQQO6U6EDPRCPKLNPL2SCEEY`
1. Determina quali versioni dell'istanza di replica sono disponibili utilizzando il comando seguente.
```
aws dms describe-orderable-replication-instances \
--query "OrderableReplicationInstances[*].[ReplicationInstanceClass,EngineVersion]"
```
Nell'output, prendi nota del numero o dei numeri di versione del motore disponibili per la classe dell'istanza di replica. Queste informazioni dovrebbero apparire nell'output della fase 1.
1. Aggiorna l'istanza di replica utilizzando il comando seguente.
```
aws dms modify-replication-instance \
--replication-instance-arn arn \
--engine-version n.n.n
```
Sostituire *arn* quanto sopra con l'ARN dell'istanza di replica effettiva del passaggio precedente.
Sostituisci *n.n.n * con il numero di versione del motore che desideri, ad esempio: `3.4.5`
**Nota**
L'aggiornamento dell'istanza di replica richiede alcuni minuti. Puoi visualizzare lo stato dell'istanza di replica utilizzando il comando seguente.
```
aws dms describe-replication-instances \
--query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceStatus]"
```
Quando l'istanza di replica è pronta, il relativo stato diventa **available (disponibile)**.
# Istanze di replica pubbliche e private
Puoi specificare se un'istanza di replica dispone di un indirizzo IP pubblico o privato che utilizza per la connessione ai database di origine e di destinazione.
Un'*istanza di replica privata* dispone di un indirizzo IP privato a cui non è possibile accedere al di fuori della rete di replica. Si utilizza un'istanza privata quando entrambi i database di origine e di destinazione si trovano nella stessa rete connessa al cloud privato virtuale (VPC) dell'istanza di replica. La rete può essere connessa al VPC utilizzando una rete privata virtuale (VPN) o il peering Direct Connect VPC.
Una connessione *peering VPC* è una connessione di rete tra due. VPCs Consente il routing utilizzando gli indirizzi IP privati di ciascun VPC come se si trovassero nella stessa rete. Per ulteriori informazioni sul peering di VPC, consulta [Peering di VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) nella *Guida per l'utente di Amazon VPC*.
Un'*istanza di replica pubblica* può utilizzare il gruppo di sicurezza VPC dell'istanza di replica e l'indirizzo IP pubblico dell'istanza di replica o l'indirizzo IP pubblico del gateway NAT. Queste connessioni creano una rete che viene utilizzata per la migrazione dei dati.
# Indirizzi IP e tipi di rete
AWS DMS crea sempre la tua istanza di replica in un Amazon Virtual Private Cloud (VPC). Quando crei il tuo VPC, puoi determinare l'indirizzo IP da utilizzare: uno IPv4 o IPv6 entrambi. Quindi, quando si crea o si modifica un'istanza di replica, è possibile specificare l'uso di un protocollo di indirizzi o di un protocollo di IPv4 indirizzi utilizzando la modalità *dual-stack*. IPv6
**IPv4 indirizzi**
Quando si crea un VPC, è possibile specificare un intervallo di IPv4 indirizzi per il VPC sotto forma di blocco CIDR (Classless Inter-Domain Routing), ad esempio 10.0.0.0/16. Un gruppo di sottoreti definisce l'intervallo di indirizzi IP in questo blocco CIDR. Questi indirizzi IP possono essere privati o pubblici.
Un indirizzo IPv4 privato è un indirizzo IP non raggiungibile tramite Internet. Puoi utilizzare indirizzi IPv4 privati per la comunicazione tra l'istanza di replica e altre risorse, ad esempio istanze Amazon EC2, nello stesso VPC. Ogni istanza di replica dispone di un indirizzo IP privato per la comunicazione nel VPC.
Un indirizzo IP pubblico è un indirizzo raggiungibile da Internet. IPv4 Puoi utilizzare gli indirizzi pubblici per la comunicazione tra l'istanza di replica e le risorse su Internet. Puoi controllare se le istanze di replica ricevono un indirizzo IP pubblico.
**Modalità e indirizzi dual-stack IPv6 **
*Se disponi di risorse che devono comunicare con l'istanza di replica IPv6, utilizza la modalità dual-stack.* Per utilizzare la modalità dual-stack, assicurati che a ogni sottorete del gruppo di sottoreti associato all'istanza di replica sia associato un blocco CIDR. IPv6 Per soddisfare questo requisito, puoi creare un nuovo gruppo di sottoreti di replica o modificare un gruppo di sottoreti di replica esistente. Ogni indirizzo è unico a livello globale. IPv6 Il blocco IPv6 CIDR per il tuo VPC viene assegnato automaticamente dal pool IPv6 di indirizzi Amazon. Non è possibile scegliere l'intervallo in modo autonomo.
DMS disabilita l'accesso a Internet Gateway per gli IPv6 endpoint delle istanze di replica private in modalità dual-stack. DMS esegue questa operazione per garantire che gli IPv6 endpoint siano privati e accessibili solo dall'interno del VPC.
**È possibile utilizzare la AWS DMS console per creare o modificare un'istanza di replica e specificare la modalità dual-stack nella sezione Tipo di rete.** L'immagine seguente mostra la sezione **Network type** (Tipo di rete) nella console.
![\[AWS Tipo di rete Database Migration Service\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-network-type.png)
**Riferimenti**
+ Per ulteriori informazioni su IPv4 e IPv6 indirizzi, consulta la sezione [Indirizzamento IP](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html#vpc-ip-addressing) nella *Amazon VPC User Guide*.
+ Per ulteriori informazioni sulla creazione di un'istanza di replica tramite la modalità dual-stack, consulta [Creazione di un'istanza di replica](CHAP_ReplicationInstance.Creating.md).
+ Per ulteriori informazioni sulla modifica di un'istanza di replica, consulta [Modifica di un'istanza di replica](CHAP_ReplicationInstance.Modifying.md).
# Configurazione di una rete per un'istanza di replica
AWS DMS crea sempre l'istanza di replica in un VPC basato su Amazon VPC. Puoi specificare il VPC in cui è posizionata l'istanza di replica. Puoi usare il tuo VPC predefinito per il tuo account e la tua AWS regione oppure puoi creare un nuovo VPC.
Assicurati che l'interfaccia di rete elastica allocata per il VPC dell'istanza di replica sia associata a un gruppo di sicurezza. Inoltre, assicurati che le regole del gruppo di sicurezza consentano a tutto il traffico su tutte le porte di uscire dal VPC. Questo approccio consente la comunicazione dall'istanza di replica agli endpoint dei database di origine e di destinazione, purché su tali endpoint siano abilitate le regole di uscita corrette. È consigliabile utilizzare le impostazioni predefinite per gli endpoint, che consentono l'uscita su tutte le porte in tutti gli indirizzi.
Gli endpoint di origine e di destinazione accedono all'istanza di replica all'interno del VPC connettendosi al VPC o rimanendo all'interno del VPC. Gli endpoint del database devono includere elenchi di controllo degli accessi alla rete (ACLs) e regole dei gruppi di sicurezza (se applicabili) che consentano l'accesso in entrata dall'istanza di replica. La modalità di impostazione dipende dalla configurazione di rete utilizzata. Puoi utilizzare il gruppo di sicurezza VPC dell'istanza di replica, l'indirizzo IP privato o pubblico dell'istanza di replica o l'indirizzo IP pubblico del gateway NAT. Queste connessioni creano una rete che viene utilizzata per la migrazione dei dati.
**Nota**
Poiché un indirizzo IP può cambiare a seguito di modifiche all'infrastruttura sottostante, ti consigliamo di utilizzare un intervallo CIDR VPC o di indirizzare il traffico in uscita dell'istanza di replica attraverso un IP elastico associato a un gateway NAT. Per ulteriori informazioni sulla creazione di un VPC, incluso un blocco CIDR, consulta [Work with VPCs and subnet](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html) nella *Amazon Virtual* Private Cloud User Guide. Per ulteriori informazioni sugli indirizzi IP elastici, consulta [Indirizzi IP elastici](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/elastic-ip-addresses-eip.html) nella *Guida per l'utente di Amazon Elastic Compute Cloud*.
## Configurazioni di rete per la migrazione del database
È possibile utilizzare diverse configurazioni di rete con AWS Database Migration Service. Di seguito sono riportate le configurazioni comuni per una rete utilizzata per la migrazione del database.
**Topics**
+ [Configurazione con tutti i componenti di migrazione del database in un VPC](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioAllVPC)
+ [Configurazione con più VPCs](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCPeer)
+ [Configurazione con condivisione VPCs](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCShared)
+ [Configurazione per una rete verso un VPC utilizzando Direct Connect o una VPN](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioDirect)
+ [Configurazione di una rete per un VPC mediante Internet](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioInternet)
+ [Configurazione con un'istanza DB RDS non in un VPC su un'istanza DB in un VPC utilizzando ClassicLink](#CHAP_ReplicationInstance.VPC.Configurations.ClassicLink)
+ [Configurazione per una rete che si connette ai servizi AWS](#CHAP_ReplicationInstance.VPC.Configurations.networkconnecting)
+ [Configurazione per una rete che si connette ai AWS servizi tramite endpoint VPC](#CHAP_ReplicationInstance.VPC.Configurations.vpcendpoints)
+ [Configurazione per una rete che si connette ai servizi tramite Internet AWS](#CHAP_ReplicationInstance.VPC.Configuration.networkconnectingusinginternet)
Se possibile, è consigliabile creare un'istanza di replica DMS nella stessa regione dell'endpoint di destinazione e nello stesso VPC o nella stessa sottorete dell'endpoint di destinazione.
### Configurazione con tutti i componenti di migrazione del database in un VPC
La rete più semplice per la migrazione del database è quella in cui l'endpoint di origine, l'istanza di replica e l'endpoint di destinazione si trovano tutti nello stesso VPC. Questa configurazione è appropriata se gli endpoint di origine e di destinazione si trovano su un'istanza database Amazon RDS o su un'istanza Amazon EC2.
La figura seguente illustra una configurazione in cui un database su un'istanza Amazon EC2 si connette all'istanza di replica e i dati vengono migrati in un'istanza database Amazon RDS.
![\[AWS Database Migration Service: esempio di VPC tutto in uno\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-scenarioAllVPC.png)
Il gruppo di sicurezza VPC utilizzato in questa configurazione deve consentire l'ingresso sulla porta del database dall'istanza di replica. Ci sono due modi per farlo. È possibile garantire che il gruppo di sicurezza utilizzato dall'istanza di replica abbia accesso agli endpoint. Oppure puoi consentire l'intervallo VPC CIDR, l'IP elastico del gateway NAT o l'indirizzo IP privato dell'istanza di replica, se ne stai utilizzando una. Tuttavia, non è consigliabile utilizzare l'indirizzo IP privato dell'istanza di replica, poiché potrebbe interrompere la replica se l'indirizzo IP di replica cambia.
### Configurazione con più VPCs
Se l'endpoint di origine e l'endpoint di destinazione sono diversi VPCs, puoi creare l'istanza di replica in uno dei. VPCs È quindi possibile collegare i due VPCs utilizzando il peering VPC.
Una connessione peering VPC è una connessione di rete tra due VPCs che consente il routing utilizzando gli indirizzi IP privati di ciascun VPC come se si trovassero nella stessa rete. Puoi creare una connessione peering VPC tra i tuoi VPCs, con un VPC in un altro AWS account o con un VPC in un'altra regione. AWS Per ulteriori informazioni sul peering di VPC, consulta [Peering di VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) nella *Guida per l'utente di Amazon VPC*.
La figura seguente illustra una configurazione di esempio che utilizza il peering di VPC. Nella figura, il database di origine su un'istanza Amazon EC2 in un VPC viene collegato a un VPC mediante il peering di VPC. Questo VPC contiene l'istanza di replica e il database di destinazione su un'istanza database Amazon RDS.
![\[AWS Istanza di replica del Database Migration Service\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-scenarioVPCPeer.png)
Per implementare il peering VPC, segui le istruzioni riportate in [Utilizzo di connessioni peering VPC](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html) nella documentazione *Peering di VPC di Amazon Virtual Private Cloud*. Assicurati che la tabella di routing di un VPC contenga il blocco CIDR dell'altro. Ad esempio, se il VPC A utilizza la destinazione 10.0.0.0/16 e il VPC B utilizza la destinazione 172.31.0.0, la tabella di routing del VPC A deve contenere 172.31.0.0 e la tabella di routing del VPC B deve contenere 10.0.0.0/16. Per informazioni più dettagliate, consulta [Aggiornamento delle tabelle di routing per una connessione peering VPC](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html) nella documentazione *Peering di VPC di Amazon Virtual Private Cloud*.
I gruppi di sicurezza VPC utilizzati in questa configurazione devono consentire l'ingresso sulla porta del database dall'istanza di replica o sul blocco CIDR del VPC in peering.
### Configurazione con condivisione VPCs
AWS DMS tratta le sottoreti condivise con un account cliente partecipante di un'organizzazione come le normali sottoreti dello stesso account. Di seguito è riportata una descrizione delle modalità di AWS DMS gestione VPCs, delle sottoreti e di come è possibile utilizzare la condivisione. VPCs
È possibile configurare la configurazione di rete per operare in sottoreti personalizzate o VPCs creando oggetti. `ReplicationSubnetGroup` Quando crei un oggetto `ReplicationSubnetGroup`, puoi scegliere di specificare le sottoreti di un particolare VPC nel tuo account. L'elenco di sottoreti specificato deve includere almeno due sottoreti che si trovano in zone di disponibilità separate e tutte le sottoreti devono trovarsi nello stesso VPC. Durante la creazione di un`ReplicationSubnetGroup`, i clienti specificano solo le sottoreti. AWS DMS determinerà il VPC per tuo conto, poiché ogni sottorete è collegata esattamente a un VPC.
Quando si crea un AWS DMS `ReplicationInstance` o un AWS DMS `ReplicationConfig`, è possibile scegliere di specificare `ReplicationSubnetGroup` and/or un gruppo di sicurezza VPC in cui opera la replica `ReplicationInstance` o serverless. Se non specificato, AWS DMS sceglie l'impostazione predefinita del cliente `ReplicationSubnetGroup` (che AWS DMS viene creata per tuo conto se non è specificata per tutte le sottoreti nel VPC predefinito) e il gruppo di sicurezza VPC predefinito.
Puoi scegliere di eseguire le migrazioni in una zona di disponibilità che specifichi oppure in una qualsiasi delle zone di disponibilità del tuo `ReplicationSubnetGroup`. Quando AWS DMS tenta di creare un'istanza di replica o avviare una replica serverless, converte le zone di disponibilità delle sottoreti in zone di disponibilità nell'account di servizio principale, per garantire l'avvio delle istanze nella zona di disponibilità corretta anche se le mappature delle zone di disponibilità non sono identiche tra i due account.
Se utilizzi un VPC condiviso, dovrai assicurarti di creare gli oggetti `ReplicationSubnetGroup` mappati alle sottoreti che desideri utilizzare da un VPC condiviso. Quando crei un oggetto `ReplicationInstance` o `ReplicationConfig`, devi specificare un oggetto `ReplicationSubnetGroup` per il VPC condiviso e un gruppo di sicurezza VPC che hai creato per il VPC condiviso con la richiesta di creazione.
Nota quanto segue in relazione all'utilizzo di un VPC condiviso:
+ Il proprietario del VPC non può condividere una risorsa con un partecipante, ma il partecipante può creare una risorsa di servizio nella sottorete del proprietario.
+ Il proprietario del VPC non può accedere a una risorsa (come un'istanza di replica) creata dal partecipante perché tutte le risorse sono specifiche dell'account. Tuttavia, se si crea l'istanza di replica nel VPC condiviso, questa può accedere alle risorse nel VPC indipendentemente dall'account proprietario, purché l'endpoint o l'attività di replica disponga delle autorizzazioni corrette.
+ Poiché le risorse sono specifiche dell'account, i partecipanti non possono accedere alle risorse di proprietà di altri account. Non ci sono autorizzazioni che puoi fornire ad altri account per consentire loro di accedere alle risorse create nel VPC condiviso con il tuo account.
### Configurazione per una rete verso un VPC utilizzando Direct Connect o una VPN
Le reti remote possono connettersi a un VPC utilizzando diverse opzioni come AWS Direct Connect o una connessione VPN software o hardware. Queste opzioni vengono spesso utilizzate per integrare servizi locali esistenti, ad esempio servizi di monitoraggio, autenticazione, sicurezza, dati o altri sistemi, estendendo una rete interna nel cloud AWS . Questo tipo di estensione di rete consente di connettersi senza problemi alle risorse ospitate su AWS, come un VPC.
La figura seguente illustra una configurazione in cui l'endpoint di origine è un database locale in un data center aziendale. Mediante Direct Connect o una VPN, il database si connette a un VPC contenente l'istanza di replica e un database di origine su un'istanza database Amazon RDS.
![\[AWS Istanza di replica del Database Migration Service\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-scenarioDirect.png)
In questa configurazione, il gruppo di sicurezza VPC deve includere una regola di indirizzamento che invia a un host il traffico destinato a un intervallo CIDR del VPC o un indirizzo IP specifico. Questo host deve essere in grado di collegare il traffico del VPC nella VPN locale. In questo caso, l'host NAT include le proprie impostazioni del gruppo di sicurezza. Queste impostazioni devono consentire il traffico proveniente dall'intervallo CIDR del VPC, dall'indirizzo IP privato o dal gruppo di sicurezza dell'istanza di replica all'istanza NAT. Tuttavia, non è consigliabile utilizzare l'indirizzo IP privato dell'istanza di replica, poiché potrebbe interrompere la replica se l'indirizzo IP di replica cambia.
### Configurazione di una rete per un VPC mediante Internet
Se non utilizzi una VPN o non ti connetti Direct Connect alle AWS risorse, puoi utilizzare Internet per migrare il database. In questo caso, è possibile eseguire la migrazione a un'istanza Amazon EC2 o a un'istanza database Amazon RDS. Questa configurazione prevede un'istanza di replica pubblica in un VPC con un gateway Internet contenente l'endpoint di destinazione e l'istanza di replica.
![\[AWS Istanza di replica del Database Migration Service\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-scenarioInternet.png)
Per aggiungere un gateway Internet al VPC, consulta [Collegamento di un gateway Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway) nella *Guida per l'utente di Amazon VPC*.
La tabella di routing VPC deve includere regole di instradamento che, per impostazione predefinita, inviano al gateway Internet il traffico non destinato al VPC. In questa configurazione, la connessione all'endpoint viene eseguita dall'indirizzo IP pubblico dell'istanza di replica e non dall'indirizzo IP privato. Per ulteriori informazioni, consulta [Tabelle di routing VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) nella *Guida per l'utente di Amazon VPC*.
### Configurazione con un'istanza DB RDS non in un VPC su un'istanza DB in un VPC utilizzando ClassicLink
| |
| --- |
| Ritireremo EC2-Classic il 15 agosto 2022. Suggeriamo di effettuare la migrazione da EC2-Classic a un VPC. Per ulteriori informazioni, consulta [Eseguire la migrazione da EC2-Classic a un VPC](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-migrate.html) nella Guida per l'utente di Amazon EC2 e il blog [EC2-Classic Networking is Retiring – Here's How to Prepare](https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-heres-how-to-prepare/) (Il networking EC2-Classic viene ritirato: ecco come prepararsi). |
Per connettere un'istanza DB Amazon RDS non in un VPC a un server di replica DMS e un'istanza DB in un VPC, puoi utilizzarla con un server proxy. ClassicLink
ClassicLink ti consente di collegare un'istanza DB EC2-Classic a un VPC nel tuo account, all'interno della stessa regione. AWS Dopo aver creato il link, l'istanza database di origine può comunicare con l'istanza di replica all'interno del VPC mediante gli indirizzi IP privati.
Poiché l'istanza di replica nel VPC non può accedere direttamente all'istanza DB di origine sulla piattaforma EC2-Classic ClassicLink utilizzando, si utilizza un server proxy. Il server proxy connette l'istanza database di origine al VPC contenente l'istanza di replica e l'istanza database di destinazione. Il server proxy utilizza ClassicLink per connettersi al VPC. L'inoltro della porta sul server proxy consente la comunicazione tra l'istanza database di origine e l'istanza database di destinazione nel VPC.
![\[AWS Database Migration Service utilizzando ClassicLink\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-scenarioClassicLink.png)
#### Utilizzo ClassicLink con AWS Database Migration Service
Puoi connettere un'istanza DB Amazon RDS che non si trova in un VPC a un server di replica DMS e AWS un'istanza DB che si trovano in un VPC. A tale scopo, puoi utilizzare Amazon EC2 ClassicLink con un server proxy.
La procedura seguente mostra come utilizzarlo ClassicLink per questo scopo. Questa procedura collega un'istanza DB di origine Amazon RDS che non si trova in un VPC a un VPC contenente un'istanza di replica DMS e AWS un'istanza DB di destinazione.
+ Crea un'istanza di replica AWS DMS in un VPC. (Tutte le istanze di replica vengono create in.) VPCs
+ Associa un gruppo di sicurezza VPC all'istanza di replica e all'istanza database di destinazione. Quando due istanze condividono un gruppo di sicurezza VPC, possono comunicare tra loro per impostazione predefinita.
+ Configura un server proxy su un'istanza EC2 Classic.
+ Crea una connessione ClassicLink tra il server proxy e il VPC.
+ Crea endpoint AWS DMS per i database di origine e di destinazione.
+ Crea un'attività AWS DMS.
**Da utilizzare ClassicLink per migrare un database su un'istanza DB non in un VPC verso un database su un'istanza DB in un VPC**
1. Crea un'istanza di replica AWS DMS e assegna un gruppo di sicurezza VPC:
1. [Accedi a Console di gestione AWS e apri la console nella versione v2/. AWS DMS https://console.aws.amazon.com/dms/](https://console.aws.amazon.com/dms/v2/)
Se hai effettuato l'accesso come utente AWS Identity and Access Management (IAM), assicurati di disporre delle autorizzazioni di accesso appropriate. AWS DMS Per ulteriori informazioni sulle autorizzazioni necessarie per la migrazione del database, consulta [Autorizzazioni IAM necessarie per l'uso AWS DMS](security-iam.md#CHAP_Security.IAMPermissions).
1. Nella pagina **Dashboard (Pannello di controllo)**, scegli **Replication Instance (Istanza di replica)**. Per creare un'istanza di replica, segui le istruzioni riportate nella sezione [Passaggio 1: creare un'istanza di replica utilizzando la console AWS DMS](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.ReplicationInstance).
1. Dopo aver creato l'istanza di replica AWS DMS, apri la console di servizio EC2. Seleziona **Interfacce di rete** nel riquadro di navigazione.
1. **Scegli l'*DMSNetworkinterfaccia*, quindi scegli **Cambia gruppi di sicurezza dal menu** Azioni.**
1. Scegli il gruppo di sicurezza che desideri utilizzare per l'istanza di replica e l'istanza database di destinazione.
1. Associa il gruppo di sicurezza dell'ultima fase all'istanza database di destinazione:
1. Apri la console del servizio Amazon RDS. Nel riquadro di navigazione, scegli **Istanze**.
1. Scegli l'istanza database di destinazione. Per **Operazioni istanza** scegli **Modifica**.
1. Per il parametro **Gruppo di sicurezza** seleziona il gruppo di sicurezza che hai usato nella fase precedente.
1. Scegli **Continua**, quindi seleziona **Modifica istanza database**.
1. Fase 3: configurazione di un server proxy su un'istanza EC2 Classic mediante NGINX. Utilizza un'AMI di tua scelta per avviare un'istanza EC2 Classic. L'esempio seguente si basa sull'AMI Ubuntu Server 14.04 LTS (HVM).
Per configurare un server proxy su un'istanza EC2 Classic
1. Connettiti all'istanza EC2 Classic e installa NGINX utilizzando i comandi seguenti:
```
Prompt> sudo apt-get update
Prompt> sudo wget http://nginx.org/download/nginx-1.9.12.tar.gz
Prompt> sudo tar -xvzf nginx-1.9.12.tar.gz
Prompt> cd nginx-1.9.12
Prompt> sudo apt-get install build-essential
Prompt> sudo apt-get install libpcre3 libpcre3-dev
Prompt> sudo apt-get install zlib1g-dev
Prompt> sudo ./configure --with-stream
Prompt> sudo make
Prompt> sudo make install
```
1. Modificare il file del daemon NGINX, `/etc/init/nginx.conf`, utilizzando il seguente codice:
```
# /etc/init/nginx.conf – Upstart file
description "nginx http daemon"
author "email"
start on (filesystem and net-device-up IFACE=lo)
stop on runlevel [!2345]
env DAEMON=/usr/local/nginx/sbin/nginx
env PID=/usr/local/nginx/logs/nginx.pid
expect fork
respawn
respawn limit 10 5
pre-start script
$DAEMON -t
if [ $? -ne 0 ]
then exit $?
fi
end script
exec $DAEMON
```
1. Creare un file di configurazione NGINX in `/usr/local/nginx/conf/nginx.conf`. Nel file di configurazione aggiungi quanto segue:
```
# /usr/local/nginx/conf/nginx.conf - NGINX configuration file
worker_processes 1;
events {
worker_connections 1024;
}
stream {
server {
listen DB instance port number;
proxy_pass DB instance identifier:DB instance port number;
}
}
```
1. Dalla riga di comando, avvia NGINX utilizzando i comandi seguenti:
```
Prompt> sudo initctl reload-configuration
Prompt> sudo initctl list | grep nginx
Prompt> sudo initctl start nginx
```
1. Crea una ClassicLink connessione tra il server proxy e il VPC di destinazione che contiene l'istanza DB di destinazione e l'istanza di replica:
1. Apri la console EC2 e scegli l'istanza EC2 Classic su cui è in esecuzione il server proxy.
1. Per **Azioni**, scegli **ClassicLink**, quindi scegli **Collega a VPC**.
1. Scegli il gruppo di sicurezza che hai usato in precedenza in questa procedura.
1. Scegli **Collegamento a VPC**.
1. Passaggio 5: Creare endpoint AWS DMS utilizzando la procedura descritta in. [Fase 2: specificazione degli endpoint di origine e di destinazione](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Endpoints) Dovrai utilizzare il nome host DNS EC2 interno del proxy come nome del server quando specifichi l'endpoint di origine.
1. Creare un'attività AWS DMS utilizzando la procedura in. [Fase 3: creazione di un'attività e migrazione dei dati](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Tasks)
### Configurazione per una rete che si connette ai servizi AWS
Per connetterti ai AWS servizi, utilizza una connessione Internet o endpoint Virtual Private Cloud (VPC). Ciò si applica quando:
Gli endpoint di origine o di destinazione utilizzano AWS servizi come:
+ Gestione dei segreti AWS
+ Amazon Simple Storage Service
L'endpoint di destinazione è un AWS servizio come:
+ Simple Storage Service (Amazon S3)
+ Amazon Kinesis
+ Amazon DynamoDB
+ Amazon Redshift
+ OpenSearch Servizio Amazon
+ Amazon Athena
### Configurazione per una rete che si connette ai AWS servizi tramite endpoint VPC
Gli endpoint VPC forniscono connessioni sicure tra le tue AWS risorse, collegando le risorse VPC ai AWS servizi senza richiedere l'accesso a Internet. Le tue applicazioni in sottoreti private possono accedere ai AWS servizi rimanendo all'interno della AWS rete, migliorando la sicurezza e riducendo la latenza. Si prega di fare riferimento all'immagine seguente:
![\[\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/aws_dms_vpc_endpoints.jpg)
Per ulteriori informazioni, consulta [Configurazione degli endpoint VPC AWS DMS come endpoint di origine e destinazione e](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_VPC_Endpoints.html) [Configurazione AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Advanced.Endpoints.secretsmanager.html) degli endpoint VPC di Secrets Manager.
### Configurazione per una rete che si connette ai servizi tramite Internet AWS
Un'istanza di replica richiede l'accesso a Internet per connettersi alle AWS risorse durante la migrazione dei dati.
*Per ulteriori informazioni sulle sottoreti private e pubbliche all'interno di un VPC, consulta Esempio[: VPC con server in sottoreti private e NAT nella Amazon Virtual Private Cloud User](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html) Guide.* Devi assicurarti di testare la configurazione di rete per la connettività con qualsiasi servizio richiesto.
## Creazione di un gruppo di sottoreti di replica
Nella rete da utilizzare per la migrazione del database è necessario specificare le sottoreti del cloud privato virtuale (VPC) che intendi utilizzare. Il VPC si deve basare sul servizio Amazon VPC. Una *sottorete* è un intervallo di indirizzi IP nel VPC all'interno di una determinata zona di disponibilità. Queste sottoreti possono essere distribuite tra le zone di disponibilità della AWS regione in cui si trova il VPC.
Quando crei un'istanza di replica o un profilo di istanza nella console AWS DMS, puoi utilizzare la sottorete che preferisci.
Puoi creare un gruppo di sottoreti di replica per definire le sottoreti da utilizzare. È necessario specificare le sottoreti in almeno due zone di disponibilità.
**Per creare un gruppo di sottoreti di replica**
1. [Accedi a Console di gestione AWS e apri la AWS DMS console nella versione v2/. https://console.aws.amazon.com/dms/](https://console.aws.amazon.com/dms/v2/)
Se hai eseguito l'accesso come utente IAM, verifica di disporre delle autorizzazioni appropriate per accedere a AWS DMS. Per ulteriori informazioni sulle autorizzazioni necessarie per la migrazione del database, consulta [Autorizzazioni IAM necessarie per l'uso AWS DMS](security-iam.md#CHAP_Security.IAMPermissions).
1. Nel pannello di navigazione selezionare **Subnet groups (Gruppi di sottoreti)**.
1. Scegli **Crea gruppo di sottoreti**.
1. Nella pagina **Crea gruppo di sottoreti di replica** specifica le informazioni sul gruppo di sottoreti di replica. Nella tabella seguente vengono illustrate le impostazioni.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_ReplicationInstance.VPC.html)
1. Scegli **Crea gruppo di sottoreti**.
## Risoluzione degli endpoint di dominio con DNS
Di solito, un'istanza di AWS DMS replica utilizza il resolver Domain Name System (DNS) in un'istanza Amazon EC2 per risolvere gli endpoint di dominio. Se devi eseguire la risoluzione DNS, puoi utilizzare il risolutore Amazon Route 53. Per ulteriori informazioni sull'utilizzo del risolutore DNS Route 53, consulta [Nozioni di base su Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-getting-started.html).
Per informazioni su come utilizzare il server dei nomi on-premise per risolvere determinati endpoint con il risolutore Amazon Route 53, consulta [Utilizzo del server dei nomi in locale](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver).
# Impostazione di una chiave di crittografia per un'istanza di replica
AWS DMS crittografa lo storage utilizzato da un'istanza di replica e le informazioni di connessione all'endpoint. Per crittografare lo storage utilizzato da un'istanza di replica, AWS DMS utilizza un AWS KMS key file univoco per l'account dell'utente. AWS È possibile visualizzare e gestire questa chiave KMS con (). AWS Key Management Service AWS KMS Puoi utilizzare la chiave KMS predefinita nel tuo account (`aws/dms`) o puoi creare una nuova chiave KMS. Se disponi di una chiave di AWS KMS crittografia esistente, puoi anche utilizzare quella chiave per la crittografia.
È possibile specificare la propria chiave di crittografia fornendo un identificatore di chiave KMS per crittografare le risorse DMS. AWS Quando specifichi una chiave di crittografia personalizzata, l'account utente utilizzato per eseguire la migrazione del database deve avere accesso a tale chiave. Per ulteriori informazioni sulla creazione delle chiavi di crittografia personalizzate e sull'assegnazione agli utenti dell'accesso a una chiave di crittografia, consulta la *[Guida per gli sviluppatori di AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)*.
Se non specifichi un identificatore di chiave KMS, DMS utilizza la chiave di crittografia predefinita. AWS KMS crea la chiave di crittografia predefinita per AWS DMS per il tuo account. AWS Il tuo AWS account ha una chiave di crittografia predefinita diversa per ogni AWS regione.
Per gestire le chiavi utilizzate per crittografare le risorse AWS DMS, si utilizza. AWS KMS Puoi trovarlo cercando **KMS AWS KMS ** nel pannello di navigazione. Console di gestione AWS
AWS KMS combina hardware e software sicuri e ad alta disponibilità per fornire un sistema di gestione delle chiavi scalabile per il cloud. Utilizzando AWS KMS, è possibile creare chiavi di crittografia e definire le politiche che controllano il modo in cui tali chiavi possono essere utilizzate. AWS KMS supporta AWS CloudTrail, in modo da poter controllare l'utilizzo delle chiavi per verificare che vengano utilizzate in modo appropriato. AWS KMS Le chiavi possono essere utilizzate in combinazione con AWS DMS e altri servizi supportati AWS . I servizi AWS supportati sono Amazon RDS, Amazon S3, Amazon Elastic Block Store (Amazon EBS) e Amazon Redshift.
Dopo aver creato le risorse AWS DMS con una chiave di crittografia specifica, non è possibile modificare la chiave di crittografia per tali risorse. Assicurati di determinare i requisiti della chiave di crittografia prima di creare le tue risorse AWS DMS.
# Creazione di un'istanza di replica
La prima attività della migrazione di un database è creare un'istanza di replica. L'istanza di replica deve disporre di storage e potenza di elaborazione sufficienti per eseguire le attività assegnate e migrare i dati dal database di origine al database di destinazione. La dimensione richiesta di questa istanza varia a seconda della quantità di dati da migrare e delle attività che deve eseguire l'istanza. Per ulteriori informazioni sulle istanze di replica, consulta [Utilizzo di un'istanza di AWS DMS replica](CHAP_ReplicationInstance.md).
**Per creare un'istanza di replica utilizzando la console AWS**
1. Scegli **Istanze di replica** nel riquadro di navigazione della AWS DMS console, quindi scegli **Crea** istanza di replica.
1. Nella pagina **Create replication instance (Crea istanza di replica)**, specifica le informazioni sull'istanza di replica. Nella tabella seguente vengono descritte le impostazioni che è possibile definire.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Scegliere la scheda **Advanced** per configurare i valori per le impostazioni di rete e crittografia, se necessari. Nella tabella seguente vengono illustrate le impostazioni.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Specifica le impostazioni di **Maintenance (Manutenzione)**. Nella tabella seguente vengono illustrate le impostazioni. Per ulteriori informazioni sulle impostazioni di manutenzione, consulta [Utilizzo della finestra di AWS DMS manutenzione](CHAP_ReplicationInstance.MaintenanceWindow.md).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Scegli **Create replication instance (Crea istanza di replica)**.
# Modifica di un'istanza di replica
Puoi modificare le impostazioni di un'istanza di replica, ad esempio, per cambiare la classe dell'istanza o per aumentare lo storage.
Quando modifichi un'istanza di replica, puoi applicare le modifiche immediatamente. Per applicare le modifiche immediatamente, puoi scegliere l'opzione **Applica immediatamente le modifiche** nella Console di gestione AWS. Oppure usa il `--apply-immediately` parametro quando chiami o imposta AWS CLI il `ApplyImmediately` parametro su `true` quando usi l'API DMS.
Se non scegli di applicare le modifiche immediatamente, le modifiche vengono inserite nella coda delle modifiche in sospeso. Durante la finestra di manutenzione successiva, le eventuali modifiche in sospeso incluse nella coda vengono eseguite.
**Nota**
Se scegli di applicare le modifiche immediatamente, anche tutte le modifiche incluse nella coda delle modifiche in sospeso saranno applicate. Se nessuna delle modifiche in sospeso richiede tempi di inattività, la scelta dell'opzione **Apply changes immediately (Applica immediatamente le modifiche)** può determinare tempi di inattività imprevisti.
**Per modificare un'istanza di replica utilizzando la console AWS**
1. Accedi a Console di gestione AWS e apri la AWS DMS console nella versione [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Nel riquadro di navigazione, scegli **Replication instances (Istanze di replica)**.
1. Scegli l'istanza di replica che desideri modificare. Nella tabella seguente vengono descritte le modifiche che è possibile apportare.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_ReplicationInstance.Modifying.html)
## Procedure consigliate per la modifica di un'istanza di replica
Quando si modifica un'istanza di replica, seguire queste best practice aiuta a garantire un aggiornamento corretto con un impatto minimo sui flussi di lavoro di migrazione. Esegui i seguenti passaggi chiave prima, durante e dopo le modifiche per mantenere l'integrità dei dati e l'efficienza operativa durante l'intero processo.
**Tempi di modifica del piano:**
+ È possibile applicare le modifiche immediatamente o programmarle per la finestra di manutenzione successiva.
+ Pianifica durante i periodi di traffico ridotto per ridurre al minimo l'impatto.
**Fasi preliminari alla modifica:**
+ Interrompere tutte le attività di replica attive.
+ Verifica che tutte le attività siano state interrotte correttamente.
+ Documenta le impostazioni correnti delle attività di configurazione.
**Durante la modifica:**
+ Monitora l'avanzamento della modifica.
+ Attendi lo stato «Disponibile» prima di procedere.
**Fasi successive alla modifica:**
+ Riprendi tutte le attività interrotte in precedenza.
+ Conferma che le attività vengano eseguite correttamente.
# riavvio di un'istanza di replica.
È possibile riavviare un'istanza di AWS DMS replica per riavviare il motore di replica. Il riavvio determina un'interruzione momentanea dell'istanza di replica, durante la quale lo stato dell'istanza viene impostato su **Rebooting (Riavvio in corso)**. Se l' AWS DMS istanza è configurata per Multi-AZ, il riavvio può essere eseguito con un failover. Al termine del riavvio viene creato un AWS DMS evento.
Se l' AWS DMS istanza è una distribuzione Multi-AZ, è possibile forzare un failover pianificato da una zona di AWS disponibilità all'altra al riavvio. Quando si impone un failover pianificato dell' AWS DMS istanza, AWS DMS chiude le connessioni attive sull'istanza corrente prima di passare automaticamente a un'istanza di standby in un'altra zona di disponibilità. Il riavvio con un failover pianificato consente di simulare un evento di failover pianificato di un'istanza, ad esempio quando si ridimensiona la classe dell' AWS DMS istanza di replica.
**Nota**
Dopo che un riavvio impone un failover da una zona di disponibilità a un'altra, la modifica della zona di disponibilità potrebbe non essere riflessa per alcuni minuti. Questo ritardo appare nelle e nelle chiamate all'API and Console di gestione AWS. AWS CLI AWS DMS
Se le attività di migrazione sono in esecuzione sull'istanza di replica quando avviene un riavvio, non si verifica alcuna perdita di dati, ma l'attività si interrompe e l'attività passa a uno stato di errore.
Se le tabelle dell'attività di migrazione vengono usate in un caricamento in blocco (fase di pieno carico) e non sono ancora state avviate, entrano in uno stato di errore. Tuttavia, le tabelle completate al momento rimangono in uno stato completato. Quando si verifica un riavvio durante la fase di pieno carico, si consiglia di eseguire uno dei passaggi seguenti.
+ Rimuovi dall'attività le tabelle che si trovano nello stato completato e riavvia l'attività con le tabelle rimanenti.
+ Crea una nuova attività con le tabelle in stato di errore e in sospeso.
Se le tabelle nell'attività di migrazione si trovano nella fase di replica continua, l'attività riprenderà al termine del riavvio.
**Non è possibile riavviare l'istanza di AWS DMS replica se il relativo stato non è nello stato Disponibile.** L' AWS DMS istanza può non essere disponibile per diversi motivi, ad esempio una modifica richiesta in precedenza o un'azione relativa alla finestra di manutenzione. Il tempo necessario per riavviare un'istanza di AWS DMS replica è in genere ridotto (meno di 5 minuti).
## Riavvio di un'istanza di replica utilizzando la console AWS
Per riavviare un'istanza di replica, utilizzare la console. AWS
**Per riavviare un'istanza di replica utilizzando la console AWS**
1. [Accedi a Console di gestione AWS e apri la AWS DMS console nella versione v2/. https://console.aws.amazon.com/dms/](https://console.aws.amazon.com/dms/v2/)
1. Nel riquadro di navigazione, scegli **Replication instances (Istanze di replica)**.
1. Scegli l'istanza di replica che desideri riavviare.
1. Scegliere **Reboot (Riavvia)**. Viene visualizzata la finestra di dialogo **Riavvia istanza di replica**.
1. Seleziona la casella di controllo **Riavvia con failover?** se hai configurato l'istanza di replica per l'implementazione multi-AZ e desideri eseguire il failover su un'altra zona di disponibilità AWS .
1. Scegliere **Reboot (Riavvia)**.
## Riavvio di un'istanza di replica mediante l'interfaccia a riga di comando (CLI)
Per riavviare un'istanza di replica, utilizzate il AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/dms/reboot-replication-instance.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reboot-replication-instance.html)comando con il seguente parametro:
+ `--replication-instance-arn`
**Example Esempio di avvio semplice**
L' AWS CLI esempio seguente riavvia un'istanza di replica.
```
aws dms reboot-replication-instance \
--replication-instance-arn arn of my rep instance
```
**Example Esempio di riavvio semplice con failover**
L' AWS CLI esempio seguente riavvia un'istanza di replica con failover.
```
aws dms reboot-replication-instance \
--replication-instance-arn arn of my rep instance \
--force-planned-failover
```
## Riavvio di un'istanza di replica mediante l'API
Per riavviare un'istanza di replica, utilizzate l'[https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)azione AWS DMS API con i seguenti parametri:
+ `ReplicationInstanceArn = arn of my rep instance`
**Example Esempio di avvio semplice**
Il codice di esempio seguente riavvia un'istanza di replica.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=RebootReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &SignatureMethod=HmacSHA256
5. &SignatureVersion=4
6. &Version=2014-09-01
7. &X-Amz-Algorithm=AWS4-HMAC-SHA256
8. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
9. &X-Amz-Date=20140425T192732Z
10. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
11. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
**Example Esempio di riavvio semplice con failover**
Il seguente esempio di codice riavvia un'istanza di replica e esegue il failover in un'altra zona di disponibilità. AWS
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=RebootReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &ForcePlannedFailover=true
5. &SignatureMethod=HmacSHA256
6. &SignatureVersion=4
7. &Version=2014-09-01
8. &X-Amz-Algorithm=AWS4-HMAC-SHA256
9. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
10. &X-Amz-Date=20140425T192732Z
11. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
12. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
# Eliminazione di un'istanza di replica.
È possibile eliminare un'istanza AWS DMS di replica al termine dell'utilizzo. Se l'istanza di replica è utilizzata da attività di migrazione, è necessario arrestare ed eliminare tali attività prima di eliminare l'istanza di replica.
Se chiudi l' AWS account, tutte le AWS DMS risorse e le configurazioni associate all'account vengono eliminate dopo due giorni. Queste risorse includono tutte le istanze di replica, la configurazione degli endpoint di origine e di destinazione, le attività di replica e i certificati SSL. Se dopo due giorni decidi di AWS DMS riutilizzarlo, ricrei le risorse di cui hai bisogno.
Se l'istanza di replica soddisfa tutti i criteri per l'eliminazione e rimane nello stato `DELETING` per un periodo di tempo prolungato, contatta l'assistenza per risolvere il problema.
## Eliminazione di un'istanza di replica tramite la console AWS
Per eliminare un'istanza di replica, utilizzare la console. AWS
**Per eliminare un'istanza di replica utilizzando la console AWS**
1. Accedi a Console di gestione AWS e apri la AWS DMS console nella versione [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Nel riquadro di navigazione, scegli **Replication instances (Istanze di replica)**.
1. Scegli l'istanza di replica da eliminare.
1. Scegli **Elimina**.
1. Nella finestra di dialogo, scegli **Delete (Elimina)**.
## Eliminazione di un'istanza di replica mediante l'interfaccia a riga di comando (CLI)
Per eliminare un'istanza di replica, utilizzate il AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/dms/delete-replication-instance.html](https://docs.aws.amazon.com/cli/latest/reference/dms/delete-replication-instance.html)comando con il seguente parametro:
+ `--replication-instance-arn`
**Example Esempio di eliminazione**
L' AWS CLI esempio seguente elimina un'istanza di replica.
```
aws dms delete-replication-instance \
--replication-instance-arn arn of my rep instance
```
## Eliminazione di un'istanza di replica mediante l'API
Per eliminare un'istanza di replica, utilizzate l'[https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html](https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html)azione AWS DMS API con i seguenti parametri:
+ `ReplicationInstanceArn = arn of my rep instance`
**Example Esempio di eliminazione**
Il codice seguente elimina un'istanza di replica.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=DeleteReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &SignatureMethod=HmacSHA256
5. &SignatureVersion=4
6. &Version=2014-09-01
7. &X-Amz-Algorithm=AWS4-HMAC-SHA256
8. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
9. &X-Amz-Date=20140425T192732Z
10. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
11. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
# Utilizzo della finestra di AWS DMS manutenzione
Ogni istanza AWS DMS di replica ha una finestra di manutenzione settimanale durante la quale vengono applicate tutte le modifiche al sistema disponibili. La finestra di manutenzione può essere considerata come un'opportunità per controllare quando vengono applicate le modifiche e le patch software.
Se si AWS DMS determina che la manutenzione è necessaria durante una determinata settimana, la manutenzione viene eseguita durante la finestra di manutenzione di 30 minuti scelta al momento della creazione dell'istanza di replica. AWS DMS completa la maggior parte della manutenzione durante la finestra di manutenzione di 30 minuti. Tuttavia, potrebbe essere necessario un periodo di tempo più lungo per applicare modifiche di dimensioni maggiori.
## Effetto della manutenzione sulle attività di migrazione esistenti
Quando un'attività di AWS DMS migrazione è in esecuzione su un'istanza, quando viene applicata una patch si verificano i seguenti eventi:
+ Se le tabelle dell'attività di migrazione si trovano nella fase di replica delle modifiche in corso (CDC), AWS DMS arresta l'attività per un momento e quindi la riprende dopo l'applicazione della patch. La migrazione quindi prosegue dal punto in cui è stata interrotta quando è stata applicata la patch.
+ Se AWS DMS si sta eseguendo la migrazione di una tabella come parte di un'attività di **migrazione dei dati esistenti** o di **migrazione dei dati esistenti e replica delle modifiche in corso**, DMS interrompe e riavvia la migrazione per tutte le tabelle in fase di pieno caricamento durante l'applicazione della patch. DMS inoltre arresta e riprende tutte le tabelle in fase CDC mentre viene applicata la patch.
## Modifica dell'impostazione della finestra di manutenzione
È possibile modificare l'intervallo di tempo della finestra di manutenzione utilizzando l' Console di gestione AWS, l'o l'API. AWS CLI AWS DMS
### Modifica dell'impostazione della finestra di manutenzione mediante la console
Puoi utilizzare la Console di gestione AWS per modificare l'intervallo di tempo della finestra di manutenzione.
**Per modificare la finestra di manutenzione preferita mediante la console**
1. Accedi a Console di gestione AWS e apri la AWS DMS console su [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Nel riquadro di navigazione, scegli **Replication instances (Istanze di replica)**.
1. Scegli l'istanza di replica che desideri modificare e scegli **Modify (Modifica)**.
1. Espandi la scheda **Maintenance (Manutenzione)** e scegli una data e un'ora per la finestra di manutenzione.
1. Scegli **Apply changes immediately (Applica immediatamente le modifiche)**.
1. Scegli **Modifica**.
### Modifica dell'impostazione della finestra di manutenzione mediante l'interfaccia a riga di comando (CLI)
Per regolare la finestra di manutenzione preferita, usa il AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)comando con i seguenti parametri.
+ `--replication-instance-identifier`
+ `--preferred-maintenance-window`
**Example**
L' AWS CLI esempio seguente imposta la finestra di manutenzione sul martedì dalle 4:00 alle 4:30. UTC.
```
aws dms modify-replication-instance \
--replication-instance-identifier myrepinstance \
--preferred-maintenance-window Tue:04:00-Tue:04:30
```
### Modifica dell'impostazione della finestra di manutenzione mediante l'API
Per regolare la finestra di manutenzione preferita, utilizzate l'[https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)azione AWS DMS API con i seguenti parametri.
+ `ReplicationInstanceIdentifier = myrepinstance`
+ `PreferredMaintenanceWindow = Tue:04:00-Tue:04:30`
**Example**
Nell'esempio di codice seguente la finestra di manutenzione viene impostata su martedì dalle 4:00 alle 4:30. UTC.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=ModifyReplicationInstance
3. &DBInstanceIdentifier=myrepinstance
4. &PreferredMaintenanceWindow=Tue:04:00-Tue:04:30
5. &SignatureMethod=HmacSHA256
6. &SignatureVersion=4
7. &Version=2014-09-01
8. &X-Amz-Algorithm=AWS4-HMAC-SHA256
9. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
10. &X-Amz-Date=20140425T192732Z
11. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
12. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```