Limitazioni note

Prima di scegliere di eseguire la migrazione dei database ad AlloyDB per PostgreSQL, considera le limitazioni note per questo scenario di migrazione.

Le limitazioni note per l'utilizzo di un database PostgreSQL come origine includono:

  • L'estensione pglogical non supporta la replica delle colonne generate per PostgreSQL 12 e versioni successive.

  • Le modifiche alle strutture delle tabelle (DDL) non vengono replicate tramite i comandi DDL standard, ma solo con i comandi eseguiti utilizzando l'estensione pglogical utilizzata per la replica. Sono incluse le modifiche ai tipi di enum.

    • Ad esempio, pglogical fornisce la funzione pglogical.replicate_ddl_command che consente di eseguire il DDL sia sul database di origine che sulla replica in un punto coerente. L'utente che esegue questo comando sull'origine deve già esistere sulla replica.
    • Per replicare i dati per le tabelle appena create, devi utilizzare il comando pglogical.replication_set_add_table per aggiungere nuove tabelle ai set di replica esistenti.
    • Per scoprire di più sulla replica DDL durante la migrazione, consulta Fedeltà della migrazione.

  • Limitazioni degli oggetti:

    • Le tabelle esterne non vengono replicate dalla replica logica.
    • Le tabelle UNLOGGED e TEMPORARY non sono e non possono essere replicate.
    • Il tipo di dati Large Object (oid che fa riferimento a pg_largeobject) non è supportato dalla decodifica logica di PostgreSQL.
    • Database Migration Service non esegue la migrazione dei dati dalle viste materializzate, ma solo dello schema della vista. Per compilare le viste nel database di destinazione, esegui: REFRESH MATERIALIZED VIEW view_name;.
    • Gli stati SEQUENCE (ad esempio last_value) nella destinazione potrebbero variare rispetto all'origine durante il CDC in corso. I valori della sequenza vengono sincronizzati durante il passaggio di promozione finale.

  • Per le tabelle senza chiavi primarie, Database Migration Service supporta la migrazione dello snapshot iniziale e delle istruzioni INSERT durante la fase Change Data Capture (CDC). La migrazione delle istruzioni UPDATE e DELETE è diversa per:

    • Migrazioni standard: le istruzioni UPDATE e DELETE non vengono migrate per le tabelle senza chiavi primarie. Devi aggiungere le chiavi primarie per le colonne prima di eseguire la migrazione o eseguire la migrazione manuale delle istruzioni UPDATE e DELETE.
    • Migrazioni con avvio rapido: con le migrazioni con avvio rapido, le chiavi primarie non sono necessarie per replicare le operazioni UPDATE e DELETE se imposti l'identità della replica su INDEX o FULL. La configurazione di REPLICA IDENTITY FULL aumenta il volume del write-ahead log (WAL) e l'overhead delle risorse. Se possibile, è consigliabile aggiungere una chiave primaria. Per saperne di più, consulta la documentazione sull'identità della replica PostgreSQL e la guida alla migrazione rapida.

  • È possibile eseguire la migrazione solo delle estensioni e delle versioni delle estensioni supportate da AlloyDB per PostgreSQL per PostgreSQL. Database Migration Service non esegue la migrazione delle estensioni non supportate da AlloyDB per PostgreSQL. Se nel database di origine sono presenti estensioni le cui versioni non sono supportate da AlloyDB per PostgreSQL, il test o l'avvio del job di migrazione potrebbe non riuscire. Per garantire una migrazione senza problemi, verifica che le estensioni di origine siano supportate e che le tue applicazioni non facciano riferimento a estensioni non supportate. Per l'elenco delle estensioni supportate, consulta Estensioni supportate nella documentazione di AlloyDB per PostgreSQL.

  • L'estensione pg_cron (o i cron job configurati al suo interno) non viene migrata da Database Migration Service, ma è supportata nelle destinazioni AlloyDB per PostgreSQL. Se utilizzi pg_cron nei database di origine, reinstalla l'estensione e configura i cron job nel cluster di destinazione al termine della migrazione.

  • Database Migration Service non supporta la migrazione da repliche di lettura in modalità Recovery [Recovery mode].

  • Database Migration Service non supporta le origini Amazon RDS in cui è applicato il pacchetto di estensione AWS SCT.

  • Non è possibile eseguire la migrazione delle funzioni definite dall'utente scritte in C, ad eccezione delle funzioni installate durante la creazione di estensioni supportate da AlloyDB per PostgreSQL.

  • I database aggiunti all'istanza di origine dopo l'avvio del job di migrazione non vengono migrati.

  • Puoi selezionare database specifici quando esegui la migrazione utilizzando Database Migration Service. Viene eseguita la migrazione di tutte le tabelle e gli schemi dei database selezionati, ad eccezione di:

    • Lo schema delle informazioni (information_schema).
    • Qualsiasi schema che inizia con pg_ (ad esempio pg_catalog, pg_toast, pgtemp*). Per l'elenco completo dei cataloghi PostgreSQL che iniziano con pg_, consulta Cataloghi di sistema PostgreSQL nella documentazione di PostgreSQL.
    • Credenziali di accesso e ruoli degli utenti.

  • Se i database criptati richiedono chiavi di crittografia gestite dal cliente (CMEK) per decriptare i dati e Database Migration Service non ha accesso alle chiavi, non è possibile eseguire la migrazione dei database. Tuttavia, è possibile eseguire la migrazione dei dati criptati con l' estensione pgcrypto perché AlloyDB per PostgreSQL supporta pgcrypto. Database Migration Service supporta anche la migrazione da database Amazon Aurora o Amazon RDS criptati, perché AWS gestisce la decriptazione in modo trasparente. Per saperne di più, consulta Crittografia delle risorse Amazon Aurora e Crittografia delle risorse Amazon RDS.

  • I database in fase di migrazione non sono protetti da scrittura durante la migrazione: AlloyDB per PostgreSQL non esegue l'istanza di destinazione in modalità di sola lettura durante la migrazione. Sebbene tu possa connetterti al cluster di destinazione per creare e gestire gli utenti del database o applicare le modifiche necessarie allo schema (DDL), non eseguire operazioni di scrittura (come INSERT, UPDATE o DELETE) su database o tabelle di cui è in corso la migrazione. La scrittura sui dati in fase di migrazione può causare conflitti di replica o errori di migrazione.

  • Il comportamento del trigger dipende dalla sua configurazione. Per impostazione predefinita, i trigger non vengono attivati sulla replica durante la replica, a meno che non siano configurati con ALTER EVENT TRIGGER o ALTER TABLE ... ENABLE ALWAYS TRIGGER.

  • I tablespace personalizzati vengono mappati al tablespace pg_default predefinito in AlloyDB per PostgreSQL.

  • Il metodo di connettività delle interfacce Private Service Connect è supportato solo per la migrazione ai cluster di destinazione esistenti. Se vuoi utilizzare la connettività IP privato ed eseguire la migrazione a un nuovo cluster di destinazione in una migrazione standard, utilizza il peering VPC.

  • L'autenticazione del database di Identity and Access Management per i cluster di destinazione non è supportata. Database Migration Service si connette al database di destinazione utilizzando l'autenticazione utente del database. Per saperne di più su IAM, consulta Gestisci l'autenticazione IAM nella documentazione di AlloyDB per PostgreSQL.

Funzioni con definer di sicurezza

Le funzioni definite con SECURITY DEFINER vengono eseguite con i privilegi dell'utente proprietario della funzione, anziché dell'utente che la esegue.

Durante la migrazione continua ad AlloyDB per PostgreSQL, le routine definite con SECURITY DEFINER diventano di proprietà dell'utente del servizio di migrazione interno alloydbexternalsync nell'istanza principale di destinazione. Poiché alloydbexternalsync possiede privilegi amministrativi elevati, inclusi i ruoli alloydbsuperuser e alloydbreplica, qualsiasi utente autorizzato a eseguire queste funzioni le esegue con diritti alloydbsuperuser completi. Questo crea un rischio di escalation dei privilegi involontaria.

Per rimediare a questo rischio, controlla tutte le funzioni SECURITY DEFINER sul tuo cluster di destinazione e revoca i privilegi di esecuzione pubblica immediatamente dopo la migrazione:

REVOKE EXECUTE ON FUNCTION SCHEMA_NAME.FUNCTION_NAME(ARGUMENT_TYPES) FROM PUBLIC;
GRANT EXECUTE ON FUNCTION SCHEMA_NAME.FUNCTION_NAME(ARGUMENT_TYPES) TO "AUTHORIZED_USER";

Allineamento di regole di confronto e impostazioni internazionali

AlloyDB per PostgreSQL utilizza per impostazione predefinita le impostazioni internazionali C.UTF-8 e en_US.utf8 fornite da libc. Tutte le altre impostazioni internazionali in AlloyDB per PostgreSQL utilizzano le regole di confronto T.I. (International Components for Unicode).

Se il database di origine utilizza una regole di confronto predefinita basata su un'altra libc impostazione locale, questa impostazione predefinita non viene trasferita automaticamente. Per garantire un ordinamento coerente per le query che utilizzano ORDER BY, potrebbe essere necessario aggiornare le tabelle con regole di confronto T.I. esplicite dopo la migrazione. Per saperne di più, consulta Impostazioni internazionali supportate per i dati importati nella documentazione di AlloyDB per PostgreSQL.

Limitazioni per le migrazioni a cluster di destinazione esistenti

  • Puoi configurare un solo job di migrazione attivo per cluster di destinazione.
  • Retrocessione del cluster di destinazione per le migrazioni standard: per le migrazioni standard ai cluster AlloyDB per PostgreSQL esistenti, Database Migration Service retrocede il cluster autonomo per configurarlo come replica esterna del database di origine.
    • Devi confermare la retrocessione quando crei il job di migrazione nella console Google Cloud inserendo l'ID cluster di destinazione (o eseguendogcloud database-migration migration-jobs demote-destination).
    • Le migrazioni con avvio rapido utilizzano la replica logica di PostgreSQL pgnative e non richiedono né eseguono la retrocessione del cluster di destinazione.
  • Per le migrazioni standard, il cluster di destinazione esistente deve essere vuoto o contenere solo dati di configurazione di sistema predefiniti. La migrazione a un cluster di destinazione esistente che contiene dati utente (ad esempio tabelle) non è supportata per le migrazioni standard.

    Se riscontri problemi dovuti a dati aggiuntivi nel cluster di destinazione esistente, cancella i database nel cluster di destinazione e riprova a eseguire il job di migrazione. Consulta Cancella i dati aggiuntivi dal cluster di destinazione esistente.

  • La migrazione a cluster con istanze di pool di lettura è supportata. Per saperne di più sui cluster e sulle istanze AlloyDB per PostgreSQL, consulta la panoramica di AlloyDB per PostgreSQL.

Considerazioni sul parallelismo del dump dei dati

Quando crei un job di migrazione, puoi aumentare il numero di sottoscrizioni parallele per accelerare il dump dei dati iniziale e la replica Change Data Capture (CDC) in corso. L'utilizzo di impostazioni di parallelismo del dump dei dati più elevate aumenta anche l'utilizzo delle connessioni e delle risorse sia nel database di origine sia nel cluster AlloyDB per PostgreSQL di destinazione.

  • Assicurati che il database di origine disponga di spazio di riserva sufficiente per CPU, memoria e I/O prima di utilizzare il parallelismo Massimo.
  • Quando utilizzi il parallelismo del dump dei dati modificato, devi configurare valori più elevati per max_replication_slots, max_wal_senders e max_worker_processes nel database di origine. Per calcoli dettagliati dei parametri, consulta Configura il database di origine.
  • L'estensione pglogical replica i dati a livello di tabella durante il dump completo iniziale. Una singola tabella non partizionata viene assegnata a una sottoscrizione e non viene suddivisa tra più sottoscrizioni parallele o thread di lavoro.
  • L'estensione pglogical replica le singole partizioni foglia come tabelle separate e può distribuire più partizioni foglia tra sottoscrizioni parallele durante il dump completo iniziale. Una singola partizione foglia di grandi dimensioni non può essere suddivisa tra più sottoscrizioni e viene copiata da un singolo thread.
  • Database Migration Service ordina le tabelle in base alle dimensioni e le distribuisce tra le sottoscrizioni parallele. Database Migration Service crea fino a 2 sottoscrizioni per database (e fino a 2 in totale per tutti i database) per il parallelismo Ottimale e fino a 4 sottoscrizioni per database (e fino a 4 in totale per tutti i database) per il parallelismo Massimo, con almeno 1 sottoscrizione per database migrato. Ad esempio, se un database contiene una tabella da 1 TB e diverse tabelle di piccole dimensioni, Database Migration Service isola la tabella da 1 TB in una sottoscrizione e distribuisce le tabelle più piccole nelle sottoscrizioni rimanenti. Anche con più sottoscrizioni attive, la velocità di dump iniziale complessiva è comunque limitata dal tempo necessario per copiare la singola tabella da 1 TB.
  • Database Migration Service assegna le tabelle senza chiavi primarie a set di replica dedicati di solo inserimento (uno per ogni sottoscrizione parallela). Più tabelle senza chiavi primarie possono essere distribuite tra sottoscrizioni parallele, ma durante il dump completo iniziale ogni singola tabella viene copiata come un singolo stream di tabella all'interno di una sottoscrizione e non viene suddivisa tra più thread paralleli.

Quote

  • In qualsiasi momento, possono esistere fino a 2000 profili di connessione e 1000 job di migrazione. Per creare spazio per altri, elimina i job di migrazione e i profili di connessione inutilizzati. Per maggiori dettagli, consulta Quote e limiti.

Compatibilità delle versioni delle estensioni PostgreSQL durante gli upgrade delle versioni principali

Quando esegui la migrazione a una versione principale di PostgreSQL successiva, Database Migration Service utilizza l'utilità pg_restore, che installa la versione predefinita dell'estensione della versione principale di PostgreSQL di destinazione. Non puoi specificare una versione esatta dell'estensione per l'utilità pg_restore.

Se il database di origine utilizza una versione dell'estensione non compatibile con lo schema della versione predefinita installata nella versione principale di PostgreSQL di destinazione, la migrazione potrebbe non riuscire a causa di una mancata corrispondenza dello schema o di errori interni.

Per evitare errori di migrazione, verifica la compatibilità dello schema. Prima di eseguire la migrazione, esegui l'upgrade delle estensioni del database di origine a una versione compatibile con la versione principale di PostgreSQL di destinazione.

Passaggi successivi