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 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 : 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 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 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é par IP privée et migrer vers une nouvelle instance de destination, utilisez l'appairage de VPC.

  • L'authentification IAM pour les bases de données n'est pas compatible avec les instances ou clusters de destination. 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 Authentification IAM dans la documentation Cloud SQL.

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 de 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 une différence 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.

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 instance Cloud SQL 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 n'ajoute des abonnements parallèles que lorsqu'il est possible de réduire le volume total de données de l'abonnement le plus volumineux. Database Migration Service crée jusqu'à deux abonnements par base de données pour un parallélisme optimal et jusqu'à quatre abonnements par base de données pour un parallélisme maximal, répartis en fonction de la taille de la base de données à partir d'un pool cible de 10 abonnements sur toutes les bases de données (avec au moins un abonnement par base de données migrée). Si une base de données présente des tailles de table très asymétriques, Database Migration Service alloue moins d'abonnements que le plafond maximal. Par exemple, si une base de données contient une table de 1 To et plusieurs petites tables, Database Migration Service isole la table de 1 To dans un abonnement et regroupe les tables plus petites dans un deuxième abonnement. Dans ce scénario, Database Migration Service n'utilise que deux abonnements, même lorsque le parallélisme est défini sur Maximum.
  • 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.

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.