Domande frequenti su Database Migration Service per AlloyDB

MySQL   |  PostgreSQL   |  PostgreSQL ad AlloyDB

• Che cos'è Database Migration Service?
• Quali fonti sono supportate?
• È disponibile il supporto per più versioni?
• Quali componenti di dati, schema e metadati vengono migrati?
• Quali modifiche vengono replicate durante la migrazione continua?
• Elementi di cui non viene eseguita la migrazione
• Quali metodi di networking vengono utilizzati?
• Quali sono le limitazioni note?

Che cos'è Database Migration Service?

Database Migration Service è un servizio che semplifica la migrazione dei dati a Google Cloud. Database Migration Service ti aiuta a eseguire il lift and shift dei carichi di lavoro PostgreSQL in AlloyDB.

Quali fonti sono supportate?

• Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14, 15, 16, 17
• Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14, 15, 16, 17
• PostgreSQL autogestito (on-premise o su qualsiasi VM cloud di cui hai il controllo totale) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16, 17
• Cloud SQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17

Quali destinazioni sono supportate?

• AlloyDB per PostgreSQL 14, 15, 16, 17

È disponibile il supporto per più versioni?

Database Migration Service supporta le migrazioni da PostgreSQL ad AlloyDB da qualsiasi versione del database di origine supportata.

Quali componenti di dati, schema e metadati vengono migrati?

Database Migration Service esegue la migrazione di schema, dati e metadati dall'origine alla destinazione. Tutti i componenti di dati, schema e metadati seguenti vengono migrati nell'ambito della migrazione del database:

Migrazione dei dati

• Tutti gli schemi e tutte le tabelle del database selezionato.

Migrazione dello schema

• Denominazione
• Chiave primaria
• Tipo di dati
• Posizione ordinale
• Valore predefinito
• Supporto di valori Null
• Attributi di incremento automatico
• Indici secondari

Migrazione dei metadati

• Stored procedure
• Funzioni
• Trigger
• Visualizzazioni
• Vincoli di chiave esterna

Quali modifiche vengono replicate durante la migrazione continua?

Solo le modifiche DML vengono aggiornate automaticamente durante la migrazione. La gestione di DDL in modo che i database di origine e di destinazione rimangano compatibili è responsabilità dell'utente e può essere eseguita in due modi:

1. Interrompi le scritture sull'origine ed esegui i comandi DDL sia sull'origine che sulla destinazione. Prima di eseguire i comandi DDL sulla destinazione, concedi il ruolo alloydbexternalsync all'utente Cloud SQL che applica le modifiche DDL. Per abilitare l'invio di query o la modifica dei dati, concedi il ruolo alloydbexternalsync agli utenti Cloud SQL pertinenti.

2. Utilizza pglogical.replicate_ddl_command per eseguire DDL su origine e destinazione in un punto coerente. L'utente che esegue questo comando deve avere lo stesso nome utente sia nell'origine che nella destinazione e deve essere il superutente o il proprietario dell'artefatto di cui viene eseguita la migrazione (ad esempio, la tabella, la sequenza, la vista o il database).

   Ecco alcuni esempi di utilizzo di pglogical.replicate_ddl_command.

   Per aggiungere una colonna a una tabella del database, esegui questo comando:

   select pglogical.replicate_ddl_command('ALTER TABLE [schema].[table] add column surname varchar(20)', '{default}');

   Per modificare il nome di una tabella del database, esegui questo comando:

   select pglogical.replicate_ddl_command('ALTER TABLE [schema].[table] RENAME TO [table_name]','{default}');

   Per creare una tabella del database, esegui questi comandi:

   1. select pglogical.replicate_ddl_command(command := 'CREATE TABLE [schema].[table] (id INTEGER PRIMARY KEY, name VARCHAR);', replication_sets := ARRAY['default'']);
   2. select pglogical.replication_set_add_table('default', '[schema].[table]');

Elementi di cui non viene eseguita la migrazione

Per aggiungere utenti all'istanza di destinazione AlloyDB, aggiungili dal client PostgreSQL. Scopri di più su come creare e gestire gli utenti PostgreSQL.

Gli oggetti di grandi dimensioni non possono essere replicati perché la funzionalità di decodifica logica di PostgreSQL non supporta la decodifica delle modifiche agli oggetti di grandi dimensioni. Per le tabelle con tipo di colonna oid che fa riferimento a oggetti di grandi dimensioni, le righe vengono comunque sincronizzate e le nuove righe vengono replicate. Tuttavia, il tentativo di accedere all'oggetto di grandi dimensioni nel database di destinazione (lettura tramite lo_get, esportazione tramite lo_export o controllo del catalogo pg_largeobject per l'oid specificato) non riesce e viene visualizzato un messaggio che indica che l'oggetto di grandi dimensioni non esiste.

Per le tabelle senza chiavi primarie, Database Migration Service supporta la migrazione degli snapshot iniziali e delle istruzioni INSERT durante la fase Change Data Capture (CDC). Devi eseguire manualmente la migrazione delle istruzioni UPDATE e DELETE.

Database Migration Service non esegue la migrazione dei dati dalle viste materializzate, ma solo dello schema della vista. Per popolare le visualizzazioni, esegui il comando seguente: REFRESH MATERIALIZED VIEW view_name.

Gli stati SEQUENCE (ad esempio, last_value) nella nuova destinazione AlloyDB potrebbero variare rispetto agli stati SEQUENCE di origine.

Quali metodi di networking vengono utilizzati?

Per creare una migrazione in Database Migration Service, è necessario stabilire la connettività tra l'origine e l'istanza Cloud SQL di destinazione. Sono supportati diversi metodi. Scegli quella più adatta al carico di lavoro specifico.

Metodo di networking	Descrizione	Vantaggi	Svantaggi
Tunnel SSH inverso tramite VM ospitata nel cloud	Stabilisce la connettività dalla destinazione all'origine tramite un tunnel SSH inverso sicuro. Richiede una VM bastion host nel Google Cloud progetto e una macchina (ad esempio, un laptop sulla rete) che abbia la connettività all'origine. Database Migration Service raccoglie le informazioni richieste al momento della creazione della migrazione e genera automaticamente lo script per la configurazione.	Facile da configurare. Non richiede alcuna configurazione firewall personalizzata. Consigliato per scenari di migrazione di breve durata (POC o migrazioni di piccoli database).	La VM Bastion è di tua proprietà e la gestisci tu. Potrebbero essere applicati costi aggiuntivi.
Proxy TCP tramite una VM ospitata nel cloud	Stabilisce la connettività dalla destinazione all'origine tramite un proxy TCP con VM ospitata nel cloud. Database Migration Service raccoglie le informazioni richieste al momento della creazione della migrazione e genera automaticamente lo script per la configurazione. Pertinente per le migrazioni AlloyDB in cui l'origine si trova nella vecchia architettura di rete.	Facile da configurare. Non richiede alcuna configurazione firewall personalizzata.	La VM Bastion è di tua proprietà e viene gestita da te e potrebbe comportare costi aggiuntivi.
Peering VPC	Questo metodo funziona configurando i VPC in modo che comunichino tra loro.	Soluzione Google Cloud nativa. Facile da configurare. Larghezza di banda elevata Consigliato per migrazioni di lunga durata o di grandi volumi.	Applicabile solo se i database di origine e destinazione sono ospitati in Google Cloud.
VPN	Configura un tunnel VPN IPSec che connette la rete interna e Google Cloud VPC tramite una connessione sicura su internet pubblico. Utilizza Google Cloud una VPN o qualsiasi soluzione VPN configurata per la rete interna.	Soluzione di connettività solida e scalabile. Larghezza di banda medio-alta. Sicurezza integrata. Offerte come soluzioni Google Cloud o da altre terze parti.	Costi aggiuntivi. Configurazione non banale (se non già in atto).
Cloud Interconnect	Utilizza una connessione a disponibilità elevata e a bassa latenza tra la rete on-premise e Google Cloud.	Larghezza di banda più elevata, ideale per migrazioni di grandi volumi di lunga durata.	Costi aggiuntivi. Per impostazione predefinita, la connessione non è sicura. Configurazione non banale (se non già in atto).

Quali sono le limitazioni note?

Vedi Limitazioni note.