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 offre 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 l'origine è Amazon RDS per SQL Server e la destinazione è in 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:

• Inizia
• Eseguire la migrazione da Amazon EC2 a Compute Engine
• Eseguire la migrazione da Amazon S3 a Cloud Storage
• Eseguire la migrazione da Amazon EKS a GKE
• Migrazione da AWS a Google Cloud: migrazione da Amazon RDS per SQL Server to Cloud SQL per SQL Server (questo documento)

Questa serie presuppone che tu abbia letto e abbia familiarità con i seguenti argomenti documenti:

• Eseguire la migrazione a Google Cloud: per iniziare: descrive il framework generale che seguirai in questa migrazione.
• Eseguire la migrazione a Google Cloud: best practice per la convalida di un piano di migrazione: descrive le modifiche e i miglioramenti potenziali al piano di migrazione.

Il seguente diagramma illustra il percorso del tuo percorso di migrazione. Per di migrazione, la fase di deployment equivale a eseguire una migrazione e il processo di sviluppo.

Puoi eseguire la migrazione da Amazon RDS a Cloud SQL in una serie di iterazioni, Ad esempio, potresti eseguire prima la migrazione di alcune istanze di database e di altre in un secondo momento. Per ogni singola iterazione della migrazione, segui le fasi di migrazione, che è il seguente:

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.

Valuta l'ambiente di origine

Nella fase di valutazione, stabilisci i requisiti e le dipendenze di eseguire la migrazione dell'ambiente di origine in Google Cloud.

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

La fase di valutazione è composta dalle seguenti attività:

1. Crea un inventario completo dei tuoi carichi di lavoro.
2. Cataloga i carichi di lavoro in base alle loro proprietà e dipendenze.
3. Addestra e forma 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 per primi i carichi di lavoro di cui vuoi eseguire la 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 nel documento.

La fase di valutazione del database consente di scegliere la dimensione e le specifiche l'istanza del database Cloud SQL di destinazione che corrisponde 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. Le dimensioni non corrette possono comportare tempi di migrazione lunghi volte, problemi di prestazioni del database, errori del database e o problemi di prestazioni. Quando 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 infrastruttura, archiviazione, autenticazione e sicurezza, replica, backup, alta disponibilità, modello di capacità delle risorse e funzionalità specifica del motore del database integrazioni ed estensioni. 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 da e ti aiuta a definire l'architettura corretta per la migrazione nell'ambiente di destinazione. La raccolta di informazioni sul rendimento è importante aiutare a stimare le esigenze di prestazioni del target di Google Cloud completamente gestito di Google Cloud. I concetti e gli strumenti di benchmarking sono descritti in dettaglio nella Fase di esecuzione di test e convalida del processo di migrazione, ma si applicano anche alla fase di creazione dell'inventario.

Strumenti per i test

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 dimensioni e configurazione suggerimenti per ogni database di origine e crea un costo totale di proprietà (TCO) per server e database.

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

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

migVisor è 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ò consigliamo 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 complete delle implementazioni attuali dei database.
• Report dettagliato sulla complessità della migrazione, basato sui più caratteristiche usate dal tuo database.
• Report finanziario con dettagli sui risparmi sui costi dopo la migrazione e la migrazione costi aggiuntivi e nuovo budget operativo.
• Piano di migrazione graduale per spostare i database e le applicazioni associate con un'interruzione minima dell'attività.

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

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

L'output di valutazione di migVisor ti aiuta a creare un inventario completo del tuo RDS di Compute Engine. Il report include proprietà generiche (versione 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 usare strumenti open source, puoi usare gli script di raccolta dati con o al posto degli strumenti menzionati. Questi script possono aiutarti a raccogliere informazioni informazioni (su carichi di lavoro, caratteristiche, oggetti di database e codice del database) e per creare l'inventario del tuo database. Inoltre, di solito gli script forniscono un database dettagliato una valutazione della migrazione, inclusa una stima delle attività di migrazione.

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

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

Identifica e documenta l'ambito della migrazione e tempi di inattività convenienti

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

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

Per definire l'ambito della migrazione, devi decidere quali dati conservare e quali eseguire la migrazione. Migrazione in corso tutti i database potrebbero 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, potresti decidere di spostare i dati dopo il processo di migrazione, a seconda della strategia e degli strumenti utilizzati.

Stabilisci basi di migrazione dei dati che ti aiutino a confrontare e valutare risultati e impatti. Queste basi sono punti di riferimento che rappresentano lo stato dei dati prima e dopo la migrazione e per aiutarti 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 tuoi dati.
• La durata e il rendimento delle transazioni commerciali più importanti. e processi.

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, per determinare il modo in cui devono essere adattati per facilitare la migrazione. Questi processi sono fondamentali per la preparazione e mantenere l'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 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 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, è possibile che tu stia utilizzando impostazioni di configurazione nei gruppi di parametri Amazon o nei gruppi di opzioni Amazon. Potrebbe essere necessario adattare gli strumenti di provisioning per utilizzare Google Cloud Storage o Secret Manager per leggere questo di configurazione automatica.
• Gestire l'infrastruttura di monitoraggio e avviso: categorie di metriche per le istanze del database di origine Amazon offrono l'osservabilità durante di migrazione. Le categorie di metriche possono includere Amazon CloudWatch, Informazioni sulle prestazioni, Monitoraggio avanzato ed elenchi di processi del sistema operativo.

Completa la valutazione

Dopo aver creato gli inventari 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 procedi nel seguente modo:

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

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

1. Creare 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 Esegui la migrazione a Google Cloud: pianifica e costruisci le tue basi.

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. Scegli gli strumenti di migrazione in base alla strategia scelta e 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, incluse quelle lavorative che implementare 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. Pulire l'ambiente di origine e configurare l'istanza di destinazione.

11. Eseguire l'ottimizzazione e l'ottimizzazione.

Ogni fase è descritta nelle sezioni seguenti.

Scegli la strategia di migrazione

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

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

• Replica continua (detta anche migrazione persistente): per mission critical, questa opzione offre un rischio minore di perdita di dati con tempi di inattività quasi azzerati. Le attività sono suddivise in più blocchi, quindi se gli errori, il rollback e la ripetizione richiedono meno tempo. Tuttavia, la configurazione è più più complessi 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 in entrambe le origini e le istanze di destinazione durante la migrazione.
  • Usare un microservizio di accesso ai dati, che riduce lo sforzo di refactoring richiesto l'approccio Y (scrittura e lettura).

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

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

Il diagramma di flusso precedente mostra i seguenti punti decisionali:

• Puoi permetterti un tempo di riposo?

  • In caso contrario, adotta la strategia di migrazione della 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 migrazione completa rappresenta la quantità di tempo da impiegare un backup del database, trasferirlo in Cloud SQL, ripristinarlo e poi passare dalle tue applicazioni.

  • In caso contrario, adotta la strategia di migrazione della 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: eseguire la migrazione di database di piccole dimensioni e utilizzati raramente con la manutenzione pianificata ma utilizza la replica continua per i database mission critical in 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 ) viene arrestata e tutte le operazioni di lettura e scrittura vengono eseguite sull'istanza di destinazione. Cambiare quando entrambe le istanze sono sincronizzate significa nessuna perdita di dati e minima o un tempo di inattività.

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

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

Per le configurazioni di migrazione che non prevedono tempi di inattività delle applicazioni è necessario una configurazione complessa. Trova il giusto equilibrio tra complessità della configurazione e tempo di inattività in orari di apertura ridotti.

Ogni strategia di migrazione presenta un compromesso e un certo impatto associati 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 dell'applicazione, almeno per la durata del ritardo di replica prima dell'utilizzo nel nuovo database. In pratica, i seguenti fattori possono aumentare il tempo di inattività:

• Il completamento delle query sul database può 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 ha una notevole memoria di buffer.
• 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 reinstradate. In base a come Le voci DNS sono state configurate. L'operazione potrebbe richiedere del tempo. Quando aggiorni il DNS ridurre il TTL prima della migrazione.

Le seguenti pratiche comuni possono aiutare a ridurre al minimo i tempi di inattività 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 reporting. 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 mediante l'implementazione di una migrazione graduale. Usa trasferimenti di dati incrementali e in batch, e adattare parte dei carichi di lavoro in modo che funzionino con i dati inattivi sulla destinazione in esecuzione in un'istanza Compute Engine.
• Valuta la possibilità di eseguire il refactoring delle applicazioni per supportare una migrazione minima impatto. 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 è la scelta del giusto di migrazione. Una volta che la strategia di migrazione è stata decisa, esaminali e decidi sullo 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.
• Dimensione del database. Più grande è il database, maggiore è il tempo necessario per eseguire la migrazione del backup iniziale.
• Frequenza delle modifiche al database.
• Disponibilità per l'utilizzo dei servizi gestiti per la migrazione.

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

I servizi di migrazione gestiti offrono i seguenti vantaggi:

• Riduci al minimo 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 sono protetti e trasferiti in modo affidabile dall'origine al database di destinazione.

• Offri un'esperienza di migrazione coerente: migrazione diversa le tecniche e i modelli possono essere consolidati utilizzando gli eseguibili per la migrazione dei database, che puoi gestire monitoraggio.

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

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

Le sezioni successive descrivono i suggerimenti degli strumenti di migrazione, che dipendono la strategia di migrazione scelta.

Strumenti per migrazioni di manutenzione pianificate

Le seguenti sottosezioni descrivono gli strumenti che possono essere utilizzati una sola volta migrazioni, nonché i relativi limiti e best practice.

Backup integrati del motore del database

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.

È richiesto un certo impegno per l'impostazione e la sincronizzazione, soprattutto per un di database, ma i backup del motore del database sono solitamente immediatamente disponibili facile da usare. 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, considera le seguenti limitazioni e pratiche:

• Per i backup di database 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 su un bucket Amazon S3 nella stessa regione Amazon di dell'istanza del database di origine.
• I backup non includono gli accessi, le autorizzazioni e il server ruoli, perché sono situati 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 maggiori dettagli sulle limitazioni e sulle 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, puoi utilizzare file flat per esportare e importare i dati (o utilizzando i piani script), puoi effettuare le seguenti operazioni:

• Eseguire 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 filtrare i dati in base al dominio, all'origine, all'età o a un'altra impostazione criteri. 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 i costi sostenuti con il tempo di inattività 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 l'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 diagramma di flusso con le domande che possono aiutarti a scegliere lo strumento di migrazione per un singolo database, quando si utilizza una replica continua strategia di migrazione:

Il diagramma di flusso precedente mostra i seguenti punti decisionali:

• Preferisci utilizzare i servizi di migrazione gestiti?

  • In caso affermativo, passa alla prossima decisione. 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 prossima decisione. Se il motore del database la replica integrata è supportata, consigliamo di usare la replica dei dati. In caso contrario, ti consigliamo di valutare altre opzioni di migrazione.

• Puoi permetterti tempi di inattività minimi ed eseguire la migrazione senza dati o sincronizzazione in tempo reale?

  • In caso affermativo, consigliamo Database Migration Service.
  • In caso contrario, esamina 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 delle repliche, insieme ai relativi limiti e best practice.

Database Migration Service per la migrazione della replica continua

Database Migration Service supporta migrazioni omogenee a Cloud SQL per SQL Server, quando la fonte è 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, tieni conto delle 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. Prendine una copia dall'istanza di origine e poi trasferiscile all'istanza di destinazione utilizzando Script o strumenti PowerShell come DBAtools.

Per un elenco completo delle limitazioni, vedi Limitazioni note.

Replica integrata del motore del database

Cloud SQL supporta la replica per SQL Server. Tuttavia, Amazon Standard RDS per SQL Server può essere solo un sottoscrittore. Replica integrata da Amazon RDS L'opzione Standard non è disponibile. Solo Amazon RDS Custom per SQL Server può essere configurato come un publisher 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 della replica continua

Altri approcci per la migrazione della replica continua includono i seguenti:

• 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 per la migrazione si concentra sul refactoring o sullo sviluppo di che si connettono alle tue istanze di database.
  • Successivamente, viene eseguito il refactoring e deployment delle applicazioni dei lettori 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 sono archiviati in un bucket Google Cloud Storage.
  • I file possono essere scritti immediatamente nell'istanza del database di destinazione utilizzando Cloud Functions.
  • 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).
  • Potete avere un'implementazione personalizzata per leggere i file e scrivere i propri contenuti in Cloud SQL.

Strumenti di terze parti per migrazioni della replica continua

Se decidi di utilizzare uno strumento di terze parti, scegli una delle seguenti opzioni Suggerimenti utili per la maggior parte dei motori del database.

Striscia è una piattaforma in memoria end-to-end per la raccolta, l'applicazione di filtri, la trasformazione arricchimento, aggregazione, analisi e distribuzione dei dati in tempo reale:

• Vantaggi:

  • Gestisce grandi volumi di dati e migrazioni complesse.
  • Change Data Capture (CDC) integrata per SQL Server.
  • Modelli di connessione preconfigurati e pipeline no-code.
  • In grado di gestire grandi database mission critical che operano sotto un carico transazionale elevato.
  • Consegna "exactly-once".

• Svantaggi:

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

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

Debezium è una piattaforma distribuita open source per CDC e può trasmettere flussi di modifiche ai dati sottoscrittori esterni:

• Vantaggi:

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

• Sfide:

  • Richiede un'esperienza specifica con Kafka e ZooKeeper.
  • La consegna "at-least-once" delle modifiche dei dati, ovvero richiedono la gestione dei duplicati.
  • Configurazione del monitoraggio manuale con Grafana e Prometheus.
  • Nessun supporto per la replica batch incrementale.

Per ulteriori informazioni sulle migrazioni a Debezium, vedi Replica dei dati quasi in tempo reale con Debezium.

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 il impatto sulla tua attività, ti consigliamo di creare un elenco di tutte le gli elementi di lavoro necessari.

La definizione dell'ambito della migrazione rivela le attività da eseguire prima, durante e dopo il processo di migrazione del database. Ad esempio, se decidi di non per eseguire la migrazione di determinate tabelle da un database, potresti aver bisogno di attività di post-migrazione per implementare questo filtro. Ti assicuri inoltre che i tuoi 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 progettazione tecnica (TDD)
• Matrice RACI
• Timeline (ad esempio un piano T-Minus)

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

TDD

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

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

Matrice RACI

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

Cronologia

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, consigliamo di creare un piano T-minus. Un piano T-minus è strutturato come un programma di conto alla rovescia ed elenca tutte le attività necessari per completare il progetto di migrazione, insieme ai gruppi responsabili e durata stimata.

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

La durata delle attività di migrazione 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	Il team addetto all'individuazione	-21	Completa
7/11/2023	Pre-migrazione	Preparazione del bersaglio	Progettare l'ambiente di destinazione come descritto nel documento di progettazione	Team della migrazione	-14	Completa
15/11/2023	Pre-migrazione	Governance aziendale	Data migrazione e approvazione T-Minus	Leadership	-6	Completa
18/11/2023	Migrazione	Configura DMS	Creazione di profili di connessione	Ingegnere della migrazione cloud	-3	Completa
19/11/2023	Migrazione	Configura 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	Ingegnere della migrazione cloud	-2	Non avviato
21/11/2023	Migrazione	DMS di cutover	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 applicazione	Esegui test delle funzionalità e delle prestazioni	Team della migrazione	0	Non avviato
22/11/2023	Migrazione	Governance aziendale	Convalida della migrazione GO o NO GO	Team della migrazione	1	Non avviato
23/11/2023	Dopo la migrazione	Convalida il monitoraggio	Configura il monitoraggio	Team Infrastruttura	2	Non avviato
25/11/2023	Dopo la migrazione	Sicurezza	Rimuovi account utente DMS	Team della sicurezza	4	Non avviato

Migrazioni di più database

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

Ti consigliamo di iniziare la procedura eseguendo la migrazione di un file più piccolo, un database non mission-critical. 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 cronologie possono essere parallelizzate. Ad esempio, per velocizzare il processo di migrazione, potresti scegliere di eseguire un gruppo di database piccoli, statici o meno mission-critical contemporaneamente, come mostrato nel diagramma seguente.

Nell'esempio mostrato nel diagramma, i database 1-4 sono un gruppo di piccoli 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. Senza le attività di preparazione, la migrazione non può avvenire o fa sì che il database migrato si trovi in inutilizzabile.

Le attività di preparazione possono essere categorizzate come segue:

• Preparazioni e prerequisiti delle 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 sulle tue istanze RDS. Se l'istanza RDS è configurata per essere privato nel tuo VPC, RFC 1918 privata la connettività deve esistere 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 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, vedi Utilizzo di Change Data Capture (CDC) 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 nel database di origine sia disponibile memoria e spazio di archiviazione del buffer durante le operazioni di migrazione. Ad esempio, se usi la transazione registrare i file di backup, monitorare l'utilizzo dello spazio di archiviazione e assicurarsi di avere di archiviazione del buffer.
• Documentare le impostazioni dei parametri del database e applicarle dell'istanza di destinazione prima di eseguire il test e la convalida della migrazione.

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

  • Misura la dimensione dei dati, nonché il carico di lavoro delle prestazioni. Tempo necessario per le query o le transazioni importanti media? Quanto dura durante le ore di punta?
  • Documentare le misurazioni di riferimento per un confronto successivo, per poter decidere meglio se la fedeltà della migrazione del database è soddisfacente. Decidi se puoi cambiare i carichi di lavoro di produzione e ritirare l'origine ambiente o se ne hai ancora bisogno per scopi di 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 il tuo cluster, devi confermare le proprietà e i requisiti che seguono le istanze Cloud SQL, perché non possono essere modificate in un secondo momento senza ricreandoli.

• Scegli il progetto e la regione del target con attenzione alle istanze Cloud SQL. Le istanze Cloud SQL non possono essere viene eseguita la migrazione tra progetti e regioni Google Cloud senza trasferimento di dati.

• Esegui la migrazione a una versione principale corrispondente su Cloud SQL. Ad esempio: Se 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à le stesse 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 limitazioni Backup specifici del motore del database .

• Esamina i flag di configurazione specifici del motore del database e confronta i valori delle rispettive istanze di origine e di destinazione. Assicurati di aver compreso i loro e se devono essere uguali o meno. Ad esempio, consigliamo di confrontare i valori nel file sys.configurations sul tuo database di origine con i valori su Cloud SQL in esecuzione in un'istanza Compute Engine. Tieni presente che non tutti i flag devono essere uguali e non tutte le modifiche ai flag sono consentite su un'istanza Cloud SQL.

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

• Best practice generali per SQL Server
• Opzioni di configurazione dell'istanza per SQL Server
• Flag specifici del motore del database per SQL Server

Configurazione specifica per la migrazione

Se utilizzi l'esportazione e l'importazione di file per la migrazione, oppure la migrazione di Database Migration Service devi creare un bucket Cloud Storage. Il bucket archivia e i file di backup dei log delle transazioni e del database. 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 l'accesso al database principale. Questo può essere ottenuto attraverso la documentazione opzioni di connettività.

A seconda del tuo scenario e della tua criticità, potrebbe essere necessario implementare una scenario di riserva, che di solito include invertendo la direzione della replica. In questo caso, potrebbe essere necessario un ulteriore meccanismo di replica Cloud SQL torna all'istanza Amazon di origine.

Per la maggior parte degli strumenti di terze parti, devi eseguire il provisioning di risorse specifiche per la migrazione. Ad esempio, per Striim, per iniziare devi utilizzare Google Cloud Marketplace. Quindi, per configurare l'ambiente di migrazione in Striim, puoi utilizzare lo strumento Designer per creare e modificare applicazioni oppure puoi selezionarne una preesistente modello. Le applicazioni possono 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 specifici del motore del database

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 una di origine al database di destinazione. I job di migrazione si connettono dell'istanza del database di origine tramite profili di connessione definiti dall'utente.

Testa tutti i prerequisiti per assicurarti che il job possa essere eseguito correttamente. Scegli un'opzione di tempo in cui i carichi di lavoro possono permettersi un tempo di inattività ridotto per la migrazione la produzione in poi.

Il processo di migrazione di solito prevede le seguenti attività:

• Esporta un backup completo del database di origine, quindi caricalo in un nel bucket Cloud Storage.
• Esegui un backup dei file di log delle transazioni e caricalo nel 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 viene monitorata l'elaborazione dei backup dei log delle transazioni.
• Interrompi la scrittura sul 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.
• Eseguire il deployment delle applicazioni che puntano al nuovo database di destinazione.

Per un processo dettagliato di configurazione della migrazione, vedi Esegui la migrazione dei tuoi database SQL Server a Cloud SQL per SQL Server.

Replica integrata del motore del database

Se utilizzi Amazon RDS Standard, potrebbe essere necessario eseguire prima la migrazione Amazon RDS Custom e poi 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 usare Striim, devi creare app nello spazio dei nomi e configurare il lettore CDC per la connessione all'istanza Amazon. Per maggiori dettagli, vedi Configurazione di SQL Server nella documentazione di Striim.

Definire gli scenari di fallback

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 la produzione fino a quando i risultati del test non sono soddisfacenti. Sia il database migrazione e lo scenario di riserva devono essere testati adeguatamente per evitare un attacco o un'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 l'azione successiva nel caso in cui il job di migrazione una tantum o il ripristino del backup a metà strada. A seconda del tempo trascorso nel tempo di inattività pianificato, potresti dover posticipare la migrazione se l'attività non viene completata tra per il tempo previsto.

Un piano di riserva di solito si riferisce al rollback della migrazione dopo aver eseguito la migrazione completa della produzione, se compaiono dei 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 aver compreso il funzionamento possibili conseguenze. L'assenza di un piano di riserva può comportare sforzi imprevisti che possono causare interruzioni evitabili nel processo di migrazione.

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

Semplicità di riserva

In questa strategia di riserva, ripristini la versione originale delle applicazioni un'istanza del database di origine. Adotta questa strategia se puoi permetterti 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 su l'istanza del database di destinazione, potresti portarla nell'origine iniziale di sistema di database in un secondo momento, soprattutto se i carichi di lavoro non sono dipende da tempi specifici di creazione dei record o vincoli di ordinamento temporale.

Replica inversa

In questa strategia, devi replicare le scritture sul nuovo target dopo il passaggio alla produzione per tornare al database di origine iniziale. In questo l'origine originale rimane sincronizzata con il nuovo database di destinazione le scritture sulla 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 se puoi ancora conservare l'istanza di origine per un po' di tempo e si esegue la migrazione della replica continua.

Inoltra replica

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 a qualsiasi meccanismo di replica, a seconda delle esigenze. Il vantaggio di questo approccio è che può essere testata completamente end-to-end.

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

Scritture duplicate

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

Le applicazioni scrivono sia nelle istanze di database di origine iniziali che di destinazione, che consente di eseguire un passaggio di produzione graduale fino a quando non si utilizzano delle istanze del database di destinazione. Se ci sono problemi, connetti il tuo per ripristinare le applicazioni all'origine iniziale senza tempi di inattività. Puoi ignorare 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.

Esegui test e convalida

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

• Migrazione dei dati nel database riuscita.
• Integrazione con le applicazioni esistenti dopo il passaggio all'utilizzo la nuova istanza di destinazione.

Definisci i principali fattori di successo, soggettivi alla migrazione. La Ecco alcuni esempi di fattori soggettivi:

• Quali dati eseguire la migrazione. Per alcuni carichi di lavoro, potrebbe non essere necessario eseguire la migrazione di tutti e i dati di Google Cloud. 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 nel tuo ambiente di origine potrebbero non essere mappate direttamente target dell'ambiente Google Cloud. Ad esempio, le configurazioni Volumi SSD per uso generico (gp2 e gp3) con prestazioni burst IOPS SSD IOPS di cui è stato eseguito il provisioning. Per confrontare e dimensionare correttamente le istanze di destinazione, esegui un'analisi comparativa della tua origine di Compute Engine, sia nelle fasi di valutazione che di convalida.

Nel processo di benchmarking, vengono applicate sequenze di operazioni simili a quelle di produzione alle istanze del database. Durante questo periodo, acquisisci ed elabori le metriche Misurare e confrontare il rendimento relativo dell'origine e del target sistemi diversi.

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 di benchmarking e test di carico di database open source. Supporta complessi carichi di lavoro transazionali e analitici, su più motori di database (sia TPROC-C che TPROC-H). HammerDB ha una documentazione dettagliata e un'ampia community di utenti. Puoi condividere 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: il benchmarking specializzato per MySQL. Un insieme di kit di carichi di lavoro del database imitano un'applicazione per un'azienda che possiede magazzini e prevede un mix di operazioni di lettura e scrittura. Usa questo strumento se vuoi usare un modello sull'elaborazione delle transazioni online (OLTP).
• DbUnit: Uno strumento 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 di database open source che supporta codice basato su test sviluppo e 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 dispone di un'ampia assistenza da parte della community o di una documentazione esaustiva, 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, compreso il test del piano di migrazione, devi sempre eseguire un esercizio 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:

• Consente di assicurare che la migrazione di tutti gli oggetti e di tutte le configurazioni venga eseguita correttamente.
• Ti aiuta a definire ed eseguire gli scenari di test della 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, per cui è utile individua 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 l'implementazione della 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à:

• Confrontare gli schemi di origine e di destinazione. Controllare se tutte le tabelle e tutti gli eseguibili esistono. Controllare i conteggi delle righe e confrontare i dati a livello di database.
• Eseguire script di convalida dei dati personalizzati.
• Verifica che i dati migrati siano visibili anche nelle applicazioni per utilizzare il database di destinazione (i dati sottoposti a migrazione vengono letti applicazione).
• Esegui test di integrazione tra le applicazioni trasferite e 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 di database più utilizzate per osservare se si verificano riduzioni dovute a configurazioni errate o a dimensioni non corrette.

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 Verifica una migrazione.

Strumento di convalida dei dati

Per eseguire la convalida dei dati, ti consigliamo di utilizzare Strumento di convalida dei dati (DVT, Data Validation Tool, DVT). DVT è uno strumento di interfaccia a riga di comando Python open source, supportato da Google, che offre una soluzione automatizzata e ripetibile per la convalida ambienti cloud-native.

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

La DVT copre molte origini dati Google Cloud, tra cui AlloyDB per PostgreSQL, File BigQuery, Cloud SQL, Spanner, JSON e CSV su di archiviazione ideale in Cloud Storage. Può anche essere integrato con Cloud Functions 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 (inclusi "AVG", "COUNT", "SUM", "MIN", "MAX", "GROUP BY" e "STRING_AGG")
• Riga (inclusi hash e corrispondenza esatta nei confronti di campi)
• Confronto dei risultati delle query personalizzate

Per ulteriori informazioni sulla TVP, consulta 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à di supporto del trasferimento da un di sistema a un altro.

Considera le seguenti best practice per la migrazione dei dati:

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

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

Esegui la migrazione completa della produzione

Il processo generale di migrazione completa può variare a seconda di migrazione. Se puoi avere tempi di inattività per i carichi di lavoro, la migrazione completa inizia interrompendo le scritture sul database di origine.

Per le migrazioni 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.
• Eseguire il deployment delle applicazioni che puntano 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 i dati nell'istanza di destinazione sono conformi in base agli 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 dell'istanza di destinazione. Puoi eseguire il deployment delle versioni delle tue applicazioni che puntano nuova istanza del database di destinazione. I deployment possono essere eseguiti tramite aggiornamenti in sequenza, release temporanee o mediante un pattern di deployment blu/verde. Potrebbero verificarsi dei tempi di inattività delle applicazioni.

Segui le best practice per la migrazione completa della produzione:

• Monitora le applicazioni che funzionano con il database di destinazione dopo il l'implementazione.
• Definire un periodo di tempo per il monitoraggio da considerare per stabilire se è necessario o meno per implementare il tuo piano di riserva.
• Tieni presente che 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.

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

Al termine della migrazione completa, puoi eliminare i database di origine. Me ti consigliamo di eseguire le seguenti azioni importanti prima di pulire il tuo istanza di origine:

• Creare un backup finale di ogni database di origine. Questi backup offrono uno stato finale dei database di origine. I backup potrebbero essere richiesti anche la conformità con alcune normative sui dati.

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

• Raccogli le statistiche del database dall'istanza di origine e confrontale a quelli nell'istanza di destinazione. Se le statistiche sono diverse, è difficile confrontare le prestazioni 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 al contrario: di origine diventerà la nuova destinazione.

Come best practice per mantenere aggiornate le istanze di origine dopo il passaggio replicare le scritture eseguite sulle istanze Cloud SQL di destinazione al 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 da controllare quando possono verificarsi aggiornamenti improvvisi.
• Configura lo spazio di archiviazione sull'istanza in modo che sia disponibile almeno il 20% spazio necessario per eseguire operazioni critiche di manutenzione del database le prestazioni di Cloud SQL. Per ricevere un avviso se è disponibile spazio su disco scende al di sotto del 20%, crea un criterio di avviso basato su metriche per il disco di utilizzo della metrica di utilizzo.

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

Per ulteriori informazioni, consulta le seguenti risorse:

• Informazioni sulla manutenzione delle istanze Cloud SQL.
• Impostazioni specifiche per SQL Server Engine.

Ottimizza l'ambiente dopo la migrazione

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

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

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

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

Definisci i tuoi requisiti di ottimizzazione

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

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

Con Cloud SQL, puoi implementare 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 impedire la rimozione accidentale delle istanze, utilizza l'eliminazione delle istanze protezione dei dati.
• Attiva recupero point-in-time (PITR) per l'istanza Cloud SQL per SQL Server.
• Automatizza i backup dei database SQL utilizzando piani di manutenzione.

Aumenta la convenienza economica della tua infrastruttura di database

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

• Fornisci al database la capacità di archiviazione minima richiesta 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 il database i carichi di lavoro tendono ad aumentare nel tempo.

• Identifica le possibili risorse sovrastimate:

  • Il dimensionamento ottimale delle istanze Cloud SQL può ridurre costi dell'infrastruttura senza aggiungere ulteriori rischi alla capacità una strategia di gestione aziendale.
  • Cloud Monitoring offre dashboard predefinite che identificare l'integrità e l'utilizzo della capacità di molte Google Cloud tra cui Cloud SQL. Per maggiori dettagli, vedi Creare e gestire dashboard personalizzate.

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

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

• Valuta il tipo di archiviazione (SSD o HDD) più conveniente per il tuo utilizzo per verificare se è così.

  • Nella maggior parte dei casi d'uso, l'SSD è il modo più efficiente a convenienza economica.
  • Se i tuoi set di dati sono di grandi dimensioni (10 TB o più), non sono sensibili alla latenza, o se si accede raramente, HDD potrebbe essere più appropriato.
  • Per maggiori dettagli, vedi Scegli tra 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 possono compensare eventuali l'impatto sulle prestazioni derivante dalla disattivazione di SMT. Questa strategia consente di ridurre i costi delle licenze, ma ciò potrebbe influire sulle prestazioni dell'istanza. Me di eseguire test di carico sull'istanza per assicurarti che Gli SLA non sono interessati.
• Valuta una migrazione eterogenea da Cloud SQL per SQL Server a Cloud SQL per PostgreSQL o AlloyDB per PostgreSQL, a seconda carico di lavoro.

Aumenta le prestazioni della tua infrastruttura di database

Spesso problemi di prestazioni minori relativi al database possono influire l'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 vincolata alla memoria o alla 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 Query Insights predefinito una dashboard in Cloud Monitoring (o un motore del database simile integrato ). Identificare i comandi più costosi e provare a ottimizzarli.

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

• Controlla la posizione del lettore e del database. La latenza influisce sulle prestazioni di lettura 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.

Aumenta le funzionalità di osservabilità del database

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

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

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

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

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

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

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

• Osserva lo stato dei tuoi database per aiutarti a migliorare le prestazioni dell'ambiente e per risolvere i problemi eventuali problemi.

Linee guida operative e best practice generali di Cloud SQL

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

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

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

Per 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, la scalabilità verticale dell'istanza può risolvere la maggior parte dei problemi di prestazioni. In seguito può analizzare ulteriormente la causa principale del problema in un ambiente di test e in considerazione delle opzioni per eliminarlo.

Eseguire e pianificare le operazioni di manutenzione del database: Indice deframmentazione, aggiornamenti statistici, analisi vacuum e reindicizzazione molto aggiornate tabelle. Controlla se e quando queste operazioni di manutenzione sono state eseguite l'ultima volta, soprattutto sugli oggetti interessati (tabelle, indici). Scopri se c'è stato un rispetto alle normali attività del database. Ad esempio, l'aggiunta recente di un nuovo o avere molti aggiornamenti in una tabella.

Esegui ottimizzazione e ottimizzazione del database: le tabelle nel tuo database sono? strutturati in modo adeguato? Le colonne contengono i tipi di dati corretti? I tuoi dati sono più adatto al tipo di carico di lavoro? Esamina 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 unioni complesse. Il tempo necessario per risolvere il problema dipende dall'esperienza e dalla disponibilità del tuo team e può variare da ore ai giorni.

Fai lo scale out delle letture: valuta la possibilità di utilizzare repliche di lettura. Durante la scalabilità verticalmente non è sufficiente per le tue esigenze e l'ottimizzazione e l'ottimizzazione del database le misure non sono di aiuto, ti consigliamo di scalare orizzontalmente. Routing delle query di lettura dalle applicazioni a una replica di lettura migliora le prestazioni 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. 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 effettuando lo sharding del database. Lo sharding è un'operazione complicata e prevede la riprogettazione dell'architettura del database e applicazioni in modo specifico ed eseguendo la migrazione dei dati. 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 scalare orizzontalmente sia le scritture che le letture. Tuttavia, aumenta e la complessità dei carichi di lavoro del database e delle applicazioni. Potrebbero inoltre verificarsi shard non bilanciati chiamati hotspot, che supererebbero il vantaggio dello sharding.

In particolare per Cloud SQL per SQL Server, considera quanto segue: pratiche:

• Per aggiornare le impostazioni di SQL Server al fine di 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, dividile in istanze più piccole, dove possibili:

  • Una dimensione del disco di almeno 4 TB garantisce una maggiore velocità effettiva 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.

• Disattivare SMT se in alcune situazioni le prestazioni diminuiscono. 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 di database diventino di dimensioni inutilmente grandi. Imposta autogrow in MB anziché in percentuale, utilizzando gli incrementi appropriati requisito. Inoltre, gestisci in modo proattivo la crescita del database prima che Soglia di autogrow raggiunta.

• Per scalare automaticamente la capacità di archiviazione, abilitare 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 comprendere i requisiti delle impostazioni internazionali, l'ordinamento e le maiuscole/minuscole e l'accento sulla sensibilità dei dati. Quando seleziona le regole di confronto per il server, il database, la colonna o l'espressione, ad assegnare determinate caratteristiche ai tuoi dati.

• I join hash ricorrenti o i salvataggi di hashing causano una riduzione delle prestazioni in un o server web. Se noti molti eventi di avviso relativi all'hash in una traccia, aggiorna il valore le statistiche sulle colonne che vengono unite. Per ulteriori informazioni, vedi Classe di evento di avviso sugli hash.

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

Passaggi successivi

• Informazioni altri percorsi di migrazione da AWS a Google Cloud.

• Scopri come confrontare i servizi AWS e Azure con Google Cloud.

• Scopri quando consulta l'assistenza per le migrazioni.

• Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.

Collaboratori

Autori:

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

Altri collaboratori:

• Derek Downey | Ingegnere per le relazioni con gli sviluppatori
• Paweł Krentowski | Scrittore tecnico
• Mario Rossi | Tecnico cloud strategico
• Paolo Somdyuti | Esperto di gestione dei dati
• Zach Seils | Esperto di networking

Per vedere profili di LinkedIn non pubblici, accedi a LinkedIn.