{"action":"closed","issue":{"url":"https://api.github.com/repos/PyMySQL/PyMySQL/issues/470","repository_url":"https://api.github.com/repos/PyMySQL/PyMySQL","labels_url":"https://api.github.com/repos/PyMySQL/PyMySQL/issues/470/labels{/name}","comments_url":"https://api.github.com/repos/PyMySQL/PyMySQL/issues/470/comments","events_url":"https://api.github.com/repos/PyMySQL/PyMySQL/issues/470/events","html_url":"https://github.com/PyMySQL/PyMySQL/issues/470","id":158395717,"number":470,"title":"Request failover and high availability awareness","user":{"login":"destinymedia","id":15253613,"avatar_url":"https://avatars.githubusercontent.com/u/15253613?v=3","gravatar_id":"","url":"https://api.github.com/users/destinymedia","html_url":"https://github.com/destinymedia","followers_url":"https://api.github.com/users/destinymedia/followers","following_url":"https://api.github.com/users/destinymedia/following{/other_user}","gists_url":"https://api.github.com/users/destinymedia/gists{/gist_id}","starred_url":"https://api.github.com/users/destinymedia/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/destinymedia/subscriptions","organizations_url":"https://api.github.com/users/destinymedia/orgs","repos_url":"https://api.github.com/users/destinymedia/repos","events_url":"https://api.github.com/users/destinymedia/events{/privacy}","received_events_url":"https://api.github.com/users/destinymedia/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-06-03T15:39:46Z","updated_at":"2016-06-04T10:47:27Z","closed_at":"2016-06-04T10:47:27Z","body":"It is increasingly common to maintain a cluster of MySQL instances with the ability to failover. Switching is left to either the application or the hosting environment, yet our drivers could share the responsibility with the cluster. \r\n\r\nSome cluster implementations such as aws-rds update a dns entry to point to the new master, but local dns caching causes an unnecessary delay in a time sensitive failover event. Readonly queries could be redirected a slave instance to balance the load on the cluster, but knowing which instance to connect to becomes the applications responsibility.\r\n\r\nCluster structures can be discoverable. The aws-aurora cluster for example can provide details about the cluster layout and failover events allowing the driver to know if the master has changed and gain a list of all the slaves. Alternatives could be the connection options identifying a list of slaves.\r\n\r\nThe mariadb connector added failover and high availability awareness to the Java connector recently and is worth reviewing for ideas. The Amazon Aurora team has been working with them on adding cluster aware features into the connector.\r\nhttps://mariadb.com/kb/en/mariadb/failover-and-high-availability-with-mariadb-connector-j/\r\n\r\nMy interest is with Aurora clusters, but there is a general feature here.\r\n\r\nBy identifying the cluster, the driver can switch to another instance immediately if the cluster reports a failover, or balance the load using a round robin or randomizer. This also allows readonly SQL activities to be automatically sent to a readonly instances (slaves) in the cluster where all writing (master) SQL activities remain with the writing instance (master) in the cluster.\r\n\r\n**Aurora** failover management steps:\r\n1. Instance A is in write replication mode, instance B and C are in read replication mode.\r\n2. Instance A fails.\r\n3. Cluster detects A failure, and promote instance B in write mode. Instance C will change its master to use B.\r\n4. Cluster end-point will change to instance B end-point.\r\n5. Instance A will recover and be in read replication mode. \r\n\r\n**Sequential** failover management steps:\r\n1. identify all instances in the cluster (ex: host1, host2, host3)\r\n2. attempt to connect to a host in order listed in connection settings\r\n\r\n\r\n"}}
{"actor":{"display_login":"methane"}}