Replies: 5 comments
-
Hello @jensdt, Thanks for reaching out and raising this issue. Currently, the AWS JDBC Wrapper indeed uses the We have acknowledged your use case. We'll take a look at this and keep you updated as we investigate. Thank you for your patience! |
Beta Was this translation helpful? Give feedback.
-
Hello @jensdt, We have forwarded the issue to the Aurora team for future investigation. |
Beta Was this translation helpful? Give feedback.
-
Hi @brunos-bq , has there been any feedback from the Aurora team in the meantime? |
Beta Was this translation helpful? Give feedback.
-
Hello @jensdt, At this time, we have not received a response from Aurora engine team yet regarding this issue. This means that at this point, we still do not know exactly whether this change to pick up manual changes in instance names on the fly will be added to Aurora or not. We are currently still following up on the matter and will provide an update as soon as we have one. Thanks! |
Beta Was this translation helpful? Give feedback.
-
Hi @jensdt, We've received a response from the Aurora engine team. Unfortunately, Aurora MySQL does not support renaming an instance without rebooting at this time and the reboot is required mainly for updating the Please feel free to reach out again if you have any other questions or concerns. Thank you! |
Beta Was this translation helpful? Give feedback.
-
We are running a 8.0.mysql_aurora.3.04.0 cluster and noticed the following behaviour which we found a bit concerning.
One of our admins recently renamed a reader node in the cluster as part of routine cleanup - updating the "DB instance identifier" of the node to be precise. After the rename, this node was no longer connected to by the read/write split code. We dove into the code & logging of this wrapper a bit, and we noticed the topology is based on the result of what is returned by a query on "information_schema.replica_host_status". The "SERVER_ID" value is used as hostname in the URL.
But when a node is renamed, the SERVER_ID isn't updated in this table. Only when that node reboots, a new entry is added in replica_host_status for the updated node and the old one disappears. But the node endpoint itself is modified as soon as the rename completes - no reboot required.
This results in the following logging:
Nov 13, 2023 3:18:52 PM software.amazon.jdbc.plugin.readwritesplitting.ReadWriteSplittingPlugin getNewReaderConnection
WARNING: Failed to connect to reader host: 'old-instance-name.REDACTED.rds.amazonaws.com:3306/'
This effectively means the node is not available to connect to by read-write split, and worse, if that node would be selected as a new master in a failover event, the plugin would not be able to connect to the new "master" node and failover would fail.
A reboot fixes this state, but as far as I could find this isn't documented anywhere. Is this intended behaviour?
Beta Was this translation helpful? Give feedback.
All reactions