Quando posso aggiungere oggetti secondari a un database di destinazione durante la migrazione di AWS DMS?

4 minuti di lettura
0

In quale fase della migrazione posso aggiungere oggetti secondari al mio database di destinazione con AWS Database Migration Service (AWS DMS)? Inoltre, quali impostazioni di attività posso utilizzare per creare oggetti secondari sul database di destinazione?

Breve descrizione

AWS DMS crea tabelle nel database di destinazione utilizzando l'opzione "TargetTablePrepMode". Quando AWS DMS crea tabelle di destinazione, esegue la migrazione solo degli oggetti di cui ha bisogno per migrare efficacemente i dati verso la destinazione. Ad esempio, AWS DMS crea tabelle, chiavi primarie e, in alcuni casi, indici univoci. Tuttavia, non crea indici secondari, vincoli di chiave non primaria, valori predefiniti dei dati o account utente. Per ulteriori informazioni, consulta la sezione Mancano le chiavi esterne e gli indici secondari.

Se stai creando manualmente tabelle sulla destinazione prima della migrazione, una best practice consiste nell'eliminare oggetti secondari come gli indici secondari prima dell'inizio della migrazione.

Nota: questo non si applica a un'attività di sola acquisizione dei dati di modifica (CDC).

Pertanto, per garantire che la migrazione abbia esito positivo e per migliorare le prestazioni delle attività, è importante capire quando creare oggetti secondari. I tempi variano a seconda del metodo di migrazione utilizzato dall'attività:

  • Solo caricamento completo (migrazione dei dati esistenti)
  • Caricamento completo e CDC (migrazione dei dati esistenti e replica delle modifiche continue)
  • CDC (replica solo delle modifiche ai dati)

Risoluzione

Solo caricamento completo

Per un'attività solo caricamento completo, una best practice consiste nell'eliminare le chiavi primarie e tutti gli oggetti secondari prima dell'inizio della migrazione. Non creare questi oggetti fino al termine del caricamento completo. Se disponi di oggetti secondari nel database di destinazione durante il caricamento completo, è possibile che si verifichi un sovraccarico di manutenzione aggiuntivo.

Se si dispone di chiavi esterne sulla destinazione, l'operazione potrebbe non riuscire. Ciò accade perché l'attività carica insieme vari gruppi di tabelle senza un ordine specifico, a meno che non sia stato specificato manualmente nei mapping delle tabelle.

Analogamente, i trigger di inserimento, aggiornamento o eliminazione potrebbero causare errori se sono presenti nel database di destinazione. Ad esempio, un inserimento di riga attivato da un trigger di inserimento in una tabella caricata in precedenza potrebbe causare righe duplicate. Anche altri tipi di trigger influiscono sulle prestazioni perché generano maggiori attività di elaborazione.

Caricamento completo e CDC

Per le attività di caricamento completo e CDC, una best practice consiste nell'eliminare tutti gli oggetti secondari prima dell'inizio della migrazione. Tuttavia, è necessario applicare oggetti secondari sul database di destinazione in diverse fasi della migrazione.

Esaminare le fasi della migrazione delle attività di caricamento completo e CDC, e in quale fase applicare oggetti secondari specifici:

  • Il caricamento completo dei dati esistenti: aggiungi indici secondari dopo che l'attività ha terminato il caricamento completo, ma prima di applicare le modifiche memorizzate nella cache acquisite.
  • Applicazione delle modifiche memorizzate nella cache: aggiungi chiavi esterne (vincoli di integrità referenziale) dopo che l'attività ha applicato le modifiche memorizzate nella cache.
  • Replica continua: crea trigger dopo il completamento della migrazione e prima della conversione dell'applicazione.

Mentre il caricamento completo è in corso, tutte le modifiche apportate alle tabelle che vengono caricate, sono poi memorizzate nella cache. Tali modifiche memorizzate nella cache vengono applicate al termine del caricamento completo della tabella. Dopo il termine del caricamento completo e l'applicazione delle modifiche memorizzate nella cache, le tabelle di destinazione sono ottimizzate a livello transazionale. AWS DMS, quindi, inizia la fase di replica continua. Per ulteriori informazioni, consulta la sezione Presentazione generale di AWS DMS.

Per interrompere l'attività durante la migrazione, utilizzare le seguenti impostazioni dell'attività:

  • Utilizzare StopTaskCachedChangesNotApplied per interrompere l'attività prima di applicare le modifiche memorizzate nella cache.
  • Utilizzare StopTaskCachedChangesApplied per interrompere l'attività dopo l'applicazione delle modifiche memorizzate nella cache.

Nota: puoi attivare sia "StopTaskCachedChangesNotApplied" che "StopTaskCachedChangesApplied" utilizzando l'interfaccia della linea di comando AWS (AWS CLI). Se ricevi un messaggio di errore durante l’esecuzione dei comandi AWS CLI, assicurati di usare la versione più recente di AWS CLI.

Attività solo CDC

Per le attività solo CDC, è possibile creare gli indici secondari e le chiavi esterne sul database di destinazione prima della migrazione. Quindi, è possibile creare i trigger sulla destinazione al termine della migrazione e prima della conversione dell'applicazione.


Informazioni correlate

Creazione di un'attività

Impostazioni delle attività a pieno carico

AWS UFFICIALE
AWS UFFICIALEAggiornata 2 anni fa