Résoudre une erreur
Le processus de job de migration peut rencontrer des erreurs lors de l'exécution.
- Pour certaines erreurs, Database Migration Service relance automatiquement les opérations défectueuses pour poursuivre le processus de migration et éviter les interruptions. L'état du job de migration passe à En cours d'exécution avec des erreurs. Cet état signifie que Database Migration Service continue de migrer les données non affectées par les erreurs.
- Certaines erreurs sont irrécupérables. Lorsque Database Migration Service rencontre une erreur irrécupérable, l'état du job de migration passe à Échec. Dans ce cas, le job de migration doit être redémarré une fois le problème résolu.
Pour résoudre une erreur, accédez au job de migration concerné, affichez l'erreur et suivez les étapes décrites dans le message d'erreur. Vous pouvez également obtenir plus de détails en consultant les journaux Cloud Monitoring de votre instance Cloud SQL de destination. Utilisez le lien Cloud Monitoring sur la page d'informations du job de migration.
Le tableau suivant présente quelques exemples de problèmes et comment les résoudre :
| Pour ce problème... | Le problème peut être... | Essayez ce qui suit... |
|---|---|---|
Message d'erreur : The BAK file's database major version number
{backup_version_num} must not be higher than the current database
major version number {your Cloud SQL for SQL Server version number}. |
Vous essayez d'importer des fichiers de sauvegarde à partir d'une version de SQL Server ultérieure à celle que vous utilisez dans votre instance de destination Cloud SQL pour SQL Server.
Database Migration Service n'est compatible avec les migrations entre versions (d'une version antérieure vers une version ultérieure) que si vous respectez les consignes de compatibilité entre versions. Consultez Bases de données sources et de destination compatibles. |
Recréez l'instance de destination Cloud SQL pour SQL Server pour utiliser une version ultérieure de SQL Server, puis réessayez le processus de migration avec votre nouvelle instance. |
Message d'erreur : The following database already exists in destination: {database_name}.
|
Votre instance Cloud SQL de destination contient déjà une base de données portant le même nom que l'une des bases de données incluses dans votre job de migration. | Supprimez le conflit de nom. Consultez Erreur : la base de données existe déjà dans la destination . |
Message d'erreur :
Permission denied for {cloudsql.databases.get} on the Database Migration Service service account. |
Le compte de service Database Migration Service ne dispose pas des autorisations nécessaires. | Ajoutez les autorisations manquantes au compte de service Database Migration Service. Consultez Contrôle des accès avec IAM. |
Message d'erreur :
Missing WAL file at Log Sequence Number (LSN) {log_number_here} |
Vos fichiers journaux de transactions utilisent peut-être des codes temporels d'epoch incorrects par rapport à l'ordre des mises à jour qu'ils contiennent. Database Migration Service utilise des numéros de séquence de journaux et des codes temporels d'epoch pour contrôler l'ordre dans lequel les fichiers journaux des transactions sont répliqués sur l'instance Cloud SQL de destination. | Vérifiez et ajustez les codes temporels epoch utilisés dans les noms de vos derniers fichiers journaux de transactions. Consultez Ajuster les noms de journaux de transactions défectueux. |
| Lorsque vous migrez des bases de données sélectionnées et que le job de migration ne parvient pas à répliquer les données vers une ou plusieurs bases de données, l'état Échec s'affiche dans la liste des bases de données. | Diverses erreurs de job de migration. | Dans la colonne Erreurs, cliquez sur Afficher les erreurs et corrigez-les. Après avoir corrigé les erreurs, cliquez sur Redémarrer. |
Erreur : La base de données existe déjà dans la destination
Le message d'erreur suivant s'affiche : The following database already exists in destination: {database_name}.
Cause possible
Votre instance Cloud SQL de destination contient déjà une base de données portant le même nom que l'une des bases de données incluses dans votre job de migration.
Solutions possibles
Selon votre scénario de migration, il existe différentes manières de résoudre le problème des bases de données en double. Essayez l'une des actions suivantes :
Renommez le bucket Cloud Storage source pour migrer votre base de données sous un autre nom.
Le nom de la base de données que Database Migration Service crée dans votre instance Cloud SQL de destination est dérivé des noms des dossiers dans Cloud Storage où vous stockez les fichiers de sauvegarde. Si vous avez deux bases de données différentes qui portent le même nom et que vous avez besoin des deux dans votre destination Cloud SQL, vous pouvez renommer les dossiers et recréer le job de migration pour éviter le conflit de noms.
Procédez comme suit :
- Créez des dossiers pour la base de données source concernée par le conflit de noms. Consultez Stocker des fichiers de sauvegarde dans un bucket Cloud Storage .
- Recréez votre job de migration. Consultez
Créer un job de migration.
Vous pouvez ajouter des bases de données à un job de migration existant, mais vous ne pouvez pas en supprimer. C'est pourquoi vous devez recréer l'intégralité du job de migration.
Supprimez la base de données en double de votre instance Cloud SQL pour SQL Server.
Si la base de données de votre instance Cloud SQL de destination est un doublon, vous pouvez la supprimer de votre instance et poursuivre le job de migration. Consultez Supprimer une base de données dans la documentation Cloud SQL pour SQL Server.
Ajuster les noms des fichiers journaux de transactions pour les fichiers WAL désordonnés
Cause possible
Vos fichiers journaux de transactions utilisent peut-être des codes temporels epoch incorrects par rapport à l'ordre des mises à jour qu'ils contiennent. Database Migration Service utilise des numéros de séquence de journaux et des codes temporels d'epoch pour contrôler l'ordre dans lequel les fichiers journaux des transactions sont répliqués sur l'instance Cloud SQL de destination.
Solutions possibles
L'importation de vos fichiers peut être retardée ou ne pas respecter l'ordre chronologique. Attendez quelques minutes que le problème se résolve ou vérifiez s'il manque des fichiers dans votre bucket Cloud Storage.
Si le problème persiste, vérifiez et ajustez les horodatages d'epoch dans les noms de vos fichiers journaux de transactions.
Procédez comme suit :
- Vérifiez la liste de vos opérations d'importation de journaux de transactions sur l'instance Cloud SQL pour SQL Server de destination. Dans la console Google Cloud , accédez à la page Instances Cloud SQL.
- Cliquez sur Afficher toutes les opérations > Afficher les journaux d'erreurs SQL Server.
- Affichez toutes les opérations d'importation des fichiers journaux de transactions et vérifiez si leurs noms de fichiers contiennent des codes temporels Epoch corrects.
- Si vous remarquez que les fichiers journaux de transactions récents utilisent des noms avec des codes temporels d'epoch non ordonnés, accédez à votre bucket Cloud Storage et renommez le fichier. Database Migration Service détecte automatiquement la modification et tente d'importer les fichiers journaux de transactions pertinents.
- Amazon RDS uniquement : il est possible que certains fichiers journaux de transactions aient été ignorés lors du processus d'exportation vers S3. Essayez de réexécuter la fonction d'exportation des journaux de transactions pour la période correspondant aux fichiers WAL manquants.