MySQL InnoDB Cluster简介
MySQL InnoDB Cluster 是最新GA的MySQL高可用方案，利用MySQL Group Replication和MySQL Shell、MySQL Router可以轻松搭建强壮的高可用方案。
MySQL InnoDB Cluster的特性:他是基于群组复制并且提供便于管理的 API以及应用故障转移和路由,易于配置，提供比群组复制更高级别的可用性。
MySQL InnoDB Cluster组件构成:
MySQL Group Replication：提供 DB 的扩展、自动故障转移
MySQL Router：是访问路由转发中间件，提供应用程序访问的failover能力
MySQL Shell：是新的mysql 客户端工具支持x protocol和mysql protocol，具备JavaScript和python可编程能力，作为搭建InnoDB Cluster管理工具
X DevAPI：一个 API 通过 XProtocol 与服务器通信
Admin API：一个特殊的API通过 MySQL Shell 使用，可以用于对 Innodb Cluster 进行配置管理
整体架构:
上图显示了 InnoDB Cluster 的整体架构，通过MySQL Shell可以配置出一个高可用自动进行故障转移的MySQL InnoDB Cluster，在后续运维过程中也可以通过MySQL Shell对集群进行状态监控及管理维护,通过MySQL Router向应用层屏蔽底层集群的细节(MySQL Router 推荐部署在应用端)，使用 MySQL Enterprise Monitor 对整体进行监控。
MySQL Group Replication:
MGR通信服务基于 Paxos 实现,为 MySQL 5.7 之后的版本提供同步复制（日志复制同步，数据施放异步），并且支持所有的 MySQL 平台,MGR 提供了高可用分布式 MySQL 数据库服务，它可以实现服务器自动故障转移，分布式容错能力，支持多主更新的架构，自动重配置（加入/移除节点，崩溃等等）并且可以自动侦测和处理冲突。
MGR特性:
(1)支持单主和多主模式
(2)基于Paxos算法，实现数据复制的一致性
(3)插件化设计，支持插件检测，新增节点小于集群当前节点主版本号，拒绝加入集群，大于则加入，但无法作为主节点
(4)没有第三方组件依赖
(5)支持全链路SSL通讯
(6)支持IP白名单
(7)不依赖网络多播
适用场景:
弹性复制，服务器的数量动态增加或缩减时，使影响降到最低。
分片的高可用-用户可以利用MGR实现单一分片的高可用，每个分片都具有一个复制组。
主从复制的替代选择-可以使用单主模式避免发生冲突检测，以替代传统的主从复制。
MGR架构:
GR插件负责执行分布式内容，侦测和处理冲突，恢复分布式集群，推送事务给其它的组成员，接收其它成员的事务以及决定事务最终的结果。
GCS群组通信系统
GCS API将通信系统的实现进行抽象化，并管理这个接口。通信引擎是基于Paxos开发的，是实现跨服务器的组件。
MGR在使用时具有两种模式，包括：
单主模式:
(1)单个MySQL实例作为数据写入的主节点，
(2)其它的节点用于热备。
优点:便于现有系统进行切换
多主模式:
群组内所有的成员都可以进行数据写入,读取操作。
因为多主模式需要确保数据写入的一致性，所以在使用上有如下限制：
(1)表必须有主键
(2)必须是InnoDb的引擎
(3)gtid-mode=on
(4)binlog格式是Row-based
(5)不支持serializable隔离级别
MGR的监视:
通过perforamnce_shcema里面的表和全局变量可以确认MGR的成员状态，当前主成员等必要信息。
MySQL Router:
(1)轻量级的中间件，可以提供负载均衡和应用连接的故障转移。
(2)通过使用 Router 和 Shell，利用 MGR 实现完整的数据库层的解决方案。
(3)它是一个会配合 MySQL 的开发路线图所发展的工具。
使Mysql应用能透明的使用高可用数据库
表现方式:
(1)client透明链接的路由(LB,应用连接的故障转移)
(2)无态化的设计使客户端的高可用得以简化(本地路由器成为应用技术堆栈的一部分)
优势:MysqlRouter可以在不影响现有的应用前提下,将单独的mysql实例,轻易的迁移到具有高可用的InnoDB分布式集群上
执行步骤:
1.执行配置的检查,之后连接到mysq1
2.执行dba.createCluster() 创建一个集群
3.最后执行 cluster.addInstance() 就可以将其它成员加入到集群
集群的故障排除与维护:
网络故障,高延迟,服务器的故障
cluster.options (集群的全局配选项,对每个集群成员的设置)
(1)expelTimeout(避免由于网络故障而频繁驱逐成员)
(2)memberWeight(发生故障转移时的下一个主要成员)
(3)exitStateAction(从集群中驱逐服务器时的操作,中止,只读,脱机模式)
(4)autoRejoinTries(驱逐后尝试重新加入)
搭建过程:
安装mysql-community-server、mysql-shell、mysql-router软件包。
(1)配置mysql的yum源
yum install -y https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm
(2)安装
yum install -y mysql-community-server mysql-shell mysql-router
(3)把主机名称映射写入hosts文件中
(4)配置本地实例
(5)初始化MySQL InnoDB Cluster
(6)初始化mysql-router
遇到问题:
(1)如何重新恢复集群
var cluster=dba.getCluster('mycluster')
dba.rebootClusterFromCompleteOutage('mycluster')
(2)执行cluster.status()部分节点提示status:UNREACHABLE，此时集群不能正常响应只剩下一个活跃节点，此节点只能提供查询，无法写入，执行写入操作会僵住。
修复这种状态，需要执行forceQuorumUsingPartitionOf指定当前活跃节点(如果是多个则选择primary node)，此时活跃节点可以提供读写操作，然后将其他节点加入此集群。
cluster.forceQuorumUsingPartitionOf('root@192.168.10.102:3306')
cluster.rejoinInstance('root@192.168.10.101:3306')
cluster.rejoinInstance('root@192.168.10.100:3306')
节点状态:
ONLINE - 节点状态正常。
OFFLINE - 实例在运行，但没有加入任何Cluster。
RECOVERING - 实例已加入Cluster，正在同步数据。
ERROR - 同步数据发生异常。
UNREACHABLE - 与其他节点通讯中断，可能是网络问题，可能是节点crash。
MISSING 节点已加入集群，但未启动group replication
集群状态:
OK:所有节点处于online状态，有冗余节点。
OK_PARTIAL:有节点不可用，但仍有冗余节点。
OK_NO_TOLERANCE:有足够的online节点，但没有冗余，例如：两个节点的Cluster，其中一个挂了，集群就不可用了。
NO_QUORUM:有节点处于online状态，但达不到法定节点数，此状态下Cluster无法写入，只能读取。
UNKNOWN:不是online或recovering状态，尝试连接其他实例查看状态。
UNAVAILABLE:组内节点全是offline状态，但实例在运行，可能实例刚重启还没加入Cluster。