Bug #100823 After switching the DNS mapping, session reconnect and using the original host
Submitted: 12 Sep 2020 16:06 Modified: 14 Sep 2020 13:52
Reporter: z yz Email Updates:
Status: Not a Bug Impact on me:
Category:MySQL Server: Command-line Clients Severity:S3 (Non-critical)
Version: OS:Any
Assigned to: MySQL Verification Team CPU Architecture:Any

[12 Sep 2020 16:06] z yz
This is the DNS mapping of two MySQL server for example:
cluster.writer.example.com   —>
cluster.reader.example.com   —>
Now we using mysql client"mysql -hcluster.writer.example.com " to connect this writer server , this session is still running . But now , we try to simulate the failover , restart these two server and change the DNS mapping as the below:
cluster.write.example.com   —>
cluster.read.example.com   —>
After auto reconnecting , this session which using writer hostname(mysql -hcluster.write.example.com ) to connect is still running on , this server( is become reader now .

This situation may cause some errors(it can also seen in mysql-workbench).

How to repeat:
I using the AWS Aurora for repeat this problem , I create a Aurora MySQL cluster , and it provide us two hostname endpoint for reader and writer .
Writer :cslccluster.cluster-c7ayu1nkumeb.rds.cn-northwest-1.amazonaws.com.cn	
(IP :
Reader :cslccluster.cluster-ro-c7ayu1nkumeb.rds.cn-northwest-1.amazonaws.com.cn	(IP :

We using the hostname endpoint to resolve the IP address and connect writer server (both using hostname and IP ) ,then I trigger the failover .
The DNS relationship mapping is change ,but this session which using writer hostname get connection is still on the original server (Did not reconnect to the new Writer database when DNS mapping changes),the new created session which connect the write hostname is all right.
[14 Sep 2020 13:52] MySQL Verification Team

If I'm properly reading your report you change the IP of a host in DNS and your client does not see this new IP when reconnecting? This is normal behavior and has very little to do with mysql, dns is caching the result and the client is caching the resolved ip's on top of that. Try for e.g. how chrome or firefox behave, in order for them to ping DNS again you usually have to close and restart them, and even then the local dns cache can delay the propagation of the change.