This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(211.20000000000002, 89%, 30%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EEM%3C/text%3E%3C/svg%3E)
Hello,
I have an Azure MySql Flexible instance running at foo.mysql.database.azure.com with zone redundant HA enabled. I attempted a forced failover per https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-high-availability. After the failover, my app was throwing errors that the database instance was read-only. After about 10 minutes, I did another forced failover and then the app started to respond correctly (no more read-only errors).
It looks like the database failed over, but perhaps my app remained connected to the same instance, which by that point was a read-only standby, since the one in the other zone became the new primary? However, the article linked above claims that the DNS record should update and point to the new primary location, which is now in a different zone.
What is missing here? Was the 10 minutes not long enough for DNS to propagate completely? Usually Azure DNS changes are lightning fast, so I'm not convinced that was the problem.
Hi @EJ Marmonti Thank you for posting your Question on Microsoft Q&A.
This is a known issue that the connections are still redirected to the old primary instance after failover. I am working closely with our product team to get more details about this issue and any plan fix.
Regards,
Oury
Thank you for the reply, Oury. Do you know how much time we might be looking at until this is working properly? A few weeks, a few months, or longer?
Hi @EJ Marmonti Sorry for the late reply.
Do you know how much time we might be looking at until this is working properly? A few weeks, a few months, or longer?
Currently, the Product Group is working on an approach. I will update you the state on this thread.
As a workaround, our Product Group has suggested to use DNS cache or use IP instead to do connection directly in client. AKS uses DNS cache in default. So, after failover, the client app connects to the original primary.
Regards,
Oury
Hi @EJ Marmonti
• Please don't forget to click on
or upvote
button whenever the information provided helps you. Original posters help the community find answers faster by identifying the correct answer. Here is how
• Want a reminder to come back and check responses? Here is how to subscribe to a notification
• If you are interested in joining the VM program and help shape the future of Q&A: Here is how you can be part of Q&A Volunteer Moderators
Hi Oury,
In response to your last message, specifically this: "As a workaround, our Product Group has suggested to use DNS cache or use IP instead to do connection directly in client. AKS uses DNS cache in default. So, after failover, the client app connects to the original primary."
Are you saying the problem is a DNS propagation issue, and that if I were to say, connect directly to the IP of the private endpoint, instead of the "foo.privatelink.mysql.database.azure.com" endpoint, this is a valid workaround?
Thank you
@EJ Marmonti sorry for the late reply. I was working with our product group on this issue. Our Product Group has decided to change the approach. They won’t do IP forward. They are working on an approach. I will inform you about the progress. For now, don't connect directly to the IP of the private endpoint.
Regards,
Oury