MySQL高可用方案-MySQL InnoDB Cluster

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。