Source database connectivity check - Data Transmission Service

The precheck verifies connectivity between the Data Transmission Service (DTS) servers and your source database. This topic describes common causes and solutions for connectivity check failures.

A connectivity precheck may fail for the following reasons:

Credential errors

Error example

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

Diagnostic steps

Connect to the source database using the command line or client to verify that the database account name and password are correct.

Common mistakes include:

Using an Alibaba Cloud account instead of a database account.
The specified database account does not exist.
The specified password is incorrect.

Solution

First, obtain the correct database account and password. Then, in the Data Transmission Service console, edit the data migration task, enter the correct credentials, and then rerun the precheck.

Important

If your source database is Tair or Redis, ensure you format the password correctly:

For a default account (which typically uses the instance ID as its name), enter only the password.
For a custom account, use the format <account_name>:<password> in the password field. For example, if the custom username is admin and the password is Rp829dlwa, you must enter admin:Rp829dlwa.

IP whitelist restrictions

Diagnostic steps

Connect to the source database using the command line or client. If the connection is successful, it indicates that the source database may have restricted the DTS server IP address.
If the source database is a self-managed MySQL instance, you can connect to the source database using a client and run the following command to verify:
```
SELECT HOST FROM mysql.user WHERE user='username',password='password';
```
Note
Replace username and password with the database account and password specified for the data migration task.
Check whether the list of allowed IP addresses in the output includes the DTS server IP addresses. For the complete list of DTS IPs, see Add the IP addresses of DTS servers to an allowlist.
If the source database is an SQL Server database, check for any host-level firewalls. Also inspect the database for any endpoints or triggers that might be restricting access based on the source IP address.
If the source database is an Oracle database, inspect the sqlnet.ora configuration file. If the TCP.VALIDNODE_CHECKING parameter is set to yes, IP address restriction is enabled.

Solution

For a self-managed MySQL database, you can execute the following command in the source database to re-grant permissions to the database account used for data migration
```
GRANT ALL ON *.* TO 'username'@'%';
```
Note
Replace username with the database account specified for the data migration task.
For SQL Server, disable the firewall or the restrictive trigger.
For Oracle, change the TCP.VALIDNODE_CHECKING parameter to no in the sqlnet.ora file and then restart the listener process.

After you perform these steps, log on to the Data Transmission Service console and rerun the precheck.

Firewall settings

Diagnostic steps

If the server running the source database is Windows, locate Windows Firewall in Control Panel and check if the firewall is configured.
If the server running the source database is Linux, use the iptables -L command to check if the server has firewall rules configured.

Solution

After disabling the relevant firewall restrictions, return to the Data Transmission Service console and rerun the precheck.

What if the connectivity check still fails after checking credentials, IP whitelists, and firewalls?

If you have already ruled out credential errors, IP whitelist restrictions, and server-level firewalls, the failure is likely caused by a more general network issue between the DTS servers and your source database.