MySQL 高可用方案--MGR 第03期：操作

MySQL数据库联盟 2021-09-09

1091

上一节内容我们聊到了 MGR 的部署，这一节内容，来聊聊 MGR 的常用操作。本节内容都是通过 MySQL Shell 执行的，MySQL Shell 安装和使用可参考上一节内容。

1 创建集群

var cluster = dba.createCluster('Cluster01')

2 给集群分配变量

将集群 Cluster01 分配给变量 cluster，如果刚通过 1 中的方式创建了集群，则可以不执行，如果是创建完集群，又退出了 MySQL Shell，则需要执行，方便后面命令执行。


var cluster = dba.getCluster('Cluster01')

3 获取集群结构信息

cluster.describe()

4 查看集群状态

cluster.status()

比如下面例子（为方便查看，部分内容已经用 ...... 替换）：

MySQL  192.168.150.232:33060+ ssl  JS > cluster.status()
{
    "clusterName": "Cluster01", 
    "defaultReplicaSet": {
    ......
        "topology": {
            "node1:3306": {
                "address": "node1:3306", 
                "memberRole": "PRIMARY", 
                "mode": "R/W", 
                "readReplicas": {}, 
                "replicationLag": null, 
                "role": "HA", 
                "status": "ONLINE", 
                "version": "8.0.25"
            }, 
            "node2:3306": {
            ......
            }, 
            "node3:3306": {
             ......
            }
        }, 
        "topologyMode": "Single-Primary"
    }, 
    "groupInformationSourceMember": "node1:3306"
}

这里重点解释一下 status 列，表示该节点的状态，可能是下面几种值：

ONLINE：实例在线并加入集群。
OFFLINE：该实例已失去与其他实例的连接。
RECOVERING：该实例正在检索它需要的事务来与集群同步。
UNREACHABLE：实例已失去与集群的通信。
ERROR：实例在恢复阶段或应用事务时遇到错误。

5 配置检查

新节点加入集群之前，检查配置是否正确：

dba.checkInstanceConfiguration('mgr_user@node4:3306')

6 节点验证

验证新加节点上的数据是否会阻止它加入集群：

cluster.checkInstanceState('mgr_user@node4:3306')

比如：

MySQL  192.168.150.232:33060+ ssl  JS > cluster.checkInstanceState('mgr_user@node4:3306')
Analyzing the instance 'bg-db-mysql-voicemonitor_pre:3306' replication state...


The instance 'bg-db-mysql-voicemonitor_pre:3306' is valid for the cluster.
The instance is new to Group Replication.


{
    "reason": "new", 
    "state": "ok"
}

输出可以是下面这些情况：

OK new：实例没有执行任何 GTID 事务，因此不会与集群执行的 GTID 冲突。
OK 可恢复：实例执行的 GTID 与集群种子实例执行的 GTID 不冲突。
ERROR diverged: 实例执行的 GTID 与集群种子实例执行的 GTID 不一致。
ERROR lost_transactions：实例执行的 GTID 比集群种子实例的执行 GTID 多。

State 为 ok，表示可以加入集群。

7 增加实例

cluster.addInstance('mgr_user@192.168.150.123:3306');

例子可参考上一节。

8 删除实例

cluster.removeInstance('mgr_user@192.168.150.123:3306');

9 列出集群中实例的配置

cluster.options()

10 更改集群全局配置

cluster.setOption(option, value)

11 更改集群单个实例的配置

cluster.setInstanceOption(instance, option, value)

12 将实例重新加入集群

cluster.rejoinInstance(instance)

13 使用仲裁恢复集群

如果部分实例故障，导致集群可能失去法定投票人数，无法进行投票，则可以选择一个包含集群元数据的实例，执行仲裁操作，从而恢复集群。这种方式也是在集群恢复过程中，其他方法都无法恢复集群情况下，最后的操作，通常不建议使用，可能会导致集群脑裂。

命令如下：

cluster.forceQuorumUsingPartitionOf('mgr_user@node1:3306');

该命令如果在运行正常的集群执行，则会出现如下报错：

ERROR: Cannot perform operation on an healthy cluster because it can only be used to restore a cluster from quorum loss.
Cluster.forceQuorumUsingPartitionOf: The cluster has quorum according to instance 'node1:3306' (RuntimeError)

14 切换到多主模式

cluster.switchToMultiPrimaryMode()

15 切换到单主模式

cluster.switchToSinglePrimaryMode('node3:3306')

如果指定了节点，则该实例将成为主节点；如果没有指定节点，则新主是权重最高的节点，权重相同时，则新主是 UUID 最低的节点。

16 更新集群元数据

cluster.rescan()

比如我们手动更改了实例的配置，或者实例退出集群之后，需要更新集群的元数据，则可以使用该命令。

rescan() 操作可以检测没有在元数据中注册的新活动实例并添加它们，或者删除在元数据中的过时实例。

MGR 常用的一些操作就介绍到这里，欢迎在留言区补充更多的命令。

在公众号后续的文章中，会聊一聊 MGR 的原理、一致性保证、网络隔离、监控、遇到的一些问题等。欢迎关注：

文章推荐

MySQL 高可用方案--MGR 第02期：部署

MySQL 高可用方案--MGR 第01期：初探

MySQL 常用高可用方案

MySQL 常见面试题

MySQL 删库到恢复

Linux 安装 MySQL 最新版本 8.0.25

Binlog分析利器-binlog_summary.py

MySQL 频频出现慢日志，你该怎么办？

如何设计一个高可用、高并发的 MySQL 架构

推荐几个不错的 MySQL 提升资料

我们创建了一个 MySQL 交流社群，围绕开发、运维、DBA、架构师和其他需要用到 MySQL 的群体，群内会分享一些读书笔记、面试技巧等，同时也用于大家交流使用 MySQL 过程中遇到的问题！

入群请加下方群秘二维码，回复 MySQL，等待群秘邀你入群。

mysql

文章转载自MySQL数据库联盟，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

MySQL 高可用方案--MGR 第03期：操作

评论