mysql-agent与sql server高可用
本文首先介绍下teledb的高可用实现方案，包括agent等组件，以及集群的运行逻辑；
然后介绍sql server 镜像下的切换方式，阐述几种运行模式及其对应的切换动作，给出agent做切换的大致思路；最后，介绍sql server官方推荐的always on方案，介绍了always on 与 WSFC的协作关系，并分析always on与MGR的异同，最后给出WSFC与always on的逐步配置
1. mysql agent
1.1 模块概述
在sql server 高可用方案确定和施工之前，可以参考下mysql agent的实现
- zookeeper
该模块为信息中心，主要是存储集群状态信息以及部分配置信息，以及为网关组件gateway提供底层数据库信息，以便将客户端流量分流到相关数据库节点；
- agent
该模块功能主要是：
1、获取zk集群中其他节点信息，搭建和管理集群；
2、上报节点状态信息，以及集群信息；
3、执行相关任务（如手动切换）等。
- gateway
该模块主要关注zk上集群信息变化，实时进行客户端流量分配。
这里的架构与原来teledb 5.7版本的架构基本没有变化，只是去除了原有的操作任务调度中心keeper模块，使得结构更加简单，运维也更加容易，但是在功能上有所增加，不仅执行原有的增强半同步以及异步复制，还支持最新的组复制。
针对sql server，其gateway主要是流量分发、转发代理读写端口（13049 13048），不需要我们关注；
zk存储集群状态信息，agent获取状态、上报状态和执行切换三种操作。
1.2 主要逻辑流程
1.2.1 集群整体运行逻辑
- 本地agent连接数据库，定时轮询检测集群状态（否加入了集群、在集群中数据库状态是否正常、数据库的读写状态配置是否正常等信息）；
- 通过对应的状态信息，如果状态异常，则进行相应的操作，如：a) 如果数据库不在集群中，则将数据库加入集群；b) 如果集群中节点状态异常，则进行修复操作；c) 如果主库宕机，则进行容灾切换操作；d) 如果发现zk上有手动切换任务，则进行相应的操作；e) 最后将状态信息上报到zk中的setrun，以便其他模块获取集群信息。f) 集群创建、实例增减、主从切换等操作的底层实现通过mysql-shell对应的api实现。详细api可参考https://dev.mysql.com/doc/dev/mysqlsh-api-python/8.0/。
1.2.2 集群创建逻辑
调用创建工具，在zk上创建相应rssetinfo节点，set@setname节点和setinfo@setname节点即可。
1.2.3 添加删除节点逻辑
添加节点方式，其实就是创建相应rssetinfo节点即可，agent会自己安装初始化逻辑加入集群；删除节点的方式，同样为删除相应rssetinfo信息，agent watch到相应的resetinfo为空，则调用remove_instance退出集群。
1.2.4 集群删除逻辑
删除集群的操作与创建集群的操作相反，工具只需要删除相应的zk节点信息。
1.2.5 切换逻辑
l 手动切换
手动切换，只需要连接集群中任意一台数据库，执行set_primary_instance即可。
l 自动切换
对于组复制，完全由MGR内部控制，agent仅仅需要及时上报集群信息即可；对于异步复制和半同步复制，当主库宕机，agent所创建的临时节点自动删除，而后leader节点将从库列表中的最大权重节点选为新主。
MGR:
由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N / 2 + 1） 决议并通过，才能得以提交。如上图所示，由3个节点组成一个复制组，Consensus层为一致 性协议层，在事务提交过程中，发生组间通讯，由2个节点决议(certify)通过这个事务，事务 才能够最终得以提交并响应。
具体搭建可参考MGR配置
对标sql server，agent需要做到（1）检测节点状态 （2）上报节点状态 （3）主从切换
2.sql server 高可用与切换
2.1 切换
切换指的是针对库级别的切换，主要结合sql server的几种模式，对应的可执行切换的操作。
2.1.1 模式与切换
每种运行模式下支持的故障转移形式
|
故障转移形式 |
高性能 |
没有见证服务器的高安全性模式 |
具有见证服务器的高安全性模式 |
|
自动故障转移 (automatic failover) |
否 |
否 |
是 |
|
手动故障转移 |
否 |
是 |
是 |
|
强制服务 |
是 |
是 |
否 |
- 在高安全模式下：
在主机执行:（sql server 镜像文档中用到的主备切换）
use master;
alter database Demo1 set partner failover;
即完成主备切换
- 在高性能模式下，
需要先切换到高安全模式下再执行切换
use master;
alter database Demo1 set partner safety full;
alter database Demo1 set partner failover;
- 在主机宕机的情况下在备机进行强制切换：
use master;
alter database Demo1 set partner FORCE_SERVICE_ALLOW_DATA_LOSS;
当主机重新开机后，在备机器上执行
use master;
alter database Demo1 set partner resume;
此时SQLSVR1成为了备机，而SQLSVR2成为了主机。
再到SQLSVR2机器上执行alter database Demo1 set partner failover;
就成了SQLSVR1成为主机，SQLSVR2成为备机
- 切换镜像在高性能模式下(慎用，可能会丢失数据)
use master;
alter database Demo1 set partner safety off;
- 关闭数据库镜像ALTER DATABASE Demo1 SET PARTNER OFF
综上，切换主从关系分为手动切换（主备节点都正常）和容灾（主节点宕机）两种情况。
2.2 always on
2.2.1 always on 与WSFC
从 SQL Server 2016 开始，配置 AlwaysOn 可用性组时可使用数据库级别运行状况检测 (DB_FAILOVER) 选项。 数据库级别运行状况检测可检测到数据库不再处于联机状态以及其他问题，然后将触发可用性组的自动故障转移。 可能触发运行状况检测的示例包括数据库处于可疑模式、数据库处于脱机状态、数据库处于恢复中（无法恢复）。
Windows Server 故障转移群集 (WSFC)：WSFC 是一组独立的服务器，它们共同协作以提高应用程序和服务的可用性。
SQL SERVER 的 ALWAYS ON 和 MYSQL的 MGR的对比
1 MYSQL 的MGR 支持 多主的模式， SQL SERVER 不支持
2 SQL SERVER 的AWO 支持 同步和异步模式 MYSQL 的 MGR 你可以视为是强一致的同步模式。
3 SQL SERVER 和 MYSQL 都是通过日志的方式来进行复制的。
4 MYSQL 的 MGR 是使用整体数据库复制的方式 ，而 SQL SERVER 的集群，不是基于 INSTANCE 而是基于数据库的
AlwaysOn 是一个充分利用 WSFC 的新的高可用性和灾难恢复解决方案。AlwaysOn 提供一个集成、灵活的解决方案，用于提高应用程序可用性，并提供更好的硬件投资回报，还简化高可用性部署和管理。
AlwaysOn 可用性组和 AlwaysOn 故障转移群集实例将 WSFC 用作一种平台技术，将组件注册为 WSFC 群集资源。相关的资源将合并为一个“资源组”，这些资源可能依赖于其他 WSFC 群集资源。这样，WSFC 群集服务就可以感测并标明是否需要重新启动 SQL Server 实例，或自动将其故障转移到 WSFC 群集中的不同服务器节点上。
