Mysql Replication与Connector/J原理（四）

十九、Connector与Failover协议

    Mysql Connector/J支持failover协议：即Client链接失效时，将会尝试与其他host建立链接，这个过程对application是透明的。Failover协议是“Multi-Host”链接模式中最基础的协议，“load balancing”、“replication”、“farbic”协议都基于Failover协议。其URL格式如下：

jdbc:mysql://[primary-host]:[port],[secondary-host]:[port],.../[database]?[property=<value>]&[property=<value>]

 

    Host列表中有两种hosts：primary（master）和secondaries（slaves）,priamry需要位于hosts列表的第一个；当创建一个新的connection时，driver会首先尝试与primary链接，如果primary链接异常，将会依次与secondaries建立链接直到成功为止；即使与primary的链接失效，但是driver并不会丢失primary的特殊状态：比如它的访问模式、优先级等。

 

    Failover协议支持如下属性：

    1）failOverReadOnly

    2）secondsBeforeRetryMaster

    3）queriesBeforeRetryMaster

    4）retriesAllDown：当所有的hosts都无法连接时，轮询重试的最大次数，默认为120。重试次数达到阈值仍然无法获取有效链接，将会抛出SQLException。

    5）autoReconnect

    6）autoReconnectForPools

 

    “failOverReadOnly”用于控制connection中“read_only”参数，即当primary链接失效时，failover到secondary时链接的默认访问模式，此值默认为“true”，即与secondary的链接访问模式为“只读”；通常情况下，primary的链接访问模式为“read/write”，即read_only为false。Connector J在failover时可以修改read_only的值，当然application在获取链接后也可以调整此值。无论何时，failover到primary的链接总是“read/write”模式；当Client与primary的链接失效时（可能primary节点并没有失效），如果failOverReadOnly为false，表示与secondary的连接上允许发生“write”操作，这极有可能是危险的，因为slaves上如果被Client写入数据将导致replicaiton集群中的数据不一致，除非slaves节点上已经设定了全局“read_only=true”。

 

    在failover发生后，Driver会定期检测primary的链接状况，如果发现primary的链接恢复正常，那么客户端链接也将会“Fallback”（回落）到primary上，即此后的read/write将在primary链接上发生（与secondary的链接将会保持空闲，或者断开）。“secondsBeforeRetryMaster”表示driver每隔多少秒将重试master的链接，“quriesBeforeRetryMaster”表示执行多少次queries后重试master的链接，如果重试成功，则将会“Fallback”到primary上；可以将上述两个属性设置为“0”来关闭自动Fallback。

 

    当primary的链接失效后，触发failover，此时driver将依次与hosts列表中的secondary建立链接，直到与某个Secondary链接成功，否则将所有的secondaries都尝试完毕，然后继续从头开始，直到与其中一个secondary链接成功。如果所有的hosts都无法链接，driver最多重试“retriesAllDown”次（默认为120）。

 

    “autoReconnect”、“autoReconnectForPools”这两个参数用于控制“重连”特性，即当一个session（或者事务）操作过程中，如果链接异常，driver不会抛出Exception而是尝试重新链接并继续执行；如果你的操作是非事务性的（Query或者变更MyISAM表），reconnect通常不会带来问题；但是如果是一个事务操作，在事务中的多个操作过程中发生重连，有可能会对session状态造成破坏，从而导致数据不一致性问题，即使开启“autocommit=false”时仍然不能避免问题，事实上重连之后并不会rollback原来中断的事务，而是继续进行，参见【autoReconnect】。此参数选项将会在未来的版本中被移除，也有可能不同版本的Connector J中实现会有不同，建议开发者禁用此特性。

 

    Failover协议，它解决了：当master失效后，Driver能够透明的与其他secondary建立链接，当master恢复后，能够自动的Fallback到primary。对于application而言，可以利用“replication”架构的优势，以提高可用性；MySQL实例的故障或者恢复，不需要调整application代码。

 

    参见源码：FailoverConnectionProxy，它为代理类，即Connection上的所有操作方法均有此proxy代理。

 

二十、Connector与Load Balancing（LB）

    Failover协议并没有提供“load balancing”特性，即读（写）操作总是只发生在一个host上。对于“replication”、“多Master”架构，我们通常希望“负载均衡”、“读写分离”等高级特性，这就是Load Balancing协议所能解决的。Load Balancing可以将read/write负载，分布在多个MySQL实例上，这些MySQL实例通常为Cluster架构或者Replication架构，本文主要讲解“Replicati