切换
切换的核心是保业务还是保数据？
如何进行身份切换：
- 停止备库同步
- 配置主库复制从库。
- 复制是一种平级的关系，可以独立。
切换策略：
单纯从切换策略卡率我们可以看到存在下面的两种方式：
- 可靠优先策略：意味着seconds_behind_master参数不能过大不能落后库太大。需要把A库切换为只读的形式，这时候业务只能读取不新增数据，当seconds_behind_master=0的时候意味着两个库同步。此时A库停止，B库停止复制A，A库开始复制B库。这个可靠说明的是数据可靠，但是不保证业务不受影响，因为最大的问题来自于停机。
- 可用性策略：取消等待数据的一致过程，A库只读B库关闭只读，B库停止复制A库，A库开始复制B库，优点是系统没有不可写时间，缺点是切换的时候如果有没有及时重放的relay log容易导致数据不一致。
对于大多数普通业务执行尽量选用可靠优先策略，但是如果对于业务高可用严格建议可用性策略，比如日志流水同样需要可用性，对于一些数据要求强一致性的比较低允许一定数据丢失的业务则可以考虑使用可用性策略。
业务如何切换？
- 预留接口，通知连接到新的数据库地址。
- 微服务框架通知业务，比如注册中心。
- 内部使用DNS，域名连接，切换之后刷新DNS处理。
- K8S使用了这种方式实现处理。
- keepalived 进行VIP漂移。通过检测处理优先级处理。
- 代理的方式切换：加一层代理负载均衡处理。
- Dble的时候主备切换
自动主从切换
keepalived 如何主备切换？
keepalive是经常被使用的中间件，在自动主从切换中它担任了身份切换和VIP飘移的角色，VIP即Virtual IP Address，是实现HA（高可用）系统的一种方案，高可用的目的是通过技术手段避免因为系统出现故障而导致停止对外服务，一般实现方式是部署备用服务器，在主服务器出现故障时接管业务。 VIP用于向客户端提供一个固定的“虚拟”访问地址，以避免后端服务器发生切换时对客户端的影响。
Keepalived的设计目的即是为了管理VIP，因此使用Keepalived实现VIP的配置非常简单。Keepalived采用了Virtual Router Redundancy Protocol (VRRP)协议来进行实现主备服务器之间的通信以及选举。
keepalive的主从切换类似下面的对方式，当比如当MysqlA服务宕机会自动切换到下一个A`的服务器提供服务，内部通过一定的选举算法选举出新节点。
Mha（master high availability） 如何进行主备切换？
Mha也是常用的Mysql高可用组件，它通过自研主从切换的概念完成主备切换，这个组件由facebook工程师进行开发，同时支持GTID的方式，最大特点：在宕机的时候第一时间登陆宕机服务器下载binlog日志。但是Mha最大的问题是无法进行VIP漂移。
根据下面的图可以看到，在Mha的工作机制当中，如果发现A节点的服务宕机此时会立刻登陆到A节点的服务器把文件进行抢救，但是这里存在复制的数据同步问题，在半同步复制中会有 脱扣时间导致binlog传送转变为异步传送有可能会出现binlog没有传递过来的情况，这种情况下有可能会导致其他数据的不完整导致数据不同步。
值得一提的是Mha的并不是直接通过客户端访问宕机节点而是需要等待SLAVE节点的数据落库之后再通过从库访问主库抢救binlog，这些操作基本都是来自于设计者日常工作经验中发现的一些问题针对的特殊处理所以十分受到广大开发者的青睐。
当抢救binlog任务完成之后，Mha 的下一步是重新选去Master，注意宕机的节点不会用脚本尝试重启恢复，因为这种情况下不通过人为干预通常已经没有太大的效果了，即使重启也有可能会有数据不一致的问题。
三高系统搭建
在搭建三高之前，我们需要思考为什么有时候集群搭建起来了为什么还会挂？原因是任何一个成熟的单一系统都不会单纯依赖某一个开源组件而是在中间层加入大量的容错机制防止某一组件崩盘造成大面积的损失，这里涉及到DRDS的概念，DRDS表示（Distributed Relational Database Service）分布式的Mysql集群，而Mysql的集群通常不会是本身的集群，而是通过一系列的中间件维持三高的基本特征。
接下来我们一步步来看下三高系统是如何搭建的：
分库分表有一个问题点：我们发现当dble出现问题的时候会导致整个服务不可用，Dble的单点问题这里我们后续进讨论，这里出现了Mha和Dble联动来解决Mysql节点宕机的问题。
对于开发人员来说日常实践过程基本碰不到这个东西这里同样找了一篇在需要的时候进行学习大致的搭建流程和一些基本配置即可：
下面是Mha结合DBLE对于整个架构的增强结构图：
通过Mha和dble的搭配，当节点出现宕机的时候可以通过Mha进行节点的切换保证分库分表的正常工作。
但是我们还发现一个问题那就是dble本身也是单点的，所以dble也需要做集群的负载均衡防止整个节点不可用，而对于dble的负载分发可以通过Haproxy结合zookeeper进行处理。
HAProxy 是一款提供高可用性、负载均衡以及基于TCP（第四层）和HTTP（第七层）应用的代理软件，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。 HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在时下的硬件上，完全可以支持数以万计的 并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上。
ZooKeeper是一个集中式服务，用于维护配置信息、命名、提供分布式同步和提供组服务。所有这些类型的服务都以某种形式被分布式应用使用。每次实现这些服务时，都有大量的工作用于修复不可避免的错误和竞争条件。由于实现这类服务的难度，应用程序最初通常会忽略它们，这使得它们在变化的情况下变得很脆弱而且难以管理。即使做得正确这些服务的不同实现也会导致应用程序部署时的管理复杂性。
最后客户端通过keepalive的VIP飘移寻找网关的入口，经过选举分发之后找到对应的dble，dble再进行分库分表查找相关的数据进行处理，最后找到相关的Mysql节点汇总数据之后返回给客户端，当Mysql节点出现问题的时候，Mha则会通过一系列的脚本抢救binlog文件之后重新选举主从节点。
至此一个三高架构的分布式Mysql集群的完整结构完成，我们把上面的文字用结构图表示可以看到还是十分复杂的：
总结
本部分内容讲述了Mysql分区表特性，以及一个国产开源的分库分表插件，其实分库分表对于大部分的中小项目基本都是不需要的，它通常出现在比较大的系统架构当中，dble作为一款国产开源组件有着不错的表现，在Mycat的基础上改进的同时使用JAVA语言编写十分贴合WEB开发人员的喜好。
在切换的部分我们讲述了另外两个组件：MHA和Keepalive，这两个组件由大量的资源和案例参考，所以这里简单拿来介绍它们是如何和Mysql进行组合增强集群架构的高可用特性的，
写到最后
三高架构看起来十分复杂并且高大上，然而实际上我们把组件拆分完成之后发现各个组件的角色分工非常明确，作用也比较明显。当然这些内容可能更多是运维会接触到和使用到，对于开发人员来说这些内容只需要简单了解流程和理论即可。
