Troubleshoot source database connectivity

During the precheck phase, DTS verifies that its servers can connect to your source database. If the connectivity check fails, use the following solutions to troubleshoot.

Common causes of connectivity precheck failures:

Credential errors

Error example

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

Diagnostic steps

Connect to the source database using a CLI or client to verify the account name and password.

Common mistakes:

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

Solution

Obtain the correct credentials, edit the migration task in the , and rerun the precheck.

Important

For Tair or Redis source databases, format the password as follows:

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 a CLI or client. If the connection succeeds, the source database may be restricting DTS server IP addresses.
For self-managed MySQL, run the following command to check access restrictions:
```
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.

Verify the output includes the DTS server IP addresses. Add the IP addresses of DTS servers to an allowlist.
For SQL Server, check for host-level firewalls and any endpoints or triggers that restrict access by source IP address.
For Oracle, check the sqlnet.ora file. If TCP.VALIDNODE_CHECKING is set to yes, IP address restriction is enabled.

Solution

For self-managed MySQL, run the following command to re-grant permissions to the migration account:
```
GRANT ALL ON *.* TO 'username'@'%';
```
Note
Replace username with the database account used in the 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 fixing the issue, rerun the precheck in the .

Firewall settings

Diagnostic steps

On Windows, check Windows Firewall in Control Panel for active firewall rules.
On Linux, run iptables -L to check for active firewall rules.

Solution

Disable the firewall restrictions, then rerun the precheck in the .

Other network issues

If credentials, IP whitelists, and firewalls are all configured correctly, the failure is likely caused by a network issue between DTS servers and your source database.