Avant de choisir de migrer vos bases de données vers Cloud SQL, assurez-vous de prendre en compte les limites connues pour ce scénario de migration.
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 Cloud SQL 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 compatibles avec Cloud SQL pour PostgreSQL peuvent être migrés.
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 un processus de migration fluide, vérifiez que vos objets ou applications ne font référence à aucune extension non prise en charge. Nous vous recommandons de supprimer ces extensions et références de votre base de données source avant de continuer.
L'extension pg_cron (ou tout paramètre cron associé à 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 l'extension pg_cron dans vos bases de données sources, vous pouvez la réinstaller sur votre instance de destination une fois la migration terminée.
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 Cloud SQL.
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 Cloud SQL 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 Cloud SQL de destination est accessible en écriture pendant la migration pour permettre l'application des 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 cloudsqlexternalsync dans l'instance répliquée Cloud SQL. Lorsqu'elle est exécutée par un utilisateur, elle l'est avec les droits de cloudsqlexternalsync, qui possède les rôles cloudsqlsuperuser et cloudsqlreplica. Il est préférable de limiter l'utilisation d'une fonction de définition de la 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.
Cloud SQL n'est pas compatible avec les espaces de table personnalisés. Toutes les données des espaces de table personnalisés sont migrées vers l'espace de table pg_default dans l'instance de destination 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
Votre instance de destination existante doit être vide ou ne contenir que des données de configuration système. La migration vers des instances de destination existantes contenant des données utilisateur (telles que des tables) n'est pas prise en charge.
Si votre instance dispose de paramètres de sauvegarde personnalisés (par exemple, un emplacement de sauvegarde personnalisé), vous devez personnaliser à nouveau vos paramètres de sauvegarde après la promotion de l'instance. 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 paramètres d'instance de destination différents de la configuration Terraform que vous avez utilisée pour le provisionnement. Si vous rencontrez ce problème, suivez 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 des profils de connexion et des tâches de migration (y compris celles déjà effectuées).
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/05 (UTC)."],[[["\u003cp\u003eDatabase Migration Service for PostgreSQL has limitations regarding the replication of generated columns, DDL commands, and \u003ccode\u003eUPDATE\u003c/code\u003e and \u003ccode\u003eDELETE\u003c/code\u003e statements for tables without primary keys.\u003c/p\u003e\n"],["\u003cp\u003eCertain PostgreSQL features, such as \u003ccode\u003eUNLOGGED\u003c/code\u003e and \u003ccode\u003eTEMPORARY\u003c/code\u003e tables, large object data types, and unsupported extensions, are not supported by the Database Migration Service and cannot be migrated.\u003c/p\u003e\n"],["\u003cp\u003eDatabase Migration Service only migrates all tables and schemas in a database, and it does not migrate specific system schemas such as \u003ccode\u003einformation_schema\u003c/code\u003e and tables beginning with \u003ccode\u003epg\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eMigration to existing Cloud SQL instances is limited to instances that are empty or contain only system configuration data, and only one migration job is allowed per destination instance.\u003c/p\u003e\n"],["\u003cp\u003eThe destination Cloud SQL database is writable during the migration process, but users should avoid making changes to the database configuration or table structures that might affect data integrity.\u003c/p\u003e\n"]]],[],null,["# Known limitations\n\n\u003cbr /\u003e\n\n[MySQL](/database-migration/docs/mysql/known-limitations \"View this page for the MySQL version of Database Migration Service.\") \\| PostgreSQL \\| [PostgreSQL to AlloyDB](/database-migration/docs/postgresql-to-alloydb/known-limitations \"View this page for the PostgreSQL to AlloyDB version of Database Migration Service.\")\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nOverview\n--------\n\nBefore you choose to migrate your databases to\nCloud SQL, make sure you consider known limitations for this migration\nscenario.\n| **Note:** You can also use Google Cloud Migration Center to discover possible limitations or gaps in feature support for your specific scenario. See [Discover and import databases](/migration-center/docs/discover-and-import-databases) in the Migration Center documentation.\n\nKnown limitations for using a PostgreSQL database as a source include:\n\n- The `pglogical` extension doesn't support the replication of [generated columns](https://www.postgresql.org/docs/current/ddl-generated-columns.html) for PostgreSQL 12+.\n\n- Changes to table structures (DDL) aren't replicated through standard DDL\n commands, but only with commands executed using the `pglogical`\n extension used for replication. This includes\n [changes to\n `enum` types](https://www.postgresql.org/docs/current/sql-altertype.html).\n\n - For example, `pglogical` provides a function\n `pglogical.replicate_ddl_command` that allows DDL to be run on\n both the source database and replica at a consistent point. The user\n running this command on the source must already exist on the replica.\n\n - In order to replicate data for new tables, you must use the\n `pglogical.replication_set_add_table` command to add\n the new tables to existing replication sets.\n\n - To learn more about DDL replication while the migration is in\n progress, see the section on\n [migration fidelity](/database-migration/docs/postgres/migration-fidelity).\n\n- For tables that don't have primary keys, Database Migration Service supports migration of the **initial snapshot and `INSERT` statements during the change data capture (CDC) phase** . You should migrate `UPDATE` and `DELETE` statements manually.\n\n- Database Migration Service doesn't migrate data from materialized views, just the view schema. To populate the views, run the following command: `REFRESH MATERIALIZED VIEW `\u003cvar translate=\"no\"\u003eview_name\u003c/var\u003e.\n\n- The `SEQUENCE` states (for example, `last_value`) on the new Cloud SQL destination might vary from the source `SEQUENCE` states.\n\n- `UNLOGGED` and `TEMPORARY` tables aren't and can't be\n replicated.\n\n- Large Object data type isn't supported. More details in the section on\n [migration fidelity](/database-migration/docs/postgres/migration-fidelity).\n\n\u003c!-- --\u003e\n\n- Only [extensions and procedural languages](/sql/docs/postgres/extensions)\n that Cloud SQL supports for PostgreSQL can be migrated.\n Database Migration Service doesn't migrate extensions that are unsupported by\n Cloud SQL. The presence of these extensions doesn't block the migration,\n but to ensure a smooth migration process verify that your objects or\n applications don't reference any unsupported extensions. We recommend removing\n these extensions and references from your source database before you\n proceed.\n\n- The [`pg_cron`](/sql/docs/postgres/extensions#pg_cron)\n extension (or any `cron` settings associated with the extension)\n isn't migrated by Database Migration Service, but it is supported in\n Cloud SQL for PostgreSQL destinations. If you use the `pg_cron`\n extension in your source databases, you can re-install it on your destination\n instance after the migration is complete.\n\n\u003c!-- --\u003e\n\n- Database Migration Service doesn't support migrating from read replicas that are in recovery mode.\n\n- Database Migration Service doesn't support Amazon RDS sources where the AWS SCT extension pack is applied.\n\n\u003c!-- --\u003e\n\n- User-defined functions written in C can't be migrated, except for functions that are installed in the PostgreSQL database when you're installing [extensions](/sql/docs/postgres/extensions) that are supported by Cloud SQL.\n\n\u003c!-- --\u003e\n\n- If other extensions and procedural languages exist in the source database, or if their versions aren't supported, then when you test or start the migration job, it will fail.\n\n- Databases that are added after the migration job has started aren't migrated.\n\n\u003c!-- --\u003e\n\n- You can't select specific tables or schemas when you migrate by using Database Migration Service. Database Migration Service migrates all tables and schemas, except for the following:\n - The information schema (`information_schema`).\n - Any tables that begin with `pg`, for example, `pg_catalog`. For the full list of PostgreSQL catalogs that begin with `pg`, see [PostgreSQL system catalogs](https://www.postgresql.org/docs/current/catalogs.html) in the PostgreSQL documentation.\n - Information about users and user roles isn't migrated.\n\n\u003c!-- --\u003e\n\n- If encrypted databases require customer-managed encryption keys to decrypt the databases, and if Database Migration Service doesn't have access to the keys, then the databases can't be migrated.\n\n However, if customer data is encrypted by the [`pgcrypto` extension](/sql/docs/postgres/extensions#miscellaneous-extensions), then the data can be migrated with Database Migration Service (because Cloud SQL supports the extension).\n\n Database Migration Service also supports migrating data from encrypted Amazon Aurora or Amazon RDS databases because these databases handle decryption transparently in their services. For more information, see [Encrypting Amazon Aurora resources](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.Encryption.html) and [Encrypting Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html).\n- The destination Cloud SQL database is\n writable during the migration\n to allow DDL changes to be applied if needed. Take care not to make any\n changes to the database configuration or table structures which might break\n the migration process or impact data integrity.\n\n- Trigger behavior depends on how they were configured. The default behavior is they\n won't trigger, but if they were configured using the\n `ALTER EVENT TRIGGER` or `ALTER TABLE` statement and the trigger state is set to either replica or always, then they will trigger\n on the replica during replication.\n\n- Functions with security definer will be created by\n `cloudsqlexternalsync` in Cloud SQL replica. When it's\n executed by any users, it will be executed with the privileges of\n `cloudsqlexternalsync` which has `cloudsqlsuperuser` and\n `cloudsqlreplica` roles. It's better to restrict use of a security\n definer function to only some users. To do that, the user should revoke the\n default PUBLIC privileges and then grant execute privilege selectively.\n\n- Cloud SQL does not support customized tablespaces. All the data inside customized\n tablespaces is migrated to the `pg_default` tablespace in the\n Cloud SQL destination instance.\n\n- [Private Service Connect interfaces connectivity method](/database-migration/docs/postgres/networking-methods#psc-interfaces)\n is only supported for migrating to existing destination instances.\n If you want to use private IP connectivity and migrate to a new destination\n instance, use VPC peering.\n\n\n ### Limitations for migrations to existing destination instances\n\n - Your existing destination instance must be empty or contain only system configuration data. Migrating to existing destination instances that contain user data (such as tables) isn't supported. If you encounter issues due to extra data in your existing destination\n instance, clear the databases in your destination instance and re-try the migration job.\n See [Clear extra\n data from your existing destination instance](/database-migration/docs/postgres/diagnose-issues#clear-ext-instance-data-steps).\n\n - You can configure only one migration job per destination instance.\n - You can only migrate to standalone Cloud SQL instances. Migrating to [external server replicas](/sql/docs/postgres/replication/configure-external-replica) isn't supported.\n - Migrating data to a Cloud SQL instance that has [Private Service Connect](/sql/docs/postgres/about-private-service-connect) enabled isn't supported.\n - After you promote an instance, you must turn on [point-in-time recovery](/sql/docs/postgres/backup-recovery/restore#tips-pitr).\n - If your instance has customized backup settings (for example, a [custom backup location](/sql/docs/postgres/backup-recovery/backing-up#locationbackups)), then after you promote the instance, you must customize your backup settings again. During the promotion process, Cloud SQL resets your backup settings to their default values.\n - **For Terraform users** : Database Migration Service modifies the backup and recovery settings of your destination instance. This might cause the destination instance settings to be different from the Terraform configuration you used for provisioning. If you experience this issue, follow the guidance in [Diagnose issues](/database-migration/docs/postgres/diagnose-issues#existing-instance-terraform-config-drift).\n\n ### Quotas\n\n - Up to 2,000 connection profiles and 1,000 migration jobs can exist at any given time. To create space for more, migration jobs (including completed ones) and connection profiles can be deleted."]]
