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à.
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 + 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 finché 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.
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 (LOB) 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?
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.
-
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 Best practice per AWS Database Migration Service.
-
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 elabora i LOB in memoria. 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
MaxFullLoadSubTasksdurante l'operazione di pieno carico.
-
-
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, i LOB influiscono sulla memoria e il numero 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.
