Cut over

La strategia di cutover del database è solitamente strettamente associata ai requisiti di downtime per l'applicazione. Le strategie che è possibile utilizzare per il taglio del database includono la migrazione offline, la migrazione flash-cut, la configurazione attiva/attiva del database e la migrazione incrementale. Questi dettagli vengono illustrarti nelle sezioni seguenti.

Migrazione offline

Se è possibile portare l'applicazione offline per un periodo prolungato durante le operazioni di scrittura, è possibile utilizzareAWS DMSimpostazioni di attività a pieno carico o una delle opzioni di migrazione offline per la migrazione dei dati. Il traffico di lettura può continuare mentre questa migrazione è in corso, ma il traffico di scrittura deve essere interrotto. Poiché tutti i dati devono essere copiati dal database di origine, vengono utilizzate risorse del database di origine come I/O e CPU.

In generale, la migrazione offline prevede le fasi seguenti:

1. Completa la conversione dello schema.

2. Avvia tempi di inattività per il traffico in scrittura.

3. Esegui la migrazione dei dati utilizzando una delle opzioni di migrazione offline.

4. Verifica dei tuoi dati.

5. Individua l'applicazione sul nuovo database.

6. Termina il tempo di inattività dell'applicazione.

Migrazione flash-cut

Nella migrazione flash-cut, l'obiettivo principale è quello di ridurre al minimo i tempi di inattività. Questa strategia si basa sulla replica continua dei dati (CDC) dal database di origine a quello di destinazione. Tutto il traffico di lettura/scrittura continuerà sul database corrente durante la migrazione dei dati. Poiché tutti i dati devono essere copiati dal database di origine, vengono utilizzate risorse del server di origine come I/O e CPU. È necessario verificare che questa attività di migrazione dei dati non influisca sugli SLA sulle prestazioni delle applicazioni.

In generale, la migrazione flash-cut prevede i seguenti passaggi:

1. Completa la conversione dello schema.

2. ConfigurazioneAWS DMSin modalità di replica continua dei dati.

3. Quando i database di origine e di destinazione sono sincronizzati, verifica dei dati.

4. Avvia il tempo di inattività dell'applicazione.

5. Imposta la nuova versione dell'applicazione, che punta al nuovo database.

6. Termina il tempo di inattività dell'applicazione.

Configurazione del database attiva/attiva

La configurazione del database attiva/attiva prevede l'impostazione di un meccanismo per mantenere sincronizzati i database di origine e di destinazione mentre entrambi i database vengono utilizzati per il traffico di scrittura. Questa strategia implica più lavoro rispetto alla migrazione offline o flash-cut, ma offre anche maggiore flessibilità durante la migrazione. Ad esempio, oltre a subire tempi di inattività minimi durante la migrazione, è possibile spostare il traffico di produzione nel nuovo database in batch piccoli e controllati invece di eseguire un cutover una tantum. È possibile eseguire operazioni di doppia scrittura in modo che vengano apportate modifiche a entrambi i database oppure utilizzare uno strumento di replica bidirezionale comeHVRper mantenere sincronizzati i database. Questa strategia ha una maggiore complessità in termini di configurazione e manutenzione, pertanto è necessario un maggior numero di test per evitare problemi di coerenza dei dati.

In generale, la configurazione del database attiva/attiva prevede le fasi seguenti:

1. Completa la conversione dello schema.

2. Copiare i dati esistenti dal database di origine nel database di destinazione, quindi mantenere sincronizzati i due database utilizzando uno strumento di replica bidirezionale o due scritture dall'applicazione.

3. Quando i database di origine e di destinazione sono sincronizzati, verifica dei dati.

4. Inizia a spostare un sottoinsieme del traffico nel nuovo database.

5. Continua a spostare il traffico fino a quando tutto il traffico del database non viene spostato nel nuovo database.

Migrazione incrementale

Nella migrazione incrementale, esegui la migrazione dell'applicazione in parti più piccole anziché eseguire un cutover completo una tantum. Questa strategia di cutover potrebbe avere molte varianti, in base all'architettura attuale dell'applicazione o al refactoring che si desidera eseguire nell'applicazione.

È possibile utilizzare unmodello di designper aggiungere nuovi microservizi indipendenti per sostituire parti di un'applicazione legacy monolitica esistente. Questi microservizi indipendenti hanno tabelle proprie che non sono condivise o accessibili da nessun'altra parte dell'applicazione. È possibile migrare questi microservizi al nuovo database uno per uno, utilizzando una qualsiasi delle altre strategie di cutover. I microservizi migrati iniziano a utilizzare il nuovo database per il traffico di lettura/scrittura mentre tutte le altre parti dell'applicazione continuano a utilizzare il vecchio database. Quando tutti i microservizi sono stati migrati, si disattiva l'applicazione legacy. Questa strategia suddivide la migrazione in parti più piccole e gestibili e può quindi ridurre i rischi associati a un'unica grande migrazione.