Migrazione da AWS a Google Cloud: migrazione 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. È 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 omogenea dei database, ovvero una 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 diviso in quattro fasi.

Potresti eseguire la migrazione dal tuo ambiente di origine a Google Cloud in una serie di iterazioni, ad esempio potresti migrare prima alcuni carichi di lavoro e altri in un secondo momento. Per ogni iterazione di migrazione distinta, segui le fasi del framework di migrazione generale:

  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 carichi di lavoro e dei dati in 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 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 la buona riuscita 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 i tuoi 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: Esegui la migrazione a Google Cloud: valuta e individua i tuoi 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 del disco e alla velocità effettiva, IOPS e numero di vCPU. Le migrazioni potrebbero essere difficoltose o non riuscite a causa di errori delle istanze 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 decidi l'istanza Cloud SQL, mantieni 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: valutare e individuare i carichi di lavoro, e integrare le informazioni in tale documento.

Crea un inventario delle tue istanze Amazon RDS

Per definire l'ambito della migrazione, devi creare un inventario e raccogliere informazioni sulle tue istanze Amazon RDS. Idealmente, il processo dovrebbe essere automatizzata, perché gli approcci manuali sono soggetti a errori e possono ipotesi errate.

Amazon RDS e Cloud SQL potrebbero non avere funzionalità simili, ad esempio specifiche o operazioni. Alcune funzionalità potrebbero essere implementate in modo diverso o non 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, esistono differenze anche 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 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 il panorama delle applicazioni e dei database, compresa l'idoneità tecnica per migrazione dei database su 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 migVisor, vedi il Panoramica di Vision.

migVisor è in grado di identificare artefatti e funzionalità di database proprietarie incompatibili che possono causare l'impostazione predefinita della migrazione e possono rimandare a soluzioni alternative. migVisor può consigliano inoltre una soluzione Google Cloud di destinazione, tra cui il dimensionamento iniziale e dell'architettura.

L'output di 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 del motore del database e versione, CPU e dimensioni della memoria), nonché dettagli sulla topologia del database, criteri di backup, impostazioni dei parametri e 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 di database 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, 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 influiscono sulla strategia e sugli 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 luoghi fisici?
  • Esistono dati che possono essere compressi e archiviati o dati che non richiedono affatto la migrazione?

Per definire l'ambito della migrazione, devi decidere quali dati conservare e 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, vecchie tabelle di logging o di archiviazione dei dati 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 effettuare misurazioni sull'ambiente di origine, per poter Valutare il successo 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à:

  • Definisci e applica i criteri di sicurezza per le tue istanze: per Ad esempio, potrebbe essere necessario sostituire Amazon Security Groups. 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. 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.
  • 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, 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 la altre attività della fase di valutazione, come descritto Esegui la migrazione a Google Cloud: valuta e individua i tuoi carichi di lavoro.

Pianifica e costruisci le tue 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 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 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.

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 utilizzare soluzioni di monitoraggio di terze parti integrate con come Datadog e Splunk. Per ulteriori informazioni, consulta Informazioni sull'osservabilità del database.

Esegui la migrazione delle istanze Amazon RDS per SQL Server in Cloud SQL per SQL Server

Per eseguire la migrazione delle istanze, segui questi passaggi:

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

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

  3. Definire il piano e le tempistiche per ogni migrazione del database, tra cui 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 fallback per ogni attività di esecuzione.

  7. Esegui test e convalida, che possono essere effettuati in una fase temporanea separata completamente gestito di Google Cloud.

  8. Esegui la migrazione.

  9. Esegui la migrazione completa della 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, avrai informazioni sufficienti per valutare e selezionare uno dei le seguenti strategie di migrazione più adatte al tuo caso d'uso database:

  • Manutenzione pianificata (chiamata anche migrazione una tantum): questo approccio è ideale se puoi permetterti i 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 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 operazioni 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. È necessario anche un ulteriore impegno necessario per il refactoring delle applicazioni che si connettono al tuo database di Compute Engine. Prendi in considerazione 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.
    • 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 quando si decide la strategia di migrazione per un singolo database:

Diagramma di flusso che ti consente di 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, passa al punto decisionale successivo.

  • Puoi permetterti il tempo di inattività rappresentato dalla finestra di migrazione mentre eseguire 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 le 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 interrotta e tutte le letture e le scritture vengono eseguite sull'istanza di destinazione. Il passaggio quando entrambe le istanze sono sincronizzate significa nessuna perdita di dati e un tempo di riposo minimo.

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

Per le configurazioni di migrazione che non prevedono tempi di inattività delle applicazioni è necessario una configurazione 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, i processi di replica implicano sulle istanze di origine e le applicazioni potrebbero essere interessate della replicazione. 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 possono aumentare il tempo di inattività:

  • Le query del database possono richiedere alcuni secondi. Al momento della 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.
  • Applicazioni arrestate nell'origine e riavviate in Google Cloud potrebbe verificarsi un leggero ritardo prima che la connessione a Google Cloud dell'istanza del database.
  • Le route di rete alle applicazioni devono essere reindirizzate. 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 riposo e l'impatto:

  • Trova un periodo di tempo in cui il tempo di riposo abbia un impatto minimo sul tuo carichi di lavoro con scale out impegnativi. ad esempio al di fuori del normale orario di lavoro, durante i fine settimana e altre finestre di manutenzione pianificate.
  • Identifica le parti dei tuoi carichi di lavoro che possono essere sottoposti a migrazione la 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 sul database di destinazione, considera con l'implementazione di 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 tue applicazioni per supportare un impatto minimo della migrazione. Ad esempio, puoi adattare le applicazioni in modo che scrivano sia all'origine che di destinazione, quindi implementano 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, ciascuno ottimizzato per determinati casi d'uso della migrazione. Ecco alcuni casi d'uso:

  • 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à di utilizzare i servizi gestiti per la migrazione.

Per garantire una migrazione e una migrazione senza interruzioni, puoi utilizzare il deployment delle applicazioni pattern, 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 gestiti offrono i seguenti vantaggi:

  • Riduci al minimo il tempo di inattività: i servizi utilizzano la replica integrata funzionalità dei motori del database, se disponibili, ed eseguire 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.

  • 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 successive descrivono i suggerimenti degli strumenti di migrazione, che dipendono la 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 è accettabile un tempo di inattività significativo e i database di origine vengono è relativamente statico, puoi usare il backup e ripristino integrati nel motore del database le funzionalità di machine learning.

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 di facile utilizzo. Questo approccio è adatto a qualsiasi dimensione di database di solito è più efficace di altri strumenti per istanze di grandi dimensioni.

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.

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 sottoposto a striping (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 dei dati dall'istanza di origine a quella di destinazione, utilizza PowerShell script 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 pianificate

L'utilizzo di altri approcci può fornire un controllo e una flessibilità maggiori il processo di migrazione per la 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 la denormalizzazione dei dati di origine.
  • Scegli le strutture di cui vuoi eseguire la migrazione e quali lasciare indietro. Potresti decidere di estrarre solo un sottoinsieme delle tabelle in file flat per l'importazione.
  • Scegli di escludere i dati in base a dominio, origine, età o altri criteri personalizzati. Ad esempio, puoi escludere i dati che raggiungono un'età e archiviarla in file o nel backup finale dell'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.
  • Consolidare più istanze o database in un'unica istanza oppure per mitigare i costi operativi e risolvere i problemi di scalabilità. Ad esempio, potresti voler cambiare il tuo approccio di un'istanza, un database o uno schema per cliente una struttura di database ottimizzata.

Altri approcci includono:

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

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

  • Utilizza i comandi Procedura guidata di importazione ed esportazione di SQL Server da Microsoft: questo strumento utilizza l'integrazione di SQL Server Services (SSIS) e consente di importare i dati da varie origini, come altre o file flat.

  • Utilizza i comandi Procedura guidata di generazione e pubblicazione degli script di SQL Server e 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 in parte.
    • L'utilità bcp consente di creare script dei dati ed esportarli in file.

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

    • Con questo approccio, ripristini il backup di SQL Server dell'istanza RDS a un'altra istanza autonoma di SQL Server su Compute Engine. Utilizza quindi la replica degli snapshot per eseguire la migrazione a Cloud SQL per SQL Server.
    • La generazione di snapshot mantiene blocchi sulle tabelle di origine, che possono dei carichi di lavoro.
    • La replica degli snapshot potrebbe introdurre carichi aggiuntivi sul tuo server Amazon RDS.
    • Tuttavia, puoi scegliere per quali oggetti eseguire la migrazione replicati, che offre flessibilità.
    • Per maggiori dettagli, vedi Migrazione dei dati da SQL Server 2017 a Cloud SQL per SQL Server utilizzando la replica degli snapshot.

Strumenti per la migrazione della 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 i servizi di migrazione gestiti?

    • Se sì, vai alla decisione successiva. Se puoi permetterti un po' tempi di inattività minimi e non richiedono trasformazione dei dati o tempo reale consigliamo la sincronizzazione con Database Migration Service. Altrimenti, esplora il terzo le opzioni del gruppo.
    • 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.

  • La replica integrata specifica del motore del database è supportata?

    • 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 con replica continua, nonché le relative limitazioni e best practice.

Database Migration Service per la migrazione della 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. I nostri suggerimenti Database Migration Service per situazioni con le seguenti circostanze:

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

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

  • Il tempo di inattività dipende dalla frequenza del log delle transazioni backup.
  • I backup non includono gli accessi, le autorizzazioni o il server , poiché sono 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. Replica integrata da Amazon RDS L'opzione 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, vedi 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 Sì (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 poi ristrutturate e implementate gradualmente per utilizzare l'istanza di destinazione.

  • Implementare funzioni che eseguono query periodiche sui dati nell'origine istanza, filtrare solo i nuovi dati e scrivere i dati in formato 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.
    • CDC (Change Data Capture) possono aiutarti a eseguire una migrazione della replica quasi in tempo reale.
    • Puoi trasmettere i flussi CDC in un data lake Amazon S3 in formato Parquet, mediante 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. Se preferisci utilizzare un servizio di migrazione gestito, e devi assicurarti che il database di destinazione sia sempre quasi in tempo reale con l'origine o se hai bisogno di trasformazioni più complesse come la pulizia, la ristrutturazione e l'adattamento 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 no-code.
    • 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, 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 un'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 con Grafana e Prometheus.
    • Nessun supporto per la replica batch incrementale.

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 eventuali modifiche 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.

Definire il piano di migrazione e le tempistiche

Per una migrazione del database e una migrazione completa della produzione, consigliamo di eseguire devi preparare un piano di migrazione ben definito e completo. 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. 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. In genere, le migrazioni pianificate vengono eseguite senza problemi, ma possono comunque verificarsi problemi imprevisti. Ti consigliamo di eseguire sempre un rollback e il piano d'azione. 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 nel TDD:

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

Matrice RACI

Alcuni progetti di migrazione richiedono una matrice RACI, ovvero un documento di gestione del progetto comune che definisce le persone o i gruppi responsabili delle attività e dei risultati 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 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 dipende in genere dalle dimensioni del database, ma sono anche altri aspetti da considerare, come la complessità della logica di business, utilizzo e disponibilità dei team.

Un piano T-Minus potrebbe avere il seguente aspetto:

Data Fase Categoria Tasks Ruolo T-meno Stato
1/11/2023 Pre-migrazione Test Crea 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 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 Creare profili di connessione Ingegnere della migrazione cloud -3 Completa
19/11/2023 Migrazione Configurare DMS Crea e avvia i job di migrazione Ingegnere della migrazione cloud -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 Cutover DMS Promuovi 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 dell'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 di 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 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 a creare conoscenza e fiducia nel processo e negli strumenti di migrazione. Puoi anche rilevare eventuali difetti del processo nelle prime fasi della migrazione nel suo complesso programmazione.

Se devi eseguire la migrazione di più database, le tempistiche 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.

Attività di migrazione del database parallele.

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

Definisci le attività di preparazione

Le attività di preparazione sono tutte le attività che devi completare soddisfare i prerequisiti per la 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 categorizzate come segue:

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

Preparazione e prerequisiti dell'istanza Amazon RDS

Considera le seguenti attività di configurazione comuni e di prerequisiti:

  • 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.

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

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

Preparazione e prerequisiti del database di origine

  • 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 del carico di lavoro delle prestazioni. Quanto tempo richiedono in media query o transazioni importanti? Per quanto tempo 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 le dimensioni e le specifiche del job Cloud SQL di destinazione in modo che corrisponda all'origine per esigenze di prestazioni simili. Paga speciale dimensioni del disco e velocità effettiva, IOPS e numero di vCPU. Sbagliato il dimensionamento ottimale può comportare lunghi tempi di migrazione, problemi di prestazioni e problemi di prestazioni delle applicazioni.

Assicurati che la destinazione sia la taglia corretta. È importante notare che Le opzioni di configurazione di Amazon RDS possono variare rispetto a Cloud SQL. Nella se Cloud SQL non soddisfa i requisiti, valuta le opzioni che includono 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. 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 l'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 il 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 del servizio di migrazione del database, 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 Database Migration Service, consulta Archivia 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 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 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 anche essere codificate utilizzando il TQL (Tungsten Query Language) linguaggio di programmazione. Con una dashboard di convalida dei dati, puoi ottenere rappresentazione dei dati gestiti dall'applicazione Striim.

Puoi ritirare le risorse che collegano i tuoi server dell'ambiente Google Cloud al termine e convalidato la migrazione.

Definisci le attività di esecuzione

Le attività di esecuzione implementano il lavoro di migrazione stesso. Le attività dipendono di migrazione prescelto, come descritto nelle sottosezioni riportate di seguito.

Backup del motore del database integrato

Per ulteriori informazioni e istruzioni per i backup specifici dei database, vedi Importare i dati da un file BAK a Cloud SQL per SQL Server e Esportazione di dati da RDS per SQL Server. Per ulteriori informazioni su come automatizzare i caricamenti dei file di log delle transazioni, consulta Pianifica 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 nel 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 questo processo, Pianifica 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 che l'origine e la destinazione vengano sincronizzate, ovvero quando viene elaborato il backup del log delle transazioni finali.
  • Arresta la replica in corso e promuovi il job di migrazione. di un job di migrazione, l'istanza Cloud SQL di destinazione disconnesso dall'istanza del database di origine, quindi viene promosso un'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 Migrazione dei dati da SQL Server 2017 a Cloud SQL per SQL Server utilizzando la replica degli snapshot.

Strumenti di terze parti

Definisci le attività di esecuzione per lo strumento di terze parti 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, vedi Configurazione di SQL Server nella documentazione di Striim.

Definire scenari di riserva

Definisci le attività di fallback per ogni attività di esecuzione della migrazione, a scopo di salvaguardia per risolvere problemi imprevisti durante il processo di migrazione. La 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 tempo di inattività rappresentato dalla finestra di migrazione completa. 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 implementare un piano di riserva, ricorda che deve essere trattato come un database completo migrazione, incluse pianificazione e test.

Se scegli di non avere un piano di riserva, assicurati di comprendere le possibili conseguenze. L'assenza di un piano di riserva può comportare sforzi imprevisti che possono 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.

Semplicità di riserva

In questa strategia di riserva, le applicazioni tornano all'istanza del database di origine originale. Adotta questa strategia se puoi permetterti tempi di inattività quando oppure se non hai bisogno dell'impegno delle transazioni sul nuovo target di un sistema operativo completo.

Se hai bisogno di tutti i dati scritti nel tuo database di destinazione e puoi permetterti un tempo di inattività limitato, puoi considerare di interrompere le scritture sul database di destinazione eseguendo backup integrati e ripristinandoli sull'istanza di origine, e poi riconnettere le applicazioni al database di origine iniziale in esecuzione in un'istanza Compute Engine. 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 di creazione specifica 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 principale svantaggio è che non puoi testare il flusso di replica finché non esegui il passaggio istanza del database di destinazione, perciò non consente il test end-to-end ha un piccolo periodo senza 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 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 migrazione di microservizi Y (scrittura e lettura) o accesso ai dati questa strategia di riserva è già impostata. Questa strategia è più complicata, perché è necessario eseguire il refactoring delle applicazioni o sviluppare strumenti che si connettano delle 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 sorgente iniziale e il meccanismo di scrittura duplicato quando si considera e la migrazione è stata eseguita senza riscontrare problemi.

Consigliamo questo approccio quando è fondamentale non avere tempi di inattività per la migrazione, un fallback affidabile e quando si dispone di tempo e risorse il refactoring delle applicazioni.

Eseguire 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 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 carichi di lavoro, potrebbe non essere necessario eseguire la migrazione di tutti i dati. Se non vuoi eseguire la migrazione di dati già aggregati, ridondanti, archiviati o obsoleti. 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'origine dell'ambiente di rete e confrontarlo con l'ambiente di destinazione dopo la migrazione.
  • Criteri delle prestazioni. Alcune transazioni aziendali possono essere più lente dell'ambiente target, ma il tempo di elaborazione è ancora all'interno di le aspettative.

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.

È possibile usare i seguenti strumenti per i test, la convalida benchmarking:

  • HammerDB: uno strumento open source per il benchmarking e i test di carico dei database. 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 confrontare i risultati tra 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: 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 open source di test delle unità utilizzato per testare i database relazionali e interazioni in Java. La configurazione e l'utilizzo sono semplici e supporta più motori di database (MySQL, PostgreSQL, SQL Server e altri). Tuttavia, a volte l'esecuzione del test può essere lenta, a seconda delle dimensioni e la complessità del database. Ti consigliamo questo strumento quando la semplicità è importanti.
  • 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 creare test funzionalità e test basati sui dati, controllo della versione e risultato dei test i report. 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 i casi di test di migrazione.
  • Offre insight sul tempo necessario per la migrazione effettiva, 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 è stata eseguita la migrazione mediante lo stesso strumento, soprattutto se si tratta di una migrazione gestita. completamente gestito di Google Cloud.

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

  • Confronta gli schemi di origine e di destinazione. Controllare se tutte le tabelle e tutti gli eseguibili esistono. 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 automatizzati 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 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 di Cloud Run e Cloud Run per l'attivazione e l'orchestrazione basate su eventi.

La TVP 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.

Eseguire la migrazione

Le attività di migrazione includono le attività per supportare il trasferimento da un sistema all'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 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.
  • 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.

Per eseguire la migrazione, segui le attività di esecuzione definite, e consulta la documentazione relativa allo strumento di migrazione selezionato.

Esegui il passaggio alla produzione

Il processo generale di migrazione completa può variare a seconda di migrazione. 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 della replica continua, in genere si esegue quanto segue passaggi del processo di migrazione completa:

  • Interrompi la scrittura sul database di origine.
  • Svuoti la fonte.
  • Arresta il processo di replica.
  • Esegui il deployment delle applicazioni che rimandano al nuovo database di destinazione.

Dopo aver eseguito la migrazione dei dati con lo strumento di migrazione scelto, convalidare 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 il nuovo 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 temporanee o mediante 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 l'implementazione.
  • Definisci un periodo di tempo di monitoraggio per valutare se è necessario o meno implementare il piano di riserva.
  • Tieni presente che la tua istanza Cloud SQL o AlloyDB per PostgreSQL potrebbe essere necessario riavviare se modifichi alcuni flag del database.
  • Tieni presente che l'impegno per il rollback della migrazione potrebbe essere maggiore piuttosto che risolvere i problemi appare 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:

  • Creare 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 del 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 fallback, potresti voler implementare la replica del scrive sull'istanza Cloud SQL per riportarlo al 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 alle istanze di origine precedenti con una perdita di dati minima.

Oltre alla pulizia dell'ambiente di origine, vengono eseguite le seguenti configurazioni critiche per le istanze Cloud SQL, procedi nel seguente modo:

  • 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 il disco è disponibile dello spazio di archiviazione è inferiore al 20%, crea un criterio di avviso basato su metriche di utilizzo del disco.

Non avviare un'operazione di amministrazione prima del completamento dell'operazione precedente.

Per ulteriori informazioni, consulta le seguenti risorse:

Ottimizza 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 la sequenza finché non hai raggiunto gli 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 Google Cloud e scegli quelli che meglio si adattano ai tuoi carichi di lavoro.

Aumentare l'affidabilità e la disponibilità del database

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

  • In caso di carichi di lavoro ad alta intensità di lettura, aggiungi repliche di lettura per ridurre il traffico dall'istanza principale.
  • Per i carichi di lavoro mission critical, usa la configurazione ad alta disponibilità, di failover a livello di regione e una configurazione affidabile per il ripristino di emergenza.
  • 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.
  • 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 risorse e servizi in modo efficiente. Valuta le seguenti opzioni.

  • Fornisci al database la capacità di archiviazione minima richiesta eseguendo seguenti:

    • 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 i carichi di lavoro del database tendono ad aumentare nel tempo.

  • Identifica le risorse potenzialmente sovrastimate:

    • Il dimensionamento ottimale delle istanze Cloud SQL può ridurre costi dell'infrastruttura senza aggiungere ulteriori rischi alla capacità una strategia di gestione aziendale.
    • 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 configurazioni di alta disponibilità o di ripristino di emergenza 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 utilizzo per verificare se è così.

    • 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 prevedibili in termini di risorse.

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

    Per ulteriori informazioni e opzioni, vedi Ottieni di più con meno risorse: ti presentiamo i suggerimenti per l'ottimizzazione dei costi di Cloud SQL con Active Assist.

Per ridurre i costi delle licenze, in particolare per Cloud SQL per SQL Server, valuta la possibilità le seguenti:

  • Esegui la migrazione a SQL Server Standard Edition, se SLA ai tuoi requisiti.
  • Disattiva multi-threading simultaneo (SMT) e aggiungi il 25% di core in più. I core aggiuntivi potrebbero compensare l'eventuale impatto sulle prestazioni derivante dalla disattivazione dell'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.

Aumenta le prestazioni della tua infrastruttura di database

Problemi di prestazioni minori relativi al database spesso hanno il potenziale di influire sull'intera operazione. Per mantenere e aumentare la tua istanza Cloud SQL del rendimento, considera le seguenti linee guida:

  • Se hai un numero elevato di tabelle di database, queste possono influire sull'istanza le prestazioni e la disponibilità e causano la perdita della copertura SLA dell'istanza.

  • 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 lenti dei database, controlla il le posizioni dell'autore e del database; 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). 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é come percentuale, utilizzando incrementi appropriati al requisito.

  • Controlla la posizione del lettore e del database. La latenza influisce sulle prestazioni di lettura delle prestazioni di scrittura.

  • Evita la frammentazione dei dati e dell'indice. Imposta una programmazione per ricreare indicizza in SQL Server, a seconda della frequenza di modifica dei dati.

  • Cambia il Impostazioni specifiche per SQL Server Engine in modo che funzionino in modo ottimale per Cloud SQL.

  • Per la manutenzione degli indici e delle statistiche, consulta Soluzione di manutenzione SQL Server.

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

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

Per ulteriori informazioni sull'aumento del rendimento, consulta Prestazioni in "Diagnostica problemi" e Cloud SQL - Analisi delle prestazioni di SQL Server e ottimizzazione delle query.

Aumentare 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 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 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 lo stato dei tuoi database, la configurazione della disponibilità, la protezione dei dati, la sicurezza e la conformità alle normative di settore.

  • Visualizza ed 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.

Linee guida operative e best practice generali di Cloud SQL

Applica le best practice per Cloud SQL per configurare e ottimizzare il 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. Ensure hai almeno il 20% di spazio disponibile per contenere database critici le operazioni di manutenzione 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 essere in grado di gestire in modo efficiente qualsiasi problema di prestazioni del database che potresti segui queste linee guida finché il problema non verrà risolto:

Fai lo scale up dell'infrastruttura: aumenta le risorse, ad esempio la velocità effettiva del disco, vCPU e RAM). A seconda dell'urgenza, della disponibilità e dell'esperienza del team, scalare verticalmente l'istanza può risolvere la maggior parte dei problemi di prestazioni. In seguito possano effettuare ulteriori accertamenti sulla causa principale del problema in un ambiente di test e valutano 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 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 ottimizzazione e ottimizzazione del database: le tabelle nel tuo database sono? strutturati in modo adeguato? 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 il supporto per le query critiche. Elimina gli indici non critici e le chiavi esterne. 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.

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. 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 necessaria un'ulteriore modifica per connetterti alla replica di lettura.

Riprogettazione dell'architettura 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.

partizionamento orizzontale del database: puoi fare lo scale out delle scritture applicando lo sharding al 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. Hai diviso di database in più istanze più piccole utilizzando un partizionamento specifico criteri. 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 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.
    • Una vCPU maggiore fornisce più IOPS e velocità effettiva. Quando si utilizza un valore superiore vCPU, il database attende il parallelismo, il che potrebbe anche aumentano.

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

  • Imposta una pianificazione per riorganizzare o ricreare gli indici, a seconda di come spesso i dati cambiano.

  • Imposta un fattore di riempimento appropriato per ridurre la frammentazione. Monitora SQL Server per gli 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 lo spazio disponibile.

  • 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 ricorrenti o i salvataggi di hashing causano una riduzione delle prestazioni in un server web. Se in una traccia noti molti eventi di avviso di hashing, aggiorna il valore le statistiche sulle colonne che vengono unite. Per ulteriori informazioni, consulta Hash Warning Event Class.

Per ulteriori dettagli, vedi Best practice generali e Linee guida operative per Cloud SQL per SQL Server.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: