Limites connues

Avant de choisir de migrer vos bases de données vers AlloyDB pour PostgreSQL, tenez compte des limites connues pour ce scénario de migration.

Voici les limites connues concernant l'utilisation d'une base de données PostgreSQL comme source :

  • 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 via les 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 la fonction pglogical.replicate_ddl_command qui permet d'exécuter le LDD sur la base de données source et l'instance répliquée à un point cohérent. L'utilisateur qui exécute cette commande sur la source doit déjà exister sur l'instance répliquée.
    • Pour répliquer les données des tables nouvellement créées, vous devez utiliser la commande pglogical.replication_set_add_table pour ajouter de nouvelles tables aux ensembles de réplication existants.
    • Pour en savoir plus sur la réplication LDD pendant la migration, consultez Fidélité de la migration.

  • Limites concernant les objets :

    • Les tables étrangères ne sont pas répliquées par la réplication logique.
    • Les tables UNLOGGED et TEMPORARY ne sont pas répliquées et ne peuvent pas l'être.
    • Le type de données Large Object (oid faisant référence à pg_largeobject) n'est pas compatible avec le décodage logique PostgreSQL.
    • Database Migration Service ne migre pas les données des vues matérialisées, mais uniquement le schéma de la vue. Pour insérer les vues dans la base de données de destination, exécutez : REFRESH MATERIALIZED VIEW view_name;.
    • Les états SEQUENCE (par exemple, last_value) sur la destination peuvent différer de la source pendant la CDC en cours. Les valeurs de séquence sont synchronisées lors de l'étape de promotion finale.

  • Pour les tables qui ne possèdent pas de clés primaires, Database Migration Service permet de migrer l'instantané initial ainsi que les instructions INSERT pendant la phase de capture des données modifiées (CDC, Change Data Capture). La migration des instructions UPDATE et DELETE est différente pour :

    • Migrations standards : les instructions UPDATE et DELETE ne sont pas migrées pour les tables sans clé primaire. Vous devez ajouter des clés primaires pour vos colonnes avant de migrer, ou migrer manuellement les instructions UPDATE et DELETE.
    • Migrations à démarrage rapide : avec les migrations à démarrage rapide, les clés primaires ne sont pas requises pour répliquer les opérations UPDATE et DELETE si vous définissez l'identité de l'instance répliquée sur INDEX ou FULL. La configuration de REPLICA IDENTITY FULL augmente le volume du journal WAL (Write-Ahead Logging) et la surcharge des ressources. Nous vous recommandons d'ajouter une clé primaire dans la mesure du possible. Pour en savoir plus, consultez la documentation sur l'identité de l'instance répliquée PostgreSQL et le guide de démarrage rapide des migrations.

  • Seules les extensions et les versions d'extensions qu'AlloyDB pour PostgreSQL accepte pour PostgreSQL peuvent être migrées. Database Migration Service ne migre pas les extensions non compatibles avec AlloyDB pour PostgreSQL. Si des extensions existent dans la base de données source dont les versions ne sont pas compatibles avec AlloyDB pour PostgreSQL, le test ou le démarrage du job de migration peut échouer. Pour faciliter la migration, vérifiez que vos extensions sources sont compatibles et que vos applications ne font pas référence à des extensions non compatibles. Pour obtenir la liste des extensions compatibles, consultez Extensions compatibles dans la documentation AlloyDB pour PostgreSQL.

  • L'extension pg_cron (ou tout job Cron configuré dans l'extension) n'est pas migrée par Database Migration Service, mais elle est compatible avec les destinations AlloyDB pour PostgreSQL. Si vous utilisez pg_cron dans vos bases de données sources, réinstallez l'extension et configurez vos jobs Cron sur le cluster de destination une fois la migration terminée.

  • Database Migration Service ne permet pas de migrer des instances dupliquées avec accès en lecture qui sont en mode de 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 des fonctions installées lors de la création d'extensions compatibles avec AlloyDB pour PostgreSQL.

  • Les bases de données ajoutées à l'instance source après le démarrage du job de migration ne sont pas migrées.

  • Vous pouvez sélectionner des bases de données spécifiques lorsque vous effectuez une migration à l'aide de Database Migration Service. Toutes les tables et tous les schémas des bases de données sélectionnées sont migrés, à l'exception des éléments suivants :

    • Le schéma d'informations (information_schema).
    • Tous les schémas commençant par pg_ (par exemple, pg_catalog, pg_toast, pgtemp*). Pour obtenir la liste complète des catalogues PostgreSQL commençant par pg_, consultez Catalogues système PostgreSQL dans la documentation PostgreSQL.
    • Identifiants de connexion et rôles des utilisateurs.

  • Si les bases de données chiffrées nécessitent des clés de chiffrement gérées par le client (CMEK) pour déchiffrer les données et que Database Migration Service n'a pas accès aux clés, les bases de données ne peuvent pas être migrées. Toutefois, les données chiffrées avec l' extension pgcrypto peuvent être migrées, car AlloyDB pour PostgreSQL est compatible avec pgcrypto. Database Migration Service permet également de migrer des bases de données Amazon Aurora ou Amazon RDS chiffrées, car AWS gère le déchiffrement de manière transparente. Pour en savoir plus, consultez Chiffrer des ressources Amazon Aurora et Chiffrer des ressources Amazon RDS.

  • Les bases de données en cours de migration ne sont pas protégées en écriture pendant la migration : AlloyDB pour PostgreSQL n'exécute pas l'instance de destination en mode lecture seule pendant la migration. Bien que vous puissiez vous connecter au cluster de destination pour créer et gérer des utilisateurs de base de données ou appliquer les modifications de schéma nécessaires (LDD), n'effectuez pas d'opérations d'écriture (telles que INSERT, UPDATE ou DELETE) sur les bases de données ou les tables en cours de migration. L'écriture dans des données en cours de migration peut entraîner des conflits de réplication ou des échecs de migration.

  • Le comportement du déclencheur dépend de sa configuration. Par défaut, les déclencheurs ne se déclenchent pas sur l'instance répliquée pendant la réplication, sauf s'ils sont configurés avec ALTER EVENT TRIGGER ou ALTER TABLE ... ENABLE ALWAYS TRIGGER.

  • Les espaces de table personnalisés sont mappés à l'espace de table pg_default par défaut dans AlloyDB pour PostgreSQL.

  • La méthode de connectivité des interfaces Private Service Connect n'est compatible qu'avec la migration vers des clusters de destination existants. Si vous souhaitez utiliser la connectivité IP privée et migrer vers un nouveau cluster de destination dans une migration standard, utilisez l'appairage de VPC.

  • L'authentification de base de données Identity and Access Management pour les clusters de destination n'est pas prise en charge. Database Migration Service se connecte à la base de données de destination à l'aide de l'authentification des utilisateurs de la base de données. Pour en savoir plus sur IAM, consultez Gérer l'authentification IAM dans la documentation AlloyDB pour PostgreSQL.

Fonctions de définition de sécurité

Les fonctions définies avec SECURITY DEFINER s'exécutent avec les droits de l'utilisateur propriétaire de la fonction, et non de l'utilisateur qui l'exécute.

Lors de la migration continue vers AlloyDB pour PostgreSQL, les routines définies avec SECURITY DEFINER deviennent la propriété de l'utilisateur du service de migration interne alloydbexternalsync sur l'instance principale de destination. Étant donné que alloydbexternalsync possède des droits d'administrateur élevés, y compris les rôles alloydbsuperuser et alloydbreplica, tout utilisateur autorisé à exécuter ces fonctions les exécute avec des droits alloydbsuperuser complets. Cela crée un risque d'élévation involontaire des privilèges.

Pour remédier à ce risque, auditez toutes les fonctions SECURITY DEFINER sur votre cluster de destination et révoquez les droits d'exécution publics immédiatement après la migration :

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";

Alignement du classement et des paramètres régionaux

AlloyDB pour PostgreSQL utilise par défaut les paramètres régionaux C.UTF-8 et en_US.utf8 fournis par libc. Tous les autres paramètres régionaux d'AlloyDB pour PostgreSQL utilisent des classements ICU (International Components for Unicode).

Si votre base de données source utilise un classement par défaut basé sur d'autres paramètres régionaux libc, ce classement par défaut n'est pas automatiquement reporté. Pour garantir un tri cohérent des requêtes à l'aide de ORDER BY, vous devrez peut-être mettre à jour vos tables avec des classements ICU explicites après la migration. Pour en savoir plus, consultez Paramètres régionaux compatibles pour les données importées dans la documentation AlloyDB pour PostgreSQL.

Limites des migrations vers des clusters de destination existants

  • Vous ne pouvez configurer qu'un seul job de migration actif par cluster de destination.
  • Rétrogradation du cluster de destination pour les migrations standards : pour les migrations standards vers des clusters AlloyDB pour PostgreSQL existants, Database Migration Service rétrograde le cluster autonome pour le configurer en tant qu'instance répliquée externe de la base de données source.
    • Vous devez confirmer la rétrogradation lors de la création du job de migration dans la console Google Cloud en saisissant l'ID du cluster de destination (ou en exécutant gcloud database-migration migration-jobs demote-destination).
    • Les migrations à démarrage rapide utilisent la réplication logique PostgreSQL pgnative et ne nécessitent ni n'effectuent de rétrogradation du cluster de destination.
  • Pour les migrations standards, votre cluster de destination existant doit être vide ou ne contenir que des données de configuration système par défaut. La migration vers un cluster de destination existant contenant des données utilisateur (comme des tables) n'est pas possible pour les migrations standards.

    Si vous rencontrez des problèmes en raison de données supplémentaires dans votre cluster de destination existant, effacez les bases de données de votre cluster de destination et relancez le job de migration. Consultez Effacer les données supplémentaires de votre cluster de destination existant.

  • 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.

Remarques concernant le parallélisme du vidage des données

Lorsque vous créez un job de migration, vous pouvez augmenter le nombre d'abonnements parallèles pour accélérer le vidage initial des données et la réplication de la capture de données modifiées (CDC) en cours. L'utilisation de paramètres de parallélisme de vidage de données plus élevés augmente également l'utilisation des connexions et des ressources sur votre base de données source et votre cluster AlloyDB pour PostgreSQL de destination.

  • Assurez-vous que votre base de données source dispose d'une marge de manœuvre suffisante en termes de processeur, de mémoire et d'E/S avant d'utiliser le parallélisme maximal.
  • Lorsque vous utilisez le parallélisme de vidage des données ajusté, vous devez configurer des valeurs plus élevées pour max_replication_slots, max_wal_senders et max_worker_processes sur votre base de données source. Pour obtenir des calculs de paramètres détaillés, consultez Configurer votre base de données source.
  • L'extension pglogical réplique les données au niveau de la table lors du vidage complet initial. Une seule table non partitionnée est attribuée à un abonnement et n'est pas répartie entre plusieurs abonnements parallèles ou threads de travail.
  • L'extension pglogical réplique les partitions feuilles individuelles sous forme de tables distinctes et peut distribuer plusieurs partitions feuilles sur des abonnements parallèles lors du vidage complet initial. Une seule partition feuille volumineuse ne peut pas être répartie sur plusieurs abonnements et est copiée par un seul thread.
  • Database Migration Service trie les tables par taille et les répartit entre les abonnements parallèles. Database Migration Service crée jusqu'à deux abonnements par base de données (et jusqu'à deux au total pour toutes les bases de données) pour un parallélisme optimal, et jusqu'à quatre abonnements par base de données (et jusqu'à quatre au total pour toutes les bases de données) pour un parallélisme maximal, avec au moins un abonnement par base de données migrée. Par exemple, si une base de données comporte une table de 1 To et plusieurs petites tables, Database Migration Service isole la table de 1 To dans un abonnement et répartit les tables plus petites entre les abonnements restants. Même avec plusieurs abonnements actifs, la vitesse de vidage initiale globale est toujours limitée par le temps nécessaire pour copier la table unique de 1 To.
  • Database Migration Service attribue les tables sans clé primaire à des ensembles de réplication dédiés en insertion seule (un par abonnement parallèle). Plusieurs tables sans clé primaire peuvent être réparties sur des abonnements parallèles, mais lors du vidage complet initial, chaque table individuelle est copiée en tant que flux de table unique dans un abonnement et n'est pas divisée en plusieurs threads parallèles.

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 les jobs de migration et les profils de connexion inutilisés. Pour en savoir plus, consultez Quotas et limites.

Compatibilité des versions d'extension PostgreSQL lors des mises à niveau de versions majeures

Lorsque vous migrez vers une version majeure de PostgreSQL plus récente, Database Migration Service utilise l'utilitaire pg_restore, qui installe la version d'extension par défaut de la version majeure de PostgreSQL cible. Vous ne pouvez pas spécifier de version d'extension exacte pour l'utilitaire pg_restore.

Si votre base de données source utilise une version d'extension dont le schéma n'est pas compatible avec la version par défaut installée sur la version majeure de PostgreSQL cible, la migration peut échouer en raison d'une incompatibilité de schéma ou d'erreurs internes.

Pour éviter les échecs de migration, vérifiez la compatibilité des schémas. Avant de procéder à la migration, mettez à niveau les extensions de votre base de données source vers une version compatible avec la version majeure de PostgreSQL cible.

Étapes suivantes