Limites connues

MySQL   |  PostgreSQL   |  PostgreSQL vers AlloyDB

Les limites connues d'utilisation d'une base de données PostgreSQL en tant que source incluent les suivantes:

• L'extension pglogical n'est pas compatible avec la réplication des colonnes générées pour PostgreSQL 12 et versions ultérieures.

• Les modifications apportées aux structures de table (DDL) ne sont pas répliquées à l'aide de commandes DDL standards, mais uniquement à l'aide de commandes exécutées à l'aide de l'extension pglogical utilisée pour la réplication.

  • Par exemple, pglogical fournit une fonction pglogical.replicate_ddl_command qui permet d'exécuter le LDD à la fois sur la base de données source et sur le réplica en un point cohérent. L'utilisateur qui exécute cette commande sur la source doit déjà exister sur le réplica.

  • Pour répliquer les données des nouvelles tables, vous devez utiliser la commande pglogical.replication_set_add_table pour ajouter les nouvelles tables aux ensembles de réplication existants.

  • Pour en savoir plus sur la réplication LDD pendant la migration, consultez la section sur la fidélité de la migration.

• Pour les tables qui ne possèdent pas de clés primaires, Database Migration Service permet de migrer l'instantané initial et les instructions INSERT pendant la phase de capture des données modifiées (CDC). Vous devez migrer les instructions UPDATE et DELETE manuellement.

• Database Migration Service ne migre pas les données des vues matérialisées, mais uniquement le schéma de la vue. Pour renseigner les vues, exécutez la commande suivante: REFRESH MATERIALIZED VIEW view_name.

• Les états SEQUENCE (par exemple, last_value) de la nouvelle destination AlloyDB peuvent différer des états SEQUENCE de la source.

• Les tables UNLOGGED et TEMPORARY ne sont pas répliquées et ne peuvent pas l'être.

• Le type de données "Large Object" n'est pas accepté. Pour en savoir plus, consultez la section sur la fidélité de la migration.

• Seules les extensions et les langages procéduraux compatibles avec AlloyDB pour PostgreSQL peuvent être migrées.

• Database Migration Service n'est pas compatible avec la migration à partir d'instances dupliquées avec accès en lecture en mode de récupération.

• Database Migration Service n'est pas compatible avec les sources Amazon RDS pour lesquelles le pack d'extension AWS SCT est appliqué.

• Les fonctions définies par l'utilisateur écrites en C ne peuvent pas être migrées, sauf celles qui sont installées dans la base de données PostgreSQL lorsque vous installez des extensions compatibles avec AlloyDB.

• Si d'autres extensions et langages procéduraux existent dans la base de données source, ou si leurs versions ne sont pas compatibles, le job de migration échouera lorsque vous le testerez ou le démarrerez.

• Les bases de données ajoutées après le démarrage de la tâche de migration ne sont pas migrées.

• Vous ne pouvez pas sélectionner des tables ou des schémas spécifiques lorsque vous effectuez une migration à l'aide de Database Migration Service. Database Migration Service migre toutes les tables et tous les schémas, à l'exception des éléments suivants :
  • Le schéma d'informations (information_schema).
  • Toutes les tables commençant par pg, par exemple pg_catalog. Pour obtenir la liste complète des catalogues PostgreSQL commençant par pg, consultez Catalogues système PostgreSQL dans la documentation PostgreSQL.
  • Les informations sur les utilisateurs et les rôles utilisateur ne sont pas migrées.

• Si les bases de données chiffrées nécessitent des clés de chiffrement gérées par le client pour être déchiffrées et que Database Migration Service n'a pas accès à ces clés, les bases de données ne peuvent pas être migrées.

  Toutefois, si les données client sont chiffrées par l'extension pgcrypto, elles peuvent être migrées avec Database Migration Service (car AlloyDB est compatible avec l'extension).

  Database Migration Service permet également de migrer des données à partir de bases de données Amazon Aurora ou Amazon RDS chiffrées, car ces bases de données gèrent le déchiffrement de manière transparente dans leurs services. Pour en savoir plus, consultez les pages Chiffrer les ressources Amazon Aurora et Chiffrer les ressources Amazon RDS.

• La base de données AlloyDB de destination est accessible en écriture pendant la migration afin de permettre l'application des modifications DDL si nécessaire. Veillez à ne pas apporter de modifications à la configuration de la base de données ni aux structures de table qui pourraient interrompre le processus de migration ou affecter l'intégrité des données.

• Le comportement des déclencheurs dépend de la façon dont ils ont été configurés. Par défaut, ils ne se déclenchent pas, mais s'ils ont été configurés à l'aide de l'instruction ALTER EVENT TRIGGER ou ALTER TABLE et que l'état du déclencheur est défini sur "replica" ou "always", ils se déclenchent sur le réplica lors de la réplication.

• Les fonctions avec un définisseur de sécurité seront créées par alloydbexternalsync dans la base de données principale AlloyDB. Lorsqu'il est exécuté par des utilisateurs, il est exécuté avec les droits de alloydbexternalsync, qui dispose des rôles alloydbsuperuser et alloydbreplica. Il est préférable de limiter l'utilisation d'une fonction de définition de la sécurité à certains utilisateurs. Pour ce faire, l'utilisateur doit révoquer les droits PUBLIC par défaut, puis accorder le droit d'exécution de manière sélective.

Limites des migrations vers des clusters de destination existants

• Votre cluster de destination existant doit être vide ou ne contenir que des données de configuration système. La migration vers un cluster de destination existant contenant des données utilisateur (telles que des tables) n'est pas prise en charge.
• Vous ne pouvez configurer qu'une seule tâche de migration par cluster de destination.
• La migration vers des clusters avec des clusters secondaires n'est pas possible.
• La migration vers des clusters avec des instances de pool de lecture est possible.

  Pour en savoir plus sur les clusters et les instances AlloyDB pour PostgreSQL, consultez la présentation d'AlloyDB pour PostgreSQL.

Quotas

• Jusqu'à 2 000 profils de connexion et 1 000 tâches de migration peuvent coexister à un moment donné. Pour libérer de l'espace, vous pouvez supprimer des profils de connexion et des tâches de migration (y compris celles déjà effectuées).