MySQL Shell如何接管手动搭建(含仲裁节点)MGR集群

这篇具有很好参考价值的文章主要介绍了MySQL Shell如何接管手动搭建(含仲裁节点)MGR集群。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

MySQL Shell如何接管手动搭建(含仲裁节点)MGR集群

本文源自GreatSQL社区用户的一次提问:

Q:一个包含仲裁节点(ARBITRATOR)的GreatSQL MGR集群,一开始是用手动方式构建,后来想用MySQL Shell接管,可以吗?

A:是可以的,不过也有一定局限性

具体的操作如下

检查当前MGR集群情况

greatsql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 04b57be0-73a0-11ee-a450-00155d064000 | 192.168.5.170 |     3307    | ONLINE       | SECONDARY   | 8.0.32         | XCom               |
| group_replication_applier | 0b157081-73a7-11ee-899b-00155d064000 | 192.168.5.170 |     3308    | ONLINE       | ARBITRATOR  | 8.0.32         | XCom               |
| group_replication_applier | d4b877cf-16f0-11ee-9e98-00155d064000 | 192.168.5.170 |     3306    | ONLINE       | PRIMARY     | 8.0.32         | XCom               |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)

可以看到三个节点都是ONLINE状态

专属账户增加相应授权

连接 Primary 节点,查看下原来的账户权限情况,对MGR专属账户增加相应授权

greatsql> show grants for GreatSQL;
+--------------------------------------------------+
| Grants for GreatSQL@%                            |
+--------------------------------------------------+
| GRANT REPLICATION SLAVE ON *.* TO `GreatSQL`@`%` |
| GRANT BACKUP_ADMIN ON *.* TO `GreatSQL`@`%`      |
+--------------------------------------------------+

可以看到该权限并不能足以让 Shell 使用,需要增加授权才可以

以下是用 Shell 接管的 MGR 集群专属账户授权,手动添加到权限一致即可

greatsql> show grants for GreatSQL;
# 只展示关键权限部分
| GRANT SELECT, RELOAD, SHUTDOWN, PROCESS, FILE, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE USER ON *.* TO `GreatSQL`@`%` WITH GRANT OPTION|
| GRANT BACKUP_ADMIN ON *.* TO `GreatSQL`@`%`|
| GRANT CLONE_ADMIN,CONNECTION_ADMIN,GROUP_REPLICATION_ADMIN,PERSIST_RO_VARIABLES_ADMIN,REPLICATION_APPLIER,REPLICATION_SLAVE_ADMIN,ROLE_ADMIN,SYSTEM_VARIABLES_ADMIN ON *.* TO `GreatSQL`@`%` WITH GRANT OPTION|
| GRANT INSERT, UPDATE, DELETE ON `mysql`.* TO `GreatSQL`@`%` WITH GRANT OPTION|
| GRANT INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON `mysql_innodb_cluster_metadata`.* TO `GreatSQL`@`%` WITH GRANT OPTION          |
| GRANT INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON `mysql_innodb_cluster_metadata_bkp`.* TO `GreatSQL`@`%` WITH GRANT OPTION      |
| GRANT INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON `mysql_innodb_cluster_metadata_previous`.* TO `GreatSQL`@`%` WITH GRANT OPTION |

上述授权工作在 Primary 节点执行完后,Secondary节点会自动跟随。ARBITRATOR节点需要手动处理。

ARBITRATOR节点手动增加授权

修改 **ARBITRATOR **节点的my.cnf,关闭 ARBITRATOR 角色

(设置 group_replication_arbitrator = 0),并记得确保MGR不会自动启动

(设置 group_replication_start_on_boot = OFF),然后重启该实例。

重启完成后,此时尚未启动MGR进程,因此 ARBITRATOR 节点会变成一个普通实例,可以对其进行读写操作。

-- 手动增加相应授权
greatsql> set sql_log_bin = 0;
-- 参考第2步,手动增加相应授权
greatsql> GRANT ....

确认授权完成后,即可关闭该实例,重新启用 ARBITRATOR 角色(设置 group_replication_arbitrator = 1),重启实例,但先不启动 MGR进程,后面再说。

用MySQL Shell接管MGR

利用Shell接管现有MGR:

mysqlsh> c=dba.create_cluster("mgr",{"adoptFromGR": "true"})

参数{"adoptFromGR": "true"}的作用就是告诉Shell,接管现有MGR集群,而不是全新创建一个。

之后会很顺利地完成接管,此时只有 PrimarySecondary 两个节点:

shell> c=dba.create_cluster("mgr", {"adoptFromGR":"true"})
A new InnoDB cluster will be created based on the existing replication group on instance '127.0.0.1:3306'.

Creating InnoDB cluster 'mgr' on '192.168.5.170:3306'...

Adding Seed Instance...
Adding Instance '192.168.5.170:3307'...
Adding Instance '192.168.5.170:3306'...
Resetting distributed recovery credentials across the cluster...
NOTE: User 'mysql_innodb_cluster_3307'@'%' already existed at instance '192.168.5.170:3306'. It will be deleted and created again with a new password.
Cluster successfully created based on existing replication group.

查看下状态

shell> c.status()
{
  "clusterName": "mgr",
  "defaultReplicaSet": {
     "name": "default",
     "primary": "192.168.5.170:3306",
     "ssl": "DISABLED",
     "status": "OK_NO_TOLERANCE",
     "statusText": "Cluster is NOT tolerant to any failures.",
     "topology": {
        "192.168.5.170:3306": {
          "address": "192.168.5.170:3306",
          "memberRole": "PRIMARY",
          "mode": "R/W",
          "readReplicas": {},
          "replicationLag": null,
          "role": "HA",
          "status": "ONLINE",
          "version": "8.0.32"
        },
        "192.168.5.170:3307": {
          "address": "192.168.5.170:3307",
          "memberRole": "SECONDARY",
          "mode": "R/O",
          "readReplicas": {},
          "replicationLag": null,
          "role": "HA",
          "status": "ONLINE",
          "version": "8.0.32"
        }
     },
     "topologyMode": "Single-Primary"
  },
  "groupInformationSourceMember": "192.168.5.170:3306"
}

连接ARBITRATOR节点,启动MGR进程

连接 ARBITRATOR 节点,并执行 start group_replication 启动MGR进程,此时能看到各节点状态工作正常:

greatsql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 04b57be0-73a0-11ee-a450-00155d064000 | 192.168.5.170 |        3307 | ONLINE       | SECONDARY   | 8.0.32         | XCom                       |
| group_replication_applier | 0b157081-73a7-11ee-899b-00155d064000 | 192.168.5.170 |        3308 | ONLINE       | ARBITRATOR  | 8.0.32         | XCom                       |
| group_replication_applier | d4b877cf-16f0-11ee-9e98-00155d064000 | 192.168.5.170 |        3306 | ONLINE       | PRIMARY     | 8.0.32         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)

切换到 MySQL Shell 查看

shell> c.status()

    "clusterName": "mgr",
    "defaultReplicaSet": {
        "name": "default",
        "primary": "192.168.5.170:3306",
        "ssl": "DISABLED",
        "status": "OK",
        "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
        "topology": {
            "192.168.5.170:3306": {
                "address": "192.168.5.170:3306",
                "memberRole": "PRIMARY",
                "mode": "R/W",
                "readReplicas": {},
                "replicationLag": null,
                "role": "HA",
                "status": "ONLINE",
                "version": "8.0.32"
            },
            "192.168.5.170:3307": {
                "address": "192.168.5.170:3307",
                "memberRole": "SECONDARY",
                "mode": "R/O",
                "readReplicas": {},
                "replicationLag": null,
                "role": "HA",
                "status": "ONLINE",
                "version": "8.0.32"
            },
            "192.168.5.170:3308": {
                "address": "192.168.5.170:3308",
                "instanceErrors": [
                    "WARNING: Instance is not managed by InnoDB cluster. Use cluster.rescan() to repair."
                ],
                "memberRole": "ARBITRATOR",
                "mode": "R/O",
                "readReplicas": {},
                "replicationLag": null,
                "role": "HA",
                "status": "ONLINE",
                "version": "8.0.32"
            }
        },
        "topologyMode": "Single-Primary"
    },
    "groupInformationSourceMember": "192.168.5.170:3306"
}

可以看到已经能看到所有节点,包括 ARBITRATOR 节点,但是因为该节点无法对其进行读写,所以实际上 Shell 接入时的一些初始化工作还是没完全执行,所以才有上面的提示:

"instanceErrors": [
"WARNING: Instance is not managed by InnoDB cluster. Use cluster.rescan() to repair."
],

不过并不影响,因为该节点只需参与MGR投票即可,可以忽略这个错误。

不知道注意到了没有,在这个过程中,并不需要像添加常规 Secondary 节点那样要 CLONE 全量数据

提醒:后续如果要通过 Shell 对 MGR 做些操作,可能 ARBITRATOR 节点会提示不支持,此时只需临时把 ARBITRATOR 的MGR进程关闭,必要的操作执行完毕后再次启动MGR进程即可。

至此,就完成了 Shell 接管 MGR 集群的过程。


这里附带几个FAQ:

Q:在GreatSQL MGR集群中,新增 ARBITRATOR 节点时,是否一定要 CLONE 数据?

因为如果当前 Primary 节点上数据量巨大时,每次都 CLONE 代价太高了,那么第一次加入 ARBITRATOR 节点的成本有点难以接受。

A:当MGR中Primary节点已有用户数据时,无论是用 Shell 还是手动加入一个新的仲裁节点(ARBITRATOR),首次加入都需要经过 CLONE 的过程(即便是在启动前已经设置group_replication_arbitrator = 1)
变通的办法有几个:

  1. 第一个加入的ARBITRATOR节点,可以在加入成功后,关闭ARBITRATOR角色,然后删除所有用户数据,这时候就变成一个空实例了,再次重启后,再开启ARBITRATOR角色,不会再次 CLONE 数据。
  2. 在上述第一个ARBITRATOR节点的基础上,在其关闭期间,做一次物理全备,然后这个备份就可以作为未来新的ARBITRATOR节点的datadir,再次加入MGR集群也不会再次 CLONE 数据。

实际上,在加入 MGR 时,判断是否需要 CLONE 数据的依据是看 gtid_purged ,因此还有第三个办法:

  1. 在完成实例初始化后,手动修改 gtid_purged,例如 set global gtid_purged = 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1-1449587416'; 也可以跳过数据 CLONE

Enjoy GreatSQL 😃

关于 GreatSQL

GreatSQL是适用于金融级应用的国内自主开源数据库,具备高性能、高可靠、高易用性、高安全等多个核心特性,可以作为MySQL或Percona Server的可选替换,用于线上生产环境,且完全免费并兼容MySQL或Percona Server。

相关链接: GreatSQL社区 Gitee GitHub Bilibili

GreatSQL社区:

社区博客有奖征稿详情:https://greatsql.cn/thread-100-1-1.html

MySQL Shell如何接管手动搭建(含仲裁节点)MGR集群

技术交流群:

微信:扫码添加GreatSQL社区助手微信好友,发送验证信息加群

MySQL Shell如何接管手动搭建(含仲裁节点)MGR集群文章来源地址https://www.toymoban.com/news/detail-747535.html

到了这里,关于MySQL Shell如何接管手动搭建(含仲裁节点)MGR集群的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • ProxySQL+MGR高可用搭建

    服务器点位 NODE IP mgr_node0 192.165.26.200 mgr_node1 192.165.25.201 mgr_node2 192.165.26.202 proxysql 192.165.26.199 修改主机名 在所有节点修改/etc/hosts 运行uuidgen获取uuid 修改所有节点的my.cnf 多主运行 每个mysql节点均运行 在第一个节点执行 在其他节点执行 查看是否搭建成功 单主运行 每个MySQL节

    2024年02月11日
    浏览(11)
  • 初识MYSQL组复制MGR

    注:本文翻译自https://dev.mysql.com/doc/refman/8.0/en/group-replication.html 创建容错系统的最常见方法是使组件冗余,换句话说,可以删除组件,而系统应继续按预期运行。这就产生了一系列挑战,将这类系统的复杂性提升到了一个完全不同的水平。具体来说,复制数据库必须处理这样

    2024年02月08日
    浏览(9)
  • 如何手动搭建自动化部署系统

    前两天写了个脚本帮助组内同学将本地构建产物上传至服务器,可以自动创建路径,监测是否存在历史版本,并将最新上传的产物替换历史版本,历史版本变为回溯版本。 核心就是: shell 脚本的复制 scp 指令。 sshpass 免交互 ssh 登录工具。 上面的脚本可以通过手动执行脚本,

    2024年02月11日
    浏览(27)
  • 图文结合丨GreatSQL MGR + ProxySQL集群搭建方案

    ProxySQL 是基于 MySQL 的一款开源的中间件的产品,是一个灵活的 MySQL 代理层,可以实现读写分离,支持 Query 路由功能,支持动态指定某个 SQL 进行缓存,支持动态加载(无需重启 ProxySQL 服务),故障切换和一些 SQL 的过滤功能。 GreatSQL 是适用于金融级应用的国内自主开源数据

    2024年02月08日
    浏览(14)
  • ZooKeeper之分布式环境搭建--仲裁模式与伪分布式环境搭建

    相关知识 为了完成本关任务,你需要掌握:1.ZooKeeper单节点安装方法,2.命令行基本操作。 ZooKeeper之仲裁模式 standlone 模式运行ZooKeeper,便于评估,开发,测试和学习。但是在实际生产中,使用ZooKeeper均以仲裁模式( quorum mode )运行, quorum mode 具有一组ZooKeeper服务器,这一组

    2024年02月05日
    浏览(17)
  • windows下全免费手动搭建php8+mysql8开发环境及可视化工具安装

    最近PHP项目少了,一直在研究UE5和Golang,但是考虑到政府、国企未来几年国产化的要求,可能又要重拾PHP。于是近日把用了N年的框架重新更新至适合PHP8.2以上的版本,同时也乘着新装机,再次搭建php和mysql开发环境。本文留个记录,以后方便操作。 选择最新版下载 https://ww

    2024年01月20日
    浏览(38)
  • 【RabbitMQ】RabbitMQ 集群的搭建 —— 基于 Docker 搭建 RabbitMQ 的普通集群,镜像集群以及仲裁队列

    在RabbitMQ中,有不同的集群模式,包括普通模式、镜像模式和仲裁队列。每种模式具有不同的特点和应用场景。 普通集群,也称为标准集群(classic cluster),具备以下特征: 在集群的各个节点之间共享部分数据,包括交换机和队列的元信息,但不包括队列中的消息。 当访问

    2024年02月04日
    浏览(16)
  • MySQL 8的MGR集群中设置autocommit=0引起ERROR 1064 (42000)错误

    在一套MySQL MGR集群测试环境中,同事测试时,在my.cnf参数文件中修改了autocommit参数(修改为autocommit=0),结果上周五,由于系统管理员要升级RHEL 8.8的系统补丁,所以将这这三台MySQL的数据库服务关闭了,升级完RHEL 8.8的系统补丁后,启动MySQL的集群时遇到了“ERROR 1192 (HY000)

    2024年02月09日
    浏览(14)
  • Docker系列---【mysql容器手动停止后,重启服务器,mysql容器被删掉了,如何恢复mysql数据?】...

    为了快速搭建数据库,我使用了docker搭建数据库,由于服务器资源紧张,我想先把mysql容器停掉,启动jenkins容器,使用完之后再停掉jenkins,启动mysql,结果由于服务器资源有限,服务器卡死了,无法远程连接了,没办法,我只能登录运营商的云平台管理平台,强制重启服务器

    2024年02月08日
    浏览(18)
  • 谈谈mysql——主从模式下的同步方式及半同步、MGR的部署方式

    MySQL的复制模式 异步复制 MySQL的复制方式默认是异步的,主从复制涉及三个线程 master I/O master I/O线程负责写入Binlog,并将执行结果返给客户端,至于Binlog有没有被IO线程读取,读取后有没有重放,重放有没有成功,它是不关心的。 slave I/O线程 负责将读取master的Binlog并写入s

    2024年02月15日
    浏览(14)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包