我正在尝试了解Mariadb Connetor J的Aurora快速故障转移实现。虽然我不是Java应用工程师，但我的主要工作是DBA。我想我对OOP语言知之甚少，并已阅读mariadb连接器J的源代码，重点关注相关的Aurora实现。但这很困难，也无法对我的猜测充满信心。
我非常感谢您分享您对此的了解或仅仅是一些评论。
在最新版本中，我们只注册Aurora集群的集群端点，驱动程序会自动找出每个实例端点。
我猜这个逻辑是如何工作的
驱动程序从information_schema.REPLICA_HOST_STATUS生成每个端点连接字符串，该字符串知道Sever_id列上的所有实例标识符。关于端点字符串有一种模式。因此，一旦驱动程序成功连接集群端点中的任何实例，驱动程序就可以生成每个实例端点。
在git每个实例端点之后，驱动程序抛出一个查询“SHOW GLOBAL STATUS LIKE'innodb_read_only'。如果返回值为0（false），则设置为Writer，否则设置为Reader。
如果运行状况检查失败，驱动程序会将连接字符串推入“黑名单”。（我无法找到写入运行状况检查的位置）
驱动程序尝试从未列入黑名单的连接字符串进行连接，但如果失败则尝试连接黑名单的连接字符串。
我的猜测主要来自以下的java文件。
答案 0 :(得分：1)
以下是一些提示： Aurora有很多例子。一个是“作家”（Master），另一个是“读者”（奴隶）。
当写入器关闭时，一个从属设备将被提升为新的主设备，其他从设备现在将从此新主设备复制（自动重启）。如果老主人再次出现，它将成为奴隶。
Aurora有一个群集的DNS端点，如“xx.cluster-yy.zz.rds.amazonaws.com”，指向当前的主人。发生故障转移时，DNS会刷新...但不能立即进行。
与极光的“连接”意味着与实例的2个底层连接：一个到主，一个到从。根据Connection.setReadonly（），驱动程序将使用底层连接到主服务器或从服务器。
每次驱动程序连接到实例时，它将确保当前状态检查全局变量“innodb_read_only”（OFF = master）。
可以添加Aurora实例，因此在初始连接时，使用用户群集端点，将使用information_schema.replica_host_status检索当前实例列表。
要建立2个底层连接，驱动程序将连接到一个随机主机，如果这是当前主机，那么所有其他主机都是从机，如果没有，驱动程序会询问从机他当前的主机，以便下一个连接将连接主机使用information_schema.replica_host_status，其中session_id ='MASTER_SESSION_ID'（比使用DNS更可靠）。 如果与实例的连接失败，则此实例名称将被放入黑名单一段时间（此黑名单按jvm共享）以避免重复使用。驱动程序尝试重新连接随机可用主机，直到没有未列入黑名单，然后可以使用黑名单重试一段时间（取决于参数）。如果连接成功，则实例将“未列入黑名单”。
对于底层从属连接的故障转移，然后使用主连接，然后一些基础线程池将尝试在后台重新连接从属实例。