Migrazione da AWS a Google Cloud: migrazione da Amazon RDS e Amazon Aurora per PostgreSQL a Cloud SQL e AlloyDB per PostgreSQL

Last reviewed 2024-09-12 UTC

Google Cloud offre strumenti, prodotti, indicazioni e servizi di servizi di cui eseguire la migrazione da Amazon Relational Database Service (RDS) o Amazon da 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 prevista per i responsabili delle decisioni che stanno valutando l'opportunità di migrare e desiderano di una migrazione.

Questo documento si concentra su una migrazione del database omogenea, ovvero una migrazione in cui i database di origine e di destinazione hanno la stessa tecnologia di database. Nella 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 di articoli 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 Eseguire la migrazione a Google Cloud: inizia.

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

Percorso di migrazione diviso in quattro fasi.

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

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

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

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

Valutare l'ambiente di origine

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

La fase di valutazione è fondamentale per il successo della migrazione. Devi acquisire conoscenze approfondite sui carichi di lavoro di cui vuoi eseguire la migrazione, sui relativi requisiti, sulle dipendenze e sul tuo ambiente attuale. Per pianificare ed eseguire correttamente una migrazione a Google Cloud, devi conoscere il punto di partenza.

La fase di valutazione è composta dalle seguenti attività:

  1. Crea un inventario completo dei tuoi carichi di lavoro.
  2. Cataloga i carichi di lavoro in base alle loro proprietà e dipendenze.
  3. Forma e istruisci i tuoi team su Google Cloud.
  4. Crea esperimenti e proof of concept su Google Cloud.
  5. Calcola il costo totale di proprietà (TCO) dell'ambiente di destinazione.
  6. Scegli la strategia di migrazione per i tuoi carichi di lavoro.
  7. Scegli gli strumenti di migrazione.
  8. Definisci il piano 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 corrispondenti all'origine per esigenze di prestazioni simili. Presta particolare attenzione alle dimensioni del disco e alla velocità effettiva, IOPS e numero di vCPU. Le migrazioni potrebbero non riuscire o non riuscire a causa di una dimensione errata dell'istanza del database di destinazione. Le dimensioni non corrette possono comportare tempi di migrazione lunghi volte, problemi di prestazioni del database, errori del database e o problemi di prestazioni. Quando scegli l'istanza Cloud SQL, tieni presente che le prestazioni del disco si basano sulle dimensioni del disco e sul numero di vCPU.

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

Crea un inventario delle tue istanze Amazon RDS o Amazon Aurora

Per definire l'ambito della migrazione, devi creare un inventario e raccogliere informazioni sulle tue istanze Amazon RDS e Amazon Aurora. L'ideale è che questo dovrebbe essere un processo automatizzato perché gli approcci manuali sono soggetti a errori e può portare a ipotesi errate.

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

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

Strumenti per i test

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

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

Per ulteriori informazioni sulla valutazione del tuo ambiente AWS utilizzando Migration Center, consulta Importare i dati da altri provider cloud.

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

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

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

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

Per alcuni esempi di output della valutazione, consulta migVisor - Cloud migration assessment tool.

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

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

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

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

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

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

In questa fase, devi documentare le informazioni essenziali che influiscono sulla strategia e sugli strumenti di migrazione. A questo punto, puoi rispondere alle seguenti domande domande:

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

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

Stabilisci delle linee di base per la migrazione dei dati che ti aiutino a confrontare e valutare i risultati e gli impatti. Queste basi sono punti di riferimento che rappresentano lo stato dei dati prima e dopo la migrazione e per aiutarti a prendere decisioni. È importante effettuare misurazioni sull'ambiente di origine, per poter Valutare il successo della migrazione dei dati. Tali misurazioni includono seguenti:

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

Determina il tempo di riposo che puoi permetterti. Quali sono gli impatti del tempo di riposo sull'attività? Esistono periodi di bassa attività del database, durante i quali il tempo di riposo riguarda meno utenti? In caso affermativo, quanto durano questi periodi e quando si verificano? Valuta la possibilità di avere un tempo di inattività parziale in scrittura e in sola lettura vengono comunque gestite.

Valuta il processo di deployment e amministrazione

Dopo aver creato gli inventari, valuta il funzionamento e il deployment per il database al fine di determinare come devono essere adattati per facilitare la migrazione. Questi processi sono fondamentali per la preparazione e mantenere l'ambiente di produzione.

Valuta come completare le seguenti attività:

  • Definisci e applica i criteri di sicurezza per le tue istanze. Ad esempio, potresti dover sostituire i gruppi di sicurezza Amazon. Puoi utilizzare la modalità Ruoli IAM di Google, regole firewall VPC e Controlli di servizio VPC per controllare l'accesso alle istanze Cloud SQL per PostgreSQL vincolare i dati all'interno di un VPC.

  • Applica le patch e configura le istanze. Potrebbe essere necessario aggiornare gli strumenti di deployment esistenti. Ad esempio, è possibile che tu stia utilizzando impostazioni di configurazione nei gruppi di parametri Amazon o nei gruppi di opzioni Amazon. Potrebbe essere necessario adattare gli strumenti di provisioning per poter usare Cloud Storage o Secret Manager per leggere questo di configurazione automatica.

  • Gestisci l'infrastruttura di monitoraggio e generazione di avvisi. Categorie di metriche per le istanze del database di origine Amazon offrono l'osservabilità durante di migrazione. Le categorie di metriche possono includere Amazon CloudWatch, Performance Insights, il monitoraggio avanzato e gli elenchi di processi del sistema operativo.

Completa la valutazione

Dopo aver creato gli inventari dal tuo ambiente Amazon RDS o Amazon Aurora, completa le restanti attività della fase di valutazione come descritto in Eseguire la migrazione a Google Cloud: valutare e scoprire i carichi di lavoro.

Pianifica e costruisci le tue basi

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

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

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

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

Per ulteriori informazioni su ciascuna di queste attività, consulta Esegui la migrazione a Google Cloud: pianifica e costruisci le tue basi.

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

Monitoraggio e avvisi

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

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

Per eseguire la migrazione delle istanze, segui questi passaggi:

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

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

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

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

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

  8. Esegui la migrazione.

  9. Esegui il passaggio alla produzione.

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

  11. Esegui il tuning e l'ottimizzazione.

Ogni fase è descritta nelle sezioni seguenti.

Scegli la strategia di migrazione

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

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

  • Replica continua (detta anche migrazione persistente): per mission critical, questa opzione offre un rischio minore di perdita di dati con tempi di inattività quasi azzerati. Le operazioni vengono suddivise in più parti, quindi, se si verifica un errore, il rollback e la ripetizione richiedono meno tempo. Tuttavia, la configurazione è più complessi e richiede più tempo e pianificazione. È necessario anche un ulteriore impegno necessario per il refactoring delle applicazioni che si connettono al tuo database di Compute Engine. Valuta una delle seguenti varianti:

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

Per ulteriori informazioni sulle strategie di migrazione dei dati, consulta Valutare gli approcci alla migrazione dei dati.

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

Diagramma di flusso che ti consente di scegliere la strategia di migrazione.

Il diagramma di flusso precedente mostra i seguenti punti decisionali:

  • Puoi permetterti un tempo di riposo?

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

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

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

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

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

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

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

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

  • Le query del database possono richiedere alcuni secondi. Al momento della migrazione, le query in corso potrebbero essere interrotte.
  • Il riempimento della cache potrebbe richiedere del tempo se il database è di grandi dimensioni o se ha una memoria buffer considerevole.
  • Applicazioni arrestate nell'origine e riavviate in Google Cloud potrebbe verificarsi un leggero ritardo prima che la connessione a Google Cloud dell'istanza del database.
  • Le route di rete alle applicazioni devono essere reindirizzate. In base a come Le voci DNS sono state configurate. L'operazione potrebbe richiedere del tempo. Quando aggiorni i record DNS, riduci il TTL prima della migrazione.

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

  • Trova un periodo di tempo in cui il tempo di riposo abbia un impatto minimo sul tuo carichi di lavoro con scale out impegnativi. Ad esempio, al di fuori del normale orario di lavoro, durante i fine settimana o altre finestre di manutenzione programmate.
  • Identifica le parti dei carichi di lavoro che possono essere sottoposte a migrazione e al passaggio alla produzione in fasi diverse. Le applicazioni potrebbero avere componenti diversi che possono essere isolati, adattati e migrati senza impatto. Ad esempio, frontend, moduli CRM, servizi di backend e piattaforme di reporting. Questi moduli potrebbero avere i propri database per i quali è possibile pianificare la migrazione in un momento precedente o successivo del processo.
  • Se puoi permetterti un po' di latenza nel database di destinazione, valuta la possibilità di implementare una migrazione graduale. Utilizza trasferimenti di dati incrementali e raggruppati e adatta parte dei tuoi carichi di lavoro per lavorare con i dati obsoleti sull'istanza di destinazione.
  • Valuta la possibilità di eseguire il refactoring delle applicazioni per supportare una migrazione minima impatto. Ad esempio, puoi adattare le applicazioni in modo che scrivano sia all'origine che di destinazione, quindi implementano una replica a livello di applicazione.

Scegli gli strumenti di migrazione

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

Sono disponibili molti strumenti, ciascuno ottimizzato per determinati casi d'uso della migrazione. Ecco alcuni casi d'uso:

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

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

I servizi di migrazione gestita offrono i seguenti vantaggi:

  • Riduci al minimo il tempo di inattività: i servizi utilizzano la replica integrata funzionalità dei motori del database, se disponibili, ed eseguire la promozione della replica.

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

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

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

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

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

Strumenti per migrazioni di manutenzione pianificate

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

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

Backup del motore del database integrato

Quando sono accettabili tempi di riposo significativi e i database di origine sono relativamente statici, puoi utilizzare le funzionalità di dump e caricamento (a volte chiamate anche backup e ripristino) integrate nel motore del database.

È richiesto un certo impegno per l'impostazione e la sincronizzazione, soprattutto per un di database, ma i backup del motore del database sono solitamente immediatamente disponibili e facile da usare. Questo approccio è adatto a qualsiasi dimensione del database ed è solitamente più efficace di altri strumenti per le istanze di grandi dimensioni.

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

  • I backup possono essere soggetti a errori, in particolare se eseguiti manualmente.
  • I dati possono non essere protetti se gli snapshot non vengono gestiti correttamente.
  • I backup non dispongono di funzionalità di monitoraggio adeguate.
  • La scalabilità dei backup richiede un impegno durante 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, gli strumenti pg_dump e pg_dumapall presentano le seguenti limitazioni generali:

  • Le utilità di backup integrate devono essere utilizzate per la migrazione dei database non superino i 500 GB. Il dump e il ripristino di database di grandi dimensioni possono richiedere potrebbe richiedere molto spazio su disco e memoria.
  • 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 hai database più grandi di 5 TB, su 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 in considerazione le seguenti limitazioni e best practice:

  • Comprimi i dati per ridurre i costi e la durata del trasferimento. Usa --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 e il livello di compressione da usare. I valori accettati per questa opzione sono compresi tra 0 a 9. Il valore predefinito è la compressione a un livello di 6. I valori più alti diminuiscono le dimensioni del file di dump, ma possono causare un consumo elevato di risorse dell'host client. Se l'host client dispone di risorse sufficienti, livelli di compressione più elevati possono ridurre ulteriormente le dimensioni del file dump.
  • Utilizza i flag corretti quando crei un file di dump SQL.
  • Verifica il database importato. Monitora l'output dell'pg_restore per eventuali messaggi di errore durante il processo di ripristino. Controlla i log PostgreSQL per verificare la presenza di 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 rispetto alle utilità di backup integrate potrebbe fornire un controllo e flessibilità nella migrazione di manutenzione pianificata. Queste altre consentono di eseguire trasformazioni, controlli o altre operazioni sui dati durante la migrazione. Puoi unificare più istanze o database in un'unica istanza o un unico database. Il consolidamento delle istanze può contribuire a ridurre i costi operativi e semplificare i problemi di scalabilità.

Un'alternativa a queste utilità di backup è l'utilizzo di file di testo per esportare e importare i dati. Per saperne di più sull'importazione di file di tipo flat, consulta Esportare e importare utilizzando file CSV per Cloud SQL per PostgreSQL.

Un'altra alternativa è utilizzare un'importazione gestita per configurare la replica da un 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 dati dall'interfaccia il server web, l'istanza RDS o Aurora, e lo importa Cloud SQL per PostgreSQL. Per ulteriori informazioni, vedi utilizza un'importazione gestita per configurare la replica da database esterni.

Un modo alternativo per eseguire una migrazione una tantum dei dati è quello di esportare dal database PostgreSQL di origine ai file CSV o SQL. Puoi quindi importare il file CSV o SQL in Cloud SQL per PostgreSQL oppure 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. La supportati sono i seguenti:

  • CSV: con questo formato, ogni file contiene i contenuti di una tabella nel database. Puoi caricare i dati nel file CSV mediante il programma a riga di comando psql. Per ulteriori informazioni, vedi Importa un file CSV.
  • DMP: questo formato file contiene l'archivio di un intero file PostgreSQL per configurare un database. Importa i dati da questo file utilizzando l'utilità pg_restore. Per ulteriori informazioni, consulta Importare un file DMP.
  • SQL: questo formato 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, consulta Importare un file SQL.

Strumenti per le migrazioni con replica continua

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

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

Il diagramma di flusso precedente mostra i seguenti punti decisionali:

  • Preferisci utilizzare i servizi di migrazione gestiti?

    • In caso affermativo, puoi permetterti qualche secondo di tempo di riposo per le scritture durante il passaggio di replica?

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

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

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

Le seguenti sezioni descrivono gli strumenti che possono essere utilizzati per migrazioni, nonché i relativi limiti 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 continui supportano migrazioni ad alta fedeltà verso da Cloud SQL per PostgreSQL e ad AlloyDB per PostgreSQL.

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

Replica integrata del motore del database

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

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

La maggior parte dei motori di database moderni implementa modi diversi per ottenere il database la replica dei dati. Un tipo di replica può essere ottenuto copiando e inviando log write-forward dell'istanza principale nelle sue repliche. Questo approccio è chiamato replica fisica o binaria. Altri tipi di replica funzionano distribuendo le istruzioni SQL non elaborate che un database principale riceve, anziché replicare le modifiche a livello di file system. Queste repliche vengono chiamati replica logica. Per PostgreSQL, ci sono anche soluzioni di terze parti come pglogical, che implementano la replica logica basandosi su log write-ahead (WAL).

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

Di seguito sono riportati i limiti e i prerequisiti di 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 in modo da consentire intervallo IP interno allocato per l'accesso privato ai servizi della rete VPC. Il database 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 il servizio privato della rete VPC. L'istanza di destinazione Cloud SQL per PostgreSQL utilizza questa rete VPC nel campo privateNetwork della sua impostazione IpConfiguration.

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

  • Assicurati che il parametro shared_preload_libraries includa il parametro pglogical sull'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 principale.

Per ulteriori informazioni sull'utilizzo di Cloud SQL per PostgreSQL per la replica, consulta la lista di controllo del server esterno nella sezione sulla replica per PostgreSQL e anche Configurare la replica e la decodifica logiche per PostgreSQL nella documentazione ufficiale di Cloud SQL.

AlloyDB per PostgreSQL supporta la replica tramite l'estensione pglogical. A abilitare l'estensione pglogical per la replica, puoi utilizzare Comando CREATE EXTENSION. Prima di utilizzare questo comando, devi impostare il parametro flag di database alloydb.enable_pglogical e alloydb.logical_decoding in 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 della tua 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 dalla tua istanza PostgreSQL a BigQuery o Cloud Storage. Questo puoi trasferire i dati replicati in Cloud SQL per PostgreSQL e AlloyDB per PostgreSQL con Dataflow utilizzando un'istanza modello flessibile Dataflow o con Dataproc.

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

Strumenti di terze parti per la migrazione della replica continua

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

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

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

  • Vantaggi:

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

  • Svantaggi:

Per ulteriori informazioni su Striim, consulta Eseguire Striim in Google Cloud.

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

  • Vantaggi:

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

  • Svantaggi:

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

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

Fivetran è una piattaforma di spostamento dei dati automatizzata per spostare i dati da e tra piattaforme di dati cloud.

  • Vantaggi:

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

  • Svantaggi:

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

Definisci il piano e le tempistiche della migrazione

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

La definizione dell'ambito della migrazione rivela le attività da eseguire prima, durante e dopo il processo di migrazione del database. Ad esempio, se decidi di non eseguire la migrazione di determinate tabelle da un database, potresti aver bisogno di attività di pre-migrazione o post-migrazione per implementare questo filtro. Inoltre, assicurati che la migrazione del database non influisca sull'accordo sul livello del servizio (SLA) e sul piano di continuità aziendale esistenti.

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

  • Documento di progettazione tecnica (TDD)
  • Matrice RACI
  • Tempistiche (ad esempio un piano T-Minus)

Le migrazioni dei database sono un processo iterativo e le prime migrazioni sono spesso più lente di quelle successive. In genere, le migrazioni pianificate vengono eseguite senza problemi, ma possono comunque verificarsi problemi imprevisti. Ti consigliamo di avere sempre un piano di rollback. Come best practice, segui le indicazioni Eseguire la migrazione a Google Cloud: best practice per la convalida di un piano di migrazione.

TDD

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

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

Matrice RACI

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

Spostamenti

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

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

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

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

Un piano T-Minus potrebbe avere il seguente aspetto:

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

Più migrazioni del database

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

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

Se devi eseguire la migrazione di più database, le cronologie possono essere parallelizzate. Ad esempio, per velocizzare il processo di migrazione, puoi scegliere di eseguire contemporaneamente la migrazione di un gruppo di database di piccole dimensioni, statici o meno critici, come mostrato nel seguente diagramma.

Attività di migrazione del database parallele.

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

Definisci le attività di preparazione

Le attività di preparazione sono tutte le attività che devi completare per soddisfare i prerequisiti della migrazione. Senza le attività di preparazione, la migrazione non può essere eseguita o il database di destinazione della migrazione risulta in uno stato inutilizzabile.

Le attività di preparazione possono essere categorizzate 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 delle istanze Amazon RDS o Amazon Aurora

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

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

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

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

  • Se stai eseguendo la migrazione da Amazon RDS, assicurati di disporre di un numero sufficiente disco libero per il buffer dei log write-ahead per la durata del carico completo sull'istanza Amazon RDS.

  • Per la replica continua (modifiche in streaming 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 la utilizzano richiedono la replica logica per PostgreSQL.

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

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

Preparazione e prerequisiti del database di origine

  • Se scegli di utilizzare Database Migration Service, configura il database di origine prima di collegarla. Per ulteriori informazioni, vedi Configura l'origine per PostgreSQL e Configura l'origine per PostgreSQL su AlloyDB per PostgreSQL.

  • Per le tabelle senza chiavi primarie, dopo che Database Migration Service ha eseguito la migrazione del backup iniziale, durante la fase CDC verrà eseguita la migrazione solo delle istruzioni INSERT al database di destinazione. Estratti conto DELETE e UPDATE per quelle tabelle.

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

  • Se scegli di utilizzare la replica integrata, tieni presente che la replica logica presenta alcune limitazioni rispetto ai comandi DDL (Data Definition Language), alle sequenze e agli oggetti di grandi dimensioni. Le chiavi principali devono esistere o essere aggiunte alle tabelle che devono essere attivate per la CDC e che vengono sottoposte a molti aggiornamenti.

  • Alcuni strumenti di migrazione di terze parti richiedono che tutte le colonne degli oggetti di grandi dimensioni sono null. Per le colonne di oggetti di grandi dimensioni con valore NOT NULL, il vincolo deve essere rimosso durante la migrazione.

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

    • Misura le dimensioni dei dati e le prestazioni del tuo carico di lavoro. Quanto tempo richiedono in media query o transazioni importanti? Quanto dura durante le ore di punta?
    • Documentare le misurazioni di riferimento per un confronto successivo, per aiutare deciderai se la fedeltà della migrazione del database è soddisfacente. Decidi se puoi spostare i carichi di lavoro di produzione e ritirare il tuo ambiente di origine o se ne hai ancora bisogno 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 del tuo PostgreSQL di destinazione dell'istanza di database in modo che corrispondano a quelli dell'istanza di origine. Presta particolare attenzione alle dimensioni e alla velocità effettiva del disco, alle operazioni di I/O al secondo (IOPS) e al numero di CPU virtuali (vCPU). Una dimensione errata può comportare tempi di migrazione lunghi, problemi di prestazioni del database, errori del database e problemi di prestazioni dell'applicazione. Quando scegli l'istanza Cloud SQL 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 modificare queste proprietà e questi requisiti in un secondo momento, dovrai di ricreare le istanze.

  • Scegli il progetto e la regione del target Istanze Cloud SQL per PostgreSQL e AlloyDB per PostgreSQL con attenzione. Non è possibile eseguire la migrazione di istanze tra progetti Google Cloud e regioni senza trasferimento di dati.

  • 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 la versione 14.x di PostgreSQL.

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

  • Esamina i flag di configurazione specifici del motore del database e confronta i valori delle istanze di origine e di destinazione. Assicurati di comprendere le e se devono essere uguali o meno. Ad esempio, quando lavorando con PostgreSQL, ti consigliamo di confrontare i valori pg_settings del database di origine a quella del database Istanza Cloud SQL e AlloyDB per PostgreSQL. Aggiorna flag le impostazioni in base alle esigenze sull'istanza del database di destinazione per replicare l'origine impostazioni.

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

Per saperne di più 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 per la migrazione

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

Se utilizzi la replica, devi assicurarti che Cloud SQL e La replica AlloyDB per PostgreSQL ha accesso al tuo database principale (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 riserva, che in genere prevede l'inversione della direzione della replica. In questo caso, potresti aver bisogno di un ulteriore meccanismo di replica da Cloud SQL e AlloyDB per PostgreSQL di destinazione all'istanza Amazon di origine.

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

Se esegui la migrazione ad AlloyDB per PostgreSQL, ti consigliamo di utilizzare un'istanza Cloud SQL per PostgreSQL come potenziale destinazione per gli scenari di riserva. Utilizza l'estensione pglogical per configurare la replica logica di Cloud SQL.

Per maggiori informazioni, consulta le seguenti risorse:

Definisci le attività di esecuzione

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

Backup integrati del motore del database

Usa l'utilità pg_dump per creare un backup. Per ulteriori informazioni sull'utilizzo di questa utility 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 una di origine al database di destinazione. I job di migrazione si connettono dell'istanza del database di origine tramite profili di connessione definiti dall'utente.

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

In Database Migration Service, la migrazione inizia con il dump iniziale dello schema e il suo successivo ripristino senza indici e vincoli, seguito dall'operazione di copia dei dati. Al termine della copia dei dati, gli indici e i vincoli vengono ripristinati. Infine, replica continua delle modifiche dall'origine al database di destinazione dell'istanza di Compute Engine.

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 dell'istanza Amazon RDS o Amazon Aurora di origine. Per questo motivo, ti consigliamo di avviare la migrazione quando il database è meno occupato ed evitare gli statement sull'origine durante la fase di dump e di replica, poiché gli statement DDL non vengono replicati. Se devi eseguire per le operazioni DDL, utilizza il comando "pglogical" per eseguire istruzioni DDL sul tuo di origine o eseguire manualmente le stesse istruzioni DDL sulla destinazione dell'istanza, ma solo al termine 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 delle modifiche provenienti dal database di origine, poi l'istanza di destinazione autonoma viene promossa a istanza principale. Questo approccio è anche chiamato passaggio alla produzione.

Per una procedura di configurazione della migrazione completamente dettagliata, consulta le guide di avvio rapido per PostgreSQL e da 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 ti consigliamo di utilizzare Estensione pglogical per la replica. Ogni tipo di replica logica ha la sua 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 da tabelle di base a tabelle di base.
  • Non esegue la replica della sequenza.
  • È il tipo di replica consigliato quando sono presenti molte tabelle senza chiave primaria. Configura la replica logica PostgreSQL integrata. Per le tabelle senza una chiave primaria, applica il formato 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.
  • I filtri per le righe sono disponibili nell'origine.
  • Non vengono replicate le tabelle UNLOGGED e TEMPORARY.
  • Per acquisire le modifiche UPDATE e DELETE, nelle tabelle è necessaria una chiave primaria o una chiave univoca.
  • La replica della sequenza è disponibile.
  • È possibile la replica ritardata.
  • Fornisce il rilevamento dei conflitti e la risoluzione configurabile se sono presenti più publisher 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 seguenti risorse:

Strumenti di terze parti

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

Questa sezione è incentrata 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 programmare le tue applicazioni personalizzate, puoi scegliere tra utilizzando uno strumento di programmazione grafico o il Tungsten Query Language (TQL) linguaggio di programmazione.

Per ulteriori informazioni su come utilizzare Striim, consulta le seguenti risorse:

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

Definire gli scenari di fallback

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

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

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

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

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

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

Fallback semplice

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

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

Replica inversa

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

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

Inoltra replica

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

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

Scritture duplicate

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

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

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

Eseguire test e convalida

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

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

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

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

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

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

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

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

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

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

  • Consente di assicurare che la migrazione di tutti gli oggetti e di tutte le configurazioni venga eseguita correttamente.
  • Ti aiuta a definire ed eseguire i casi di test di migrazione.
  • Offre informazioni sul tempo necessario per la migrazione effettiva, in modo da poter calibrare le tempistiche.
  • Rappresenta un'occasione per testare, convalidare e adattare il piano di migrazione. A volte non è possibile pianificare tutto in anticipo, quindi questo ti aiuta a individuare eventuali lacune.

Il test dei dati può essere eseguito su un piccolo insieme di database di cui è prevista la migrazione o sull'intero insieme. A seconda del numero totale di database e degli strumenti utilizzati per implementarne la migrazione, puoi decidere di adottare un approccio basato sul rischio. Con questo approccio, esegui la convalida dei dati su un sottoinsieme di database è stata eseguita la migrazione mediante lo stesso strumento, soprattutto se si tratta di una migrazione gestita. completamente gestito di Google Cloud.

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

  • Confronta gli schemi di origine e di destinazione. Controllare se tutte le tabelle e tutti gli eseguibili esistono. Controlla i conteggi delle righe e confronta i dati a livello di database.
  • Eseguire script di convalida dei dati personalizzati.
  • Verifica che i dati migrati siano visibili anche nelle applicazioni per utilizzare il database di destinazione (i dati sottoposti a migrazione vengono letti applicazione).
  • Esegui test di integrazione tra le applicazioni trasferite e il database di destinazione testando vari casi d'uso. Questi test includono sia la lettura sia la scrittura dei dati nei database di destinazione tramite le applicazioni in modo che i carichi di lavoro supportino completamente i dati di cui è stata eseguita la migrazione insieme ai dati appena creati.
  • Testa le prestazioni delle query di database più utilizzate per osservare se si verificano riduzioni dovute a configurazioni errate o a dimensioni non corrette.

Idealmente, tutti questi scenari di test di migrazione sono automatizzati e ripetibili su qualsiasi sistema di origine. La suite di casi di test automatici è adattata per essere eseguita su applicazioni trasferite.

Se utilizzi Database Migration Service come strumento di migrazione, consulta la versione per 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 Strumento di convalida dei dati (DVT, Data Validation Tool, DVT). DVT è uno strumento di interfaccia a riga di comando Python open source, supportato da Google, che offre una soluzione automatizzata e ripetibile per la convalida ambienti cloud-native.

La DVT può contribuire a semplificare la procedura di convalida dei dati offrendo funzioni di convalida personalizzate e su più livelli per confrontare le tabelle di origine e di destinazione a livello di tabella, colonna e riga. Puoi anche aggiungere regole di convalida.

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

La TVP supporta i seguenti tipi di convalide:

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

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

Esegui la migrazione

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

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

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

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

Esegui il passaggio alla produzione

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

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

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

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

Una volta che la convalida dei dati soddisfa i tuoi criteri, puoi eseguire il passaggio al nuovo sistema a livello di applicazione. Esegui il deployment dei carichi di lavoro sottoposti a refactoring per utilizzare il nuovo di destinazione. Esegui il deployment delle versioni delle applicazioni che fanno riferimento alla nuova istanza di database di destinazione. I deployment possono essere eseguiti tramite aggiornamenti in sequenza, release graduali o utilizzando un pattern di deployment blu/verde. Potrebbe verificarsi un certo tempo di riposo dell'applicazione.

Segui le best practice per la migrazione completa della produzione:

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

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

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

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

  • Raccogli le impostazioni dei parametri del database dell'istanza di origine. In alternativa, verifica che corrispondano a quelle raccolte nel di creazione dell'inventario. 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 a quelli nell'istanza di destinazione. Se le statistiche sono diverse, è difficile confrontare le prestazioni dell'istanza di origine e dell'istanza di destinazione.

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

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

In alternativa, puoi utilizzare un'altra istanza e replicare le modifiche apportate in esecuzione in un'istanza Compute Engine. Ad esempio, se AlloyDB per PostgreSQL è una destinazione di migrazione, valuta la possibilità di configurare la replica su un'istanza Cloud SQL per PostgreSQL scenari di riserva.

Oltre alla pulizia dell'ambiente di origine, sono per le istanze Cloud SQL per PostgreSQL:

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

Non avviare un'operazione amministrativa prima che l'operazione precedente abbia 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, vedi Informazioni sulla manutenzione per le istanze Cloud SQL.

Ottimizza l'ambiente dopo la migrazione

L'ottimizzazione è l'ultima fase della migrazione. In questa fase, esegui l'iterazione 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 attuale, i team e il ciclo di ottimizzazione.
  2. Definisci i requisiti e gli obiettivi di ottimizzazione.
  3. Ottimizza il tuo ambiente e i tuoi team.
  4. Ottimizza il ciclo di ottimizzazione.

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

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

Stabilisci i requisiti di ottimizzazione

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

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

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

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

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

Aumentare le prestazioni dell'infrastruttura del database

Problemi di prestazioni minori relativi al database spesso hanno il potenziale di influire sull'intera operazione. Per mantenere e aumentare le prestazioni delle istanze Cloud SQL, tieni presenti le seguenti linee guida:

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

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

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

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

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

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

Durante la migrazione da Amazon RDS e Aurora per PostgreSQL a Cloud SQL per PostgreSQL, considera 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%, ti consigliamo di aumentare la dimensione della RAM dell'istanza. Per ulteriori informazioni, vedi Raccoglitore delle statistiche PostgreSQL.
  • Recupera spazio ed evita prestazioni dell'indice scadenti. A seconda della frequenza con cui cambiano i dati, imposta una pianificazione per eseguire il comando VACUUM su Cloud SQL per PostgreSQL.
  • Usa la versione Cloud SQL Enterprise Plus per una quantità maggiore di macchine di configurazione e la cache dei dati. Per ulteriori informazioni su Cloud SQL Enterprise Plus, consulta Introduzione alle versioni di Cloud SQL.
  • Passa a AlloyDB per PostgreSQL. Se esegui il passaggio, puoi usufruire della piena compatibilità con PostgreSQL, di un'elaborazione transazionale migliore e di carichi di lavoro di analisi transazionale rapidi supportati nel tuo database di elaborazione. Riceverai anche un consiglio per nuovi indici mediante l'uso della funzionalità Index Advisors.

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

Durante la migrazione da Amazon RDS e Aurora per PostgreSQL a AlloyDB per PostgreSQL, considera le seguenti linee guida per aumentare delle 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 può essere complessa e richiedere molto tempo. Per questo motivo, è essenziale avere un luogo centralizzato in cui tutti i membri del team possano vedere cosa succede a livello di database e istanza. Puoi monitorare le istanze Cloud SQL nei seguenti modi:

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

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

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

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

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

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

Best practice generali e linee guida operative 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 di Cloud SQL:

  • Se hai istanze di grandi dimensioni, ti consigliamo di suddividerle in istanze più piccole, se possibile.
  • Configura lo spazio di archiviazione per la manutenzione critica del database. Ensure hai almeno il 20% di spazio disponibile per contenere database critici le operazioni di manutenzione che Cloud SQL potrebbe eseguire.
  • La presenza di troppe tabelle di database può influire sul tempo di upgrade del database. Idealmente, dovresti avere meno di 10.000 tabelle per istanza.
  • Scegli le dimensioni appropriate per le istanze in modo da tenere conto della conservazione dei log delle transazioni (binari), in particolare per le istanze con attività di scrittura elevata.

Per essere in grado di gestire in modo efficiente qualsiasi problema di prestazioni del database che potresti segui queste linee guida finché il problema non verrà risolto:

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

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

Esegui ottimizzazione e ottimizzazione del database: le tabelle nel tuo database sono? strutturati in modo adeguato? Le colonne hanno i tipi di dati corretti? I tuoi dati sono più adatto al tipo di carico di lavoro? Esamina query lente e i relativi piani di esecuzione. Utilizzano gli indici disponibili? Controlla se sono presenti scansioni dell'indice, blocchi e attese su altre risorse. Valuta la possibilità di aggiungere indici per il supporto per le query critiche. Elimina gli indici non critici e le chiavi esterne. Prendi in considerazione e riscrivere query e join complessi. Il tempo necessario per risolvere il problema dipende dall'esperienza e dalla disponibilità del team e può variare da alcune ore a diversi giorni.

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

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

partizionamento orizzontale del database: puoi fare lo scale out delle scritture applicando lo sharding al database. Lo sharding è un'operazione complicata e prevede la riprogettazione dell'architettura del database e applicazioni in modo specifico ed eseguendo la migrazione dei dati. Hai diviso di database in più istanze più piccole utilizzando un partizionamento specifico criteri. I criteri possono essere basati sul cliente o sul soggetto. Questa opzione ti consente di eseguire il scaling orizzontale sia delle scritture che delle letture. Tuttavia, aumenta la complessità dei carichi di lavoro del database e delle applicazioni. Potrebbero anche verificarsi frammenti sbilanciati chiamati hotspot, che superano i vantaggi dello sharding.

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

  • Per scaricare il traffico dall'istanza principale, aggiungi repliche di lettura. Tu puoi utilizzare anche un bilanciatore del carico come HAProxy per gestire il traffico o lo scale out mediante repliche di lettura. Tuttavia, evita di creare troppe repliche, in quanto ciò ostacola l'operazione VACUUM. Per ulteriori informazioni sull'utilizzo di HAProxy, visita 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 consente di raggruppare più tuple in ogni iterazione.
  • Poiché gli indici più grandi richiedono una quantità di tempo significativa scansione dell'indice, imposta il parametro INDEX_CLEANUP su OFF per eseguire rapidamente la pulizia e bloccare i dati della tabella.
  • Quando si utilizza AlloyDB per PostgreSQL, usa la dashboard degli insight di sistema di AlloyDB per PostgreSQL e gli audit log. La dashboard degli insight di sistema di AlloyDB per PostgreSQL mostra le metriche le risorse che utilizzi e ti permette di monitorarle. Per ulteriori dettagli, consulta le linee guida del Monitora le istanze all'argomento nel AlloyDB per PostgreSQL documentazione.

Per maggiori dettagli, consulta le risorse seguenti:

Passaggi successivi

Collaboratori

Autori:

Altro collaboratore: Somdyuti Paul | Specialista di gestione dei dati