Esegui la migrazione da AWS a Google Cloud: esegui la migrazione da Amazon RDS e Amazon Aurora per PostgreSQL a Cloud SQL e AlloyDB per PostgreSQL

Last reviewed 2024-09-12 UTC

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

Questo documento è rivolto agli amministratori di cloud e database che vogliono pianificare, implementare e convalidare un progetto di migrazione del database. È inoltre destinato ai responsabili delle decisioni che stanno valutando l'opportunità di eseguire la migrazione e vogliono un esempio di come potrebbe essere una migrazione.

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

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 Migrazione a Google Cloud: Guida introduttiva.

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

Percorso di migrazione con quattro fasi.

Potresti eseguire la migrazione dall'ambiente di origine a Google Cloud in una serie di iterazioni. Ad esempio, potresti eseguire la migrazione di alcuni workload prima e di altri in un secondo momento. Per ogni iterazione di migrazione separata, segui le fasi del framework di migrazione generale:

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

Per maggiori informazioni sulle fasi di questo framework, consulta la pagina Eseguire la migrazione a Google Cloud: guida introduttiva.

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

Valuta l'ambiente di origine

Nella fase di valutazione, determini i requisiti e le dipendenze per migrare l'ambiente di origine a Google Cloud.

La fase di valutazione è fondamentale per il successo della migrazione. Devi acquisire una conoscenza approfondita dei carichi di lavoro di cui vuoi eseguire la migrazione, dei loro requisiti, delle loro dipendenze e del tuo ambiente attuale. Devi comprendere il tuo punto di partenza per pianificare ed eseguire correttamente una Google Cloud migrazione.

La fase di valutazione è costituita dalle seguenti attività:

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

La fase di valutazione del database ti aiuta a scegliere le dimensioni e le specifiche dell'istanza del database Cloud SQL di destinazione che corrisponde all'origine per esigenze di prestazioni simili. Presta particolare attenzione alle dimensioni e al throughput del disco, alle IOPS e al numero di vCPU. Le migrazioni potrebbero avere difficoltà o non riuscire a causa di un dimensionamento errato dell'istanza del database di destinazione. Il dimensionamento errato può comportare tempi di migrazione lunghi, problemi di prestazioni del database, errori del database e problemi di prestazioni dell'applicazione. Quando scegli l'istanza Cloud SQL, tieni presente che le prestazioni del disco si basano sulle dimensioni del disco e sul numero di vCPU.

Le sezioni seguenti si basano su Migrazione a Google Cloud: valutazione e individuazione dei carichi di lavoro e integrano le informazioni contenute in questo documento.

Crea un inventario delle tue istanze Amazon RDS o Amazon Aurora

Per definire l'ambito della migrazione, crea un inventario e raccogli informazioni sulle tue istanze Amazon RDS e Amazon Aurora. Idealmente, questo dovrebbe essere un processo automatizzato perché gli approcci manuali sono soggetti a errori e possono portare a ipotesi errate.

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

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

Strumenti per i test

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

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

Per saperne di più sulla valutazione del tuo ambiente AWS utilizzando Migration Center, consulta Importare dati da altri cloud provider.

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

migVisor può identificare artefatti e funzionalità di database proprietarie incompatibili che possono causare l'impostazione predefinita della migrazione e può indicare soluzioni alternative. migVisor può anche consigliare una soluzione Google Cloud di destinazione, tra cui dimensionamento iniziale e architettura.

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

  • Individuazione e analisi complete dei deployment di database attuali.
  • Report dettagliato sulla complessità della migrazione, basato sulle funzionalità proprietarie utilizzate dal tuo 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 interruzioni minime per l'attività.

Per visualizzare 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 non di punta.

L'output della valutazione di migVisor ti aiuta a creare un inventario completo delle tue istanze RDS. Il report include proprietà generiche (versione e edizione del motore del database, CPU e dimensioni della memoria), nonché dettagli su topologia del database, policy di backup, impostazioni dei parametri e personalizzazioni speciali in uso.

Se preferisci utilizzare strumenti open source, puoi utilizzare gli script di raccolta dei 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 del database) e a creare l'inventario del database. Inoltre, gli script forniscono in genere una valutazione dettagliata della migrazione del database, inclusa una stima dell'impegno richiesto per la migrazione.

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

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

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

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

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

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

Stabilisci le baseline di migrazione dei dati che ti aiutano a confrontare e valutare i risultati e gli impatti. Queste baseline sono punti di riferimento che rappresentano lo stato dei tuoi dati prima e dopo la migrazione e ti aiutano a prendere decisioni. È importante eseguire misurazioni nell'ambiente di origine che possano aiutarti a valutare la riuscita della migrazione dei dati. Queste misurazioni includono:

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

Determina la quantità di tempo di inattività che puoi permetterti. Quali sono gli impatti commerciali dei tempi di inattività? Esistono periodi di bassa attività del database, durante i quali il numero di utenti interessati dal downtime è inferiore? Se sì, quanto durano questi periodi e quando si verificano? Valuta la possibilità di avere un downtime parziale di sola scrittura, mentre le richieste di sola lettura vengono comunque gestite.

Valuta il processo di deployment e amministrazione

Dopo aver creato gli inventari, valuta i processi operativi e di deployment per il tuo database per determinare in che modo devono essere adattati per facilitare la migrazione. Questi processi sono fondamentali per la preparazione e la manutenzione dell'ambiente di produzione.

Considera come completi le seguenti attività:

  • Definisci e applica criteri di sicurezza per le tue istanze. Ad esempio, potrebbe essere necessario sostituire i gruppi di sicurezza Amazon. Puoi utilizzare i ruoli Google IAM, le regole firewall VPC e i controlli di servizio VPC per controllare l'accesso alle tue istanze Cloud SQL per PostgreSQL e limitare i dati all'interno di un VPC.

  • Applica patch e configura le istanze. Potrebbe essere necessario aggiornare gli strumenti di deployment esistenti. Ad esempio, potresti utilizzare impostazioni di configurazione personalizzate nei gruppi di parametri o nei gruppi di opzioni Amazon. Potrebbe essere necessario adattare gli strumenti di provisioning per utilizzare Cloud Storage o Secret Manager per leggere questi elenchi di configurazione personalizzati.

  • Gestisci l'infrastruttura di monitoraggio e avvisi. Le categorie di metriche per le istanze del database di origine Amazon forniscono l'osservabilità durante la procedura di migrazione. Le categorie di metriche possono includere Amazon CloudWatch, Performance Insights, monitoraggio avanzato ed elenchi di processi del sistema operativo.

Completa la valutazione

Dopo aver creato gli inventari dall'ambiente Amazon RDS o Amazon Aurora, completa le altre attività della fase di valutazione come descritto in Migrazione a Google Cloud: valuta e scopri i tuoi carichi di lavoro.

Pianificare e creare le basi

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

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

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

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

Per maggiori informazioni su ciascuna di queste attività, consulta la sezione Eseguire la migrazione a Google Cloud: pianificare e creare le basi.

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

Monitoraggio e avvisi

Utilizza Google Cloud Monitoring, che include dashboard predefinite per diversi prodotti Google Cloud , tra cui una dashboard di monitoraggio di Cloud SQL. In alternativa, puoi valutare l'utilizzo di soluzioni di monitoraggio di terze parti integrate con Google Cloud, come Datadog e Splunk. Per saperne di più, consulta Informazioni sull'osservabilità del database.

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

Per eseguire la migrazione delle istanze:

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

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

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

  4. Definisci le attività di preparazione da svolgere per garantire il corretto funzionamento dello strumento di migrazione.

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

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

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

  8. Esegui la migrazione.

  9. Esegui il cutover di produzione.

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

  11. Esegui l'ottimizzazione.

Ogni fase è descritta nelle sezioni seguenti.

Scegliere la strategia di migrazione

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

  • Manutenzione pianificata (chiamata anche migrazione una tantum o migrazione big bang): questo approccio è ideale se puoi permetterti tempi di inattività. Questa opzione è relativamente più economica e meno complessa, perché i tuoi carichi di lavoro e servizi non richiedono molto refactoring. Tuttavia, se la migrazione non va a buon fine prima del completamento, devi riavviare la procedura, il che prolunga il tempo di inattività.

  • Replica continua (chiamata anche migrazione online o migrazione incrementale): per i database mission-critical, questa opzione offre un rischio inferiore di perdita di dati e tempi di inattività quasi nulli. Gli sforzi sono suddivisi in più parti, in modo che, in caso di errore, il rollback e la ripetizione richiedano meno tempo. Tuttavia, la configurazione è più complessa e richiede più pianificazione e tempo. È necessario anche un ulteriore sforzo per eseguire il refactoring delle applicazioni che si connettono alle istanze del database. Valuta una delle seguenti varianti:

    • Utilizzando l'approccio Y (scrittura e lettura), che è una forma di migrazione parallela, i dati vengono duplicati sia nell'istanza di origine che in quella 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, vedi Valutare gli approcci alla migrazione dei dati.

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

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

Il diagramma di flusso precedente mostra i seguenti punti decisionali:

  • Puoi permetterti tempi di inattività?

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

  • Puoi permetterti il tempo di inattività rappresentato dalla finestra di cutover durante la migrazione dei dati? La finestra di cutover rappresenta il tempo necessario per eseguire un backup del database, trasferirlo a Cloud SQL, ripristinarlo e poi cambiare le applicazioni.

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

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

In genere, una migrazione viene considerata completata quando viene eseguito il passaggio dall'istanza di origine iniziale all'istanza di destinazione. Qualsiasi replica (se utilizzata) viene interrotta e tutte le operazioni di lettura e scrittura vengono eseguite sull'istanza di destinazione. Il passaggio quando entrambe le istanze sono sincronizzate non comporta perdita di dati e tempi di inattività minimi.

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

Le configurazioni di migrazione che non prevedono tempi di inattività dell'applicazione richiedono una configurazione più complessa. Trova il giusto equilibrio tra complessità della configurazione e tempi di inattività pianificati durante le ore lavorative di scarso traffico.

Ogni strategia di migrazione comporta un compromesso e un impatto associato al processo di migrazione. Ad esempio, i processi di replica comportano un carico aggiuntivo sulle istanze di origine e le applicazioni potrebbero essere interessate dal ritardo di replica. Le applicazioni (e i clienti) potrebbero dover attendere durante il tempo di inattività dell'applicazione, almeno per la durata del ritardo di replica prima di utilizzare il nuovo database. In pratica, i seguenti fattori potrebbero aumentare i tempi di inattività:

  • Il completamento delle query del database può richiedere alcuni secondi. Al momento della migrazione, le query in corso potrebbero essere interrotte.
  • Potrebbe essere necessario un po' di tempo per riempire la cache se il database è di grandi dimensioni o dispone di una memoria buffer sostanziale.
  • Le applicazioni arrestate nell'origine e riavviate in Google Cloud potrebbero avere un piccolo ritardo fino a quando non viene stabilita la connessione all'istanza di database Google Cloud.
  • 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 pratiche comuni possono contribuire a ridurre al minimo i tempi di inattività e l'impatto:

  • Trova un periodo di tempo in cui il tempo di inattività avrebbe un impatto minimo sui tuoi workload. Ad esempio, al di fuori del normale orario di lavoro, durante i fine settimana o altri periodi di manutenzione pianificati.
  • Identifica le parti dei tuoi workload che possono essere sottoposte a migrazione e al cutover di produzione in fasi diverse. Le tue applicazioni potrebbero avere componenti diversi che possono essere isolati, adattati e migrati senza alcun impatto. Ad esempio, frontend, moduli CRM, servizi di backend e piattaforme di reporting. Questi moduli potrebbero avere database propri che possono essere pianificati per la migrazione prima o dopo nel processo.
  • Se puoi tollerare una certa latenza nel database di destinazione, valuta la possibilità di implementare una migrazione graduale. Utilizza trasferimenti di dati incrementali e batch e adatta parte dei tuoi workload per funzionare con i dati obsoleti nell'istanza di destinazione.
  • Valuta la possibilità di eseguire il refactoring delle applicazioni per ridurre al minimo l'impatto della migrazione. Ad esempio, adatta le tue applicazioni per scrivere sia nei database di origine che in quelli di destinazione e implementa quindi una replica a livello di applicazione.

Scegli gli strumenti di migrazione

Il fattore più importante per una migrazione riuscita è la scelta dello strumento di migrazione giusto. Una volta decisa la strategia di migrazione, esamina e scegli lo strumento di migrazione.

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

  • Strategia di migrazione (manutenzione pianificata o replica continua).
  • Motori di database di origine e di destinazione e versioni del motore.
  • Gli ambienti in cui si trovano le istanze di origine e di destinazione.
  • Dimensioni del database. Più grande è il database, più tempo ci vuole per migrare il backup iniziale.
  • Frequenza delle modifiche al database.
  • Disponibilità a utilizzare i servizi gestiti per la migrazione.

Per garantire una migrazione e un cutover senza problemi, puoi utilizzare pattern di deployment delle applicazioni, orchestrazione dell'infrastruttura e applicazioni di migrazione personalizzate. Tuttavia, strumenti specializzati chiamati servizi di migrazione gestita possono 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, trasportano i dati in modo sicuro ai database di destinazione e possono facoltativamente modificare i dati durante il transito. Grazie a queste funzionalità, incapsulano la complessa logica della migrazione e offrono funzionalità di monitoraggio della migrazione.

I servizi di migrazione gestiti offrono i seguenti vantaggi:

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

  • Garantisci 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: diverse tecniche e pattern di migrazione possono essere consolidati in un'interfaccia comune e coerente utilizzando file eseguibili di migrazione del database, che puoi gestire e monitorare.

  • Offrire modelli di migrazione resilienti e comprovati: le migrazioni di database sono eventi rari ma critici. Per evitare errori da principiante e problemi con le soluzioni esistenti, puoi utilizzare strumenti di esperti esperti, anziché creare una soluzione personalizzata.

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

Le sezioni successive descrivono i consigli dello strumento di migrazione, che dipendono dalla strategia di migrazione scelta.

Strumenti per le migrazioni di manutenzione pianificate

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

Per le migrazioni una tantum a Cloud SQL per PostgreSQL o ad AlloyDB per PostgreSQL, ti consigliamo di utilizzare i backup del motore del database per esportare i dati dall'istanza di origine e importarli nell'istanza di destinazione. I job di migrazione una tantum non sono supportati in Database Migration Service.

Backup motore del database integrati

Quando è accettabile un tempo di inattività significativo e i database di origine sono relativamente statici, puoi utilizzare le funzionalità di dump e caricamento integrate delmotore del databasee (a volte chiamate anche backup e ripristino).

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

I backup del motore di database presentano le seguenti limitazioni generali:

  • I backup possono essere soggetti a errori, soprattutto se eseguiti manualmente.
  • I dati possono essere non protetti se gli snapshot non vengono gestiti correttamente.
  • I backup non dispongono di funzionalità di monitoraggio adeguate.
  • I backup richiedono uno sforzo di scalabilità quando si esegue la migrazione di molti database.

Puoi utilizzare le utilità di backup integrate di PostgreSQL, pg_dump e pg_dumpall, per eseguire la migrazione sia di Cloud SQL per PostgreSQL sia di AlloyDB per PostgreSQL. Tuttavia, le utilità pg_dump e pg_dumapall presentano le seguenti limitazioni generali:

  • Le utilità di backup integrate devono essere utilizzate per eseguire la migrazione di database con dimensioni pari o inferiori a 500 GB. Il dump e il ripristino di database di grandi dimensioni possono richiedere molto tempo e potrebbero richiedere spazio su disco e memoria considerevoli.
  • L'utilità pg_dump non include utenti e ruoli. Per eseguire la migrazione di questi account utente e ruoli, puoi utilizzare l'utilità pg_dumpall.
  • Cloud Storage supporta una dimensione massima di un singolo oggetto fino a 5 terabyte (TB). Se i database sono più grandi di 5 TB, l'operazione di esportazione in Cloud Storage non va a buon fine. In questo caso, devi suddividere i file di esportazione in segmenti più piccoli.

Se scegli di utilizzare queste utilità, tieni presente le seguenti limitazioni e best practice:

  • Comprimi i dati per ridurre i costi e la durata del trasferimento. Utilizza l'opzione --jobs con il comando pg_dump per eseguire un determinato numero di job di dump contemporaneamente.
  • Utilizza l'opzione -z con il comando pg_dump per specificare il livello di compressione da utilizzare. I valori accettabili per questa opzione vanno da 0 a 9. Il valore predefinito è la compressione a livello 6. Valori più elevati riducono le dimensioni del file di dump, ma possono causare un elevato consumo di risorse nell'host client. Se l'host client dispone di risorse sufficienti, livelli di compressione più elevati possono ridurre ulteriormente le dimensioni del file di dump.
  • Utilizza i flag corretti quando crei un file di dump SQL.
  • Verifica il database importato. Monitora l'output dell'utilità pg_restore per eventuali messaggi di errore durante il processo di ripristino. Controlla i log di PostgreSQL per eventuali avvisi o errori durante il processo di ripristino. Esegui query di base e conteggi delle tabelle per verificare l'integrità del database.

Per ulteriori informazioni su limitazioni e best practice, consulta le seguenti risorse:

Altri approcci per la migrazione della manutenzione pianificata

L'utilizzo di approcci diversi dalle utilità di backup integrate potrebbe fornire un maggiore controllo e flessibilità nella migrazione della manutenzione pianificata. Questi altri tipi di approcci ti consentono di eseguire trasformazioni, controlli o altre operazioni sui tuoi dati durante la migrazione. Puoi consolidare più istanze o database in una singola istanza o database. Il consolidamento delle istanze può contribuire a ridurre i costi operativi e a risolvere i problemi di scalabilità.

Un'alternativa di questo tipo alle utilità di backup è l'utilizzo di file flat per esportare e importare i dati. Per saperne di più sull'importazione di file flat, vedi Esportazione e importazione mediante file CSV per Cloud SQL per PostgreSQL.

Un'altra alternativa è utilizzare un'importazione gestita per configurare la replica da un database PostgreSQL esterno. Quando utilizzi un'importazione gestita, viene eseguito un caricamento iniziale dei dati dal database esterno nell'istanza Cloud SQL per PostgreSQL. Questo caricamento iniziale utilizza un servizio che estrae i dati dal server esterno (l'istanza RDS o Aurora) e li importa direttamente nell'istanza Cloud SQL per PostgreSQL. Per ulteriori informazioni, consulta Utilizzo di un'importazione gestita per configurare la replica da database esterni.

Un modo alternativo per eseguire una migrazione dei dati una tantum consiste nell'esportare le tabelle dal database PostgreSQL di origine in file CSV o SQL. Puoi quindi importare il file CSV o SQL in Cloud SQL per PostgreSQL o AlloyDB per PostgreSQL. Per esportare la data dell'istanza di origine, puoi utilizzare l'estensione aws_s3 per PostgreSQL. In alternativa, puoi utilizzare Amazon Database Migration Service e un bucket S3 come destinazione. Per informazioni dettagliate su questo approccio, consulta le seguenti risorse:

Puoi anche importare manualmente i dati in un'istanza AlloyDB per PostgreSQL. I formati supportati sono i seguenti:

  • CSV: con questo formato di file, ogni file contiene i contenuti di una tabella nel database. Puoi caricare i dati nel file CSV utilizzando il programma a riga di comando psql. Per saperne di più, vedi Importare un file CSV.
  • DMP: questo formato di file contiene l'archivio di un intero database PostgreSQL. Importa i dati da questo file utilizzando l'utilità pg_restore. Per ulteriori informazioni, vedi Importare un file DMP.
  • SQL: questo formato di file contiene la ricostruzione del testo di un database PostgreSQL. I dati in questo file vengono elaborati utilizzando la riga di comando psql. Per ulteriori informazioni, vedi Importare un file SQL.

Strumenti per le migrazioni di replica continua

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

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

Il diagramma di flusso precedente mostra i seguenti punti decisionali:

  • Preferisci utilizzare servizi di migrazione gestiti?

    • In caso affermativo, puoi permetterti alcuni secondi di inattività di scrittura durante il passaggio di replica?

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

    • In caso contrario, devi valutare se la replica integrata del motore del database è supportata:

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

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

Database Migration Service per la migrazione con replica continua

Database Migration Service fornisce un tipo di job specifico per le migrazioni continue. Questi job di migrazione continua supportano migrazioni ad alta fedeltà a Cloud SQL per PostgreSQL e ad AlloyDB per PostgreSQL.

Quando utilizzi Database Migration Service per eseguire la migrazione a Cloud SQL per PostgreSQL o AlloyDB per PostgreSQL, esistono prerequisiti e limitazioni associati a ogni istanza di destinazione:

Replica integrata del motore del database

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

La replica del database rappresenta il processo di copia e distribuzione dei dati da un database chiamato database principale ad altri database chiamati repliche. È progettato per aumentare l'accessibilità dei dati e migliorare la tolleranza agli errori e l'affidabilità di un sistema di database. Sebbene la migrazione del database non sia lo scopo principale della replica del database, può essere utilizzata con successo come strumento per raggiungere questo obiettivo. La replica del database è in genere un processo continuo che si verifica in tempo reale man mano che i dati vengono inseriti, aggiornati o eliminati nel database principale. La replica del database può essere eseguita come operazione una tantum o come sequenza di operazioni batch.

La maggior parte dei motori di database moderni implementa diversi modi per ottenere la replica del database. Un tipo di replica può essere ottenuto copiando e inviando il log write-ahead o il log delle transazioni della replica primaria alle relative repliche. Questo approccio è chiamato replica fisica o binaria. Altri tipi di replica funzionano distribuendo le istruzioni SQL non elaborate ricevute da un database primario, anziché replicare le modifiche a livello di file system. Questi tipi di replica sono chiamati replica logica. Per PostgreSQL, esistono anche estensioni di terze parti, come pglogical, che implementano la replica logica basandosi sul log write-ahead (WAL).

Cloud SQL supporta la replica per PostgreSQL. Tuttavia, esistono alcuni prerequisiti e limitazioni.

Di seguito sono riportati i limiti e i prerequisiti per Cloud SQL per PostgreSQL:

  • Sono supportate le seguenti versioni di Amazon:

    • Amazon RDS 9.6.10 e versioni successive, 10.5 e versioni successive, 11.1 e versioni successive, 12, 13, 14
    • Amazon Aurora 10.11 e versioni successive, 11.6 e versioni successive, 12.4 e versioni successive e 13.3 e versioni successive

  • Il firewall del server esterno deve essere configurato per consentire l'intervallo IP interno allocato per l'accesso ai servizi privati della rete VPC. Il database di replica Cloud SQL per PostgreSQL utilizza la rete VPC come rete privata.

  • Il firewall del database di origine deve essere configurato per consentire l'intero intervallo IP interno allocato per la connessione al servizio privato della rete VPC. L'istanza di destinazione Cloud SQL per PostgreSQL utilizza questa rete VPC nel campo privateNetwork dell'impostazione IpConfiguration.

  • Quando installi l'estensione pglogical su un'istanza Cloud SQL per PostgreSQL, assicurati di aver impostato il flag enable_pglogical su on (ad esempio, cloudsql.enable_pglogical=on).

  • Assicurati che il parametro shared_preload_libraries includa l'estensione pglogical nell'istanza di origine (ad esempio, shared_preload_libraries=pg_stat_statements,pglogical). Imposta il parametro rds.logical_replication su 1. Questa impostazione attiva i log write-ahead a livello logico.

    Queste modifiche richiedono il riavvio dell'istanza primaria.

Per saperne di più sull'utilizzo di Cloud SQL per PostgreSQL per la replica, consulta l'elenco di controllo del server esterno nella sezione sulla replica per PostgreSQL e anche Configura la replica e la decodifica logiche per PostgreSQL dalla documentazione ufficiale di Cloud SQL.

AlloyDB per PostgreSQL supporta la replica tramite l'estensione pglogical. Per attivare l'estensione pglogical per la replica, puoi utilizzare il comando CREATE EXTENSION. Prima di utilizzare questo comando, devi impostare i flag del database alloydb.enable_pglogical e alloydb.logical_decoding su on nell'istanza AlloyDB per PostgreSQL in cui vuoi utilizzare l'estensione. L'impostazione di questi flag richiede il riavvio dell'istanza.

Altri approcci per la migrazione con replica continua

Puoi utilizzare Datastream per replicare le modifiche quasi in tempo reale dell'istanza PostgreSQL di origine. Datastream utilizza Change Data Capture (CDC) e la replica per replicare e sincronizzare i dati. Puoi quindi utilizzare Datastream per la replica continua da Amazon RDS e Amazon Aurora. Utilizzi Datastream per replicare le modifiche dall'istanza PostgreSQL a BigQuery o Cloud Storage. Questi dati replicati possono poi essere importati nella tua istanza Cloud SQL per PostgreSQL e AlloyDB per PostgreSQL con Dataflow utilizzando un modello Dataflow Flex o con Dataproc.

Per ulteriori informazioni sull'utilizzo di Datastream e Dataflow, consulta le seguenti risorse:

Strumenti di terze parti per la migrazione della replica continua

In alcuni casi, è meglio utilizzare uno strumento di terze parti per la maggior parte dei motori di database. Questi casi possono verificarsi se preferisci utilizzare un servizio di migrazione gestito e devi assicurarti che il database di destinazione sia sempre sincronizzato quasi in tempo reale con l'origine oppure se hai bisogno di trasformazioni più complesse come la pulizia, la ristrutturazione e l'adattamento dei dati durante la procedura 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 end-to-end in memoria per raccogliere, filtrare, trasformare, arricchire, aggregare, analizzare e distribuire i dati in tempo reale:

  • Vantaggi:

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

  • Svantaggi:

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

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

  • Vantaggi:

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

  • Svantaggi:

    • Richiede esperienza specifica con Kafka e ZooKeeper.
    • Distribuzione "at-least-once" delle modifiche ai dati, il che significa che è necessario gestire i duplicati.
    • Configurazione manuale del monitoraggio utilizzando Grafana e Prometheus.
    • Nessun supporto per la replica batch incrementale.

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

Fivetran è una piattaforma di spostamento automatizzato dei dati per spostare i dati all'esterno e all'interno delle piattaforme di dati cloud.

  • Vantaggi:

    • Modelli di connessione preconfigurati e pipeline senza codice.
    • Propaga le modifiche allo schema dall'origine al database di destinazione.
    • Consegna exactly-once delle modifiche ai dati, il che significa che non è necessario gestire i duplicati.

  • Svantaggi:

    • Non open source.
    • Il supporto per la trasformazione complessa dei dati è limitato.

Definisci il piano di migrazione e le tempistiche

Per una migrazione del database e un cutover di produzione riusciti, ti consigliamo di 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 rivela 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à pre-migrazione o post-migrazione per implementare questo filtro. Inoltre, ti assicuri che la migrazione del database non influisca sull'accordo sul livello del servizio (SLA) e sul piano di continuità aziendale esistenti.

Ti consigliamo di includere nella documentazione di pianificazione della migrazione i seguenti documenti:

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

Le migrazioni dei database sono un processo iterativo e le prime migrazioni sono spesso più lente delle successive. In genere, le migrazioni ben pianificate vengono eseguite senza problemi, ma possono comunque sorgere problemi imprevisti. Ti consigliamo di avere sempre un piano di rollback. Come best practice, segui le indicazioni riportate in 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 quanto segue nel TDD:

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

Matrice RACI

Alcuni progetti di migrazione richiedono una matrice RACI, un documento comune di gestione dei progetti che definisce quali persone o gruppi sono responsabili di attività e risultati finali all'interno del progetto di migrazione.

Cronologia

Prepara una cronologia per ogni database di cui è necessario eseguire la migrazione. Includi tutte le attività di lavoro da svolgere, nonché le date di inizio definite e le date di fine stimate.

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

La cronologia deve tenere conto non solo 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 ci sono anche altri aspetti da considerare, come la complessità della logica di business, l'utilizzo dell'applicazione e la disponibilità del team.

Un piano T-Minus potrebbe avere il seguente aspetto:

Data Fase Categoria Tasks Ruolo T-minus Stato
1/11/2023 Pre-migrazione Valutazione Creare un report sul test Discovery team -21 Completa
7/11/2023 Pre-migrazione Preparazione del target Progetta l'ambiente di destinazione come descritto nel documento di progettazione Team di migrazione -14 Completa
15/11/2023 Pre-migrazione Governance aziendale Data di migrazione e approvazione del conto alla rovescia Leadership -6 Completa
18/11/2023 Migrazione Configurare DMS Creare profili di connessione Ingegnere della migrazione al cloud -3 Completa
19/11/2023 Migrazione Configurare DMS Crea e avvia job di migrazione Ingegnere della migrazione al cloud -2 Non avviato
19/11/2023 Migrazione Monitora DMS Monitorare i job DMS e le modifiche DDL nell'istanza di origine Ingegnere della migrazione al cloud -2 Non avviato
21/11/2023 Migrazione Cutover DMS Promuovi la replica DMS Ingegnere della migrazione al cloud 0 Non avviato
21/11/2023 Migrazione Convalida della migrazione Convalida della migrazione del database Team di migrazione 0 Non avviato
21/11/2023 Migrazione Test dell'applicazione Eseguire test di funzionalità e prestazioni Team di migrazione 0 Non avviato
22/11/2023 Migrazione Governance aziendale Convalida della migrazione OK o NO Team di migrazione 1 Non avviato
23/11/2023 Post-migrazione Convalidare il monitoraggio Configura il monitoraggio Team dell'infrastruttura 2 Non avviato
25/11/2023 Post-migrazione Sicurezza Rimuovere l'account utente DMS Team di sicurezza 4 Non avviato

Migrazioni di più database

Se hai più database da migrare, il tuo piano di migrazione deve contenere attività per tutte le migrazioni.

Ti consigliamo di iniziare la procedura eseguendo la migrazione di un database più piccolo, idealmente non mission-critical. Questo approccio può aiutarti ad acquisire conoscenza e sicurezza nel processo e negli strumenti di migrazione. Puoi anche rilevare eventuali difetti nel processo nelle prime fasi del programma di migrazione complessivo.

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

Attività di migrazione del database parallele.

Nell'esempio mostrato nel diagramma, i database 1-4 sono un gruppo di piccoli database che vengono migrati contemporaneamente.

Definisci le attività di preparazione

Le attività di preparazione sono tutte le attività che devi completare per soddisfare i prerequisiti per la migrazione. Senza le attività di preparazione, la migrazione non può avvenire o i risultati della migrazione fanno sì che il database migrato si trovi in uno stato inutilizzabile.

Le attività di preparazione possono essere classificate come segue:

  • Preparativi e prerequisiti per un'istanza Amazon RDS o Amazon Aurora
  • Preparazione del database di origine e prerequisiti
  • Configurazione delle istanze Cloud SQL per PostgreSQL e AlloyDB per PostgreSQL
  • Configurazione specifica per la migrazione

Preparazione e prerequisiti dell'istanza Amazon RDS o Amazon Aurora

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

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

  • Potresti dover configurare un nuovo gruppo di sicurezza per consentire connessioni remote sulle porte richieste e applicare il gruppo di sicurezza all'istanza Amazon RDS o Amazon Aurora:

    • Per impostazione predefinita, in AWS l'accesso alla rete è disattivato per le istanze di database.
    • Puoi specificare regole in un gruppo di sicurezza 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.

  • Se esegui la migrazione da Amazon RDS, assicurati di avere spazio libero sufficiente sul disco per memorizzare i log write-ahead per la durata dell'operazione di caricamento completo sull'istanza Amazon RDS.

  • Per la replica continua (streaming delle modifiche tramite CDC), devi utilizzare un'istanza RDS completa e non una replica di lettura.

  • Se utilizzi la replica integrata, devi configurare l'istanza Amazon RDS o Amazon Aurora per la replica per PostgreSQL. La replica integrata o gli strumenti che utilizzano la replica integrata richiedono la replica logica per PostgreSQL.

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

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

Preparazione del database di origine e prerequisiti

  • Se scegli di utilizzare Database Migration Service, configura il database di origine prima di connetterti. Per saperne di più, consulta Configura l'origine per PostgreSQL e Configura l'origine per PostgreSQL in AlloyDB per PostgreSQL.

  • Per le tabelle senza chiavi primarie, dopo che Database Migration Service esegue la migrazione del backup iniziale, solo le istruzioni INSERT verranno migrate al database di destinazione durante la fase CDC. Le istruzioni DELETE e UPDATE non vengono migrate per queste tabelle.

  • Tieni presente che gli oggetti di grandi dimensioni non possono essere replicati da Database Migration Service, in quanto la funzionalità di decodifica logica in PostgreSQL non supporta la decodifica delle modifiche agli oggetti di grandi dimensioni.

  • Se scegli di utilizzare la replica integrata, tieni presente che la replica logica presenta alcune limitazioni per quanto riguarda i comandi DDL (Data Definition Language), le sequenze e gli oggetti di grandi dimensioni. Le chiavi primarie devono esistere o essere aggiunte alle tabelle da attivare per la CDC e che vengono aggiornate spesso.

  • Alcuni strumenti di migrazione di terze parti richiedono che tutte le colonne di oggetti di grandi dimensioni siano nullabili. Qualsiasi colonna di oggetti di grandi dimensioni che sia NOT NULL deve essere rimossa durante la migrazione.

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

    • Misura le dimensioni dei dati e le prestazioni del carico di lavoro. Quanto tempo richiedono in media le query o le transazioni importanti? Quanto tempo durante le ore di punta?
    • Documenta le misurazioni di base per il confronto successivo, per aiutarti a decidere se la fedeltà della migrazione del database è soddisfacente. Decidi se puoi cambiare i carichi di lavoro di produzione e ritirare l'ambiente di origine o se ti serve ancora per il fallback.

Configurazione delle istanze Cloud SQL per PostgreSQL e AlloyDB per PostgreSQL

Per fare in modo che l'istanza di destinazione raggiunga livelli di prestazioni simili a quelli dell'istanza di origine, scegli le dimensioni e le specifiche dell'istanza del database PostgreSQL di destinazione in modo che corrispondano a quelle dell'istanza di origine. Presta particolare attenzione alle dimensioni e al throughput del disco, operazioni di I/O al secondo (IOPS) e al numero di CPU virtuali (vCPU). Il dimensionamento errato può comportare tempi di migrazione lunghi, problemi di prestazioni del database, errori del database e problemi di prestazioni dell'applicazione. Quando scegli l'istanza Cloud SQL per PostgreSQL o AlloyDB per PostgreSQL, tieni presente che le prestazioni del disco si basano sulle dimensioni del disco e sul numero di vCPU.

Prima di creare le istanze Cloud SQL per PostgreSQL e AlloyDB per PostgreSQL, devi confermare le seguenti proprietà e requisiti. Se vuoi modificare queste proprietà e questi requisiti in un secondo momento, dovrai ricreare le istanze.

  • Scegli con attenzione il progetto e la regione delle istanze Cloud SQL per PostgreSQL e AlloyDB for PostgreSQL di destinazione. Le istanze non possono essere migrate tra progetti e regioni senza trasferimento di dati. Google Cloud

  • Esegui la migrazione a una versione principale corrispondente su Cloud SQL per PostgreSQL e AlloyDB per PostgreSQL. Ad esempio, se utilizzi PostgreSQL 14.x su Amazon RDS o Amazon Aurora, devi eseguire la migrazione a Cloud SQL o AlloyDB per PostgreSQL per PostgreSQL versione 14.x.

  • Replica le informazioni utente separatamente se utilizzi backup motore del database integrati o Database Migration Service. Per maggiori dettagli, consulta la sezione Backup specifici del motore di database.

  • Esamina i flag di configurazione specifici del motore del database e confronta i valori dell'istanza di origine e di destinazione. Assicurati di comprenderne l'impatto e se devono essere uguali o meno. Ad esempio, quando lavori con PostgreSQL, ti consigliamo di confrontare i valori della tabella pg_settings nel database di origine con quelli nell'istanza Cloud SQL e AlloyDB per PostgreSQL. Aggiorna le impostazioni dei flag in base alle esigenze nell'istanza del database di destinazione per replicare le impostazioni di origine.

  • A seconda della natura del carico di lavoro, potrebbe essere necessario abilitare estensioni specifiche per supportare il database. Se il tuo workload richiede queste estensioni, esamina le estensioni PostgreSQL supportate e come attivarle in Cloud SQL e AlloyDB per PostgreSQL.

Per ulteriori informazioni sulla configurazione di Cloud SQL per PostgreSQL, consulta Opzioni di configurazione dell'istanza, Flag specifici del motore del database e estensioni supportate.

Per saperne di più sulla configurazione di AlloyDB per PostgreSQL, consulta Flag di database supportati e estensioni supportate.

Configurazione specifica della migrazione

Se puoi permetterti tempi di inattività, puoi importare i file di dump SQL in Cloud SQL e AlloyDB per PostgreSQL. In questi casi potrebbe essere necessario creare un bucket Cloud Storage per archiviare il dump del database.

Se utilizzi la replica, devi assicurarti che la replica Cloud SQL e AlloyDB per PostgreSQL abbia accesso al database primario (di origine). Questo accesso può essere ottenuto utilizzando le opzioni di connettività documentate.

A seconda del caso d'uso e della criticità, potrebbe essere necessario implementare uno scenario di failover, che in genere prevede l'inversione della direzione della replica. In questo caso, potresti aver bisogno di un meccanismo di replica aggiuntivo dalla tua istanza Cloud SQL e AlloyDB per PostgreSQL di destinazione alla tua istanza Amazon di origine.

Puoi ritirare le risorse che collegano l'ambiente Amazon eGoogle Cloud dopo che la migrazione è stata completata e convalidata.

Se esegui la migrazione ad AlloyDB per PostgreSQL, valuta la possibilità di utilizzare un'istanza Cloud SQL per PostgreSQL come potenziale destinazione per gli scenari di fallback. Utilizza l'estensione pglogical per configurare la replica logica nell'istanza Cloud SQL.

Per maggiori informazioni, consulta le seguenti risorse:

Definisci le attività di esecuzione

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

Backup motore del database integrati

Utilizza l'utilità pg_dump per creare un backup. Per saperne di più sull'utilizzo di questo strumento per importare ed esportare i dati, consulta le seguenti risorse:

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 workload possono permettersi un breve periodo di inattività per la migrazione e il cutover di produzione.

In Database Migration Service, la migrazione inizia con il dump e il ripristino dello schema iniziale senza indici e vincoli, seguito dall'operazione di copia dei dati. Al termine della copia dei dati, vengono ripristinati indici e vincoli. Infine, viene avviata la replica continua delle modifiche dall'origine all'istanza del database di destinazione.

Database Migration Service utilizza l'estensione pglogical per la replica dall'origine all'istanza del database di destinazione. All'inizio della migrazione, questa estensione configura la replica richiedendo blocchi esclusivi a breve termine su tutte le tabelle nell'istanza di origine Amazon RDS o Amazon Aurora. Per questo motivo, ti consigliamo di iniziare la migrazione quando il database è meno occupato ed evitare istruzioni sull'origine durante la fase di dump e replica, poiché le istruzioni DDL non vengono replicate. Se devi eseguire operazioni DDL, utilizza le funzioni "pglogical" per eseguire istruzioni DDL sull'istanza di origine o esegui manualmente le stesse istruzioni DDL sull'istanza di destinazione della migrazione, ma solo dopo il completamento della fase di dump iniziale.

Il processo di migrazione con Database Migration Service termina con l'operazione di promozione. La promozione di un'istanza di database disconnette il database di destinazione dal flusso di modifiche provenienti dal database di origine, quindi l'istanza di destinazione ora autonoma viene promossa a istanza primaria. Questo approccio è chiamato anche cambio di produzione.

Per una procedura di configurazione della migrazione completamente dettagliata, consulta le guide di avvio rapido per PostgreSQL e PostgreSQL ad AlloyDB per PostgreSQL.

Replica integrata del motore del database

Cloud SQL supporta due tipi di replica logica: la replica logica integrata di PostgreSQL e la replica logica tramite l'estensione pglogical. Per AlloyDB per PostgreSQL consigliamo di utilizzare l'estensione pglogical per la replica. Ogni tipo di replica logica ha le proprie funzionalità e limitazioni.

La replica logica integrata presenta le seguenti funzionalità e limitazioni:

  • È disponibile in PostgreSQL 10 e versioni successive.
  • Tutte le modifiche e le colonne vengono replicate. Le pubblicazioni sono definite a livello di tabella.
  • I dati vengono replicati solo dalle tabelle di base alle tabelle di base.
  • Non esegue la replica della sequenza.
  • È il tipo di replica consigliato quando ci sono molte tabelle senza chiave primaria. Configura la replica logica PostgreSQL integrata. Per le tabelle senza una chiave primaria, applica il modulo REPLICA IDENTITY FULL in modo che la replica integrata utilizzi l'intera riga come identificatore univoco anziché una chiave primaria.

La replica logica pglogical presenta le seguenti funzionalità e limitazioni:

  • È disponibile in tutte le versioni di PostgreSQL e offre il supporto tra le versioni.
  • Il filtro delle righe è disponibile nell'origine.
  • Non replica le tabelle UNLOGGED e TEMPORARY.
  • È necessaria una chiave primaria o univoca nelle tabelle per acquisire le modifiche UPDATE e DELETE.
  • La replica della sequenza è disponibile.
  • È possibile una replica ritardata.
  • Fornisce il rilevamento dei conflitti e la risoluzione configurabile in caso di più editori o conflitti tra i dati replicati e le modifiche locali.

Per istruzioni su come configurare la replica logica PostgreSQL integrata da un server esterno come Amazon RDS o Amazon Aurora per PostgreSQL, consulta le seguenti risorse:

Strumenti di terze parti

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

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

Utilizzi uno o più flussi per organizzare questi processi di migrazione all'interno delle tue applicazioni personalizzate. Per codificare le tue applicazioni personalizzate, puoi scegliere di utilizzare uno strumento di programmazione grafica o il linguaggio di programmazione Tungsten Query Language (TQL).

Per saperne di più su come utilizzare Striim, consulta le seguenti risorse:

Se decidi di utilizzare Striim per eseguire la migrazione dei dati, consulta le seguenti guide su come utilizzare Striim per eseguire la migrazione dei dati in Google Cloud:

Definisci gli scenari di riserva

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

Il fallback potrebbe richiedere un impegno significativo. Come best practice, non eseguire il cutover di produzione finché i risultati del test non sono soddisfacenti. Sia la migrazione del database sia lo scenario di fallback devono essere testati correttamente per evitare un'interruzione grave.

Definisci i criteri di successo e limita il tempo di esecuzione di tutte le attività di migrazione. L'esecuzione di una prova generale della migrazione consente di raccogliere informazioni sui tempi previsti per ogni attività. Ad esempio, per una migrazione di manutenzione pianificata, puoi permetterti il tempo di inattività rappresentato dalla finestra di cutover. Tuttavia, è importante pianificare la tua prossima azione nel caso in cui il job di migrazione una tantum o il ripristino del backup non vada a buon fine. A seconda del tempo di inattività pianificato trascorso, potresti dover posticipare la migrazione se l'attività di migrazione non termina nel tempo previsto.

Un piano di rollback in genere si riferisce al rollback della migrazione dopo l'esecuzione del cutover di produzione, se vengono visualizzati problemi nell'istanza di destinazione. Se implementi un piano di fallback, ricorda che deve essere trattato come una migrazione completa del database, inclusi pianificazione e test.

Se scegli di non avere un piano di riserva, assicurati di comprendere le possibili conseguenze. Non avere un piano di fallback può comportare un impegno imprevisto e causare interruzioni evitabili nel processo di migrazione.

Sebbene il fallback sia l'ultima risorsa e la maggior parte delle migrazioni di database non finisca per utilizzarlo, ti consigliamo di avere sempre una strategia di fallback.

Fallback semplice

In questa strategia di fallback, le applicazioni tornano all'istanza del database di origine originale. Adotta questa strategia se puoi permetterti tempi di inattività quando esegui il rollback o se non hai bisogno che le transazioni vengano eseguite sul nuovo sistema di destinazione.

Se hai bisogno di tutti i dati scritti nel database di destinazione e puoi permetterti un po' di inattività, puoi valutare la possibilità di interrompere le scritture nell'istanza del database di destinazione, eseguire backup integrati e ripristinarli nell'istanza di origine, quindi ricollegare le applicazioni all'istanza del database di origine iniziale. A seconda della natura del carico di lavoro e della quantità di dati scritti nell'istanza del database di destinazione, puoi inserirli nel sistema di database di origine iniziale in un secondo momento, soprattutto se i carichi di lavoro non dipendono da un orario di creazione specifico dei record o da vincoli di ordinamento temporale.

Replica inversa

In questa strategia, replichi le scritture che si verificano nel nuovo database di destinazione dopo il cutover di produzione nel database di origine iniziale. In questo modo, mantieni sincronizzata l'origine originale 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 fino a quando non esegui il cutover all'istanza del database di destinazione, pertanto non consente test end-to-end e ha un breve periodo di nessun fallback.

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

Replica in avanti

Questa strategia è una variante della replica inversa. Replichi le scritture nel nuovo database di destinazione in un'istanza di database di terze parti a tua scelta. Puoi indirizzare le tue applicazioni a questo terzo database, che si connette al server ed esegue query di sola lettura mentre il server non è disponibile. Puoi utilizzare qualsiasi meccanismo di replica, a seconda delle tue esigenze. Il vantaggio di questo approccio è che può essere testato completamente dall'inizio alla fine.

Adotta questo approccio quando vuoi essere coperto da un fallback in qualsiasi momento o quando devi eliminare il database di origine iniziale poco dopo il cutover di produzione.

Scritture duplicate

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

Le tue applicazioni scrivono sia nell'origine iniziale sia nelle istanze del database di destinazione, il che ti consente di eseguire un cutover graduale della produzione finché non utilizzi solo le istanze del database di destinazione. In caso di problemi, puoi ricollegare le tue applicazioni all'origine iniziale senza tempi di inattività. Puoi ignorare l'origine iniziale e il meccanismo di scrittura duplicato quando ritieni che la migrazione sia stata eseguita senza problemi.

Consigliamo questo approccio quando è fondamentale non avere tempi di inattività della migrazione, quando è presente un fallback affidabile e quando hai tempo e risorse per eseguire il refactoring dell'applicazione.

Eseguire test e convalida

Gli obiettivi di questo passaggio sono testare e convalidare quanto segue:

  • Migrazione riuscita dei dati nel database.
  • Integrazione con le applicazioni esistenti dopo che sono state modificate per utilizzare la 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:

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

Le configurazioni di archiviazione nell'ambiente di origine potrebbero non essere mappate direttamente alle destinazioni dell'ambienteGoogle Cloud . Ad esempio, configurazioni di volumi SSD per uso generico (gp2 e gp3) con prestazioni di burst IOPS o SSD con IOPS con provisioning. Per confrontare e dimensionare correttamente le istanze di destinazione, esegui il benchmark delle istanze di origine sia nelle fasi di valutazione che di convalida.

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

Per le configurazioni convenzionali basate su server, utilizza le misurazioni pertinenti osservate durante i picchi di carico. Per i modelli di capacità delle risorse flessibili come Aurora Serverless, valuta la possibilità di esaminare i dati storici delle metriche per osservare le tue esigenze di scalabilità.

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

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

Per eseguire un test end-to-end, incluso il test del piano di migrazione, esegui sempre una prova generale della migrazione. Una prova generale esegue la migrazione del database con ambito completo senza cambiare i carichi di lavoro di produzione e offre i seguenti vantaggi:

  • Consente di assicurarti che tutti gli oggetti e le configurazioni vengano migrati correttamente.
  • Ti aiuta a definire ed eseguire i casi di test di migrazione.
  • Fornisce informazioni sul tempo necessario per la migrazione effettiva, in modo da poter calibrare la cronologia.
  • Rappresenta un'occasione per testare, convalidare e adattare il piano di migrazione. A volte non è possibile pianificare tutto in anticipo, quindi questa funzionalità ti aiuta a individuare eventuali lacune.

Il test dei dati può essere eseguito su un piccolo insieme di database di cui eseguire la migrazione o sull'intero insieme. A seconda del numero totale di database e degli strumenti utilizzati per implementarne la migrazione, puoi decidere di adottare un approccio basato sul rischio. Con questo approccio, esegui la convalida dei dati su un sottoinsieme di database migrati tramite lo stesso strumento, soprattutto se questo strumento è un servizio di migrazione gestito.

Per i test, devi avere accesso ai database di origine e di destinazione ed eseguire le seguenti attività:

  • Confronta gli schemi di origine e di destinazione. Controlla se esistono tutte le tabelle e tutti gli eseguibili. Controlla i conteggi delle righe e confronta i dati a livello di database.
  • Esegui script di convalida dei dati personalizzati.
  • Verifica che i dati di cui è stata eseguita la migrazione siano visibili anche nelle applicazioni che sono passate all'utilizzo del database di destinazione (i dati di cui è stata eseguita la migrazione vengono letti tramite l'applicazione).
  • Esegui test di integrazione tra le applicazioni cambiate e il database di destinazione testando vari casi d'uso. Questi test includono la lettura e la scrittura dei dati nei database di destinazione tramite le applicazioni, in modo che i carichi di lavoro supportino completamente i dati migrati insieme a quelli appena creati.
  • Testa le prestazioni delle query di database più utilizzate per verificare se si verifica un degrado dovuto a configurazioni errate o 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 automatizzati è adattata per essere eseguita rispetto alle applicazioni cambiate.

Se utilizzi Database Migration Service come strumento di migrazione, consulta la versione PostgreSQL o PostgreSQL ad AlloyDB per PostgreSQL dell'argomento "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.

DVT può contribuire a semplificare il processo di convalida dei dati offrendo funzioni di convalida multilivello personalizzate per confrontare le tabelle di origine e di destinazione a livello di tabella, colonna e riga. Puoi anche aggiungere regole di convalida.

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

Il DVT 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 dei campi)
  • Confronto personalizzato dei risultati delle query

Per saperne di più sulla convalida dei dati, consulta il repository Git e Data Validation made easy with Google Cloud's Data Validation Tool.

Eseguire la migrazione

Le attività di migrazione includono le attività per supportare il trasferimento da un sistema all'altro.

Tieni presente le seguenti best practice per la migrazione dei dati:

  • Informa i team coinvolti ogni volta che inizia e termina un passaggio del piano.
  • Se uno qualsiasi dei passaggi richiede più tempo del previsto, confronta il tempo trascorso con il tempo massimo assegnato per quel passaggio. Invia aggiornamenti intermedi regolari ai team coinvolti quando si verifica questa situazione.
  • Se l'intervallo di tempo è superiore alla quantità massima di tempo riservata per ogni passaggio del piano, valuta la possibilità di eseguire il rollback.
  • Prendi decisioni "go or no-go" per ogni passaggio del piano di migrazione e di transizione.
  • Valuta le azioni di rollback o gli scenari alternativi per ciascuno dei passaggi.

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

Esegui il cutover di produzione

Il processo di cutover della produzione di alto livello può variare a seconda della strategia di migrazione scelta. Se puoi avere tempi di inattività sui tuoi carichi di lavoro, il cutover della migrazione inizia interrompendo le scritture nel database di origine.

Per le migrazioni con replica continua, in genere esegui i seguenti passaggi di alto livello nel processo di cutover:

  • Smetti di scrivere nel database di origine.
  • Svuota la fonte.
  • Interrompi il processo di replica.
  • Esegui il deployment delle applicazioni che puntano al nuovo database di destinazione.

Dopo la migrazione dei dati utilizzando lo strumento di migrazione scelto, devi 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 supera i tuoi criteri, puoi eseguire il cutover a livello di applicazione. Esegui il deployment dei carichi di lavoro di cui è stato eseguito il refactoring per utilizzare la nuova istanza di destinazione. Esegui il deployment delle versioni delle tue applicazioni che puntano alla nuova istanza del database di destinazione. I deployment possono essere eseguiti tramite aggiornamenti in sequenza, rilasci scaglionati o utilizzando un pattern di deployment blu/verde. Potrebbe verificarsi un periodo di inattività dell'applicazione.

Segui le best practice per il cutover della produzione:

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

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

Una volta completato il cutover, puoi eliminare i database di origine. Ti consigliamo di eseguire le seguenti azioni importanti prima della pulizia dell'istanza di origine:

  • Crea un backup finale di ogni database di origine. Questi backup forniscono uno stato finale dei database di origine. In alcuni casi, i backup potrebbero essere necessari anche per la conformità ad alcune normative sui dati.

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

  • Raccogli le statistiche del database dall'istanza di origine e confrontale con quelle dell'istanza di destinazione. Se le statistiche sono disparate, è difficile confrontare il rendimento dell'istanza di origine e dell'istanza di destinazione.

In uno scenario di failover, potresti voler implementare la replica delle scritture sull'istanza Cloud SQL nel database di origine originale. La configurazione è simile al processo di migrazione, ma viene eseguita al contrario: il database di origine iniziale diventa la nuova destinazione.

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

In alternativa, puoi utilizzare un'altra istanza e replicare le modifiche in questa istanza. Ad esempio, quando AlloyDB per PostgreSQL è una destinazione di migrazione, valuta la possibilità di configurare la replica in un'istanza Cloud SQL per PostgreSQL per scenari di fallback.

Oltre alla pulizia dell'ambiente di origine, devono essere eseguite le seguenti configurazioni critiche per le istanze Cloud SQL per PostgreSQL:

  • Configura un periodo di manutenzione per l'istanza principale per controllare quando possono verificarsi aggiornamenti che causano interruzioni.
  • Configura lo spazio di archiviazione sull'istanza in modo da avere almeno il 20% di spazio disponibile per ospitare eventuali operazioni di manutenzione del database critiche che Cloud SQL potrebbe eseguire. Per ricevere un avviso se lo spazio su disco disponibile scende al di sotto del 20%, crea unacriterio di avvisoo basata sulle metriche per la metrica di utilizzo del disco.

Non avviare un'operazione amministrativa prima che la precedente sia stata completata.

Per saperne di più sulla manutenzione e sulle best practice per le istanze Cloud SQL per PostgreSQL e AlloyDB per PostgreSQL, consulta le seguenti risorse:

Per ulteriori informazioni sulla manutenzione e sulle best practice, consulta la sezione Informazioni sulla manutenzione delle istanze Cloud SQL.

Ottimizzare l'ambiente dopo la migrazione

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

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

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

Per ulteriori informazioni sull'ottimizzazione dell'ambiente Google Cloud , vedi Migrazione a Google Cloud: ottimizza il tuo ambiente e Google Cloud Well-Architected Framework: ottimizzazione delle prestazioni.

Stabilire i requisiti di ottimizzazione

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

Aumentare l'affidabilità e la disponibilità del database

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

Aumentare il rapporto costo-efficacia dell'infrastruttura di database

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

Aumentare le prestazioni dell'infrastruttura di database

I problemi di prestazioni minori correlati al database hanno spesso il potenziale di influire sull'intera operazione. Per mantenere e aumentare le prestazioni dell'istanza Cloud SQL, considera le seguenti linee guida:

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

  • Assicurati che l'istanza non sia vincolata alla memoria o alla CPU.

    • Per i carichi di lavoro che richiedono molte risorse, assicurati che l'istanza abbia almeno 60 GB di memoria.
    • Per inserimenti, aggiornamenti o eliminazioni lenti del database, controlla le posizioni del writer e del database; l'invio di dati su lunghe distanze introduce latenza.

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

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

  • Controlla la posizione del lettore e del database. La latenza influisce maggiormente sulle prestazioni di lettura rispetto a quelle di scrittura.

Quando esegui la migrazione da Amazon RDS e Aurora per PostgreSQL a Cloud SQL per PostgreSQL, tieni presente le seguenti linee guida:

  • Utilizza la memorizzazione nella cache per migliorare le prestazioni di lettura. Esamina le varie statistiche dalla visualizzazione pg_stat_database. Ad esempio, il rapporto blks_hit / (blks_hit + blks_read) deve essere superiore al 99%. Se questo rapporto non è superiore al 99%, valuta la possibilità di aumentare le dimensioni della RAM della tua istanza. Per ulteriori informazioni, vedi PostgreSQL statistics collector.
  • Recupera spazio ed evita prestazioni scadenti dell'indice. A seconda della frequenza con cui i dati cambiano, imposta una pianificazione per eseguire il comando VACUUM su Cloud SQL per PostgreSQL.
  • Utilizza la versione Cloud SQL Enterprise Plus per aumentare i limiti di configurazione della macchina e la cache dei dati. Per saperne di più su Cloud SQL Enterprise Plus, consulta Introduzione alle versioni di Cloud SQL.
  • Passa ad AlloyDB per PostgreSQL. Se esegui il passaggio, puoi avere la piena compatibilità con PostgreSQL, un'elaborazione transazionale migliore e carichi di lavoro di analisi transazionale veloci supportati nel database di elaborazione. Ricevi anche un suggerimento per nuovi indici tramite la funzionalità Index Advisor.

Per saperne di più su come migliorare le prestazioni dell'infrastruttura di database Cloud SQL per PostgreSQL, consulta la documentazione sul miglioramento delle prestazioni di Cloud SQL per PostgreSQL.

Quando esegui la migrazione da Amazon RDS e Aurora per PostgreSQL ad AlloyDB per PostgreSQL, tieni presente le seguenti linee guida per aumentare le prestazioni dell'istanza del database AlloyDB per PostgreSQL:

Aumentare le funzionalità di osservabilità del database

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

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

    • Utilizza Cloud Monitoring per raccogliere le misurazioni del servizio e delle Google Cloud risorse che utilizzi. Cloud Monitoring include dashboard predefinite per diversi prodotti Google Cloud , inclusa una dashboard di monitoraggio di Cloud SQL.
    • Puoi creare dashboard personalizzate che ti aiutano a monitorare le metriche e configurare criteri di avviso per ricevere notifiche tempestive.
    • In alternativa, puoi valutare l'utilizzo di soluzioni di monitoraggio di terze parti integrate con Google Cloud, come Datadog e Splunk.

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

  • Cloud Trace raccoglie i dati di latenza e i piani di query eseguiti dalle applicazioni per aiutarti a monitorare la propagazione delle richieste nella tua applicazione.

  • Database Center fornisce una panoramica centralizzata del parco risorse di database assistita dall'AI. Puoi monitorare lo stato delle tue banche dati, la configurazione della disponibilità, la protezione dei dati, la sicurezza e la conformità del settore.

Per ulteriori informazioni su come aumentare l'osservabilità dell'infrastruttura di database, consulta le seguenti sezioni della documentazione:

Best practice e linee guida operative generali per Cloud SQL e AlloyDB per PostgreSQL

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

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

  • Se hai istanze di grandi dimensioni, ti consigliamo di suddividerle in istanze più piccole, se possibile.
  • Configura lo spazio di archiviazione per ospitare la manutenzione critica del database. Assicurati di avere almeno il 20% di spazio disponibile per ospitare eventuali operazioni di manutenzione critiche del database che Cloud SQL potrebbe eseguire.
  • Un numero eccessivo di tabelle del database può influire sul tempo di upgrade del database. Idealmente, punta ad avere meno di 10.000 tabelle per istanza.
  • Scegli le dimensioni appropriate per le tue istanze per tenere conto della conservazione dei log delle transazioni (binari), in particolare per le istanze con attività di scrittura elevata.

Per poter gestire in modo efficiente eventuali problemi di prestazioni del database che potresti riscontrare, segui le seguenti linee guida finché il problema non viene risolto:

Aumentare le dimensioni dell'infrastruttura: aumenta le risorse (come velocità effettiva del disco, vCPU e RAM). A seconda dell'urgenza, della disponibilità e dell'esperienza del tuo team, lo scalabilità verticale dell'istanza può risolvere la maggior parte dei problemi di prestazioni. In un secondo momento, puoi esaminare ulteriormente la causa principale del problema in un ambiente di test e valutare le opzioni per eliminarla.

Esegui e pianifica operazioni di manutenzione del database: deframmentazione dell'indice, aggiornamenti delle statistiche, analisi del vacuum e reindicizzazione delle tabelle aggiornate di frequente. Controlla se e quando sono state eseguite l'ultima volta queste operazioni di manutenzione, soprattutto sugli oggetti interessati (tabelle, indici). Scopri se si è verificato un cambiamento rispetto alle normali attività del database. Ad esempio, l'aggiunta recente di una nuova colonna o molti aggiornamenti a una tabella.

Esegui l'ottimizzazione e l'aggiustamento del database: le tabelle del database sono strutturate correttamente? Le colonne hanno i tipi di dati corretti? Il tuo modello di dati è adatto al tipo di carico di lavoro? Esamina le query lente e i relativi piani di esecuzione. Utilizzano gli indici disponibili? Controlla la presenza di scansioni di indici, blocchi e attese su altre risorse. Valuta la possibilità di aggiungere indici per supportare le query critiche. Elimina gli indici e le chiavi esterne non critici. Valuta la possibilità di riscrivere query e unioni complesse. Il tempo necessario per risolvere il problema dipende dall'esperienza e dalla disponibilità del tuo team e può variare da ore a giorni.

Scalare le letture: valuta la possibilità di utilizzare repliche di lettura. Quando lo scaling verticale non è sufficiente per le tue esigenze e le misure di ottimizzazione e ottimizzazione del database non sono utili, valuta lo scaling orizzontale. Il routing delle query di lettura dalle tue applicazioni a una replica di lettura migliora le prestazioni complessive del carico di lavoro del database. Tuttavia, potrebbe essere necessario un ulteriore sforzo per modificare le applicazioni in modo che si connettano alla replica di lettura.

Riprogettazione del database: valuta la possibilità di partizionare e indicizzare il database. Questa operazione richiede uno sforzo significativamente maggiore rispetto alla messa a punto e all'ottimizzazione del database e potrebbe comportare una migrazione dei dati, ma può essere una soluzione a lungo termine. A volte, una progettazione scadente del modello dei dati può causare problemi di prestazioni, che possono essere parzialmente compensati dallo scale up verticale. Tuttavia, un modello dei dati adeguato è una soluzione a lungo termine. Valuta la possibilità di partizionare le tabelle. Se possibile, archivia i dati che non sono più necessari. Normalizza la struttura del database, ma ricorda che la denormalizzazione può anche migliorare il rendimento.

Sharding del database: puoi fare lo scale out le scritture eseguendo lo sharding del database. Lo sharding è un'operazione complessa e comporta la riprogettazione del database e delle applicazioni in un modo specifico e l'esecuzione della migrazione dei dati. Dividi l'istanza del database in più istanze più piccole utilizzando criteri di partizionamento specifici. I criteri possono essere basati sul cliente o sull'oggetto. Questa opzione ti consente di scalare orizzontalmente sia le scritture che le letture. Tuttavia, aumenta la complessità dei carichi di lavoro del database e delle applicazioni. Potrebbe anche portare a shard sbilanciati chiamati hotspot, che supererebbero il vantaggio dello sharding.

Per Cloud SQL per PostgreSQL e AlloyDB per PostgreSQL, considera le seguenti best practice:

  • Per ridurre il traffico dell'istanza principale, aggiungi repliche di lettura. Puoi anche utilizzare un bilanciatore del carico come HAProxy per gestire il traffico verso le repliche. Tuttavia, evita troppe repliche, in quanto ciò ostacola l'operazione VACUUM. Per ulteriori informazioni sull'utilizzo di HAProxy, consulta il sito web ufficiale di HAProxy.
  • Ottimizza l'operazione VACUUM aumentando la memoria di sistema e il parametro maintenance_work_mem. L'aumento della memoria di sistema significa che è possibile raggruppare più tuple in ogni iterazione.
  • Poiché gli indici più grandi consumano una quantità significativa di tempo per la scansione dell'indice, imposta il parametro INDEX_CLEANUP su OFF per pulire e bloccare rapidamente i dati della tabella.
  • Quando utilizzi AlloyDB per PostgreSQL, utilizza la dashboard System Insights e i log di controllo di AlloyDB per PostgreSQL. La dashboard di AlloyDB per PostgreSQL System Insights mostra le metriche delle risorse che utilizzi e ti consente di monitorarle. Per maggiori dettagli, consulta le linee guida nell'argomento Monitorare le istanze della documentazione di AlloyDB per PostgreSQL.

Per maggiori dettagli, consulta le risorse seguenti:

Passaggi successivi

Collaboratori

Autori:

Altro collaboratore: Somdyuti Paul | Specialista in gestione dei dati