Limites connues

Avant de choisir de migrer vos bases de données vers Cloud SQL, 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.
    • 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.

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

  • 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 la commande suivante : 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.

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

  • Seules les extensions compatibles avec Cloud SQL pour PostgreSQL peuvent être migrées. Database Migration Service ne migre pas les extensions non compatibles avec Cloud SQL. La présence de ces extensions ne bloque pas la migration, mais pour garantir une migration fluide, vérifiez que vos applications ne font pas référence à des extensions non compatibles. Pour obtenir la liste des extensions compatibles, consultez Extensions PostgreSQL dans la documentation Cloud SQL.

  • 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 Cloud SQL pour PostgreSQL. Si vous utilisez pg_cron dans vos bases de données sources, réinstallez l'extension et configurez vos jobs Cron sur l'instance 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 Recovery.

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

  • Si d'autres extensions existent dans la base de données source et que leurs versions ne sont pas compatibles avec Cloud SQL, le test ou le démarrage du job de migration échouera.

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

  • Comportement opérationnel de la base de données de destination pendant la migration :

    • Base de données de destination accessible en écriture : Cloud SQL pour PostgreSQL n'exécute pas la base de données de destination en mode lecture seule pendant la migration. L'instance de destination n'est pas rétrogradée lorsqu'elle est créée par Database Migration Service.

    • Évitez les opérations d'écriture sur les données en cours de migration : n'effectuez pas d'opérations d'écriture (telles que INSERT, UPDATE, DELETE ou des modifications de schéma LDD) sur les tables ou les bases de données participant à la migration. L'exécution d'écritures sur des données en cours de migration peut entraîner des conflits de réplication avec le flux de capture des données modifiées (CDC) entrant.

    • Gérer les utilisateurs de la base de données : vous pouvez créer et gérer des utilisateurs de la base de données à tout moment à l'aide des commandes psql standards ou via Cloud SQL dans la console Google Cloud . Pour en savoir plus, consultez Gérer les utilisateurs dans la documentation Cloud SQL.

    • Fonctionnalités suspendues : les sauvegardes automatisées et la récupération à un moment précis (PITR) sont suspendues pendant la réplication continue. De plus, vous ne pouvez pas créer d'instances répliquées Cloud SQL avec accès en lecture à partir de l'instance de destination tant que le job de migration n'a pas été promu.

  • 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 fonctions définies avec SECURITY DEFINER sont créées par cloudsqlexternalsync sur l'instance Cloud SQL de destination, qui dispose de droits élevés. Limitez les droits d'exécution sur les fonctions SECURITY DEFINER sensibles en révoquant les autorisations publiques et en accordant l'accès de manière sélective.

  • Cloud SQL n'est pas compatible avec les espaces de table personnalisés. Tous les objets des espaces de table personnalisés sont migrés vers l'espace de table pg_default par défaut dans Cloud SQL.

  • 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 des migrations vers des instances de destination existantes

  • Rétrogradation de l'instance de destination pour les migrations standards : pour les migrations standards vers des instances Cloud SQL existantes, Database Migration Service rétrograde l'instance autonome pour la configurer en tant qu'instance répliquée externe de la base de données source.
    • La rétrogradation de l'instance ne place pas le moteur PostgreSQL en mode lecture seule, mais vous devez éviter les opérations d'écriture sur les tables en cours de migration pour éviter les conflits de réplication.
    • La rétrogradation de l'instance suspend les sauvegardes automatiques et la récupération à un moment précis (PITR), et empêche l'ajout d'instances dupliquées avec accès en lecture Cloud SQL jusqu'à la promotion.
    • Vous devez confirmer la rétrogradation lors de la création du job de migration dans la console Google Cloud en saisissant l'ID de l'instance 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 de l'instance de destination.
  • Votre instance de destination existante ne peut contenir que les bases de données système par défaut qui sont configurées automatiquement lorsque vous créez l'instance de destination. La migration vers des instances de destination existantes contenant des données utilisateur n'est pas possible.

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

  • Vous ne pouvez configurer qu'un seul job de migration par instance de destination.
  • Vous ne pouvez migrer que vers des instances Cloud SQL autonomes. La migration vers des instances répliquées de serveur externe n'est pas possible.
  • Après avoir promu une instance, vous devez activer la récupération à un moment précis.
  • Si votre instance dispose de paramètres de sauvegarde personnalisés (par exemple, un emplacement de sauvegarde personnalisé), vous devez restaurer à nouveau vos paramètres de sauvegarde après la promotion. Au cours du processus de promotion, Cloud SQL rétablit les valeurs par défaut des paramètres de sauvegarde.
  • Pour les utilisateurs de Terraform : Database Migration Service modifie les paramètres de sauvegarde et de récupération de votre instance de destination. Cela peut entraîner des différences entre les paramètres de l'instance de destination et la configuration Terraform utilisée pour le provisionnement. Si vous rencontrez ce problème, consultez les conseils de la section Diagnostiquer les problèmes.

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.

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.