Voici quelques indices :Aurora a de nombreuses instances. L'un est "écrivain" (Maître), les autres sont "Lecteur" (Esclaves).
Lorsqu'un enregistreur est arrêté, un esclave sera promu nouveau maître, les autres esclaves répliqueront désormais à partir de ce nouveau maître (redémarrage automatique). Si l'ancien maître resurgit, il deviendra un esclave.
Aurora a un point de terminaison DNS pour le cluster comme "xx.cluster-yy.zz.rds.amazonaws.com" qui pointe vers le maître actuel. Lorsqu'un basculement se produit, le DNS est rafraîchi ... mais pas immédiatement.
Une "connexion" à Aurora signifie 2 connexions sous-jacentes aux instances :une au maître, une à l'esclave. Le pilote utilisera la connexion sous-jacente au maître ou à l'esclave selon Connection.setReadonly().
Chaque fois que le pilote se connecte à une instance, il s'assure que l'état actuel vérifie la variable globale "innodb_read_only" (OFF =maître).
Des instances Aurora peuvent être ajoutées, donc lors de la connexion initiale, à l'aide du point de terminaison du cluster d'utilisateur, la liste actuelle des instances sera récupérée à l'aide de information_schema.replica_host_status.
Pour établir les 2 connexions sous-jacentes, le pilote se connectera à un hôte aléatoire, s'il s'agit du maître actuel, bon alors tous les autres hôtes sont des esclaves, sinon, le pilote demandera à l'esclave son maître actuel afin que la prochaine connexion se connecte à l'hôte en utilisant information_schema. replica_host_status where session_id ='MASTER_SESSION_ID' (plus fiable que l'utilisation de DNS). Si la connexion à une instance échoue, ce nom d'instance sera mis dans une liste noire pendant un certain temps (cette liste noire est partagée par jvm) pour éviter de la réutiliser. Le pilote essaie de reconnecter un hôte disponible au hasard jusqu'à ce qu'il n'y en ait aucun qui ne soit pas sur liste noire, puis peut réessayer avec un hôte sur liste noire pendant un certain temps (selon les paramètres). Si la connexion réussit, l'instance est "non mise sur liste noire".
Pour le basculement de la connexion esclave sous-jacente, la connexion maître est alors utilisée, et un pool de threads sous-jacent essaiera alors de reconnecter une instance esclave en arrière-plan.
