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 (LDD) ne sont pas répliquées à l'aide des commandes LDD standards, mais uniquement avec les commandes exécutées à l'aide de l'extension pglogical utilisée pour la réplication. Cela inclut les modifications apportées aux types enum.

  • Par exemple, pglogical fournit une fonction pglogical.replicate_ddl_command qui permet d'exécuter le LDD sur la base de données source et le réplica à 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 afin d'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, Change Data Capture). 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 remplir 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 être différents de ceux de la source.SEQUENCE

• 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 qu'AlloyDB prend en charge pour PostgreSQL peuvent être migrés.

• Database Migration Service n'est pas compatible avec la migration depuis des instances répliquées avec accès en lecture en mode récupération.

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

• Les fonctions définies par l'utilisateur écrites en C ne peuvent pas être migrées, à l'exception de 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 du job de migration ne sont pas migrées.

• Vous ne pouvez pas sélectionner de tables ni de schémas spécifiques lorsque vous migrez des données à l'aide de Database Migration Service. Database Migration Service migre toutes les tables et tous les schémas, à l'exception des éléments suivants :
  • 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 qui commencent 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 si Database Migration Service n'y a pas accès, elles 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 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 pour permettre d'appliquer les modifications LDD si nécessaire. Veillez à ne pas modifier la configuration de la base de données ni les structures de table, car cela pourrait perturber le processus de migration ou affecter l'intégrité des données.

• Le comportement des déclencheurs dépend de leur configuration. Par défaut, ils ne se déclenchent pas. Toutefois, 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" (réplique) ou "always" (toujours), ils se déclenchent sur la réplique lors de la réplication.

• Les fonctions avec un définisseur de sécurité seront créées par alloydbexternalsync dans l'instance principale AlloyDB. Lorsqu'elle est exécutée par un utilisateur, elle l'est avec les droits de alloydbexternalsync, qui possède les rôles alloydbsuperuser et alloydbreplica. Il est préférable de limiter l'utilisation d'une fonction de définition de sécurité à certains utilisateurs uniquement. 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.

• La méthode de connectivité des interfaces Private Service Connect n'est compatible qu'avec la migration vers des instances de destination existantes. Si vous souhaitez utiliser la connectivité IP privée et migrer vers une nouvelle instance de destination, utilisez l'appairage de VPC.

Limites pour les 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 des clusters de destination existants contenant des données utilisateur (telles que des tables) n'est pas prise en charge.
• Vous ne pouvez configurer qu'un seul job 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, supprimez des profils de connexion et des tâches de migration (y compris celles déjà effectuées).