Esegui la migrazione da AWS a Google Cloud: migra da Amazon RDS per SQL Server a Cloud SQL per SQL Server

Last reviewed 2024-06-28 UTC

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

Questo documento è rivolto agli amministratori di cloud e database che vogliono pianificare, implementare e convalidare un progetto di migrazione del database. È rivolto anche ai responsabili decisionali che stanno valutando la possibilità di eseguire la migrazione e vogliono un esempio di come potrebbe essere una migrazione.

Questo documento si concentra su una migrazione omogenea del database, ovvero una migrazione in cui i database di origine e di destinazione hanno la stessa tecnologia di database. La fonte è Amazon RDS per SQL Server e la destinazione è Cloud SQL per SQL Server.

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

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.

Percorso di migrazione con quattro fasi.

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 iterazione di migrazione distinta, segui le fasi del framework di migrazione generale:

  1. Valuta e scopri i tuoi carichi di lavoro e i tuoi 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 saperne di più 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 il piano di migrazione, consulta Eseguire la migrazione a Google Cloud: best practice per convalidare 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 la buona riuscita della migrazione. Devi acquisire conoscenze approfondite sui carichi di lavoro di cui vuoi eseguire la migrazione, sui relativi requisiti, sulle dipendenze e sul tuo ambiente attuale. Per pianificare ed eseguire correttamente una migrazione a Google Cloud, devi conoscere il punto di partenza.

La fase di valutazione è composta dalle seguenti attività:

  1. Crea un inventario completo dei tuoi workload.
  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 workload.
  7. Scegli gli strumenti di migrazione.
  8. Definisci il piano e le tempistiche della migrazione.
  9. Convalida il piano di migrazione.

Per ulteriori informazioni sulla fase di valutazione e su queste attività, consulta Eseguire la migrazione a Google Cloud: valutare e rilevare i carichi di lavoro. Le sezioni seguenti si basano sulle informazioni contenute in questo documento.

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 non riuscire o non riuscire a causa di una dimensione errata dell'istanza del database di destinazione. Una dimensione errata può comportare tempi di migrazione lunghi, problemi di prestazioni del database, errori del database e problemi di prestazioni dell'applicazione. 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

Per definire l'ambito della migrazione, crea un inventario e raccogli informazioni sulle tue istanze Amazon RDS. Idealmente, il processo dovrebbe essere automatico, perché gli approcci manuali sono soggetti a errori e possono portare a presupposti errati.

Amazon RDS e Cloud SQL potrebbero non avere funzionalità, specifiche o operazioni simili. Alcune funzionalità potrebbero essere implementate diversamente o non essere 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, delle dimensioni dell'istanza e dell'architettura, esistono anche differenze nei valori predefiniti delle impostazioni dei parametri del database.

Il benchmarking può aiutarti a comprendere meglio i carichi di lavoro di cui eseguire la migrazione e 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 nella fase di Eseguire test e convalida del processo di migrazione, ma si applicano anche alla fase di creazione dell'inventario.

Strumenti per le valutazioni

Per una valutazione di panoramica iniziale della tua infrastruttura attuale, ti consigliamo di utilizzare il Centro di migrazione di Google Cloud insieme ad altri strumenti di valutazione del database specializzati come migVisor e DMA (Database Migration Assessment Tool).

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 del tuo ambiente AWS utilizzando Migration Center, consulta Importare i dati da altri provider cloud.

Oltre al Centro di migrazione, puoi utilizzare lo strumento specializzato migVisor. migVisor supporta una serie di motori di database ed è particolarmente adatto per le migrazioni eterogenee. Per un'introduzione a migVisor, consulta la panoramica di migVisor.

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 della valutazione, consulta migVisor - Cloud migration assessment tool.

Tieni presente che migVisor aumenta temporaneamente l'utilizzo del server di database. In genere, questo carico aggiuntivo è inferiore al 3% e può essere eseguito durante le ore di punta.

L'output della valutazione di migVisor ti aiuta a creare un inventario completo delle tue istanze RDS. 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 dettagliate (su carichi di lavoro, funzionalità, oggetti e codice di database) e a creare l'inventario del database. Inoltre, gli script di solito forniscono una valutazione dettagliata della migrazione del database, inclusa una stima dell'impegno richiesto.

Consigliamo lo strumento open source DMA, sviluppato dagli ingegneri di Google. Offre una valutazione completa e accurata del database, incluse le funzionalità in uso, la logica del database e gli oggetti del database (inclusi schemi, tabelle, viste, funzioni, trigger e stored procedure).

Per utilizzare DMA, scarica gli script di raccolta per il tuo motore del database dal repository Git, e segui le istruzioni. Invia i file di output a Google Cloud per analizzarli. Google Cloud crea e fornisce un report di valutazione del database e indica i passaggi successivi del 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 influiscono sulla strategia e sugli strumenti di migrazione. A questo punto, puoi rispondere alle seguenti domande:

  • I tuoi database sono più grandi di 5 TB?
  • Il tuo database contiene tabelle di grandi dimensioni? Sono superiori a 16 TB?
  • Dove si trovano i database (regioni e zone) e qual è la 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 tuoi database potrebbe richiedere molto tempo e impegno. Alcuni dati potrebbero rimanere 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. Queste misurazioni includono quanto segue:

  • 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. Quali sono gli impatti del tempo di riposo sull'attività? Esistono periodi di bassa attività del database, durante i quali il tempo di riposo riguarda meno utenti? In caso affermativo, quanto durano questi periodi e quando si verificano? Valuta la possibilità di avere un tempo di riposo parziale solo per le scritture, mentre le richieste di sola lettura vengono comunque eseguite.

Valuta il processo di deployment e amministrazione

Dopo aver creato gli inventari, valuta i processi di operazione e di implementazione per il tuo database per determinare in che modo devi adattarli per semplificare 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 i ruoli Google IAM, le regole firewall VPC e i Controlli di servizio VPC per controllare l'accesso alle tue istanze Cloud SQL e limitare i dati all'interno di un VPC. Se prevedi di utilizzare l'autenticazione Windows con Cloud SQL per SQL Server, devi eseguire il deployment di Microsoft AD gestito e connetterti all'infrastruttura Active Directory esistente.
  • Esegui patch e configura le istanze: potrebbe essere necessario aggiornare gli strumenti di deployment esistenti. 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 questi elenchi di configurazione personalizzati.
  • Gestisci l'infrastruttura di monitoraggio e generazione di avvisi: le categorie di metriche per le istanze del database di origine Amazon forniscono l'osservabilità durante il processo di migrazione. Le categorie di metriche possono includere Amazon CloudWatch, Performance Insights, il monitoraggio avanzato e gli elenchi di processi del sistema operativo.

Completa la valutazione

Dopo aver creato gli inventari dal tuo ambiente Amazon RDS, completa il resto delle attività della fase di valutazione come descritto in Eseguire la migrazione a Google Cloud: valuta e scopri i tuoi carichi di lavoro.

Pianifica e crea le basi

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

  • 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 compilazione è composta dalle seguenti attività:

  1. Crea una gerarchia di risorse.
  2. Configurare Identity and Access Management (IAM) di Google Cloud.
  3. Configura la fatturazione.
  4. Configura la connettività di rete.
  5. Rafforza la 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: pianificare e creare le basi.

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 per SQL Server a Cloud SQL per SQL Server

Per eseguire la migrazione delle istanze:

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

  2. Scegli gli strumenti di migrazione, in base alla strategia e ai requisiti scelti.

  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 svolgere per garantire il corretto funzionamento dello strumento di migrazione.

  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 il passaggio alla produzione.

  10. Ripulisci l'ambiente di origine e configura l'istanza di destinazione.

  11. Esegui il tuning e l'ottimizzazione.

Ogni fase è descritta nelle sezioni seguenti.

Scegli la strategia di migrazione

In questo passaggio, hai informazioni sufficienti per valutare e selezionare una delle seguenti strategie di migrazione più adatta al tuo caso d'uso per ogni database:

  • Manutenzione pianificata (chiamata anche migrazione una tantum): questo approccio è ideale se puoi permetterti i tempi di inattività. Questa opzione ha un costo e una complessità relativamente inferiori, perché i carichi di lavoro e i servizi non richiedono molto refactoring. Tuttavia, se la migrazione non va a buon fine prima del completamento, devi riavviare il processo, il che prolunga il tempo di riposo.

  • Replica continua (chiamata anche migrazione graduale): per i database mission-critical, questa opzione offre un rischio inferiore di perdita di dati e tempi di inattività quasi nulli. Le attività vengono suddivise in più parti, quindi, se si verifica un errore, 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:

    • Utilizzando l'approccio Y (scrittura e lettura), che è una forma di migrazione parallela, i dati vengono duplicati sia nelle istanze di origine sia in quelle di destinazione durante la migrazione.
    • Utilizzo di un microservizio di accesso ai dati, che riduce lo sforzo di refactoring richiesto dall'approccio Y (scrittura e lettura).

Per ulteriori informazioni sulle strategie di migrazione dei dati, consulta Valutare gli 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:

Diagramma di flusso per aiutarti a scegliere la strategia di migrazione.

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, vai al punto di decisione successivo.

  • Puoi permetterti il tempo di riposo rappresentato dal periodo di transizione durante la migrazione dei dati? La finestra di transizione rappresenta il tempo necessario per eseguire un backup del database, trasferirlo in Cloud SQL, ripristinarlo e passare alle applicazioni.

    • In caso contrario, adotta la strategia di migrazione con replica continua.
    • In caso affermativo, adotta la strategia di migrazione con 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.

In genere, una migrazione è considerata completata quando avviene il passaggio tra l'istanza di origine iniziale e l'istanza di destinazione. Qualsiasi replica (se utilizzata) viene interrotta e tutte le letture e le scritture vengono eseguite sull'istanza di destinazione. Il passaggio quando entrambe le istanze sono sincronizzate non comporta perdita di dati e un tempo di riposo minimo.

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

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 comporta un compromesso e un certo impatto associato al processo 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:

  • Le query del database possono 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 se ha una memoria buffer considerevole.
  • 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. A seconda di come sono configurate le voci DNS, l'operazione può 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 inattività 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 o altre finestre di manutenzione programmate.
  • Identifica le parti dei carichi di lavoro che possono essere sottoposte a migrazione e al passaggio alla produzione in fasi diverse. Le tue applicazioni potrebbero avere diversi componenti che possono essere isolati, adattati e di cui eseguire la migrazione senza alcun impatto. Ad esempio, frontend, moduli CRM, servizi di backend e piattaforme di generazione di report. Questi moduli potrebbero avere i propri database per i quali è possibile pianificare la migrazione in un momento precedente o successivo del 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 workload per lavorare con i dati obsoleti sull'istanza di destinazione.
  • Valuta la possibilità di eseguire il refactoring delle tue applicazioni per supportare un impatto minimo della migrazione. 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 è scegliere lo strumento di migrazione corretto. Una volta stabilita la strategia di migrazione, esamina e scegli lo strumento di migrazione.

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

  • Strategia di migrazione (manutenzione pianificata o replica continua).
  • Motori del database di origine e di destinazione e relative versioni.
  • Ambienti in cui si trovano le istanze di origine e di destinazione.
  • Dimensioni del database. Maggiore è il database, maggiore è il tempo necessario per eseguire la migrazione del backup iniziale.
  • Frequenza delle modifiche al database.
  • Disponibilità di utilizzare i 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 spostamento 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 funzionalità, incapsulano la logica complessa della migrazione e offrono funzionalità di monitoraggio della migrazione.

I servizi di migrazione gestita 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: le migrazioni dei database sono eventi infrequenti, ma critici. Per evitare errori da principianti e problemi con le soluzioni esistenti, puoi utilizzare gli strumenti di esperti esperti, anziché creare una soluzione personalizzata.

  • Ottimizza i costi: i servizi di migrazione gestita possono essere più convenienti rispetto al provisioning di server e risorse aggiuntivi per soluzioni di migrazione personalizzate.

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

Strumenti per le migrazioni di manutenzione pianificata

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

Backup del motore del database integrato

Quando sono accettabili tempi di riposo significativi e i database di origine sono relativamente statici, puoi utilizzare le funzionalità di backup e ripristino integrate del motore del database.

La configurazione e la sincronizzazione richiedono un po' di impegno, soprattutto per un numero elevato di database, ma i backup del motore del database sono in genere disponibili e facili da usare. Questo approccio è adatto a qualsiasi dimensione del database ed è solitamente più efficace di altri strumenti per le istanze di grandi dimensioni.

I backup del motore del database presentano 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.

Se scegli questo approccio, tieni presenti le seguenti limitazioni e best practice:

  • Per i backup di database di dimensioni superiori a 5 TB, utilizza un backup suddiviso in parti (un backup di più file).
  • Quando utilizzi un backup sottoposto a striping, non puoi eseguire il backup o il ripristino da più di 10 file di backup contemporaneamente.
  • Devi eseguire il backup in un bucket Amazon S3 nella stessa regione Amazon della tua istanza del database di origine.
  • I backup non includono gli accessi, le autorizzazioni e i ruoli del server SQL Server, perché si trovano a livello di istanza. Per trasferire questo tipo di dati dall'istanza di origine a quella di destinazione, utilizza script PowerShell o strumenti come DBAtools.

Per informazioni dettagliate su limitazioni e best practice, consulta Best practice per l'importazione e l'esportazione dei dati con Cloud SQL per SQL Server e Problemi noti di Cloud SQL per SQL Server.

Altri approcci per le migrazioni di manutenzione pianificata

L'utilizzo di altri approcci potrebbe offrire maggiore controllo e flessibilità nella procedura di migrazione della manutenzione pianificata.

Ad esempio, utilizzando file di tipo flat per esportare e importare i dati (o script personalizzati), puoi:

  • Esegui trasformazioni, controlli o altre operazioni sui dati durante la migrazione. Ad esempio, convalide, aggregazione o normalizzazione e denormalizzazione dei dati di origine.
  • Scegli le strutture di cui vuoi eseguire la migrazione e quelle da non includere. Potresti decidere di estrarre solo un sottoinsieme delle tabelle in file di tipo flat per l'importazione.
  • Scegli di filtrare i dati in base a dominio, origine, età o altri criteri personalizzati. Ad esempio, puoi escludere i dati che raggiungono una soglia di età e archiviarli in file o nel backup finale del database di origine prima della migrazione.
  • Esegui il refactoring delle strutture del database e sincronizza il tempo di riposo speso con il tempo di riposo della migrazione.
  • Consolida più istanze o database in un'unica istanza o database per ridurre i costi operativi e semplificare i problemi di scalabilità. Ad esempio, potresti voler cambiare il tuo approccio passando da un'istanza, un database o uno schema per cliente a una singola struttura di database ottimizzata per il multitenancy.

Altri approcci includono:

  • Utilizza file CSV o JSON: con questo approccio, estrai i dati del database nei file e poi li importi nelle istanze di destinazione.

    • Sebbene in genere sia più lento, questo metodo consente di eseguire la migrazione di un sottoinsieme di tabelle (o di dati all'interno di una determinata tabella).
    • I formati CSV e JSON sono compresi da molti strumenti.
    • Se automatizzi il processo, hai la possibilità di eseguire la transizione a una migrazione di replica continua in batch.

  • Utilizza la procedura guidata di importazione ed esportazione di SQL Server di Microsoft: questo strumento utilizza SQL Server Integration Services (SSIS) e ti consente di importare dati da varie origini, come altri motori di database o file di testo.

  • Utilizza la procedura guidata per la generazione e la pubblicazione di script di SQL Server e l'utilità bcp: questo strumento fa parte di Microsoft SQL Server Management Studio.

    • Questo approccio ti consente di creare script per l'intero schema del database o solo per alcune parti.
    • L'utilità bcp ti consente di creare script per i dati ed esportarli in file.

  • Utilizza la replica degli snapshot, se la sorgente utilizza Amazon RDS Standard:

    • Con questo approccio, ripristini il backup di SQL Server dell'istanza RDS in un'altra istanza autonoma di SQL Server su Compute Engine. Quindi, utilizza la replica degli snapshot per eseguire la migrazione a Cloud SQL per SQL Server.
    • La generazione di istantanee mantiene i blocchi sulle tabelle di origine, il che potrebbe influire sui tuoi carichi di lavoro.
    • La replica degli snapshot potrebbe introdurre carichi aggiuntivi sul tuo server Amazon RDS.
    • Tuttavia, puoi scegliere gli oggetti di cui eseguire la migrazione o la replica, il che offre flessibilità.
    • Per informazioni dettagliate, consulta Eseguire la migrazione dei dati da SQL Server 2017 a Cloud SQL per SQL Server utilizzando la replica degli snapshot.

Strumenti per le migrazioni con replica continua

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

Diagramma di flusso per aiutarti a scegliere uno strumento per le migrazioni con replica continua.

Il diagramma di flusso precedente mostra i seguenti punti decisionali:

  • Preferisci utilizzare servizi di migrazione gestiti?

    • Se sì, vai alla decisione successiva. Se puoi permetterti un minimo di tempo di inattività e non hai bisogno di trasformazione dei dati o sincronizzazione in tempo reale, ti consigliamo Database Migration Service. In caso contrario, valuta le opzioni di terze parti.
    • In caso contrario, vai alla decisione successiva. Se la replica integrata del motore del database è supportata, ti consigliamo di utilizzarla. In caso contrario, ti consigliamo di valutare altre opzioni di migrazione.

  • Puoi permetterti un tempo di inattività minimo ed eseguire la migrazione senza trasformazione dei dati o sincronizzazione in tempo reale?

    • In caso affermativo, ti consigliamo Database Migration Service.
    • In caso contrario, valuta le opzioni di terze parti.

  • È supportata la replica integrata specifica del motore del database?

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

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

Database Migration Service per la migrazione con replica continua

Database Migration Service supporta le migrazioni omogenee a Cloud SQL per SQL Server quando la sorgente è Amazon RDS.

Database Migration Service è uno strumento semplice ed economico. Ti consigliamo di utilizzare Database Migration Service per le seguenti situazioni:

  • Puoi permetterti tempi di inattività minimi.
  • Non è necessaria la sincronizzazione in tempo reale.
  • Non è necessario eseguire trasformazioni dei dati durante la migrazione.

Se scegli questo strumento, tieni presente le seguenti limitazioni e best practice:

  • La durata del tempo di riposo dipende dalla frequenza dei backup dei log delle transazioni.
  • I backup non includono gli accessi, le autorizzazioni o i ruoli del server SQL Server, perché si trovano a livello di istanza. Estrai gli script dall'istanza di origine e poi trasferiscili all'istanza di destinazione utilizzando script o strumenti PowerShell come DBAtools.

Per un elenco completo delle limitazioni, consulta Limitazioni note.

Replica integrata del motore del database

Cloud SQL supporta la replica per SQL Server. Tuttavia, Amazon RDS per SQL Server standard può essere solo un abbonato. La replica integrata da Amazon RDS Standard non è disponibile. Solo Amazon RDS Custom per SQL Server può essere configurato come editor integrato.

Per un elenco delle funzionalità supportate e non supportate su Amazon RDS, consulta Amazon RDS per Microsoft SQL Server.

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 di migrazione si concentra sul refactoring o sullo sviluppo di strumenti che si connettono alle istanze di database.
    • Le applicazioni di lettura vengono quindi ristrutturate e implementate gradualmente per utilizzare l'istanza di destinazione.

  • Implementa funzioni che eseguono query periodicamente sui dati dell'istanza di origine, filtrano solo i nuovi dati e scrivono i dati in file CSV, JSON o Parquet.

    • Questi file vengono archiviati in un bucket Google Cloud Storage.
    • I file possono essere scritti immediatamente nell'istanza del database di destinazione utilizzando le funzioni Cloud Run.
    • Le funzionalità di Change Data Capture (CDC) possono aiutarti a eseguire una migrazione di replica quasi in tempo reale.
    • Puoi eseguire lo streaming del CDC in un data lake Amazon S3 in formato Parquet, utilizzando AWS Database Migration Service (AWS DMS).
    • Puoi avere un'implementazione personalizzata per leggere i file e scrivere i relativi contenuti in Cloud SQL.

Strumenti di terze parti per le migrazioni con replica continua

In alcuni casi, potrebbe essere meglio utilizzare uno strumento di terze parti per la maggior parte dei motori di database. Questi casi possono verificarsi 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 del 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:

Per ulteriori informazioni su Striim, consulta Eseguire 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'assistenza della community solida.
    • Economica.
    • 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 distribuzione "almeno una volta" dei dati cambia, il che significa che è necessaria la gestione dei duplicati.
    • Configurazione del monitoraggio manuale utilizzando 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 dei dati automatizzata per spostare i dati da e tra piattaforme di dati cloud.

  • Vantaggi:

    • Modelli di connessione preconfigurati e pipeline senza codice.
    • Propaga eventuali modifiche allo schema dall'origine al database di destinazione.
    • La consegna "esattamente una volta" dei dati cambia, il che significa che non è necessaria 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 eseguire la migrazione di determinate tabelle da un database, potresti aver bisogno di attività di pre-migrazione o post-migrazione per implementare questo filtro. Inoltre, assicurati che la migrazione del database non influisca sull'accordo sul livello del servizio (SLA) e sul piano di continuità aziendale esistenti.

Ti consigliamo di includere nella documentazione di pianificazione della migrazione i seguenti 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 sono spesso più lente di quelle successive. In genere, le migrazioni pianificate vengono eseguite senza problemi, ma possono comunque verificarsi problemi imprevisti. Ti consigliamo di avere sempre un piano di rollback. Come best practice, segui le indicazioni riportate in Eseguire la migrazione a Google Cloud: best practice per convalidare un piano di migrazione.

TDD

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

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

Matrice RACI

Alcuni progetti di migrazione richiedono una matrice RACI, ovvero un documento comune di gestione del progetto che definisce le persone o i gruppi responsabili delle attività e dei risultati del progetto di migrazione.

Cronologia

Prepara una sequenza temporale per ogni database di cui è necessaria la migrazione. Includi tutte le attività di lavoro da eseguire, nonché le date di inizio e di fine stimate.

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 sequenza temporale deve tenere conto non solo dell'esecuzione delle attività di preparazione pre-migrazione, ma anche delle attività di convalida, controllo o test che si verificano dopo 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-minus 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 Progetta l'ambiente di destinazione come descritto dal documento di progettazione Team di migrazione -14 Completa
15/11/2023 Pre-migrazione Governance aziendale Data di migrazione e approvazione T-Minus Leadership -6 Completa
18/11/2023 Migrazione Configurare DMS Creare profili di connessione Cloud migration engineer -3 Completa
19/11/2023 Migrazione Configurare 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 Cloud migration engineer -2 Non avviato
21/11/2023 Migrazione Eseguire il cutover di DMS Promuovi la replica DMS Cloud migration engineer 0 Non avviato
21/11/2023 Migrazione Convalida della migrazione Convalida della migrazione del database Team di migrazione 0 Non avviato
21/11/2023 Migrazione Test dell'applicazione Esegui test di funzionalità e prestazioni Team di migrazione 0 Non avviato
22/11/2023 Migrazione Governance aziendale Convalida della migrazione: OK o NO Team di migrazione 1 Non avviato
23/11/2023 Dopo la migrazione Convalidare il monitoraggio Configura il monitoraggio Team di infrastruttura 2 Non avviato
25/11/2023 Dopo la migrazione Sicurezza Rimuovere l'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 ad acquisire conoscenza e sicurezza in merito al processo e agli 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 tempistiche possono essere parallelizzate. Ad esempio, per velocizzare il processo di migrazione, puoi scegliere di eseguire contemporaneamente la migrazione di un gruppo di database di piccole dimensioni, statici o meno critici, come mostrato nel seguente diagramma.

Attività di migrazione del database parallele.

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 per soddisfare i prerequisiti della migrazione. Se non completi le attività di preparazione, la migrazione non può essere eseguita o il database di destinazione potrebbe essere inutilizzabile.

Le attività di preparazione possono essere classificate come segue:

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

Preparazione e prerequisiti delle istanze Amazon RDS

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 le connessioni remote sulle porte richieste.

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

  • Per la replica continua (modifiche in streaming tramite CDC), devi utilizzare un'istanza RDS completa e non una replica di lettura con il CDC abilitato. Per maggiori dettagli, consulta Utilizzare l'acquisizione dei dati delle modifiche con SQL Server.

  • Se utilizzi strumenti di terze parti, in genere sono necessarie impostazioni e configurazioni preliminari prima di poter utilizzare lo strumento. Consulta la documentazione dello strumento di terze parti.

Preparazione del database di origine e prerequisiti

  • Assicurati che il database di origine disponga di memoria e spazio di archiviazione buffer disponibili durante le operazioni di migrazione. Ad esempio, se utilizzi file di backup dei log delle transazioni, monitora l'utilizzo dello spazio di archiviazione e assicurati di avere spazio di archiviazione aggiuntivo per i buffer.
  • Documenta le impostazioni dei parametri del database e applicale all'istanza di destinazione prima di eseguire i test e la convalida della migrazione.

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

    • Misura le dimensioni dei dati e le prestazioni del tuo carico di lavoro. Quanto tempo richiedono in media query o transazioni importanti? Per quanto tempo durante le ore di punta?
    • Documenta le misurazioni di riferimento per un confronto successivo, in modo da decidere se la fedeltà della migrazione del database è soddisfacente. Decidi se puoi cambiare i carichi di lavoro di produzione e ritirare l'ambiente di origine o se ne hai ancora bisogno per il fallback.

Configurazione di Cloud SQL

Scegli con attenzione le dimensioni e le specifiche dell'istanza di database Cloud SQL di destinazione in modo che corrispondano a quelle dell'origine per esigenze di prestazioni simili. Presta particolare attenzione alle dimensioni e alla velocità effettiva del disco, alle IOPS e al numero di vCPU. Una dimensione errata può comportare tempi di migrazione lunghi, problemi di prestazioni del database, errori del database e problemi di prestazioni dell'applicazione.

Assicurati che la destinazione sia adatta. È importante notare che le opzioni di configurazione di Amazon RDS potrebbero variare da Cloud SQL. Nel caso in cui Cloud SQL non soddisfi i tuoi requisiti, valuta le opzioni che includono i database su Compute Engine.

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 attentamente il progetto e la regione delle istanze Cloud SQL di destinazione. Non è possibile eseguire la migrazione delle istanze Cloud SQL tra progetti e regioni Google Cloud senza trasferimento dei dati.

  • Esegui la migrazione a una versione principale corrispondente su Cloud SQL. Ad esempio, se la tua origine utilizza SQL Server 15.0, esegui la migrazione a Cloud SQL per SQL Server 15.0. Se le versioni sono diverse, l'impostazione del livello di compatibilità deve essere la stessa per garantire le stesse funzionalità del motore.

  • Replica le informazioni utente separatamente, se utilizzi i backup del motore del database integrato o Database Migration Service. Per maggiori dettagli, consulta le limitazioni nella sezione Backup specifici del motore del database.

  • Esamina i flag di configurazione specifici del motore del database e confronta i valori delle istanze di origine e di destinazione. Assicurati di comprenderne l'impatto e se devono essere uguali o meno. Ad esempio, ti consigliamo di confrontare i valori nella vista sys.configurations nel database di origine con i valori nell'istanza Cloud SQL. Tieni presente che non tutti i flag devono essere uguali e non tutte le modifiche ai flag sono consentite in un'istanza Cloud SQL.

Per ulteriori informazioni sulla configurazione di Cloud SQL, consulta quanto segue:

Configurazione specifica per la migrazione

Se utilizzi l'esportazione e l'importazione dei file per eseguire la migrazione o lo strumento di migrazione Database Migration Service, devi creare un bucket Cloud Storage. Il bucket memorizza i file di backup del database e dei log delle transazioni. Per ulteriori informazioni sull'utilizzo di Database Migration Service, consulta Archiviare i file di backup in un bucket Cloud Storage.

Se utilizzi la replica, devi assicurarti che la replica Cloud SQL abbia accesso al tuo database principale. Questo può essere ottenuto tramite le opzioni di connettività descritte.

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, potresti aver bisogno di un ulteriore meccanismo di replica da Cloud SQL 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 devi utilizzare Google Cloud Marketplace per iniziare. Per configurare l'ambiente di migrazione in Striim, puoi utilizzare Flow Designer per creare e modificare le applicazioni oppure selezionare un modello preesistente. 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.

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 ulteriori informazioni e istruzioni per i backup specifici del database, consulta Importare i dati da un file BAK in Cloud SQL per SQL Server e Esportazione dei dati da RDS per SQL Server. Per ulteriori informazioni su come automatizzare i caricamenti dei file di log delle transazioni, consulta Pianificare i caricamenti dei file di log delle transazioni per Amazon RDS.

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 all'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.

La procedura di migrazione in genere prevede le seguenti attività:

  • Esporta un backup completo del database di origine, quindi caricalo in un bucket Cloud Storage.
  • Esegui il backup dei file dei log delle transazioni e caricali nello stesso bucket Cloud Storage. Per ulteriori informazioni su come automatizzare questa procedura, consulta Pianificare i caricamenti dei file di log delle transazioni per Amazon RDS.
  • In Database Migration Service, monitori l'elaborazione dei backup dei log delle transazioni.
  • Interrompi la scrittura nel database di origine.
  • Attendi la sincronizzazione dell'origine e della destinazione, ovvero quando viene elaborato il backup del log delle transazioni finale.
  • Interrompi la replica in corso e promuovi il job di migrazione.Promuovendo un job di migrazione, l'istanza Cloud SQL di destinazione viene disconnessa dall'istanza del database di origine e poi promossa a istanza principale.
  • Esegui il deployment delle applicazioni che rimandano al nuovo database di destinazione.

Per una procedura dettagliata di configurazione della migrazione, consulta Eseguire la migrazione dei database SQL Server in Cloud SQL per SQL Server.

Replica integrata del motore del database

Se utilizzi Amazon RDS Standard, potrebbe essere necessario eseguire prima la migrazione alla versione personalizzata di Amazon RDS e poi eseguire la replica in Cloud SQL.

Cloud SQL supporta la replica per SQL Server. Per ulteriori informazioni sulla replica da un server esterno, consulta Eseguire la migrazione dei dati da SQL Server 2017 a Cloud SQL per SQL Server utilizzando la replica degli snapshot.

Strumenti di terze parti

Definisci eventuali attività di esecuzione per lo strumento di terze parti che hai scelto. Ad esempio, se decidi di utilizzare Striim, devi creare app nel tuo spazio dei nomi e configurare il lettore CDC per connetterti all'istanza Amazon. Per maggiori dettagli, consulta la sezione Configurazione di SQL Server nella documentazione di Striim.

Definire scenari di riserva

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.

Il fallback 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 imposta una tempistica per tutte le attività di esecuzione della migrazione. Eseguire un simulacro della migrazione consente di raccogliere informazioni sui tempi previsti per ogni 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 periodo di 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 comprendere le possibili conseguenze. La mancanza di un piano di riserva può comportare un impegno imprevisto e causare interruzioni evitabili nel processo di migrazione.

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

Fallback semplice

In questa strategia di riserva, le applicazioni tornano all'istanza del database di origine originale. 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 nell'istanza del database di destinazione, puoi importarli nel sistema di database di origine iniziale in un secondo momento, soprattutto se i carichi di lavoro non dipendono da un'ora specifica di creazione dei record o da 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. Puoi replicare le scritture sul nuovo database di destinazione in una terza istanza di database a tua scelta. Puoi indirizzare le tue applicazioni a questo terzo database, che si connette al server ed esegue query di sola lettura quando il server non è disponibile. Puoi utilizzare qualsiasi meccanismo di replica, a seconda delle tue esigenze. Il vantaggio di questo approccio è che può essere testato completamente end-to-end.

Adotta questo approccio quando vuoi essere sempre coperto da un piano di riserva o quando devi eliminare il database di origine iniziale poco dopo il passaggio alla produzione.

Scritture duplicate

Se scegli una strategia di migrazione dei microservizi di accesso ai dati Y (scrittura e lettura), questo piano di riserva è già impostato. 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 iniziali del database di origine sia in quelle di destinazione, in modo da poter eseguire un passaggio graduale alla produzione fino a quando non utilizzi solo le istanze del database di destinazione. In caso di problemi, puoi ricollegare le applicazioni all'origine iniziale senza tempi di riposo. 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.

Eseguire test e convalida

Gli obiettivi di questo passaggio sono 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 fattori chiave di successo, che sono soggettivi alla tua migrazione. Di seguito sono riportati alcuni esempi di fattori soggettivi:

  • Di quali dati eseguire la migrazione. Per alcuni workload, potrebbe non essere necessario eseguire la migrazione di tutti i dati. Potresti non voler eseguire la migrazione di dati già aggregati, ridondanti, archiviati o vecchi. Puoi archiviare i dati in un bucket Cloud Storagee come backup.
  • Una percentuale accettabile di perdita di dati. Ciò vale in particolare per i dati utilizzati per i carichi di lavoro di analisi, in cui la perdita di parte dei dati non influisce sulle tendenze generali o sul rendimento 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 le configurazioni convenzionali basate su server, utilizza le misurazioni pertinenti osservate durante i picchi di carico. Per i modelli di capacità delle risorse flessibili come Aurora Serverless, ti consigliamo di esaminare i dati delle metriche storiche per osservare le tue esigenze di scalabilità.

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

  • HammerDB: uno strumento open source per il benchmarking e i test di carico dei database. Supporta carichi di lavoro transazionali e di analisi complessi, basati su standard di settore, su più motori di database (sia TPROC-C che TPROC-H). HammerDB ha una documentazione dettagliata e una vasta community di utenti. Puoi condividere e confrontare i risultati in diversi motori di database e configurazioni di archiviazione. Per ulteriori informazioni, consulta Test di carico di SQL Server tramite HammerDB e Eseguire il benchmark delle prestazioni di Amazon RDS SQL Server tramite HammerDB.
  • Strumento di benchmark DBT2: benchmarking specializzato per MySQL. Un insieme di kit di carichi di lavoro del database simula un'applicazione per un'azienda che possiede warehouse e prevede una combinazione di transazioni di lettura e scrittura. Utilizza questo strumento se vuoi utilizzare un test di carico OLTP (Online Transaction Processing) predefinito.
  • 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 diversi 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 complesse e vuoi eseguire test automatici e integrarli con la tua procedura di integrazione e distribuzione continua.

Per eseguire un test end-to-end, inclusi i test del piano di migrazione, esegui sempre un'esercitazione di prova della migrazione. Un dry run esegue la migrazione del database nell'ambito completo senza cambiare i carichi di lavoro di produzione e offre i seguenti vantaggi:

  • Ti consente di assicurarti che la migrazione di tutti gli oggetti e le configurazioni venga eseguita correttamente.
  • Ti aiuta a definire ed eseguire i casi di test di migrazione.
  • Offre informazioni sul tempo necessario per la migrazione effettiva, in modo da poter calibrare le tempistiche.
  • 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.

Il test dei dati può essere eseguito su un piccolo insieme di database di cui è prevista la migrazione o sull'intero insieme. 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, devi disporre dell'accesso ai database di origine e di destinazione ed eseguire le seguenti attività:

  • Confronta 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.
  • Esegui 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. Questi test includono sia la lettura sia la scrittura dei dati nei database di destinazione tramite le applicazioni in modo che i carichi di lavoro supportino completamente i dati di cui è stata eseguita la migrazione 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 casi di test automatici è adattata per essere eseguita su applicazioni trasferite.

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

Strumento di convalida dei dati

Per eseguire la convalida dei dati, ti consigliamo di utilizzare lo strumento di convalida dei dati (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 DVT può contribuire a semplificare la procedura di convalida dei dati offrendo funzioni di convalida personalizzate e su 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 (incluse "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à per supportare il trasferimento da un sistema all'altro.

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

  • Informa i team coinvolti ogni volta che inizia e termina un passaggio del piano.
  • Se uno dei passaggi richiede più tempo del previsto, confronta il tempo trascorso con il tempo massimo allocato per quel passaggio. In questi casi, emetti aggiornamenti intermedi regolari per i team coinvolti.
  • Se l'intervallo di tempo è superiore al tempo massimo riservato per ogni passaggio del piano, valuta la possibilità di eseguire il rollback.
  • Prendi decisioni di tipo "go or no-go" per ogni passaggio del piano di migrazione e di transizione.
  • Valuta le azioni di rollback o gli scenari alternativi per ciascuno dei passaggi.

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 riposo nei carichi di lavoro, il passaggio alla migrazione inizia interrompendo le scritture nel database di origine.

Per le migrazioni con replica continua, in genere nella procedura di passaggio al nuovo sistema vengono eseguiti i seguenti passaggi di alto livello:

  • Interrompi la scrittura nel database di origine.
  • Svuotare la sorgente.
  • Interrompi il processo di replica.
  • Esegui il deployment delle applicazioni che rimandano 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 soddisfa i tuoi criteri, puoi eseguire il passaggio al nuovo sistema a livello di applicazione. Esegui il deployment dei carichi di lavoro sottoposti a refactoring per utilizzare la nuova istanza di destinazione. Esegui il deployment delle versioni delle applicazioni che fanno riferimento alla nuova istanza di database di destinazione. I deployment possono essere eseguiti tramite aggiornamenti in sequenza, release graduali o utilizzando un pattern di deployment blu/verde. Potrebbe verificarsi un certo tempo di riposo dell'applicazione.

Segui le best practice per il passaggio alla produzione:

  • Monitora le applicazioni che funzionano con il database di destinazione dopo il passaggio.
  • Definisci un periodo di tempo di monitoraggio per valutare se è necessario o meno implementare il piano di riserva.
  • Tieni presente che l'istanza Cloud SQL o AlloyDB per PostgreSQL potrebbe richiedere un riavvio se modifichi alcuni flag di database.
  • Tieni presente che lo sforzo necessario per eseguire il rollback della migrazione potrebbe essere maggiore rispetto alla risoluzione dei problemi che si verificano nell'ambiente di destinazione.

Ripulisci l'ambiente di origine e configura l'istanza Cloud SQL

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. In alcuni casi, i backup potrebbero essere richiesti anche per la conformità ad alcune normative relative ai dati.

  • Raccogli le impostazioni dei parametri del database dell'istanza di origine. In alternativa, controlla che corrispondano a quelli raccolti nella fase di compilazione dell'inventario. Modifica i parametri dell'istanza di destinazione in modo che corrispondano a quelli dell'istanza di origine.

  • Raccogli le statistiche del database dall'istanza di origine e confrontale con quelle dell'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, devono essere eseguite le seguenti configurazioni critiche per le istanze Cloud SQL:

  • Configura un periodo di manutenzione per l'istanza principale per controllare quando possono verificarsi aggiornamenti che causano interruzioni.
  • 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 di amministrazione prima del completamento dell'operazione precedente.

Per ulteriori informazioni, consulta le seguenti risorse:

Ottimizzare l'ambiente dopo la migrazione

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

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

Ripeti questa sequenza finché non raggiungi i tuoi obiettivi di ottimizzazione.

Per ulteriori informazioni sull'ottimizzazione dell'ambiente Google Cloud, consulta Esegui la migrazione a Google Cloud: ottimizza l'ambiente e Procedura di ottimizzazione delle prestazioni.

Stabilisci i requisiti di ottimizzazione

Esamina i seguenti requisiti di ottimizzazione per il tuo ambiente Google Cloud e scegli quelli più adatti ai tuoi carichi di lavoro.

Aumentare l'affidabilità e la disponibilità del 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à, considera quanto segue:

  • In caso di carichi di lavoro incentrati sulla 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 workload meno critici, i backup automatici e on demand possono essere sufficienti.
  • Per evitare la rimozione accidentale delle istanze, utilizza la protezione dall'eliminazione delle istanze.
  • Abilita il recupero point-in-time (PITR) per la tua istanza Cloud SQL per SQL Server.
  • Automatizza i backup dei database SQL utilizzando piani di manutenzione.

Aumentare l'efficienza in termini di costi dell'infrastruttura del database

Per avere un impatto economico positivo, i carichi di lavoro devono utilizzare in modo efficiente le risorse e i servizi disponibili. 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, abilita gli aumenti automatici dello spazio di archiviazione. Tuttavia, assicurati di configurare le istanze in modo che abbiano un po' di buffer nei periodi di picco dei carichi di lavoro. Ricorda che i carichi di lavoro del database 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à.
    • Cloud Monitoring 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 configurazioni di alta disponibilità o di ripristino di emergenza e rimuovile dall'infrastruttura.

  • Rimuovi tabelle e 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.

    • Per la maggior parte dei casi d'uso, l'unità SSD è la scelta più efficiente e conveniente.
    • 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 di risorse prevedibili.

  • Utilizza Active Assist 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.

Per ridurre i costi di licenza, in particolare per Cloud SQL per SQL Server, tieni conto di quanto segue:

  • Esegui la migrazione a SQL Server Standard Edition, se gli SLA soddisfano i tuoi requisiti.
  • Disattiva il multi-threading simultaneo (SMT) e aggiungi il 25% di core in più. I core aggiuntivi potrebbero compensare qualsiasi impatto sulle prestazioni derivante dalla disattivazione di SMT. Questa strategia può contribuire a ridurre i costi delle licenze, ma potrebbe influire sulle prestazioni dell'istanza. Ti consigliamo di eseguire test di carico sull'istanza per assicurarti che gli SLA non siano interessati.
  • Valuta la possibilità di eseguire una migrazione eterogenea da Cloud SQL per SQL Server a Cloud SQL per PostgreSQL o AlloyDB per PostgreSQL, a seconda del tuo carico di lavoro.

Aumentare le prestazioni dell'infrastruttura del database

I problemi di prestazioni minori relativi al database possono spesso influire sull'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 i carichi di lavoro ad alta intensità di prestazioni, assicurati che l'istanza abbia almeno 60 GB di memoria.
    • Per inserimenti, aggiornamenti o eliminazioni del database lenti, controlla le posizioni dello scrittore e del database. L'invio di dati su lunghe distanze introduce latenza.

  • Migliora le prestazioni delle query utilizzando la dashboard Query Insights predefinita in Cloud Monitoring (o funzionalità integrate simili del motore del database). Identifica i comandi più costosi e prova a ottimizzarli.

  • Evita che i file del database diventino inutilmente grandi. Imposta autogrow in MB anziché come percentuale, utilizzando incrementi appropriati al requisito.

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

  • Evita la frammentazione dei dati e degli indici. Imposta una pianificazione per ricostruire gli indici in SQL Server, in base alla frequenza con cui i dati cambiano.

  • Modifica le impostazioni specifiche del motore SQL Server in modo che funzionino in modo ottimale per Cloud SQL.

  • Per la manutenzione di indici e statistiche, consulta SQL Server Maintenance Solution.

  • Aggiorna regolarmente le statistiche su Cloud SQL per SQL Server.

  • Valuta la possibilità di eseguire operazioni ETL su una replica di lettura, in quanto potrebbero influire sulla cache dell'istanza.

Per ulteriori informazioni su come aumentare le prestazioni, consulta Prestazioni in "Risolvi i problemi" e Cloud SQL - Analisi delle prestazioni di SQL Server e ottimizzazione delle query.

Aumentare le funzionalità di osservabilità del database

La diagnosi e la risoluzione dei problemi nelle applicazioni che si connettono alle istanze di database può essere complessa e richiedere molto tempo. Per questo motivo, è essenziale avere un luogo centralizzato in cui tutti i membri del team possano vedere cosa succede a livello di database e istanza. Puoi monitorare le istanze Cloud SQL nei seguenti modi:

  • Cloud SQL utilizza agenti personalizzati della memoria integrati per raccogliere la telemetria delle query.

    • 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, tra cui una dashboard di monitoraggio di Cloud SQL.
    • Puoi creare dashboard personalizzate che ti aiutano a monitorare le metriche e a configurare criteri di avviso in modo da ricevere notifiche tempestive.
    • In alternativa, puoi utilizzare soluzioni di monitoraggio di terze parti integrate con Google Cloud, come Datadog e Splunk.

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

  • Cloud Trace raccoglie i dati di latenza e i piani di query eseguiti dalle applicazioni per aiutarti a monitorare il modo in cui le richieste si propagano nell'applicazione.

  • Database Center offre una panoramica centralizzata del parco risorse di database con l'aiuto dell'AI. Puoi monitorare lo stato dei tuoi database, la configurazione della disponibilità, la protezione dei dati, la sicurezza e la conformità alle normative di settore.

  • Visualizza e esegui query sui log per la tua istanza Cloud SQL.

  • Osserva lo stato dei tuoi database per migliorare le prestazioni del tuo ambiente e risolvere eventuali problemi.

Best practice generali e linee guida operative di Cloud SQL

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

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

  • Se hai istanze di grandi dimensioni, ti consigliamo di suddividerle in istanze più piccole, se possibile.
  • Configura lo spazio di archiviazione per la manutenzione di database critici. 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, punta a avere meno di 10.000 tabelle per istanza.
  • Scegli le dimensioni appropriate per le istanze in modo da tenere conto della conservazione dei log delle transazioni (binari), in particolare per le istanze con attività di scrittura elevata.

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 sono state eseguite per l'ultima volta queste operazioni di manutenzione, soprattutto sugli oggetti interessati (tabelle, indici). Scopri se è stata rilevata 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? Il tuo modello di dati è adatto al tipo di carico di lavoro? Esamina le query lente e i relativi piani di esecuzione. Utilizzano gli indici disponibili? Controlla se sono presenti scansioni dell'indice, blocchi e attese su altre risorse. Valuta la possibilità di aggiungere indici per supportare le tue query critiche. Elimina gli indici e le chiavi esterne non critici. Valuta la possibilità di riscrivere query e unioni complesse. Il tempo necessario per risolvere il problema dipende dall'esperienza e dalla disponibilità del team e può variare da alcune ore a diversi giorni.

Esegui lo scale out delle letture: valuta la possibilità di avere 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. Instradare le query di lettura dalle tue applicazioni a una replica di lettura migliora le prestazioni complessive del tuo 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 molto maggiore rispetto alla messa a punto e all'ottimizzazione del database e potrebbe comportare una migrazione dei dati, ma può essere una soluzione a lungo termine. A volte, una progettazione scadente del modello dei dati può causare problemi di prestazioni, che possono essere compensati parzialmente dall'aumento verticale. Tuttavia, un modello dei dati adeguato è una soluzione a lungo termine. Valuta la possibilità di partizionare le tabelle. Archivia i dati che non sono più 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 che prevede la riprogettazione del database e delle applicazioni in un modo specifico ed esecuzione della 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 sull'oggetto. Questa opzione ti consente di eseguire il scaling orizzontale sia delle scritture che delle letture. Tuttavia, aumenta 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 SQL Server, tieni conto delle seguenti best practice:

  • Per aggiornare le impostazioni di SQL Server per ottenere prestazioni ottimali con Cloud SQL, consulta Impostazioni di SQL Server.
  • Determina la capacità del sottosistema I/O prima di eseguire il deployment di SQL Server.

  • Se hai istanze di grandi dimensioni, suddividile in istanze più piccole, se possibile:

    • Una dimensione del disco di almeno 4 TB offre una maggiore velocità in termini di throughput e IOPS.
    • Un numero maggiore di vCPU offre più IOPS e una maggiore velocità effettiva. Quando utilizzi un numero maggiore di vCPU, monitora le attese del database per il parallelismo, che potrebbero anche aumentare.

  • Disattiva SMT se il rendimento è ridotto in alcune situazioni. Ad esempio, se un'applicazione esegue thread che diventano un collo di bottiglia e l'architettura della CPU non li gestisce in modo efficace.

  • Imposta una pianificazione per riorganizzare o ricostruire gli indici, a seconda della frequenza con cui cambiano i dati.

  • Imposta un fattore di riempimento appropriato per ridurre la frammentazione. Monitora SQL Server per verificare la presenza di indici mancanti che potrebbero offrire prestazioni migliori.

  • Evita che i file del database diventino inutilmente grandi. Imposta autogrow in MB anziché come percentuale, utilizzando incrementi appropriati al requisito. Inoltre, gestisci in modo proattivo la crescita del database prima che venga raggiunta la soglia di autogrow.

  • Per scalare automaticamente la capacità di archiviazione, abilita gli aumenti automatici dello spazio di archiviazione. Cloud SQL può aggiungere spazio di archiviazione se il database e l'istanza rimangono senza spazio.

  • Assicurati di conoscere i requisiti relativi alle impostazioni internazionali, all'ordine di ordinamento, alle lettere e alla sensibilità agli accenti dei dati con cui stai lavorando. Quando selezioni la concatenazione per il server, il database, la colonna o l'espressione, assegni determinate caratteristiche ai dati.

  • I join hash ricorsivi o le uscite di emergenza hash causano una riduzione delle prestazioni in un server. Se in una traccia vengono visualizzati molti eventi di avviso relativi all'hash, aggiorna le statistiche sulle colonne che vengono unite. Per ulteriori informazioni, consulta Hash Warning Event Class.

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

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: