Cette page a été traduite par l'API Cloud Translation.

Diagnostiquer les problèmes de migration de PostgreSQL vers AlloyDB

Résoudre les erreurs de migration

Le processus de tâche de migration peut générer des erreurs lors de l'exécution.

Certaines erreurs, telles qu'un mot de passe incorrect dans la base de données source, peuvent être récupérées, ce qui signifie qu'elles peuvent être corrigées et que le job de migration reprend automatiquement.
Certaines erreurs sont irrécupérables, comme les erreurs de réplication des données. Dans ce cas, le job de migration doit être redémarré depuis le début.

En cas d'erreur, l'état du job de migration passe à Failed et le sous-état reflète le dernier état avant l'échec.

Pour résoudre un problème, accédez à la tâche de migration ayant échoué pour afficher l'erreur, puis suivez la procédure décrite dans le message d'erreur.

Pour afficher plus de détails sur l'erreur, accédez à Cloud Monitoring à l'aide du lien sur le job de migration. Les journaux sont filtrés en fonction du job de migration spécifique.

Le tableau suivant contient quelques exemples de problèmes et leur solution :

Problème constaté	Causes possibles	Solutions possibles
Échec de la connexion à l'instance de base de données source.	Un problème de connectivité est survenu entre l'instance de base de données source et l'instance de destination.	Suivez la procédure décrite dans Déboguer la connectivité.
Échec de l'exécution du job de migration en raison de versions de base de données source et de destination incompatibles.	Les versions des bases de données source et de destination ne sont pas compatibles. Plus précisément, la version de la base de données source fournie n'est pas compatible avec la version de la base de données de destination.	Assurez-vous que la version de la base de données de destination est identique à celle de la base de données source ou supérieure d'une version majeure. Créez ensuite un job de migration.
Les langages de définition de données (LDD) ou les langages de manipulation de données (LMD) sont bloqués sur la source.	Les LDD qui nécessitent le verrouillage `ACCESS EXCLUSIVE` et qui sont en cours d'exécution pendant la phase de vidage complet sont bloquées.	Lors du processus de synchronisation initiale (vidage complet), les LDD ou les programmes nécessitant des verrous `ACCESS EXCLUSIVE` tels que `ALTER TABLE` ou `DROP TABLE` doivent être évités sur les tables. Sinon, les DDL ou les programmes attendront la fin de la synchronisation initiale. Par exemple, si une table est toujours en cours de synchronisation initiale et qu'une commande `ALTER TABLE` est exécutée sur cette même table, la commande ne sera pas exécutée et les commandes LDD et LMD suivantes seront bloquées jusqu'à la fin de la synchronisation initiale.
Message d'erreur : `No pglogical extension installed on databases (X)`	`pglogical` n'est pas installé dans une ou plusieurs bases de données sources.	Suivez ces instructions pour installer `pglogical` sur les bases de données de l'instance source.
Message d'erreur : `Replication user 'x' doesn't have sufficient privileges.`	L'utilisateur qui utilise Database Migration Service ne dispose pas des droits requis pour effectuer l'opération désignée.	Suivez ces consignes pour vous assurer que cet utilisateur dispose des droits requis.
Message d'erreur : `Unable to connect to source database server.`	Database Migration Service ne peut pas établir de connexion au serveur de base de données source.	Assurez-vous que les instances de base de données source et de destination peuvent communiquer entre elles, et que vous avez rempli toutes les conditions préalables requises qui s'affichent lorsque vous définissez les paramètres du job de migration.
Message d'erreur : `The source database 'wal_level' configuration must be equal to 'logical'.`	Le `wal_level` de la base de données source est défini sur une valeur autre que `logical`.	Définissez `wal_level` sur `logical`.
Message d'erreur : `The source database 'max_replication_slots' configuration is not sufficient.`	Le paramètre `max_replication_slots` n'a pas été configuré correctement.	Pour définir correctement ce paramètre, suivez ces consignes.
Message d'erreur : `The source database 'max_wal_senders' configuration is not sufficient.`	Le paramètre `max_wal_senders` n'a pas été configuré correctement.	Pour définir correctement ce paramètre, suivez ces consignes.
Message d'erreur : `The source database 'max_worker_processes' configuration is not sufficient.`	Le paramètre `max_worker_processes` n'a pas été configuré correctement.	Pour définir correctement ce paramètre, suivez ces consignes.
Message d'erreur : `Cleanup may have failed on source due to error: generic::unknown: failed to connect to on-premises database.` OU Message d'erreur : `Error promoting EM replica: finished drop replication with errors.`	Les paramètres nécessaires à la réplication ne peuvent pas être nettoyés lors de la promotion d'un job de migration.	Pour chaque base de données, exécutez les commandes en tant qu'utilisateur disposant du droit `superuser`. Pour savoir quelles commandes exécuter, consultez Nettoyer les emplacements de réplication.
Message d'erreur : `x509 certificate signed by unknown authority.`	Le certificat CA source fourni à Database Migration Service ne contient peut-être que le certificat racine. Toutefois, le certificat source nécessite à la fois le certificat racine et tous les certificats intermédiaires. Par exemple, pour Amazon Relational Database Service, l'utilisation du certificat rds-ca-2019-root.pem peut entraîner ce problème.	Créez un certificat CA source combiné contenant le certificat racine et tous les certificats intermédiaires requis. Pour le cas d'utilisation d'Amazon Relational Database Service, utilisez le certificat rds-combined-ca-bundle.pem au lieu du certificat rds-ca-2019-root.pem.
Message d'erreur : `ERROR: Out of shared memory HINT: You might need to increase max_locks_per_transaction.`	La valeur définie pour le paramètre `max_locks_per_transaction` n'est pas suffisante.	Définissez la valeur de ce paramètre sur au moins {`max_number_of_tables_per_database`}/(`max_connections` + `max_prepared_transactions`).
Message d'erreur : `ERROR: no data left in message.`	Le package pglogical n'est pas installé correctement sur l'instance source.	Pour savoir comment installer correctement ce package, consultez Installer le package pglogical sur l'instance source.
Message d'erreur : `Cannot assign TransactionIds during recovery.`	La source configurée est en mode récupération.	Configurez une source qui n'est pas en mode récupération.
Le dump complet est lent.	L'importation de données volumineuses depuis la base de données source vers la destination AlloyDB peut être lente.	Choisissez un niveau supérieur pour la destination AlloyDB afin d'obtenir la bande passante réseau et disque maximale disponible. Ajustez l'indicateur `max_wal_size` de la destination AlloyDB. En règle générale, 32 Go ou 64 Go est une bonne valeur à définir pour cette option. La mise à jour de ce signalement ne nécessite pas de redémarrer le serveur.
Message d'erreur : `subscriber {subscriber_name} initialization failed during nonrecoverable step (d), please try the setup again`	La tâche de migration a échoué lors de la phase de vidage complet et n'est pas récupérable. L'instance de base de données source a été redémarrée ou était en mode récupération, ou les connexions de réplication ont été interrompues en raison d'une valeur insuffisante définie pour le paramètre `wal_sender_timeout`. Pour trouver l'origine du problème : Accédez à la page Explorateur de journaux dans la console Google Cloud . Dans la liste des ressources, sélectionnez votre instance AlloyDB. Une liste des journaux les plus récents de l'instance s'affiche. Dans les noms de fichiers journaux, sélectionnez `postgres.log`. Définissez le niveau de gravité du journal sur tous les niveaux supérieurs à `Warning`. Les premiers journaux d'erreurs peuvent être à l'origine de l'échec.	Assurez-vous que Database Migration Service peut toujours se connecter à l'instance de base de données source pendant la phase de vidage complet. Vérifiez si la valeur du paramètre `wal_sender_timeout` est définie sur un nombre plus élevé (par exemple, `0`) sur l'instance de base de données source. Redémarrez la tâche de migration, puis réessayez.
Message d'erreur : `ERROR: unknown column name {column_name}`	Une colonne a été ajoutée à une table répliquée sur le nœud principal, mais pas sur le nœud de réplica.	Seules les modifications du langage de manipulation de données (LMD) sont automatiquement mises à jour lors des migrations continues. La gestion des modifications du langage de définition de données (LDD) pour que les bases de données source et de destination restent compatibles incombe à l'utilisateur. Vous pouvez procéder de deux manières : Arrêtez les opérations d'écriture sur la base de données source, puis exécutez les commandes LDD sur la source et la destination. Avant d'exécuter les commandes LDD sur la destination, accordez le rôle `cloudsqlexternalsync` à l'utilisateur Cloud SQL qui applique les modifications LDD. Utilisez `pglogical.replicate_ddl_command` pour autoriser l'exécution des commandes LDD sur la source et la destination en un point cohérent. L'utilisateur qui exécute les commandes doit avoir le même nom d'utilisateur sur la source et la destination, et doit être le super-utilisateur ou le propriétaire de l'artefact migré (par exemple, la table, la séquence, la vue ou la base de données). Consultez Migration continue pour trouver des exemples d'utilisation de `pglogical.replicate_ddl_command.`.
Message d'erreur : `ERROR: cannot truncate a table referenced in a foreign key constraint`	L'utilisateur a essayé de tronquer une table comportant une contrainte de clé étrangère.	Supprimez d'abord la contrainte de clé étrangère, puis tronquez la table.
Message d'erreur : `ERROR: connection to other side has died`	La connexion de réplication s'est terminée en raison d'une valeur insuffisante définie pour `wal_sender_timeout parameter`. L'erreur se produit généralement lors de la phase de réplication après la réussite du vidage initial.	Envisagez d'augmenter la valeur du paramètre `wal_sender_timeout` ou de désactiver le mécanisme de délai d'expiration en définissant sa valeur sur `0` sur l'instance de base de données source.
Lorsque vous migrez des bases de données sélectionnées et que la tâche de migration ne parvient pas à répliquer les données dans une ou plusieurs bases de données, l'état Échec s'affiche dans la liste des bases de données.	Diverses erreurs de tâches de migration.	Dans la colonne Erreurs, cliquez sur Afficher les erreurs et corrigez-les. Vous pouvez également supprimer les bases de données ayant échoué de la tâche de migration. Pour savoir comment supprimer une base de données ayant échoué d'un job de migration, consultez Gérer les jobs de migration.

Nettoyer les emplacements de réplication

Un des messages suivants s'affiche :

Cleanup may have failed on source due to error: generic::unknown: failed to connect to on-premises database.
Error promoting EM replica: finished drop replication with errors.

Causes possibles

Lorsque vous promouvez une instance AlloyDB, si l'instance source n'est pas accessible depuis l'instance AlloyDB (par exemple, si l'instance source n'est pas en cours d'exécution ou si vous avez supprimé l'instance AlloyDB de la liste d'autorisation des instances sources), les paramètres nécessaires à la réplication ne peuvent pas être nettoyés lors de la promotion d'un job de migration. Vous devez nettoyer les emplacements de réplication manuellement.

Solutions possibles

Pour chaque base de données, exécutez les commandes suivantes en tant qu'utilisateur disposant du droit superuser :

Obtenez les noms des emplacements de réplication à partir du message d'erreur, puis exécutez la commande suivante pour supprimer les emplacements, un par un :
```
select pg_drop_replication_slot({slot_name});
```
Si les noms des emplacements de réplication ne sont pas disponibles dans le message d'erreur, exécutez la commande suivante pour interroger les emplacements de réplication existants :
```
select pg_drop_replication_slot(slot_name) from pg_replication_slots where slot_name like '%alloydb%' and active = 'f';
```
S'il n'existe aucune réplique AlloyDB utilisant l'instance source, exécutez la commande suivante pour nettoyer les paramètres pglogical :
```
select pglogical.drop_node(node_name) from pglogical.node where node_name like 'alloydb';
```
Si l'extension pglogical n'est plus nécessaire, exécutez la commande suivante pour la désinstaller :
```
DROP EXTENSION IF EXISTS pglogical;
```

Supprimer les clusters AlloyDB orphelins en mode amorçage

Dans de rares cas extrêmes, il est possible que votre job de migration ait été supprimé, mais pas le cluster AlloyDB associé, qui est toujours en mode bootstrapping. Il est possible de supprimer le cluster à l'aide de la commande gcloud d'AlloyDB pour supprimer un cluster, combinée à l'option --force.

Notez que la suppression d'un cluster d'amorçage pendant qu'il est utilisé par un job de migration entraîne un comportement indéfini.

Gérer les utilisateurs et les rôles

Migrer les utilisateurs existants

Actuellement, Database Migration Service ne permet pas de migrer des utilisateurs existants d'une instance source vers une instance AlloyDB de destination. Vous pouvez gérer cette migration en créant manuellement les utilisateurs dans AlloyDB.

À propos de l'utilisateur `alloydbexternalsync`

Lors de la migration, tous les objets de la base de données AlloyDB principale appartiennent à l'utilisateur alloydbexternalsync. Une fois les données migrées, vous pouvez modifier la propriété des objets pour d'autres utilisateurs en procédant comme suit :

Exécutez la commande GRANT alloydbexternalsync to {USER}.
Sur chaque base de données, exécutez la commande reassign owned by alloydbexternalsync to {USER};.
Pour supprimer l'utilisateur alloydbexternalsync, exécutez la commande drop role alloydbexternalsync.

Diagnostiquer les problèmes de migration de PostgreSQL vers AlloyDB Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.