Dépannage de la connectivité à la base de données source - Précontrôle DTS - Data Transmission Service

Lors de la phase de précontrôle, DTS vérifie que ses serveurs peuvent se connecter à votre base de données source. Si le test de connectivité échoue, appliquez les solutions suivantes pour résoudre le problème.

Causes courantes des échecs de précontrôle de connectivité :

Erreurs d'identifiants

Exemple d'erreur

Access denied for user 'XXX'@'XXX' (using password: YES)

Étapes de diagnostic

Connectez-vous à la base de données source via une CLI ou un client pour vérifier le nom du compte et le mot de passe.

Erreurs fréquentes :

Utilisation d'un compte Alibaba Cloud au lieu d'un compte de base de données.
Le compte de base de données n'existe pas.
Le mot de passe est incorrect.

Solution

Récupérez les identifiants corrects, modifiez la tâche de migration dans la console DTS, puis relancez le précontrôle.

Important

Pour les bases de données source Tair ou Redis, formatez le mot de passe comme suit :

Pour un compte par défaut, qui utilise généralement l'ID de l'instance comme nom, saisissez uniquement le mot de passe.
Pour un compte personnalisé, utilisez le format <nom_du_compte>:<mot_de_passe> dans le champ du mot de passe. Par exemple, si le nom d'utilisateur personnalisé est admin et que le mot de passe est Rp829dlwa, vous devez saisir admin:Rp829dlwa.

Restrictions de la liste d'autorisation IP

Étapes de diagnostic

Connectez-vous à la base de données source via une CLI ou un client. Si la connexion aboutit, il est possible que la base de données source restreigne les adresses IP des serveurs DTS.
Pour MySQL géré par vos soins, exécutez la commande suivante pour vérifier les restrictions d'accès :
```
SELECT HOST FROM mysql.user WHERE user='username',password='password';
```
Remarque
Remplacez username et password par le compte de base de données et le mot de passe spécifiés pour la tâche de migration des données.

Vérifiez que la sortie inclut les adresses IP des serveurs DTS. Ajoutez les adresses IP des serveurs DTS à une liste d'autorisation.
Pour SQL Server, vérifiez la présence de pare-feu au niveau de l'hôte ainsi que de tout endpoint ou déclencheur limitant l'accès par adresse IP source.
Pour Oracle, consultez le fichier sqlnet.ora. Si TCP.VALIDNODE_CHECKING est défini sur yes, la restriction par adresse IP est activée.

Solution

Pour MySQL géré par vos soins, exécutez la commande suivante pour réattribuer les autorisations au compte de migration :
```
GRANT ALL ON *.* TO 'username'@'%';
```
Remarque
Remplacez username par le compte de base de données utilisé dans la tâche de migration.
Pour SQL Server, désactivez le pare-feu ou le déclencheur restrictif.
Pour Oracle, modifiez le paramètre TCP.VALIDNODE_CHECKING en le définissant sur no dans le fichier sqlnet.ora, puis redémarrez le processus listener.

Une fois le problème résolu, relancez le précontrôle dans la console DTS.

Paramètres du pare-feu

Étapes de diagnostic

Sous Windows, vérifiez les règles de pare-feu actives dans le Pare-feu Windows via le Panneau de configuration.
Sous Linux, exécutez iptables -L pour vérifier les règles de pare-feu actives.

Solution

Désactivez les restrictions du pare-feu, puis relancez le précontrôle dans la console DTS.

Autres problèmes réseau

Si les identifiants, les listes d'autorisation IP et les pare-feu sont tous configurés correctement, l'échec est probablement dû à un problème réseau entre les serveurs DTS et votre base de données source.