Présentation
Avant de choisir de migrer vos bases de données vers Cloud SQL, assurez-vous de prendre en compte les limites connues de 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 (DDL) ne sont pas répliquées à l'aide de commandes DDL standards, mais uniquement à l'aide de commandes exécutées à l'aide de l'extension
pglogical
utilisée pour la réplication.Par exemple,
pglogical
fournit une fonctionpglogical.replicate_ddl_command
qui permet d'exécuter le LDD à la fois sur la base de données source et sur le réplica en 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
pour 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). Vous devez migrer les instructionsUPDATE
etDELETE
manuellement.Database Migration Service ne migre pas les données des vues matérialisées, mais uniquement le schéma de la vue. Pour renseigner 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 varier par rapport aux étatsSEQUENCE
de la source.Les tables
UNLOGGED
etTEMPORARY
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é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 un processus de migration fluide, vérifiez que vos objets ou applications ne font pas référence à des extensions non compatibles. 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 les paramètrescron
associés à l'extension) n'est pas migrée par Database Migration Service, mais elle est prise en charge dans les destinations Cloud SQL pour PostgreSQL. Si vous utilisez l'extensionpg_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 à partir d'instances dupliquées avec accès en lecture en mode de récupération.
Database Migration Service n'est pas compatible avec les sources Amazon RDS pour lesquelles le pack d'extension AWS SCT est appliqué.
- Les fonctions définies par l'utilisateur écrites en C ne peuvent pas être migrées, sauf 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 de la tâche de migration ne sont pas migrées.
- Vous ne pouvez pas sélectionner d'objets de base de données spécifiques (tels que des bases de données, des tables ou des schémas) lorsque vous effectuez une migration à l'aide de Database Migration Service.
Database Migration Service migre toutes les tables et tous les schémas, à l'exception des schémas suivants :
- Schéma d'informations (
information_schema
) - Tous les schémas commençant par
pg
(par exemple,pg_catalog
, qui contient les tables système et tous les types de données, fonctions et opérateurs intégrés, et qui existe automatiquement dans toutes les bases de données). Par conséquent, les informations sur les utilisateurs et les rôles utilisateur ne sont pas migrées. Consultez la liste complète des schémas commençant parpg
.
- Schéma d'informations (
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 que Database Migration Service n'a pas accès à ces clés, les bases de données 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 les pages 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 afin de permettre l'application des modifications DDL si nécessaire. Veillez à ne pas apporter de modifications à la configuration de la base de données ni aux structures de table qui pourraient interrompre le processus de migration ou affecter l'intégrité des données.
Le comportement des déclencheurs dépend de la façon dont ils ont été configurés. Par défaut, ils ne se déclenchent pas, mais s'ils ont été configurés à l'aide de l'instruction
ALTER EVENT TRIGGER
ouALTER TABLE
et que l'état du déclencheur est défini sur "replica" ou "always", ils se déclenchent sur le réplica lors de la réplication.Les fonctions avec un définisseur de sécurité seront créées par
cloudsqlexternalsync
dans l'instance dupliquée Cloud SQL. Lorsqu'il est exécuté par des utilisateurs, il est exécuté avec les droits decloudsqlexternalsync
, qui dispose des rôlescloudsqlsuperuser
etcloudsqlreplica
. Il est préférable de limiter l'utilisation d'une fonction de définition de la sécurité à certains utilisateurs. 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.
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 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 réessayez la tâche de migration. Consultez la section Effacer les données supplémentaires de votre instance de destination existante.
- Vous ne pouvez configurer qu'une seule tâche de migration par instance de destination.
- Vous ne pouvez migrer que vers des instances Cloud SQL autonomes. La migration vers des répliques de serveurs externes n'est pas prise en charge.
- La migration de données vers une instance Cloud SQL sur laquelle Private Service Connect est activé n'est pas acceptée.
- 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 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 différences entre les paramètres de l'instance de destination et 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, vous pouvez supprimer des profils de connexion et des tâches de migration (y compris celles déjà effectuées).