Esegui la migrazione da AWS a Google Cloud: migra da Amazon RDS e Amazon Aurora per MySQL a Cloud SQL per MySQL

Last reviewed 2024-08-16 UTC

Google Cloud fornisce strumenti, prodotti, indicazioni e servizi professionali per eseguire la migrazione da Amazon Relational Database Service (RDS) o Amazon Aurora a Cloud SQL per MySQL.

Questo documento è rivolto agli amministratori di cloud e database che vogliono pianificare, implementare e convalidare un progetto di migrazione del database. È inoltre prevista per i responsabili delle decisioni che stanno valutando l'opportunità di migrare e desiderano di una migrazione.

Questo documento si concentra su una migrazione del database omogenea, ovvero una migrazione in cui i database di origine e di destinazione utilizzano la stessa tecnologia di database. In questa guida alla migrazione, l'origine è Amazon RDS o Amazon Aurora per MySQL e la destinazione è Cloud SQL per MySQL.

Questo documento fa parte di una serie di articoli sulla migrazione da AWS a Google Cloud che include i seguenti documenti:

• Inizia
• Eseguire la migrazione da Amazon EC2 a Compute Engine
• Eseguire la migrazione da Amazon S3 a Cloud Storage
• Eseguire la migrazione da Amazon EKS a GKE
• Esegui la migrazione da Amazon RDS e Amazon Aurora per MySQL a Cloud SQL per MySQL (questo documento)
• Esegui la migrazione da Amazon RDS e Amazon Aurora per PostgreSQL a Cloud SQL per PostgreSQL e AlloyDB per PostgreSQL
• Eseguire la migrazione da Amazon RDS per SQL Server a Cloud SQL per SQL Server

Per questa migrazione a Google Cloud, ti consigliamo di seguire il framework di migrazione descritto in Eseguire la migrazione a Google Cloud: inizia.

Il seguente diagramma illustra il percorso del tuo percorso di migrazione.

Potresti eseguire la migrazione dal tuo ambiente di origine a Google Cloud in una serie di iterazioni, ad esempio potresti eseguire la migrazione di alcuni carichi di lavoro prima e di altri più tardi. Per ogni singola iterazione della migrazione, segui le fasi del framework generale per la migrazione:

1. Valuta e individua i carichi di lavoro e i dati.
2. Pianifica e crea una base su Google Cloud.
3. Esegui la migrazione dei tuoi carichi di lavoro e dei tuoi dati a Google Cloud.
4. Ottimizza il tuo ambiente Google Cloud.

Per ulteriori informazioni sulle fasi di questo framework, consulta Eseguire la migrazione a Google Cloud: inizia.

Per progettare un piano di migrazione efficace, ti consigliamo di convalidare ogni passaggio del piano e di assicurarti di avere una strategia di rollback. Per aiutarti a convalidare di migrazione, consulta Eseguire la migrazione a Google Cloud: best practice per la convalida di un piano di migrazione.

Valutare l'ambiente di origine

Nella fase di valutazione, devi determinare i requisiti e le dipendenze per eseguire la migrazione dell'ambiente di origine a Google Cloud.

La fase di valutazione è fondamentale per il successo della migrazione. Devi conoscere a fondo i carichi di lavoro di cui vuoi eseguire la migrazione, i loro requisiti dalle loro dipendenze e dal tuo ambiente attuale. Devi comprendere il tuo punto di partenza per pianificare ed eseguire con successo un progetto Google Cloud migrazione.

La fase di valutazione è composta dalle seguenti attività:

1. Crea un inventario completo dei tuoi carichi di lavoro.
2. Cataloga i carichi di lavoro in base alle loro proprietà e dipendenze.
3. Forma e istruisci i tuoi team su Google Cloud.
4. Crea esperimenti e proof of concept su Google Cloud.
5. Calcola il costo totale di proprietà (TCO) dell'ambiente di destinazione.
6. Scegli la strategia di migrazione per i tuoi carichi di lavoro.
7. Scegli gli strumenti di migrazione.
8. Definisci il piano e le tempistiche della migrazione.
9. Convalida il piano di migrazione.

La fase di valutazione del database ti aiuta a scegliere le dimensioni e le specifiche dell'istanza del database Cloud SQL di destinazione corrispondenti all'origine per esigenze di prestazioni simili. Presta particolare attenzione alle dimensioni e alla velocità effettiva del disco, alle IOPS e al numero di vCPU. Le migrazioni potrebbero essere difficoltose o non riuscite a causa di errori delle istanze del database di destinazione. Le dimensioni non corrette possono comportare tempi di migrazione lunghi volte, problemi di prestazioni del database, errori del database e o problemi di prestazioni. Quando scegli l'istanza Cloud SQL, tieni presente che le prestazioni del disco si basano sulle dimensioni del disco e sul numero di vCPU.

Le sezioni seguenti si basano su Eseguire la migrazione a Google Cloud: valuta e scopri i tuoi carichi di lavoro e integrano le informazioni contenute in quel documento.

Crea un inventario delle tue istanze Amazon RDS o Amazon Aurora

Per definire l'ambito della migrazione, devi creare un inventario e raccogliere informazioni sulle tue istanze Amazon RDS o Amazon Aurora. Ti consigliamo di automatizzare questa procedura utilizzando strumenti specializzati, in quanto gli approcci manuali sono soggetti a errori e possono portare a supposizioni errate.

Amazon RDS o Amazon Aurora e Cloud SQL potrebbero non avere caratteristiche, specifiche dell'istanza o operazioni. Alcune funzionalità possono essere se implementate in modo diverso o non sono disponibili. Le aree di differenza possono includere infrastrutture, archiviazione, autenticazione e sicurezza, replica, backup, alta disponibilità, modello di capacità delle risorse e integrazioni ed estensioni di funzionalità specifiche del motore del database. A seconda del tipo di motore del database, dimensioni e architettura, possono esserci anche differenze nei valori predefiniti delle impostazioni dei parametri del database.

Il benchmarking può aiutarti a comprendere meglio i carichi di lavoro di cui deve essere eseguita la migrazione e contribuisce a definire l'architettura corretta dell'ambiente di destinazione della migrazione. La raccolta di informazioni sul rendimento è importante per contribuire a stimare le esigenze di rendimento dell'ambiente di destinazione Google Cloud. I concetti e gli strumenti di benchmarking sono descritti in dettaglio nella Fase di esecuzione di test e convalida del processo di migrazione, ma si applicano anche alla fase di creazione dell'inventario.

Strumenti per le valutazioni

Per una valutazione iniziale della tua infrastruttura attuale, ti consigliamo che utilizzi Centro di migrazione di Google Cloud insieme ad altri strumenti specializzati di valutazione di database come migVisor e Strumento di valutazione della migrazione dei database (DMA).

Con il Centro di migrazione puoi eseguire una valutazione completa del tuo panorama di applicazioni e database, inclusa l'idoneità tecnica per una migrazione del database a Google Cloud. Ricevi consigli sulle dimensioni e sulla configurazione per ogni database di origine e crei un report sul costo totale di proprietà (TCO) per i server e i database.

Per ulteriori informazioni sulla valutazione dell'ambiente AWS mediante Centro di migrazione, consulta Importare dati da altri cloud provider.

Oltre a Migration Center, puoi utilizzare lo strumento migVisor. migVisor supporta vari motori di database ed è particolarmente adatto a migrazioni eterogenee. Per un'introduzione migVisor, vedi il Panoramica di Vision.

migVisor può identificare gli elementi e le funzionalità dei database proprietari incompatibili che possono causare il valore predefinito della migrazione e può indicare le soluzioni alternative. migVisor può anche consigliare una soluzione Google Cloud di destinazione, inclusi le dimensioni e l'architettura iniziali.

L'output della valutazione del database migVisor fornisce quanto segue:

• Rilevamento e analisi completi dei deployment di database attuali.
• Report dettagliato sulla complessità della migrazione, in base alle funzionalità proprie utilizzate dal database.
• Report finanziario con dettagli sui risparmi sui costi dopo la migrazione, sui costi di migrazione e sul nuovo budget operativo.
• Piano di migrazione graduale per spostare i database e le applicazioni associate con un'interruzione minima dell'attività.

Per alcuni esempi di output di valutazione, consulta Vimigsor - Strumento di valutazione della migrazione nel cloud.

Tieni presente che migVisor aumenta temporaneamente l'utilizzo del server di database. Generalmente, questo carico aggiuntivo è inferiore al 3% e può essere eseguito durante la stagione non di picco nell'orario lavorativo locale del TAM.

L'output di valutazione di migVisor ti aiuta a creare un inventario completo del tuo RDS di Compute Engine. Il report include proprietà generiche (versione e versione del motore del database, CPU e dimensioni della memoria), nonché dettagli sulla topologia del database, sui criteri di backup, sulle impostazioni dei parametri e sulle personalizzazioni speciali in uso.

Se preferisci utilizzare strumenti open source, puoi utilizzare gli script del raccoglitore di dati con (o al posto di) gli strumenti menzionati. Questi script possono aiutarti a raccogliere informazioni informazioni (su carichi di lavoro, caratteristiche, oggetti di database e codice del database) e per creare l'inventario del tuo database. Inoltre, di solito gli script forniscono un database dettagliato una valutazione della migrazione, inclusa una stima delle attività di migrazione.

Consigliamo lo strumento open source DMA, che è stato progettato dagli ingegneri di Google. Offre un database completo e accurato valutazione delle funzionalità in uso, della logica del database e degli oggetti di database (inclusi schemi, tabelle, viste, funzioni, trigger e di sicurezza).

Per utilizzare DMA, scarica gli script di raccolta per il motore del database dal Repository Git, e segui le istruzioni. Invia i file di output a Google Cloud per e analisi. Google Cloud crea e fornisce un report di valutazione del database e indica i passaggi successivi nel percorso di migrazione.

Identifica e documenta l'ambito della migrazione e il tempo di inattività accettabile

In questa fase, devi documentare le informazioni essenziali che influenzano la tua la strategia e gli strumenti di migrazione. A questo punto, puoi rispondere alle seguenti domande domande:

• I database hanno dimensioni superiori a 5 TB?
• Nel database sono presenti tabelle di grandi dimensioni? Sono più grandi di 16 TB?
• Dove si trovano i database (regioni e zone) e qual è il loro vicinanza alle applicazioni?
• Con quale frequenza cambiano i dati?
• Qual è il tuo modello di coerenza dei dati?
• Quali sono le opzioni per i database di destinazione?
• Quanto sono compatibili i database di origine e di destinazione?
• I dati devono trovarsi in alcune località fisiche?
• Esistono dati che possono essere compressi e archiviati o dati che non richiedono affatto la migrazione?

Per definire l'ambito della migrazione, decidi quali dati conservare e di quali eseguire la migrazione. La migrazione di tutti i database potrebbe richiedere molto tempo e impegno. Alcuni dati potrebbero rimarranno nei backup del database di origine. Ad esempio, le vecchie tabelle di logging o i dati di archiviazione potrebbero non essere necessari. In alternativa, puoi decidere di spostare i dati dopo la procedura di migrazione, a seconda della tua strategia e dei tuoi strumenti.

Stabilisci delle linee di base per la migrazione dei dati che ti aiutino a confrontare e valutare i risultati e gli impatti. Queste linee di base sono punti di riferimento che rappresentano lo stato dei dati prima e dopo la migrazione e ti aiutano a prendere decisioni. È importante eseguire misurazioni nell'ambiente di origine che possano aiutarti a valutare l'esito della migrazione dei dati. Tali misurazioni includono seguenti:

• Le dimensioni e la struttura dei dati.
• La completezza e la coerenza dei dati.
• La durata e il rendimento delle transazioni e dei processi aziendali più importanti.

Determina il tempo di riposo che puoi permetterti. Quale impatto ha sull'attività o un tempo di riposo? Si sono verificati periodi di scarsa attività del database durante i quali si verificano di utenti interessati dal tempo di inattività? In tal caso, quanto sono lunghi e quando si verificano? Valuta la possibilità di avere un tempo di inattività parziale in scrittura e in sola lettura vengono comunque gestite.

Valutare il processo di implementazione e amministrazione

Dopo aver creato gli inventari, valuta il funzionamento e il deployment per il database al fine di determinare in che modo è necessario adattarli per facilitare la migrazione. Queste procedure sono fondamentali per preparare e gestire il tuo ambiente di produzione.

Valuta come completare le seguenti attività:

• Definire e applicare i criteri di sicurezza per le istanze: ad esempio, potresti dover sostituire i gruppi di sicurezza Amazon. Puoi utilizzare la modalità Ruoli IAM di Google, regole firewall VPC e Controlli di servizio VPC controllare l'accesso alle istanze Cloud SQL e limitare all'interno di un VPC.

• Applica patch e configura le istanze: i tuoi strumenti di deployment esistenti potrebbe richiedere un aggiornamento. Ad esempio, potresti utilizzare impostazioni di configurazione personalizzate nei gruppi di parametri o nei gruppi di opzioni Amazon. Potrebbe essere necessario adattare gli strumenti di provisioning per utilizzare Google Cloud Storage o Secret Manager per leggere questo di configurazione automatica.

• Gestire l'infrastruttura di monitoraggio e avviso: categorie di metriche per le istanze del database di origine Amazon offrono l'osservabilità durante di migrazione. Le categorie di metriche possono includere Amazon CloudWatch, Informazioni sulle prestazioni, Monitoraggio avanzato ed elenchi di processi del sistema operativo.

Completa la valutazione

Dopo aver creato gli inventari da Amazon RDS o Amazon Aurora di valutazione, completa le altre attività della fase di valutazione descritti in Esegui la migrazione a Google Cloud: valuta e individua i tuoi carichi di lavoro.

Pianifica e crea le basi

Nella fase di pianificazione e creazione, esegui il provisioning e la configurazione dell'infrastruttura segui questi passaggi:

• Supporta i tuoi carichi di lavoro nel tuo ambiente Google Cloud.
• Connetti l'ambiente di origine e l'ambiente Google Cloud per completare la migrazione.

La fase di pianificazione e creazione è composta dalle seguenti attività:

1. Crea una gerarchia di risorse.
2. Configura Identity and Access Management (IAM) di Google Cloud.
3. Configura la fatturazione.
4. Configura la connettività di rete.
5. Rafforza la tua sicurezza.
6. Configura il logging, il monitoraggio e gli avvisi.

Per ulteriori informazioni su ciascuna di queste attività, consulta la pagina Eseguire la migrazione a Google Cloud: pianifica e crea le basi.

Se prevedi di utilizzare Database Migration Service per la migrazione, consulta Metodi di networking per MySQL per comprendere le configurazioni di rete disponibili per gli scenari di migrazione.

Monitoraggio e avvisi

Utilizza Cloud Monitoring di Google, che include dashboard predefinite per diversi prodotti Google Cloud, tra cui una dashboard di monitoraggio di Cloud SQL. In alternativa, puoi considerare la possibilità di utilizzare soluzioni di monitoraggio di terze parti integrate con Google Cloud, come Datadog e Splunk. Per ulteriori informazioni, consulta Informazioni sull'osservabilità del database.

Esegui la migrazione delle istanze Amazon RDS e Amazon Aurora per MySQL a Cloud SQL per MySQL

Per eseguire la migrazione delle istanze, segui questi passaggi:

1. Scegli la strategia di migrazione: replica continua o manutenzione pianificata.

2. Scegliere gli strumenti di migrazione a seconda della strategia scelta i tuoi requisiti.

3. Definisci il piano e le tempistiche di migrazione per ogni database, incluse le attività di preparazione ed esecuzione.

4. Definisci le attività di preparazione da eseguire per garantire la migrazione che lo strumento funzioni correttamente.

5. Definisci le attività di esecuzione, che includono le attività di lavoro che implementano la migrazione.

6. Definisci scenari di riserva per ogni attività di esecuzione.

7. Esegui test e convalida, che possono essere eseguiti in un ambiente di staging distinto.

8. Esegui la migrazione.

9. Esegui la migrazione completa della produzione.

10. Pulire l'ambiente di origine e configurare l'istanza di destinazione.

11. Eseguire l'ottimizzazione e l'ottimizzazione.

Ogni fase è descritta nelle sezioni seguenti.

Scegli la tua strategia di migrazione

In questo passaggio, avrai informazioni sufficienti per valutare e selezionare uno dei le seguenti strategie di migrazione più adatte al tuo caso d'uso database:

• Manutenzione pianificata (detta anche migrazione una tantum): questo approccio è ideale se puoi permetterti tempi di inattività. Questa opzione ha un costo relativamente più basso e poiché i carichi di lavoro e i servizi non richiedono il refactoring. Tuttavia, se la migrazione non riesce prima del completamento, è necessario riavvia il processo, prolungando il tempo di inattività.

• Replica continua (detta anche migrazione persistente): per mission critical, questa opzione offre un rischio minore di perdita di dati con tempi di inattività quasi azzerati. Le attività sono suddivise in più blocchi, quindi se gli errori, il rollback e la ripetizione richiedono meno tempo. Tuttavia, la configurazione è più complessa e richiede più tempo e pianificazione. È inoltre necessario un impegno aggiuntivo per eseguire il refactoring delle applicazioni che si connettono alle istanze del database. Valuta una delle seguenti varianti:

  • Usare il tasto Y (scrittura e lettura) , ovvero una forma di migrazione parallela, che duplica i dati sia e le istanze di destinazione durante la migrazione.
  • Usare un microservizio di accesso ai dati, che riduce lo sforzo di refactoring richiesto l'approccio Y (scrittura e lettura).

Per ulteriori informazioni sulle strategie di migrazione dei dati, vedi Valutazione degli approcci alla migrazione dei dati.

Il seguente diagramma mostra un diagramma di flusso basato su domande di esempio che potresti avere quando decidi la strategia di migrazione per un singolo database:

Il diagramma di flusso precedente mostra i seguenti punti decisionali:

• Puoi permetterti un tempo di riposo?

  • In caso contrario, adotta la strategia di migrazione con replica continua.
  • In caso affermativo, passa al punto decisionale successivo.

• Puoi permetterti il tempo di riposo rappresentato dal periodo di transizione durante la migrazione dei dati? La finestra di migrazione completa rappresenta la quantità di tempo da impiegare un backup del database, trasferirlo in Cloud SQL, ripristinarlo e poi passare dalle tue applicazioni.

  • In caso contrario, adotta la strategia di migrazione con replica continua.
  • In caso affermativo, adotta la strategia di migrazione di manutenzione pianificata.

Le strategie possono variare per database diversi, anche se si trovano nella stessa istanza. Un mix di strategie può produrre risultati ottimali. Ad esempio, esegui la migrazione di database di piccole dimensioni e usati di rado utilizzando l'approccio di manutenzione pianificata, ma utilizza la replica continua per i database mission-critical in cui i tempi di inattività sono costosi.

Di solito, una migrazione viene considerata completata quando il passaggio l'istanza di origine iniziale e l'istanza di destinazione. Qualsiasi replica (se utilizzata) viene arrestata e tutte le operazioni di lettura e scrittura vengono eseguite sull'istanza di destinazione. Cambiare quando entrambe le istanze sono sincronizzate significa nessuna perdita di dati e minima o un tempo di inattività.

Per ulteriori informazioni sulle strategie e sui deployment di migrazione dei dati, vedi Classificazione delle migrazioni dei database.

Riduci al minimo i tempi di inattività e gli impatti relativi alla migrazione

Le configurazioni di migrazione che non prevedono tempi di inattività dell'applicazione richiedono una configurazione più complessa. Trova il giusto equilibrio tra complessità di configurazione e tempo di riposo pianificato durante l'orario di apertura con traffico ridotto.

Ogni strategia di migrazione presenta un compromesso e un certo impatto associati di migrazione. Ad esempio, le procedure di replica comportano un carico aggiuntivo sulle istanze di origine e le applicazioni potrebbero essere interessate dal ritardo nella replica. Le applicazioni (e i clienti) potrebbero dover attendere durante il tempo di riposo dell'applicazione, almeno per la durata del ritardo di replica prima di utilizzare il nuovo database. In pratica, i seguenti fattori potrebbero aumentare il tempo di riposo:

• Il completamento delle query sul database può richiedere alcuni secondi. Al momento della migrazione, le query in corso potrebbero essere interrotte.
• Il riempimento della cache potrebbe richiedere del tempo se il database è di grandi dimensioni o ha una notevole memoria di buffer.
• Le applicazioni interrotte nell'origine e riavviate in Google Cloud potrebbero presentare un piccolo ritardo fino a quando non viene stabilita la connessione all'istanza di database Google Cloud.
• I percorsi di rete alle applicazioni devono essere reindirizzati. In base a come Le voci DNS sono state configurate. L'operazione potrebbe richiedere del tempo. Quando aggiorni i record DNS, riduci il TTL prima della migrazione.

Le seguenti best practice comuni possono aiutarti a ridurre al minimo i tempi di riposo e l'impatto:

• Trova un periodo di tempo in cui il tempo di riposo avrebbe un impatto minimo sui tuoi carichi di lavoro. ad esempio al di fuori del normale orario di lavoro, durante i fine settimana e altre finestre di manutenzione pianificate.
• Identifica le parti dei carichi di lavoro che possono essere sottoposte a migrazione e al passaggio alla produzione in fasi diverse. Le applicazioni potrebbero avere componenti diversi che possono essere isolati, adattati e migrati senza impatto. Ad esempio, frontend, moduli CRM, servizi di backend e piattaforme di generazione di report. Questi moduli potrebbero avere i propri database essere pianificati per la migrazione prima o dopo il processo.
• Se puoi permetterti un po' di latenza nel database di destinazione, valuta la possibilità di implementare una migrazione graduale. Utilizza trasferimenti di dati incrementali e raggruppati e adatta parte dei tuoi carichi di lavoro per lavorare con i dati obsoleti sull'istanza di destinazione.
• Valuta la possibilità di eseguire il refactoring delle applicazioni per supportare una migrazione minima impatto. Ad esempio, adatta le tue applicazioni in modo che scrivano sia nei database di origine che in quelli di destinazione e, di conseguenza, implementa una replica a livello di applicazione.

Scegli gli strumenti di migrazione

Il fattore più importante per una migrazione di successo è la scelta del giusto di migrazione. Una volta stabilita la strategia di migrazione, esamina e scegli lo strumento di migrazione.

Sono disponibili molti strumenti, ciascuno ottimizzato per determinati casi d'uso della migrazione. I casi d'uso possono includere:

• Strategia di migrazione (manutenzione pianificata o replica continua).
• Motori del database di origine e di destinazione e versioni del motore.
• Ambienti in cui si trovano le istanze di origine e di destinazione.
• Dimensioni del database. Più grande è il database, maggiore è il tempo necessario per eseguire la migrazione del backup iniziale.
• Frequenza delle modifiche al database.
• Disponibilità per l'utilizzo dei servizi gestiti per la migrazione.

Per garantire una migrazione e un passaggio senza problemi, puoi utilizzare pattern di deployment delle applicazioni, orchestrazione dell'infrastruttura e applicazioni di migrazione personalizzate. Tuttavia, strumenti specializzati chiamati servizi di migrazione gestita possono semplificare il processo di trasferimento di dati, applicazioni o persino intere infrastrutture da un ambiente all'altro. Eseguono l'estrazione dei dati dai database di origine, trasportano i dati in modo sicuro nei database di destinazione e, facoltativamente, possono modificarli durante il transito. Con queste capacità, incapsulano la logica complessa della migrazione e offrire funzionalità di monitoraggio della migrazione.

I servizi di migrazione gestiti offrono i seguenti vantaggi:

• Riduci al minimo i tempi di inattività: i servizi utilizzano le funzionalità di replica integrate dei motori di database, se disponibili, ed eseguono la promozione della replica.

• Garantire l'integrità e la sicurezza dei dati: i dati vengono trasferiti in modo sicuro e affidabile dall'origine al database di destinazione.

• Offrire un'esperienza di migrazione coerente: diversi pattern e tecniche di migrazione possono essere raggruppati in un'interfaccia comune e coerente utilizzando i file eseguibili per la migrazione del database, che puoi gestire e monitorare.

• Offri modelli di migrazione resilienti e comprovati: database le migrazioni sono eventi rari ma critici. Per evitare errori dei principianti e risolvere problemi con le soluzioni esistenti, puoi utilizzare strumenti esperti, invece di creare una soluzione personalizzata.

• Ottimizzazione dei costi: i servizi di migrazione gestiti possono avere un costo maggiore efficace rispetto al provisioning di server e risorse aggiuntivi soluzioni di migrazione.

Le sezioni seguenti descrivono i consigli per gli strumenti di migrazione, che dipendono dalla strategia di migrazione scelta.

Strumenti per migrazioni di manutenzione pianificate

Il seguente diagramma mostra un diagramma di flusso con le domande che possono aiutarti a scegliere lo strumento di migrazione per un singolo database, quando esegui una migrazione di manutenzione pianificata strategia:

Il diagramma di flusso precedente mostra i seguenti punti decisionali:

• Preferisci i servizi di migrazione gestiti?
  • In caso affermativo, ti consigliamo di utilizzare Database Migration Service.
  • In caso contrario, ti consigliamo di eseguire la migrazione utilizzando i backup integrati del motore del database.

L'utilizzo di un servizio di migrazione gestito offre alcuni vantaggi, descritti nella sezione Scegliere gli strumenti di migrazione di questo documento.

Le seguenti sottosezioni descrivono gli strumenti che possono essere utilizzati per le migrazioni una tantum, nonché le relative limitazioni e best practice.

Database Migration Service per la migrazione con manutenzione pianificata

Database Migration Service gestisce sia la sincronizzazione iniziale sia la replica CDC (Change Data Capture) continua e fornisce lo stato dell'operazione di migrazione.

Utilizzando Database Migration Service, puoi creare job di migrazione che puoi gestire e verificare. Ti consigliamo di utilizzare Database Migration Service, perché supporta le migrazioni a Cloud SQL per MySQL tramite job di migrazione una tantum. Per i database di grandi dimensioni, puoi utilizzare il parallelismo del dump dei dati in Database Migration Service.

Per ulteriori informazioni sull'architettura di migrazione dei database e su Database Migration Service, consulta Esegui la migrazione di un database a Cloud SQL per MySQL utilizzando Database Migration Service e Fedeltà della migrazione per MySQL.

Per ulteriori informazioni sulle limitazioni e sui prerequisiti di Database Migration Service, consulta quanto segue:

• Limitazioni note in Database Migration Service.
• Quote e limiti in Database Migration Service.
• Configura l'origine in Database Migration Service.

Backup del motore del database integrato

Quando è accettabile un tempo di inattività significativo e i database di origine vengono è relativamente statico, puoi usare i sistemi di dump e caricamento integrati del motore del database (a volte chiamate anche funzionalità di backup e ripristino).

È richiesto un certo impegno per l'impostazione e la sincronizzazione, soprattutto per un di database, ma i backup del motore del database sono solitamente immediatamente disponibili facile da usare.

I backup del motore del database hanno le seguenti limitazioni generali:

• I backup possono essere soggetti a errori, in particolare se eseguiti manualmente.
• I dati non sono protetti se i backup non sono gestiti correttamente.
• I backup non dispongono di funzionalità di monitoraggio adeguate.
• È necessario un impegno per eseguire la scalabilità se si esegue la migrazione di molti database utilizzando questo strumento.

Se scegli questo approccio, considera le seguenti limitazioni e pratiche:

• Se il tuo database è relativamente piccolo (meno di 10 GB), ti consigliamo di utilizzare mysqldump. Non esiste un limite fisso, ma le dimensioni ideali del database per mysqldump sono in genere inferiori a 10 GB.

• Se importi database di dimensioni superiori a 10 GB, potresti aver bisogno di altri per ridurre al minimo il tempo di inattività del database. Ecco alcune di queste strategie:

  • Esporta lo schema e i dati in sottosezioni, senza chiavi secondarie.
  • Sfrutta i timestamp. Se una delle tue tabelle utilizza colonne con timestamp, puoi utilizzare una funzionalità del comando mysqldump che ti consente di specificare una clausola WHERE per filtrare in base a una colonna con timestamp.
  • Valuta altri approcci, ad esempio l'utilizzo degli strumenti mydumper e myloader.

I dump e i backup del database di solito non includono account utente MySQL. Quando mentre stai preparando la migrazione, esamina tutti gli account utente nell'istanza di origine. Per Ad esempio, puoi eseguire il comando SHOW GRANTS per ogni utente per esaminare l'insieme di privilegi attuale e vedere se ce ne sono alcuni con restrizioni in Cloud SQL. Analogamente, lo strumento pt-show-grants di Percona può elencare i privilegi concessi.

Le restrizioni sui privilegi utente in Cloud SQL possono influire sulle migrazioni durante la migrazione di oggetti di database con un attributo DEFINER. Ad esempio, un stored procedure potrebbe avere un definitore con super privilegi per eseguire comandi SQL come modificare una variabile globale non consentita in Cloud SQL. Per casi come questa, potresti dover riscrivere il codice della stored procedure o eseguire la migrazione come le stored procedure come passaggio di migrazione separato. Per ulteriori informazioni, consulta le best practice per l'importazione e l'esportazione dei dati.

Per ulteriori informazioni su limitazioni e best practice, consulta quanto segue:

• Informazioni sugli utenti di Cloud SQL per MySQL.
• Best practice per l'importazione e l'esportazione di dati con Cloud SQL per MySQL.
• Problemi noti di Cloud SQL per MySQL.

Altri approcci per la migrazione con manutenzione pianificata

Nell'ambito dell'utilizzo di un'importazione gestita per configurare la replica da un database MySQL esterno, viene eseguito un caricamento iniziale dei dati dal database esterno nell'istanza Cloud SQL. Questo approccio utilizza un servizio che estrae i dati dal server esterno, in questo caso l'istanza RDS, e li importa direttamente nell'istanza Cloud SQL.

Per i database di grandi dimensioni (diversi TB), un modo più rapido è utilizzare un caricamento iniziale di importazione personalizzato che utilizza gli strumenti mydumper e myloader.

Puoi valutare la possibilità di esportare le tabelle dal database MySQL in file CSV, che può quindi essere importato in Cloud SQL per MySQL. Per esportare i dati dalla tua istanza RDS, puoi utilizzare AWS Database Migration Service (AWS DMS) e un bucket S3 come destinazione.

Per informazioni e passaggi dettagliati, consulta Utilizzare un'importazione gestita per configurare la replica da database esterni.

Strumenti per la migrazione della replica continua

Il seguente diagramma mostra un diagramma di flusso con le domande che possono aiutarti a scegliere lo strumento di migrazione per un singolo database, quando utilizzi una replica continua strategia di migrazione:

Il diagramma di flusso precedente mostra i seguenti punti decisionali:

• Preferisci utilizzare i servizi di migrazione gestiti?

  • Se sì, potete permettervi qualche secondo di tempo di inattività in scrittura a seconda del numero di tabelle nel tuo database?

    • In caso affermativo, utilizza Database Migration Service.
    • In caso contrario, esplora le altre opzioni di migrazione.

  • Se la risposta è no, devi valutare se la replica integrata nel motore del database è supportato:

    • In caso affermativo, ti consigliamo di utilizzare la replica integrata.
    • In caso contrario, ti consigliamo di valutare altre opzioni di migrazione.

Le sezioni seguenti descrivono gli strumenti che possono essere utilizzati per le migrazioni continue, nonché le relative limitazioni e best practice.

Database Migration Service per la migrazione con replica continua

Database Migration Service fornisce un supporto senza interruzioni per migrazioni continue attraverso e l'uso di tipi di job di migrazione continui. È possibile eseguire solo job di migrazione continui promosso, che segnala l'arresto della replica.

Se scegli questo strumento, considera le seguenti limitazioni e pratiche:

• Evita transazioni di lunga durata durante la migrazione. In questi casi, consigliamo se non stai eseguendo la migrazione da AWS Aurora.
• Per un elenco completo delle limitazioni, vedi Limitazioni note.

Replica integrata del motore del database

La replica integrata del motore del database è un'opzione alternativa a Database Migration Service per una migrazione continua.

La replica del database rappresenta il processo di copia e distribuzione dei dati da un database chiamato database principale ad altri database chiamati repliche. È ha lo scopo di aumentare l'accessibilità dei dati e migliorare la tolleranza di errore. l'affidabilità di un sistema di database. Sebbene la migrazione del database non sia l'attività scopo della replica del database, può essere utilizzato raggiungere questo obiettivo. La replica del database è in genere un processo continuo che avviene in tempo reale quando i dati vengono inseriti, aggiornati o eliminati nel database principale. Può essere eseguita come operazione una tantum o sequenza di operazioni operazioni aziendali.

La maggior parte dei motori di database moderni implementa modi diversi per ottenere il database la replica dei dati. Un tipo di replica può essere ottenuto copiando e inviando log write-forward dell'istanza principale nelle sue repliche. Questo approccio è chiamato replica fisica o binaria. Altri tipi di replica funzionano distribuendo le istruzioni SQL non elaborate che un database principale riceve, anziché replicare le modifiche a livello di file system.

Cloud SQL supporta la replica per MySQL. Tuttavia, ci sono alcune prerequisiti e limitazioni.

Prerequisiti:

• Assicurati di utilizzare MySQL 5.5, 5.6, 5.7 o 8.0 sull'istanza Amazon RDS o Amazon Aurora.
• Assicurati che i log binari siano abilitati.
• Per velocizzare la fase di dump completo iniziale, scegli un livello di macchina sufficientemente grande dal punto di vista delle dimensioni della CPU e della memoria.
• Se devi accelerare la fase CDC, puoi provare configurare la replica parallela e attivare flushing ad alte prestazioni.
• Se la replica Cloud SQL è attivata con indirizzi IP interni perché l'indirizzo IP in uscita non è statico, configura il firewall del server Amazon RDS o Amazon Aurora in modo da consentire l'intervallo IP interno allocato per l'accesso ai servizi privati della rete VPC utilizzata dalla replica Cloud SQL come rete privata. Per ulteriori informazioni, consulta Informazioni sulla replica da un server esterno e Configurare l'accesso privato ai servizi.

Limitazioni:

• Se nel database sono presenti singole tabelle di grandi dimensioni e molti indici secondari, il dump completo iniziale potrebbe richiedere più tempo.
• Se il server esterno contiene clausole DEFINER (visualizzazioni, eventi, o stored procedure), a seconda dell'ordine in cui vengono delle istruzioni, la replica potrebbe non riuscire. Scopri di più sull'DEFINER utilizzo e sulle potenziali soluzioni alternative in Cloud SQL.
• InnoDB è l'unico motore del database supportato in Cloud SQL. La migrazione di MyISAM potrebbe causare incoerenza dei dati e richiedere la convalida dei dati. Consulta Convertire le tabelle da MyISAM a InnoDB.

Altri approcci per la migrazione con replica continua

Altri approcci di migrazione con replica continua includono:

• Esegui il refactoring delle applicazioni per eseguire operazioni di Y (scrittura e lettura) o utilizza un microservizio di accesso ai dati.

  • La replica continua viene eseguita dalle tue applicazioni.
  • L’impegno per la migrazione si concentra sul refactoring o sullo sviluppo di che si connettono alle tue istanze di database.
  • Le applicazioni di lettura vengono poi ristrutturate e implementate gradualmente per utilizzare l'istanza di destinazione.

• Replica le modifiche quasi in tempo reale dell'istanza MySQL utilizzando Datastream.

  • Datastream è un servizio CDC (Change Data Capture) e di replica serverless che può essere utilizzato con Amazon RDS o Amazon Aurora per replicare e sincronizzare i dati.
  • Utilizza Datastream per replicare le modifiche dall'istanza MySQL a BigQuery o Cloud Storage e quindi userai Dataflow o Dataproc per trasferire i dati nella tua istanza Cloud SQL.

Per ulteriori informazioni sulla replica con Datastream, consulta seguenti:

• Configura un database Amazon RDS per MySQL in Datastream
• Configura un database Amazon Aurora MySQL in Datastream
• Trasmetti modifiche ai dati in tempo reale con Datastream

Strumenti di terze parti per la migrazione della replica continua

In alcuni casi, potrebbe essere meglio utilizzare uno strumento di terze parti per la maggior parte dei e motori di ricerca. Ad esempio, se preferisci utilizzare un servizio di migrazione gestito e devi assicurarti che il database di destinazione sia sempre sincronizzato in tempo quasi reale con quello di origine oppure se hai bisogno di trasformazioni più complesse come pulizia, ristrutturazione e adattamento dei dati durante il processo di migrazione.

Se decidi di utilizzare uno strumento di terze parti, scegli uno dei seguenti consigli, che puoi utilizzare per la maggior parte dei motori di database.

Striim è una piattaforma in-memory end-to-end per raccogliere, filtrare, trasformare, arricchire, aggregare, analizzare e pubblicare dati in tempo reale:

• Vantaggi:

  • Gestisce grandi volumi di dati e migrazioni complesse.
  • Change Data Capture integrato per SQL Server.
  • Modelli di connessione preconfigurati e pipeline senza codice.
  • In grado di gestire database di grandi dimensioni mission-critical che operano con un elevato carico transazionale.
  • Consegna "exactly-once".

• Svantaggi:

  • Non open source.
  • Può diventare costoso, soprattutto per le migrazioni lunghe.
  • Alcune limitazioni delle operazioni DDL (Data Definition Language) durante la propagazione. Per ulteriori informazioni, consulta Operazioni DDL supportate e Note e limitazioni sull'evoluzione dello schema.

Per ulteriori informazioni su Striim, vedi Esecuzione di Striim in Google Cloud.

Debezium è una piattaforma distribuita open source per il CDC e può trasmettere in streaming le modifiche ai dati agli abbonati esterni:

• Vantaggi:

  • Open source.
  • Un solido supporto dalla community.
  • Conveniente.
  • Controllo granulare su righe, tabelle o database.
  • Specializzata per l'acquisizione delle modifiche in tempo reale dai log delle transazioni del database.

• Svantaggi:

  • Richiede esperienza specifica con Kafka e ZooKeeper.
  • La consegna "at-least-once" delle modifiche dei dati, che ti consente richiedono la gestione dei duplicati.
  • Configurazione del monitoraggio manuale con Grafana e Prometheus.
  • La replica batch incrementale non è supportata.

Per ulteriori informazioni sulle migrazioni di Debezium, consulta Near Real Time Data Replication using Debezium.

Fivetran è una piattaforma di spostamento automatizzato dei dati per spostare i dati da e tra i dati nel cloud piattaforme di terze parti.

• Vantaggi:

  • Modelli di connessione preconfigurati e pipeline no-code.
  • Propaga qualsiasi modifica allo schema dall'origine al database di destinazione.
  • La distribuzione "exactly-once" dei dati cambia, il che significa che richiedono la gestione dei duplicati.

• Svantaggi:

  • Non open source.
  • Il supporto per la trasformazione di dati complessi è limitato.

Definisci il piano e le tempistiche della migrazione

Per una migrazione del database e un passaggio alla produzione riusciti, ti consigliamo di preparare un piano di migrazione completo e ben definito. Per ridurre l'impatto sulla tua attività, ti consigliamo di creare un elenco di tutti gli elementi di lavoro necessari.

La definizione dell'ambito della migrazione indica le attività di lavoro che devi svolgere prima, durante e dopo il processo di migrazione del database. Ad esempio, se decidi di non per eseguire la migrazione di determinate tabelle da un database, potresti aver bisogno di attività di post-migrazione per implementare questo filtro. Ti assicuri inoltre che la migrazione dei database non influisce sull'accordo sul livello del servizio (SLA) e la continuità aziendale esistenti e il piano d'azione.

Ti consigliamo di includere nella documentazione sulla pianificazione della migrazione quanto segue documenti:

• Documento di design tecnico (TDD)
• Matrice RACI
• Timeline (ad esempio un piano T-Minus)

Le migrazioni dei database sono un processo iterativo e le prime migrazioni più lentamente di quelli successivi. Di solito, le migrazioni ben pianificate vengono eseguite senza problemi, ma possono comunque sorgere problemi non pianificati. Ti consigliamo di eseguire sempre un rollback e il piano d'azione. Come best practice, segui le indicazioni Eseguire la migrazione a Google Cloud: best practice per la convalida di un piano di migrazione.

TDD

Il TDD documenta tutte le decisioni tecniche da prendere per il progetto. Includi nel TDD:

• Requisiti aziendali e criticità
• RTO (Recovery Time Objective)
• Recovery Point Objective (RPO)
• Dettagli sulla migrazione del database
• Stime dell'attività di migrazione
• Consigli per la convalida della migrazione

Matrice RACI

Alcuni progetti di migrazione richiedono una matrice RACI, che è un progetto comune di gestione che definisce quali individui o gruppi sono responsabili le attività e i risultati finali del progetto di migrazione.

Spostamenti

Prepara una sequenza temporale per ogni database di cui eseguire la migrazione. Includi tutti attività lavorative da svolgere e le date di inizio e di fine stimate date.

Per ogni ambiente di migrazione, ti consigliamo di creare un piano per il giorno precedente la migrazione. Un piano T-minus è strutturato come una pianificazione del conto alla rovescia ed elenca tutte le attività necessarie per completare il progetto di migrazione, insieme ai gruppi responsabili e alla durata stimata.

La cronologia deve tenere conto non solo delle attività di preparazione alla pre-migrazione l'esecuzione delle attività, ma anche le attività di convalida, controllo o test che vengono eseguite dopo avviene il trasferimento dei dati.

La durata delle attività di migrazione in genere dipende dalle dimensioni del database, ma esistono anche altri aspetti da considerare, come la complessità della logica di business, l'utilizzo dell'applicazione e la disponibilità del team.

Un piano T-Minus potrebbe avere il seguente aspetto:

Data	Fase	Categoria	Tasks	Ruolo	T-meno	Stato
1/11/2023	Pre-migrazione	Test	Creare un report di valutazione	Team di discovery	-21	Completa
7/11/2023	Pre-migrazione	Preparazione del target	Progettare l'ambiente di destinazione come descritto nel documento di progettazione	Team della migrazione	-14	Completa
15/11/2023	Pre-migrazione	Governance aziendale	Data migrazione e approvazione T-Minus	Leadership	-6	Completa
18/11/2023	Migrazione	Configura DMS	Creazione di profili di connessione	Cloud migration engineer	-3	Completa
19/11/2023	Migrazione	Configura DMS	Crea e avvia i job di migrazione	Cloud migration engineer	-2	Non avviato
19/11/2023	Migrazione	Monitora DMS	Monitora i job DMS e le modifiche DDL nell'istanza di origine	Ingegnere della migrazione cloud	-2	Non avviato
21/11/2023	Migrazione	Cutover DMS	Promuovere la replica DMS	Ingegnere della migrazione cloud	0	Non avviato
21/11/2023	Migrazione	Convalida della migrazione	Convalida della migrazione del database	Team della migrazione	0	Non avviato
21/11/2023	Migrazione	Test applicazione	Esegui test delle funzionalità e delle prestazioni	Team di migrazione	0	Non avviato
22/11/2023	Migrazione	Governance aziendale	Convalida della migrazione GO o NO GO	Team della migrazione	1	Non avviato
23/11/2023	Dopo la migrazione	Convalida il monitoraggio	Configura il monitoraggio	Team Infrastruttura	2	Non avviato
25/11/2023	Dopo la migrazione	Sicurezza	Rimuovi account utente DMS	Team di sicurezza	4	Non avviato

Più migrazioni del database

Se devi eseguire la migrazione di più database, il piano di migrazione deve contenere attività per tutte le migrazioni.

Ti consigliamo di iniziare la procedura eseguendo la migrazione di un database più piccolo, possibilmente non di importanza fondamentale. Questo approccio può aiutarti a creare conoscenza e fiducia nel processo e negli strumenti di migrazione. Puoi anche rilevare eventuali difetti nel processo nelle prime fasi del programma di migrazione complessiva.

Se devi eseguire la migrazione di più database, le cronologie possono essere parallelizzate. Ad esempio, per velocizzare il processo di migrazione, potresti scegliere di migrare un gruppo di database piccoli, statici o meno mission-critical contemporaneamente, come mostrato nel diagramma seguente.

Nell'esempio mostrato nel diagramma, i database 1-4 sono un gruppo di piccoli database di cui viene eseguita la migrazione contemporaneamente.

Definisci le attività di preparazione

Le attività di preparazione sono tutte le attività che devi completare soddisfare i prerequisiti per la migrazione. Senza le attività di preparazione, la migrazione non può essere eseguita o i risultati della migrazione nel database migrato essere inutilizzabili.

Le attività di preparazione possono essere classificate come segue:

• Preparativi e prerequisiti per le istanze Amazon RDS o Amazon Aurora
• Preparazione e prerequisiti del database di origine
• Configurazione di Cloud SQL
• Configurazione specifica per la migrazione

Preparazione e prerequisiti delle istanze Amazon RDS o Amazon Aurora

Prendi in considerazione le seguenti attività di configurazione e prerequisiti comuni:

• A seconda del percorso di migrazione, potrebbe essere necessario consentire le connessioni remote sulle istanze RDS. Se l'istanza RDS è configurata come privata nel VPC, deve esistere una connettività privata RFC 1918 tra Amazon e Google Cloud.

• Potresti dover configurare un nuovo gruppo di sicurezza per consentire l'accesso e le connessioni a quest'ultimo sulle porte richieste.

  • Per impostazione predefinita, in AWS l'accesso alla rete è attivato per le istanze di database.
  • In un gruppo di sicurezza puoi specificare le regole che consentono l'accesso da un intervallo di indirizzi IP, una porta o un gruppo di sicurezza. Le stesse regole si applicano a tutte le istanze di database associate a quel gruppo di sicurezza.

• Assicurati di avere spazio libero su disco sufficiente per mettere in buffer i log WAL per la durata dell'operazione di caricamento completo nell'istanza Amazon RDS.

• Per ottenere risultati ottimali, valuta la possibilità di eseguire la migrazione da una replica di lettura, a meno che tu non stia eseguendo la migrazione da Amazon Aurora. Inoltre, ti consigliamo di iniziare il processo di migrazione in un periodo di attività ridotta del database.

• MySQL limita il nome host a 60 caratteri. Database Amazon RDS i nomi host sono in genere più lunghi di 60 caratteri. Se questo è il caso del database di cui stai eseguendo la migrazione, configura un reindirizzamento DNS per creare un record CNAME che associ il tuo nome di dominio al nome di dominio della tua istanza del database RDS.

• Se utilizzi la replica integrata, devi configurare il tuo Amazon Istanza RDS o Amazon Aurora per la replica. Replica integrata oppure che lo utilizzano, devono impostare il logging binario per MySQL su ROW.

• Se utilizzi strumenti di terze parti, impostazioni e configurazioni iniziali sono generalmente richiesti prima di utilizzare lo strumento. Consulta la documentazione dello strumento di terze parti.

Per saperne di più sulla preparazione e sui prerequisiti dell'istanza, consulta Configura il server esterno per la replica per MySQL.

Preparazione e prerequisiti del database di origine

• Se scegli di utilizzare Database Migration Service, devi configurare l'origine prima di connetterti. Esamina i job di migrazione prima di implementarli. Per ulteriori informazioni, vedi Configura l'origine per MySQL.
• A seconda del motore del database, potresti alcune funzionalità. Ad esempio, Cloud SQL per MySQL supporta solo il motore del database InnoDB. Devi modificare le tabelle MyISAM in InnoDB.
• Alcuni strumenti di migrazione di terze parti richiedono che tutte le colonne LOB siano null. Tutte le colonne LOB che corrispondono a NOT NULL devono avere questo vincolo rimosso durante la migrazione.

• Esegui misurazioni di riferimento nell'ambiente di origine in uso in produzione. Considera quanto segue:

  • Misura le dimensioni dei dati e del carico di lavoro delle prestazioni. Tempo necessario per le query o le transazioni importanti media? Quanto dura durante le ore di punta?
  • Documentare le misurazioni di riferimento per un confronto successivo, per poter decidere meglio se la precisione della migrazione del database è soddisfacente. Decidi se puoi cambiare i carichi di lavoro di produzione e ritirare l'ambiente di origine oppure se ne hai ancora bisogno per il fallback.

Configurazione di Cloud SQL

Scegli attentamente la dimensione e le specifiche del tuo Cloud SQL per MySQL di destinazione in modo che corrisponda all'origine per esigenze di prestazioni simili. Presta particolare attenzione alle dimensioni e alla velocità effettiva del disco, alle IOPS e al numero di vCPU. Sbagliato il dimensionamento ottimale può comportare lunghi tempi di migrazione, problemi di prestazioni e problemi di prestazioni delle applicazioni.

Prima di creare le tue istanze Cloud SQL, devi confermare le seguenti proprietà e requisiti, perché non possono essere modificati in un secondo momento senza essere ricollocate.

• Scegli il progetto e la regione del target con attenzione alle istanze Cloud SQL. Le istanze Cloud SQL non possono essere viene eseguita la migrazione tra progetti e regioni Google Cloud senza trasferimento di dati.
• Esegui la migrazione a una versione principale corrispondente su Cloud SQL. Ad esempio, se la tua origine utilizza MySQL 8.0.34 su Amazon RDS o Amazon Aurora, devi eseguire la migrazione alla versione 8.0.34 di Cloud SQL per MySQL.
• Replica le informazioni utente separatamente, se utilizzi i backup del motore del database integrato o Database Migration Service. Cloud SQL gestisce gli utenti utilizzando o IAM. Per maggiori dettagli, consulta le limitazioni nella sezione Backup del motore del database integrato.
• Esamina i flag di configurazione del motore del database e confronta i valori delle rispettive istanze di origine e di destinazione. Assicurati di comprenderne l'impatto e se devono essere uguali o meno. Ad esempio, consigliamo eseguendo il comando SHOW VARIABLES sul tuo prima della migrazione ed eseguirlo di nuovo un database Cloud SQL. Aggiorna le impostazioni dei flag in base alle esigenze nella per replicare le impostazioni di origine. Tieni presente che non tutti i flag MySQL sono consentiti in un'istanza Cloud SQL.

Per saperne di più sulla configurazione di Cloud SQL, consulta quanto segue:

• Best practice generali per MySQL
• Opzioni di configurazione dell'istanza per MySQL
• Considerazioni importanti prima della migrazione di Aurora a Cloud SQL per MySQL

Configurazione specifica per la migrazione

Se importi i file di dump SQL in Cloud SQL, potrebbe essere necessario creare un nel bucket Cloud Storage. Il bucket archivia il dump del database.

Se utilizzi la replica, devi assicurarti che la replica Cloud SQL l'accesso al database principale. Questo accesso può essere ottenuto attraverso la documentazione opzioni di connettività.

A seconda dello scenario e della criticità, potresti dover implementare un scenario di riserva, che in genere include l'inversione della direzione della replica. In questo caso, potrebbe essere necessario un ulteriore meccanismo di replica Cloud SQL torna all'istanza Amazon di origine.

Per la maggior parte degli strumenti di terze parti, devi eseguire il provisioning di risorse specifiche per la migrazione. Ad esempio, per Striim, per iniziare devi utilizzare Google Cloud Marketplace. Quindi, per configurare l'ambiente di migrazione in Striim, puoi utilizzare lo strumento Designer per creare e modificare applicazioni oppure puoi selezionarne una preesistente modello. Le applicazioni possono essere codificate anche utilizzando il linguaggio di programmazione Tungsten Query Language (TQL). Utilizzando una dashboard di convalida dei dati, puoi ottenere una rappresentazione visiva dei dati gestiti dalla tua applicazione Striim.

Puoi ritirare le risorse che collegano il tuo ambiente Amazon e Google Cloud dopo che la migrazione è stata completata e convalidata.

Per ulteriori informazioni, consulta le seguenti risorse:

• Gestire i job di migrazione in Database Migration Service
• Best practice per l'importazione e l'esportazione dei dati
• Connettività per MySQL

Definisci le attività di esecuzione

Le attività di esecuzione implementano il lavoro di migrazione stesso. Le attività dipendono dallo strumento di migrazione scelto, come descritto nelle sottosezioni seguenti.

Backup del motore del database integrato

Per eseguire una migrazione una tantum, utilizza l'utilità mysqldump per creare un backup che copia i dati da Amazon RDS al computer client locale. Per istruzioni, consulta Importare un file di dump SQL in Cloud SQL per MySQL.

Puoi Controllare lo stato delle operazioni di importazione ed esportazione per la tua istanza Cloud SQL.

Job di migrazione di Database Migration Service

Definisci e configura i job di migrazione in Database Migration Service per eseguire la migrazione dei dati da un'istanza di origine al database di destinazione. I job di migrazione si connettono dell'istanza del database di origine tramite profili di connessione definiti dall'utente.

Testa tutti i prerequisiti per assicurarti che il job possa essere eseguito correttamente. Scegli un momento in cui i tuoi carichi di lavoro possono permettersi un breve tempo di riposo per la migrazione e il passaggio alla produzione.

In Database Migration Service, la migrazione inizia con il caricamento e il backup completo iniziale, seguito da un flusso continuo di modifiche dall'istanza di database di origine a quella di destinazione.

Database Migration Service richiede alcuni secondi per acquisire il blocco di lettura di tutte le tabelle dell'istanza Amazon RDS o Amazon Aurora di origine di cui ha bisogno per eseguire il dump iniziale completo in modo coerente. Per ottenere il blocco di lettura, potrebbe essere necessaria una con un tempo di inattività compreso tra 1 e 49 secondi. I tempi di riposo dipendono dal numero di tabelle nel database, con 1 secondo corrispondente a 100 tabelle e 9 secondi corrispondenti a 10.000 tabelle.

Il processo di migrazione con Database Migration Service termina con l'operazione di promozione. La promozione di un'istanza di database disconnette il database di destinazione dal flusso delle modifiche provenienti dal database di origine, poi la versione autonoma di destinazione viene promosso a istanza principale. Questo approccio è talvolta chiamato anche passaggio alla produzione.

Per ulteriori informazioni sui job di migrazione in Database Migration Service, consulta quanto segue:

• Esaminare un job di migrazione
• Gestire i job di migrazione
• Promuovere una migrazione

Per un processo dettagliato di configurazione della migrazione, vedi Esegui la migrazione di un database a Cloud SQL per MySQL utilizzando Database Migration Service. In Database Migration Service, la migrazione viene eseguita avviando ed eseguendo una migrazione lavoro.

Replica integrata del motore del database

Puoi utilizzare la replica integrata da Amazon RDS a un server Cloud SQL per MySQL.

Per MySQL, devi prima iniziare con un dump iniziale che può essere archiviato in nel bucket Cloud Storage, quindi importa i dati in Cloud SQL per MySQL. Poi per avviare il processo di replica.

Monitora la replica e interrompi le scritture sull'istanza di origine in un al momento giusto. Controlla di nuovo lo stato di replica per assicurarti che tutti sono state replicate e promuovere la replica Cloud SQL per MySQL in un autonoma per completare la migrazione.

Per istruzioni dettagliate su come configurare la replica integrata da un server esterno come Amazon RDS o Amazon Aurora per MySQL, consulta Informazioni sulla replica da un server esterno e Configurare Cloud SQL e il server esterno per la replica.

Per ulteriori informazioni e indicazioni, consulta le seguenti risorse:

• Esportare il database in un bucket Cloud Storage
• Utilizza un'importazione gestita per configurare la replica da database esterni
• Avvia la replica sul server esterno

Strumenti di terze parti

Definisci eventuali attività di esecuzione per lo strumento di terze parti che hai scelto.

Questa sezione si concentra su Striim come esempio. Striim utilizza applicazioni che acquisiscono dati da varie origini, elaborare i dati e poi inviarli ad altre applicazioni o target.

Le applicazioni possono essere create graficamente utilizzando il client web e contengono origini, destinazioni e altri componenti logici organizzati in uno o più flussi.

Per configurare l'ambiente di migrazione in Striim, puoi utilizzare Flow Designer funzionalità per creare e modificare applicazioni oppure puoi scegliere tra una serie di modelli preesistenti. Le applicazioni possono essere codificate anche utilizzando il linguaggio di programmazione TQL.

Puoi ottenere una rappresentazione visiva dei dati gestiti dall'applicazione Striim utilizzando una dashboard di convalida dei dati.

Per un avvio rapido su Striim in Google Cloud, consulta Esecuzione di Striim in Google Cloud. Per scoprire di più sui concetti di base di Striim, consulta Concetti di Striim. Assicurati di leggere anche la guida alle best practice per il passaggio da un caricamento iniziale alla replica continua.

Tieni a mente le seguenti best practice per la migrazione dei dati:

• Informa i team coinvolti ogni volta che inizia ogni fase del piano finiture in cui sono finite.
• Se uno o più passaggi richiedono più tempo del previsto, confronta il tempo trascorso con il tempo massimo previsto per ogni passaggio. Problema regolare gli aggiornamenti intermediari ai team coinvolti nel caso in cui ciò si verifichi.
• Se l'intervallo di tempo è superiore al tempo massimo riservato per ogni passaggio del piano, valuta la possibilità di eseguire il rollback.
• Imposta "Via libera o no" per ogni fase della migrazione, e un piano generale.
• Valuta le azioni di rollback o gli scenari alternativi per ciascuno dei passaggi.

Definire gli scenari di fallback

Definisci attività di riserva per ogni attività di esecuzione della migrazione, per proteggerti da problemi imprevisti che potrebbero verificarsi durante il processo di migrazione. Le attività di riserva dipendono in genere dalla strategia di migrazione e dagli strumenti utilizzati.

La procedura di riserva potrebbe richiedere uno sforzo significativo. Come best practice, non eseguire il passaggio alla produzione finché i risultati del test non sono soddisfacenti. Sia la migrazione del database sia lo scenario di riserva devono essere testati correttamente per evitare un grave interruzione del servizio.

Definisci i criteri di successo e la casella temporale per tutte le attività di esecuzione della migrazione. Eseguire una La prova della migrazione consente di raccogliere informazioni sui tempi previsti per ogni dell'attività. Ad esempio, per una migrazione di manutenzione pianificata, puoi permetterti il tempo di riposo rappresentato dal periodo di transizione. Tuttavia, è importante pianificare la prossima azione nel caso in cui il job di migrazione una tantum o il ripristino del backup non vada a buon fine a metà. A seconda del tempo trascorso dal tempo di riposo pianificato, potresti dover posticipare la migrazione se l'attività di migrazione non termina nel tempo previsto.

Un piano di riserva in genere si riferisce al rollback della migrazione dopo l'esecuzione del passaggio alla produzione, se si verificano problemi nell'istanza di destinazione. Se implementi un piano di riserva, ricorda che deve essere considerato come una migrazione completa del database, inclusa la pianificazione e i test.

Se scegli di non avere un piano di riserva, assicurati di aver compreso il funzionamento possibili conseguenze. L'assenza di un piano di riserva può comportare sforzi imprevisti che possono causare interruzioni evitabili nel processo di migrazione.

Sebbene un fallback sia l'ultima risorsa e la maggior parte delle migrazioni dei database non quando lo usi, ti consigliamo di avere sempre una strategia di riserva.

Semplicità di riserva

In questa strategia di riserva, ripristini la versione originale delle applicazioni un'istanza del database di origine. Adotta questa strategia se puoi permetterti il tempo di riposo quando esegui il fallback o se non hai bisogno delle transazioni committate sul nuovo sistema di destinazione.

Se hai bisogno di tutti i dati scritti nel database di destinazione e puoi permetterti un certo tempo di riposo, puoi valutare la possibilità di interrompere le scritture nell'istanza del database di destinazione, eseguire i backup integrati e ripristinarli nell'istanza di origine, quindi ricollegare le applicazioni all'istanza del database di origine iniziale. A seconda della natura del carico di lavoro e della quantità di dati scritti su l'istanza del database di destinazione, potresti portarla nell'origine iniziale di sistema di database in un secondo momento, soprattutto se i carichi di lavoro non sono dipende da tempi specifici di creazione dei record o vincoli di ordinamento temporale.

Replica inversa

In questa strategia, le scritture che avvengono nel nuovo database di destinazione dopo il passaggio alla produzione vengono replicate nel database di origine iniziale. In questo modo, mantieni l'origine originale sincronizzata con il nuovo database di destinazione e le scritture vengono eseguite nella nuova istanza del database di destinazione. Il suo svantaggio principale è che non puoi testare lo stream di replica fino al passaggio all'istanza del database di destinazione, pertanto non consente test end-to-end e presenta un breve periodo di assenza di fallback.

Scegli questo approccio quando puoi ancora mantenere l'istanza di origine per un po' di tempo e esegui la migrazione utilizzando la migrazione con replica continua.

Esegui la replica in avanti

Questa strategia è una variante della replica inversa. Devi replicare scrive sul nuovo database di destinazione su una terza istanza di database di tua scelta. Puoi puntare le tue applicazioni a questo terzo database, che si connette un server web ed esegue query di sola lettura quando il server non è disponibile. Puoi utilizzare la modalità a qualsiasi meccanismo di replica, a seconda delle esigenze. Il vantaggio di questo approccio è che può essere testata completamente end-to-end.

Scegli questo approccio quando vuoi avere sempre un fallback o quando devi eliminare il database di origine iniziale subito dopo la produzione l'implementazione.

Scritture duplicate

Se scegli una migrazione di microservizi Y (scrittura e lettura) o accesso ai dati questa strategia di riserva è già impostata. Questa strategia è più complicata, perché devi eseguire il refactoring delle applicazioni o sviluppare strumenti che si connettono alle tue istanze di database.

Le applicazioni scrivono sia nelle istanze di database di origine iniziali che di destinazione, che consente di eseguire un passaggio di produzione graduale fino a quando non si utilizzano delle istanze del database di destinazione. Se ci sono problemi, connetti il tuo per ripristinare le applicazioni all'origine iniziale senza tempi di inattività. Puoi ignorare la fonte iniziale e il meccanismo di scrittura duplicato se ritieni che la migrazione sia stata eseguita senza problemi.

Consigliamo questo approccio quando è fondamentale non avere tempi di riposo durante la migrazione, disporre di un piano di riserva affidabile e quando hai tempo e risorse per eseguire il refactoring delle applicazioni.

Esegui test e convalida

L'obiettivo di questo passaggio è testare e convalidare quanto segue:

• Migrazione dei dati nel database riuscita.
• Integrazione con le applicazioni esistenti dopo che è stato eseguito il passaggio all'utilizzo della nuova istanza di destinazione.

Definisci i principali fattori di successo, soggettivi alla migrazione. Di seguito sono riportati alcuni esempi di fattori soggettivi:

• Di quali dati eseguire la migrazione. Per alcuni carichi di lavoro, potrebbe non essere necessario eseguire la migrazione di tutti e i dati di Google Cloud. Potresti non voler eseguire la migrazione di dati già aggregati, ridondanti, archiviati o vecchi. Puoi archiviare i dati in un bucket Cloud Storage come backup.
• Una percentuale accettabile di perdita di dati. Ciò vale in particolare per i dati utilizzata per i carichi di lavoro di analisi, in cui la perdita di parte dei dati non influisce sulle tendenze generali o sulle prestazioni dei carichi di lavoro.
• Criteri di qualità e quantità dei dati, che puoi applicare all'ambiente di origine e confrontare con l'ambiente di destinazione dopo la migrazione.
• Criteri di rendimento. Alcune transazioni aziendali potrebbero essere più lente nell'ambiente di destinazione, ma il tempo di elaborazione rientra comunque nelle aspettative definite.

Le configurazioni di archiviazione nell'ambiente di origine potrebbero non essere mappate direttamente agli obiettivi dell'ambiente Google Cloud. Ad esempio, le configurazioni dei volumi SSD per uso generico (gp2 e gp3) con prestazioni di picco di IOPS o SSD con IOPS pianificati. Per confrontare e determinare correttamente le dimensioni delle istanze di destinazione, esegui il benchmark delle istanze di origine sia nelle fasi di valutazione che di convalida.

Nella procedura di benchmarking, applichi sequenze di operazioni simili a quelle di produzione alle istanze di database. Durante questo periodo, acquisisci ed elabori le metriche per misurare e confrontare il rendimento relativo dei sistemi di origine e di destinazione.

Per configurazioni convenzionali basate su server, utilizza misurazioni pertinenti osservato durante i picchi di carico. Per modelli di capacità delle risorse flessibili come Aurora Serverless, valuta la possibilità di esaminare i dati delle metriche storiche per osservare la scalabilità e alle esigenze aziendali.

I seguenti strumenti possono essere utilizzati per test, convalida e benchmarking dei database:

• HammerDB: uno strumento di benchmarking e test di carico di database open source. Supporta complessi carichi di lavoro transazionali e analitici, su più motori di database (sia TPROC-C che TPROC-H). HammerDB ha una documentazione dettagliata e un'ampia community di utenti. Puoi condividere e confrontare i risultati in diversi motori di database e configurazioni di archiviazione. Per ulteriori informazioni, vedi Test di carico di SQL Server con HammerDB e Confronta le prestazioni di SQL Server di Amazon RDS utilizzando HammerDB.
• Strumento di benchmark DBT2: il benchmarking specializzato per MySQL. Un insieme di kit di carichi di lavoro del database imitano un'applicazione per un'azienda che possiede magazzini e prevede un mix di operazioni di lettura e scrittura. Usa questo strumento se vuoi usare un modello sull'elaborazione delle transazioni online (OLTP).
• DbUnit: uno strumento di test di unità open source utilizzato per testare le interazioni con i database relazionali in Java. La configurazione e l'utilizzo sono semplici e supporta più motori di database (MySQL, PostgreSQL, SQL Server e altri). Tuttavia, l'esecuzione del test può essere lenta a volte, a seconda delle dimensioni e della complessità del database. Consigliamo questo strumento quando la semplicità è importante.
• DbFit: un framework di test del database open source che supporta lo sviluppo di codice basato sui test e i test automatici. Utilizza una sintassi di base per la creazione di casi di test e offre test basati sui dati, controllo della versione e generazione di report sui risultati dei test. Tuttavia, il supporto per query e transazioni complesse è limitato e non ha un ampio supporto della community o una documentazione completa, rispetto ad altri strumenti. Ti consigliamo questo strumento se le tue query non sono complessi e vuoi eseguire test automatici e integrarli il processo di integrazione e distribuzione continue.

Per eseguire un test end-to-end, inclusi i test del piano di migrazione, esegui sempre un'esercitazione di prova della migrazione. Una prova esegue il database a ambito completo senza dover cambiare carichi di lavoro di produzione e offre i seguenti vantaggi:

• Ti consente di assicurarti che la migrazione di tutti gli oggetti e le configurazioni sia avvenuta correttamente.
• Ti aiuta a definire ed eseguire gli scenari di test della migrazione.
• Offre insight sul tempo necessario per l'effettiva migrazione, in modo che tu può calibrare la sequenza temporale.
• Rappresenta un'occasione per testare, convalidare e adattare il piano di migrazione. A volte non è possibile pianificare tutto in anticipo, quindi questo ti aiuta a individuare eventuali lacune.

I test sui dati possono essere eseguiti su un piccolo insieme di database di cui eseguire la migrazione l'intero set. A seconda del numero totale di database e degli strumenti utilizzati per implementarne la migrazione, puoi decidere di adottare un approccio basato sul rischio. Con questo approccio, esegui la convalida dei dati su un sottoinsieme di database sottoposti a migrazione tramite lo stesso strumento, in particolare se si tratta di un servizio di migrazione gestita.

Per i test, dovresti avere accesso sia ai database di origine sia ai database di destinazione le seguenti attività:

• Confrontare gli schemi di origine e di destinazione. Controlla se esistono tutte le tabelle e gli eseguibili. Controlla i conteggi delle righe e confronta i dati a livello di database.
• Eseguire script di convalida dei dati personalizzati.
• Verifica che i dati di cui è stata eseguita la migrazione siano visibili anche nelle applicazioni che hanno iniziato a utilizzare il database di destinazione (i dati di cui è stata eseguita la migrazione vengono letti tramite l'applicazione).
• Esegui test di integrazione tra le applicazioni trasferite e il database di destinazione testando vari casi d'uso. Questo test include sia la lettura e scrivere dati nei database di destinazione tramite le applicazioni, i carichi di lavoro supportano completamente i dati migrati insieme ai dati appena creati.
• Testa le prestazioni delle query del database più utilizzate per osservare se si verifica un degrado a causa di configurazioni errate o di un dimensionamento errato.

Idealmente, tutti questi scenari di test di migrazione sono automatici e ripetibili su qualsiasi sistema di origine. La suite di scenari di test automatici è adattata per offrire rispetto alle applicazioni passate.

Se utilizzi Database Migration Service come strumento di migrazione, consulta Verifica una migrazione.

Strumento di convalida dei dati

Per eseguire la convalida dei dati, ti consigliamo di utilizzare Strumento di convalida dei dati (DVT, Data Validation Tool, DVT). DVT è uno strumento CLI Python open source, supportato da Google, che fornisce una soluzione automatizzata e ripetibile per la convalida in diversi ambienti.

La TVP può aiutare a semplificare il processo di convalida dei dati offrendo servizi funzioni di convalida a più livelli per confrontare le tabelle di origine e di destinazione a livello di tabella, colonna e riga. Puoi anche aggiungere regole di convalida.

La DVT copre molte origini dati Google Cloud, tra cui AlloyDB per PostgreSQL, BigQuery, Cloud SQL, Spanner, file JSON e CSV su Cloud Storage. Può anche essere integrato con le funzioni Cloud Run e Cloud Run per l'attivazione e l'orchestrazione basate su eventi.

La verifica dei dati supporta i seguenti tipi di convalide:

• Confronti a livello di schema
• Colonna (inclusi "AVG", "COUNT", "SUM", "MIN", "MAX", "GROUP BY" e "STRING_AGG")
• Riga (inclusa la corrispondenza esatta e l'hash nei confronti dei campi)
• Confronto dei risultati delle query personalizzate

Per ulteriori informazioni sulla convalida dei dati, consulta il repository Git e Convalida dei dati semplificata con lo strumento di convalida dei dati di Google Cloud.

Esegui la migrazione

Le attività di migrazione includono le attività di supporto del trasferimento da un sistema a un altro.

Considera le seguenti best practice per la migrazione dei dati:

• Informa i team coinvolti ogni volta che inizia e finisce un passaggio del piano.
• Se uno o più passaggi richiedono più tempo del previsto, confronta il tempo trascorso con il tempo massimo previsto per quel passaggio. Problema regolare gli aggiornamenti intermediari ai team coinvolti nel caso in cui ciò si verifichi.
• Se l'intervallo di tempo è superiore al tempo massimo riservato per ogni passaggio del piano, valuta la possibilità di eseguire il rollback.
• Imposta "Via libera o no" per ogni fase della migrazione, e un piano generale.
• Prendi in considerazione azioni di rollback o scenari alternativi per ogni passaggio.

Esegui la migrazione seguendo le attività di esecuzione definite e consulta la documentazione dello strumento di migrazione selezionato.

Esegui il passaggio alla produzione

La procedura di passaggio alla produzione di alto livello può variare a seconda della strategia di migrazione scelta. Se puoi avere tempi di inattività per i carichi di lavoro, la migrazione completa inizia interrompendo le scritture sul database di origine.

Per le migrazioni con replica continua, in genere vengono eseguiti i seguenti passaggi di alto livello nel processo di passaggio:

• Interrompi la scrittura nel database di origine.
• Svuotare la sorgente.
• Interrompi il processo di replica.
• Eseguire il deployment delle applicazioni che puntano al nuovo database di destinazione.

Dopo aver eseguito la migrazione dei dati utilizzando lo strumento di migrazione scelto, convalida i dati nel database di destinazione. Confermi che il database di origine e i database di destinazione sono sincronizzati e che i dati nell'istanza di destinazione rispettano gli standard di successo della migrazione che hai scelto.

Una volta che la convalida dei dati ha superato i criteri, puoi eseguire la migrazione completa di livello. Esegui il deployment dei carichi di lavoro sottoposti a refactoring per utilizzare la nuova istanza di destinazione. Puoi eseguire il deployment delle versioni delle tue applicazioni che puntano nuova istanza del database di destinazione. I deployment possono essere eseguiti tramite aggiornamenti in sequenza, release graduali o utilizzando un pattern di deployment blu/verde. Potrebbero verificarsi dei tempi di inattività delle applicazioni.

Segui le best practice per il passaggio alla produzione:

• Monitora le applicazioni che funzionano con il database di destinazione dopo il passaggio.
• Definire un periodo di tempo per il monitoraggio da considerare per stabilire se è necessario o meno per implementare il tuo piano di riserva.
• Tieni presente che l'istanza Cloud SQL o AlloyDB for PostgreSQL potrebbe richiedere un riavvio se modifichi alcuni flag di database.
• Tieni presente che l'impegno per il rollback della migrazione potrebbe essere maggiore piuttosto che risolvere i problemi appare nell'ambiente di destinazione.

Pulisci l'ambiente di origine e configura l'istanza Cloud SQL o AlloyDB per PostgreSQL

Al termine del passaggio, puoi eliminare i database di origine. Ti consigliamo di eseguire le seguenti azioni importanti prima della pulizia dell'istanza di origine:

• Crea un backup finale di ogni database di origine. Questi backup forniscono un stato finale dei database di origine. I backup potrebbero essere richiesti anche in alcuni casi per la conformità ad alcune normative relative ai dati.

• Raccogli le impostazioni dei parametri di database dell'istanza di origine. In alternativa, verifica che corrispondano a quelle raccolte nel di creazione dell'inventario. Regola i parametri dell'istanza target in modo che corrispondano quelle dell'istanza di origine.

• Raccogli le statistiche del database dall'istanza di origine e confrontale a quelli nell'istanza di destinazione. Se le statistiche sono diverse, è difficile confrontare il rendimento dell'istanza di origine e dell'istanza di destinazione.

In uno scenario di riserva, ti consigliamo di implementare la replica delle tue scritture sull'istanza Cloud SQL nel database di origine originale. La configurazione è simile al processo di migrazione, ma viene eseguita in ordine inverso: il database di origine iniziale diventa il nuovo target.

Come best practice per mantenere aggiornate le istanze di origine dopo il passaggio, riproduci le scritture eseguite sulle istanze Cloud SQL di destinazione nel database di origine. Se devi eseguire il rollback, puoi eseguire il fallback alle vecchie istanze di origine con una perdita di dati minima.

Oltre alla pulizia dell'ambiente di origine, devi apportare le seguenti configurazioni critiche per le tue istanze Cloud SQL:

• Configura un periodo di manutenzione per l'istanza principale da controllare quando possono verificarsi aggiornamenti improvvisi.
• Configura lo spazio di archiviazione nell'istanza in modo da avere almeno il 20% di spazio disponibile per eventuali operazioni di manutenzione del database critiche che Cloud SQL potrebbe eseguire. Per ricevere un avviso se lo spazio su disco disponibile diventa inferiore al 20%, crea un criterio di avviso basato su metriche per la metrica Utilizzo disco.

Non avviare un'operazione amministrativa prima del completamento dell'operazione precedente.

Per ulteriori informazioni sulla manutenzione e sulle best practice, vedi Informazioni sulla manutenzione per le istanze Cloud SQL.

Ottimizza l'ambiente dopo la migrazione

L'ottimizzazione è l'ultima fase della migrazione. In questa fase, esegui l'iterazione attività di ottimizzazione finché l'ambiente di destinazione non soddisfa i requisiti di ottimizzazione i tuoi requisiti. I passaggi di ogni iterazione sono i seguenti:

1. Valuta l'ambiente attuale, i team e il ciclo di ottimizzazione.
2. Definisci i requisiti e gli obiettivi di ottimizzazione.
3. Ottimizza il tuo ambiente e i tuoi team.
4. Ottimizza il ciclo di ottimizzazione.

Ripeti la sequenza finché non hai raggiunto gli obiettivi di ottimizzazione.

Per saperne di più sull'ottimizzazione del tuo ambiente Google Cloud, consulta Eseguire la migrazione a Google Cloud: ottimizzare l'ambiente e Procedura di ottimizzazione del rendimento.

Definisci i tuoi requisiti di ottimizzazione

Esamina i seguenti requisiti di ottimizzazione per Google Cloud e scegli quelli più adatti ai tuoi carichi di lavoro:

Aumenta l'affidabilità e la disponibilità del tuo database

Con Cloud SQL, puoi implementare una strategia di ripristino di emergenza ad alta disponibilità in linea con l'RTO (Recovery Time Objective) e l'RPO (Recovery Point Objective). Per aumentare l'affidabilità e la disponibilità, tieni in considerazione quanto segue:

• In caso di carichi di lavoro con un'elevata percentuale di operazioni di lettura, aggiungi repliche di lettura per scaricare il traffico dall'istanza principale.
• Per i carichi di lavoro mission-critical, utilizza la configurazione ad alta disponibilità, le repliche per il failover regionale e una configurazione di ripristino di emergenza solida.
• Per i carichi di lavoro meno critici, i backup automatizzati e on demand sufficienti.
• Per evitare la rimozione accidentale delle istanze, utilizza la protezione dall'eliminazione delle istanze.
• Valuta la possibilità di utilizzare la versione Cloud SQL Enterprise Plus per usufruire di una maggiore disponibilità, della conservazione dei log e della manutenzione pianificata con tempi di inattività quasi azzerati. Per saperne di più su Cloud SQL Enterprise Plus, vedi Introduzione alle versioni di Cloud SQL e Manutenzione pianificata con tempi di inattività quasi azzerati.

Per ulteriori informazioni su come aumentare l'affidabilità e la disponibilità dei consulta il seguente database:

• Promuovi repliche per la migrazione a livello di regione o il ripristino di emergenza
• Ripristino di emergenza del database Cloud SQL
• Informazioni sui backup di Cloud SQL
• Documentazione su come impedire l'eliminazione di un'istanza

Aumenta la convenienza economica della tua infrastruttura di database

Per avere un impatto economico positivo, i carichi di lavoro devono utilizzare risorse e servizi in modo efficiente. Valuta le seguenti opzioni.

• Fornisci al database la capacità di archiviazione minima richiesta svolgendo quanto segue:

  • Per scalare automaticamente la capacità di archiviazione man mano che i dati aumentano, abilitare gli aumenti automatici dello spazio di archiviazione. Tuttavia, assicurati di configurare per avere un po' di buffer nei carichi di lavoro di picco. Ricorda che il database i carichi di lavoro tendono ad aumentare nel tempo.

• Identifica le risorse potenzialmente sovrastimate:

  • La scelta della dimensione corretta per le istanze Cloud SQL può ridurre il costo dell'infrastruttura senza aggiungere rischi aggiuntivi alla strategia di gestione della capacità.
  • Monitoraggio cloud fornisce dashboard predefinite che consentono di identificare l'integrità e l'utilizzo della capacità di molti componenti di Google Cloud, tra cui Cloud SQL. Per maggiori dettagli, vedi Creare e gestire dashboard personalizzate.

• Identifica le istanze che non richiedono alta disponibilità o emergenze configurazioni di ripristino e rimuovile dall'infrastruttura.

• Rimuovi le tabelle e gli oggetti che non sono più necessari. Puoi archiviarli in un backup completo o in un bucket Cloud Storage di archiviazione.

• Valuta il tipo di archiviazione (SSD o HDD) più conveniente per il tuo caso d'uso.

  • Nella maggior parte dei casi d'uso, l'SSD è il modo più efficiente a convenienza economica.
  • Se i set di dati sono di grandi dimensioni (10 TB o più), insensibili alla latenza o con accesso infrequente, l'HDD potrebbe essere più appropriato.
  • Per maggiori dettagli, consulta Scegliere tra lo spazio di archiviazione SSD e HDD.

• Acquista sconti per impegno di utilizzo per carichi di lavoro con esigenze prevedibili in termini di risorse.

• Utilizza le funzionalità di Assistente attivo per ottenere approfondimenti e consigli sui costi.

  Per ulteriori informazioni e opzioni, consulta Fai di più con meno: presentazione dei consigli per l'ottimizzazione dei costi di Cloud SQL con Active Assist.

Aumentare le prestazioni dell'infrastruttura del database

Spesso problemi di prestazioni minori relativi al database possono influire l'intera operazione. Per mantenere e aumentare le prestazioni delle istanze Cloud SQL, tieni presenti le seguenti linee guida:

• Se hai un numero elevato di tabelle di database, queste possono influire sulle prestazioni e sulla disponibilità dell'istanza e causare la perdita della copertura dello SLA (accordo sul livello del servizio).

• Assicurati che l'istanza non sia limitata in termini di memoria o CPU.

  • Per carichi di lavoro che richiedono prestazioni elevate, assicurati che l'istanza abbia almeno 60 GB di memoria.
  • Per inserimenti, aggiornamenti o eliminazioni del database lenti, controlla la posizione dello scrittore e del database. L'invio di dati su lunghe distanze introduce latenza.

• Migliora le prestazioni delle query utilizzando Query Insights predefinito in Cloud Monitoring (o motore del database simile integrato ). Identificare i comandi più costosi e provare a ottimizzarli.

• Evita che i file di database diventino di dimensioni inutilmente grandi. Imposta autogrow in MB anziché in percentuale, utilizzando gli incrementi appropriati requisito.

• Controlla la posizione del lettore e del database. La latenza influisce sulle prestazioni di lettura più che su quelle di scrittura.

• Valuta la possibilità di utilizzare la versione Cloud SQL Enterprise Plus per usufruire di limiti di configurazione delle macchine e della cache dei dati più elevati. Per maggiori informazioni le informazioni, vedi Introduzione alle versioni di Cloud SQL.

Per ulteriori informazioni su come migliorare il rendimento, consulta Rendimento in "Diagnostica dei problemi".

Aumenta le funzionalità di osservabilità del database

Diagnosi e risoluzione dei problemi nelle applicazioni che si connettono al database possono essere complesse e richiedere molto tempo. Per questo motivo, un sistema posizione in cui tutti i membri del team possono vedere cosa succede nel database e nell'istanza livello è essenziale. Puoi monitorare le istanze Cloud SQL nei modi seguenti:

• Cloud SQL utilizza agenti personalizzati della memoria integrata per raccogliere le query la telemetria.

  • Utilizza Cloud Monitoring per raccogliere le misurazioni del tuo servizio e delle risorse Google Cloud in uso. Cloud Monitoring include dashboard predefinite per diversi prodotti Google Cloud, inclusa una dashboard di monitoraggio di Cloud SQL.
  • Puoi creare dashboard personalizzate per monitorare le metriche e configurare criteri di avviso per poter ricevere notifiche tempestive.
  • In alternativa, puoi prendere in considerazione l'utilizzo di soluzioni di monitoraggio di terze parti che si integrano con Google Cloud, come Datadog e Splunk.

• Cloud Logging raccoglie i dati di logging da componenti di applicazioni comuni.

• Cloud Trace raccoglie dati sulla latenza ed esegue piani di query dalle applicazioni per aiutare puoi tenere traccia del modo in cui le richieste si propagano nell'applicazione.

• Centro database offre una panoramica del parco risorse di database centralizzato e assistito dall'AI. Puoi monitorare integrità dei database, configurazione della disponibilità, protezione dei dati sicurezza e conformità del settore.

Best practice generali e linee guida operative di Cloud SQL

Applica le best practice per Cloud SQL per configurare e ottimizzare per configurare un database.

Di seguito sono riportati alcuni suggerimenti generali importanti di Cloud SQL:

• Se hai istanze di grandi dimensioni, ti consigliamo di suddividerle in di piccole dimensioni, se possibile.
• Configura lo spazio di archiviazione per la manutenzione critica del database. Assicurati di avere almeno il 20% di spazio disponibile per gestire eventuali operazioni di manutenzione del database critiche che Cloud SQL potrebbe eseguire.
• La presenza di troppe tabelle di database può influire sul tempo di upgrade del database. Idealmente, dovresti avere meno di 10.000 tabelle per istanza.
• Scegli la dimensione appropriata per cui tenere conto delle istanze conservazione dei log delle transazioni (binari), soprattutto in caso di attività di scrittura elevate di Compute Engine.

Per poter gestire in modo efficiente eventuali problemi di prestazioni del database che potresti riscontrare, segui le linee guida riportate di seguito fino alla risoluzione del problema:

Esegui lo scale up dell'infrastruttura: aumenta le risorse (ad esempio throughput del disco, vCPU e RAM). A seconda dell'urgenza e della disponibilità ed esperienza del tuo team, il scaling verticale dell'istanza può risolvere la maggior parte dei problemi di prestazioni. In un secondo momento, puoi esaminare ulteriormente la causa principale del problema in un ambiente di test e prendere in considerazione le opzioni per eliminarlo.

Esegui e pianifica le operazioni di manutenzione del database: defragmentazione degli indici, aggiornamenti delle statistiche, analisi vacuum e ridefinizione degli indici delle tabelle aggiornate di frequente. Controlla se e quando queste operazioni di manutenzione sono state eseguite l'ultima volta, soprattutto sugli oggetti interessati (tabelle, indici). Scopri se c'è stata una variazione rispetto alle normali attività del database. Ad esempio, l'aggiunta di una nuova colonna o la presenza di molti aggiornamenti in una tabella.

Esegui la messa a punto e l'ottimizzazione del database: le tabelle del database sono strutturate correttamente? Le colonne hanno i tipi di dati corretti? I tuoi dati sono più adatto al tipo di carico di lavoro? Esamina le query lente e i relativi piani di esecuzione. Utilizzano gli indici disponibili? Verifica indice scansioni, blocchi e attende su altre risorse. Valuta la possibilità di aggiungere indici per supportare le tue query critiche. Elimina gli indici e le chiavi esterne non critici. Prendi in considerazione e riscrivere query e join complessi. Il tempo necessario per risolvere il problema dipende dall'esperienza e dalla disponibilità del tuo team e può variare da ore ai giorni.

Fai lo scale out delle letture: valuta la possibilità di utilizzare repliche di lettura. Se la scalabilità verticale non è sufficiente per le tue esigenze e le misure di ottimizzazione e ottimizzazione del database non sono utili, valuta la possibilità di eseguire la scalabilità orizzontale. Routing delle query di lettura dalle applicazioni a una replica di lettura migliora le prestazioni complessive del carico di lavoro del database. Tuttavia, potrebbe essere necessario un impegno aggiuntivo per modificare le applicazioni in modo che si connettano alla replica di lettura.

Riprogettazione del database: valuta la possibilità di partizionare e indicizzare il database. Questa operazione richiede uno sforzo notevolmente maggiore rispetto all'ottimizzazione e e potrebbe comportare una migrazione dei dati, ma può essere un processo correggere l'errore. A volte, una progettazione scadente del modello dei dati può portare a problemi di prestazioni, che possono essere parzialmente compensati mediante scale up verticali. Tuttavia, un modello dei dati adeguato è una soluzione a lungo termine. Valuta la possibilità di partizionare le tabelle. Archivia i dati non necessari se possibile. Normalizza la struttura del database, ma ricorda che anche la denormalizzazione può migliorare le prestazioni.

Sharding del database: puoi eseguire lo scaling out delle scritture eseguendo lo sharding del database. Lo sharding è un'operazione complicata e prevede la riprogettazione dell'architettura del database e applicazioni in modo specifico ed eseguendo la migrazione dei dati. Dividi l'istanza di database in più istanze più piccole utilizzando criteri di partizione specifici. I criteri possono essere basati sul cliente o sul soggetto. Questa opzione ti consente di eseguire il scaling orizzontale sia delle scritture che delle letture. Tuttavia, aumenta e la complessità dei carichi di lavoro del database e delle applicazioni. Potrebbero anche verificarsi frammenti sbilanciati chiamati hotspot, che superano i vantaggi dello sharding. - In particolare per Cloud SQL per MySQL, assicurati che le tabelle abbiano una chiave primaria o univoca. Cloud SQL utilizza le soluzioni basate su righe di replica, che funziona meglio su tabelle con chiavi primarie o univoche.

Per ulteriori dettagli, consulta le best practice generali e le linee guida operative per Cloud SQL per MySQL.

Passaggi successivi

• Scopri di più su altri percorsi di migrazione da AWS a Google Cloud.
• Scopri come confrontare i servizi AWS e Azure con Google Cloud.
• Scopri quando consulta l'assistenza per le migrazioni.
• Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.

Collaboratori

Autori:

• Alex Cârciu | Architetto di soluzioni
• Marco Ferrari | Cloud Solutions Architect

Altri collaboratori:

• Derek Downey | Developer Relations Engineer
• Paweł Krentowski | Technical Writer
• Mario Rossi | Tecnico cloud strategico
• Somdyuti Paul | Specialista di gestione dei dati
• Zach Seils | Specialista di networking