Need help?

Our experts have had an average response time of 11.7 minutes in August 2021 to fix urgent issues.

We will keep your servers stable, secure, and fast at all times for one fixed price.

DMS Endpoint Connectivity Failures – Troubleshoot & Fix

by | Aug 1, 2021

Stuck with DMS endpoint connectivity failures? We can help you.

Generally, with this error, we can’t connect to the AWS Database Migration Services endpoints.

Here, at Bobcares, we assist our customers with several AWS queries as part of our AWS Support Services.

Today, let us see why the test connection fails, and how we can troubleshoot these connectivity issues.

 

DMS endpoint connectivity failures

It is always a good practice to test the connectivity from the AWS DMS replication instance to the endpoints.

However, we perform this before the AWS DMS migration task. It helps make sure that the task doesn’t fail due to connectivity issues with the endpoint.

The security group must include outbound rules for the endpoint’s IP addresses for the specific port, for the AWS DMS replication instance to connect to the source and target endpoints

Suppose, the outbound rules are correct. In that case, we check the inbound network or security configuration on the source or target database.

On the other hand, if the issue was with denial of access to the database, the errors will be as follows:

Test Endpoint failed: Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider Network error has occurred, Application-Detailed-Message: RetCode: SQL_ERROR SqlState: 08001 NativeError: 101 Message: [unixODBC]FATAL: password authentication failed for user "dmsuser" ODBC general error.
Test Endpoint failed: Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider ODBC general error., Application-Detailed-Message: RetCode: SQL_ERROR SqlState: HY000 NativeError: 2005 Message: [unixODBC][MySQL][ODBC 5.3(w) Driver]Unknown MySQL server host 'mysql1.chulbfpmdg0x.us-east-1.rds.amazonaws.com' (22) ODBC general error.

To resolve them, we need to confirm the following endpoint details are set correctly:

  • Username and Password
  • ServerName (DB instance endpoint name)
  • Port

At times, the error can cause by network configuration or timeouts. Then the error will be like this:

Test Endpoint failed: Application-Status: 1020912, Application-Message: Failed to connect Network error has occurred, Application-Detailed-Message: RetCode: SQL_ERROR SqlState: HYT00 NativeError: 0 Message: [unixODBC][Microsoft][ODBC Driver 13 for SQL Server]Login timeout
expired ODBC general error.
Test Endpoint failed: Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider Network error has occurred, Application-Detailed-Message: RetCode: SQL_ERROR SqlState: 08001
NativeError: 101 Message: [unixODBC]timeout expired ODBC general error.

To resolve them, we check the resolution for the NativeError for the endpoint’s database engine.

 

The source or target database is hosted on AWS

In this case, we confirm the database has a security group configuration. It must allow incoming traffic from the AWS DMS replication instance’s IP address.

Our Support Techs recommend the steps below to verify the public and private IP address:

  1. Initially, we open the AWS DMS console and select Replication instances from the navigation pane.
  2. Then we select the name of the replication instance.
  3. We can check the Public and Private IP address of the replication instance from the Details tab. Or, we can run describe-replication-instances:

Private IP address:

aws dms describe-replication-instances
--filters Name=replication-instance-id,Values=<DMS replication instance name> "ReplicationInstances[*].ReplicationInstancePrivateIpAddress" --output=text

Public IP address:

aws dms describe-replication-instances --filters Name=replication-instance-id,Values=<DMS replication instance name> "ReplicationInstances[*].ReplicationInstancePublicIpAddress" --output=text

Then, we confirm that the Network ACL rules don’t restrict incoming traffic to the source or target databases and the replication instance.

Finally, we confirm that the route table for the subnet has sufficient entries that allow either public or private network traffic.

 

The source or target database is hosted on-premises

We need to check with the network administrator to check if the database allows incoming connections from the AWS DMS replication instance.

Then we verify if the DNS configuration is set up correctly. In addition, we make sure there isn’t a firewall blocking communication to the source or target database.

Suppose, we can’t identify the issue in the network connectivity. Then we create a new Amazon EC2 instance in the same VPC.

But it should be of the same network configurations as the AWS DMS replication instance.

From the new test EC2 instance, to further troubleshoot the network connectivity we run:

telnet <IP address of host database server> <port number>
nslookup <Fully qualified domain name for the database server>
tracert <IP address of host database server> <ip address of host database server> <port number> <fully qualified domain name for the database server> <ip address of host database server>

[Need help with the connectivity issues? We’d be happy to assist]

 

Conclusion

In short, we saw how our Support Techs fix the connectivity issues with the DMS endpoint.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

var google_conversion_label = "owonCMyG5nEQ0aD71QM";

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF