翼度科技»论坛 编程开发 mysql 查看内容

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

5

主题

5

帖子

15

积分

新手上路

Rank: 1

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

本文源自GreatSQL社区用户的一次提问:
Q:一个包含仲裁节点(ARBITRATOR)的GreatSQL MGR集群,一开始是用手动方式构建,后来想用MySQL Shell接管,可以吗?
A:是可以的,不过也有一定局限性
具体的操作如下
检查当前MGR集群情况
  1. greatsql> select * from performance_schema.replication_group_members;
  2. +---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
  3. | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
  4. +---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
  5. | group_replication_applier | 04b57be0-73a0-11ee-a450-00155d064000 | 192.168.5.170 |     3307    | ONLINE       | SECONDARY   | 8.0.32         | XCom               |
  6. | group_replication_applier | 0b157081-73a7-11ee-899b-00155d064000 | 192.168.5.170 |     3308    | ONLINE       | ARBITRATOR  | 8.0.32         | XCom               |
  7. | group_replication_applier | d4b877cf-16f0-11ee-9e98-00155d064000 | 192.168.5.170 |     3306    | ONLINE       | PRIMARY     | 8.0.32         | XCom               |
  8. +---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
  9. 3 rows in set (0.00 sec)
复制代码
可以看到三个节点都是ONLINE状态
专属账户增加相应授权

连接 Primary 节点,查看下原来的账户权限情况,对MGR专属账户增加相应授权
  1. greatsql> show grants for GreatSQL;
  2. +--------------------------------------------------+
  3. | Grants for GreatSQL@%                            |
  4. +--------------------------------------------------+
  5. | GRANT REPLICATION SLAVE ON *.* TO `GreatSQL`@`%` |
  6. | GRANT BACKUP_ADMIN ON *.* TO `GreatSQL`@`%`      |
  7. +--------------------------------------------------+
复制代码
可以看到该权限并不能足以让 Shell 使用,需要增加授权才可以
以下是用 Shell 接管的 MGR 集群专属账户授权,手动添加到权限一致即可
  1. greatsql> show grants for GreatSQL;
  2. # 只展示关键权限部分
  3. | GRANT SELECT, RELOAD, SHUTDOWN, PROCESS, FILE, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE USER ON *.* TO `GreatSQL`@`%` WITH GRANT OPTION|
  4. | GRANT BACKUP_ADMIN ON *.* TO `GreatSQL`@`%`|
  5. | 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|
  6. | GRANT INSERT, UPDATE, DELETE ON `mysql`.* TO `GreatSQL`@`%` WITH GRANT OPTION|
  7. | 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          |
  8. | 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      |
  9. | 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 节点会变成一个普通实例,可以对其进行读写操作。
  1. -- 手动增加相应授权
  2. greatsql> set sql_log_bin = 0;
  3. -- 参考第2步,手动增加相应授权
  4. greatsql> GRANT ....
复制代码
确认授权完成后,即可关闭该实例,重新启用 ARBITRATOR 角色(设置 group_replication_arbitrator = 1),重启实例,但先不启动 MGR进程,后面再说。
用MySQL Shell接管MGR

利用Shell接管现有MGR:
  1. mysqlsh> c=dba.create_cluster("mgr",{"adoptFromGR": "true"})
复制代码
参数{"adoptFromGR": "true"}的作用就是告诉Shell,接管现有MGR集群,而不是全新创建一个。
之后会很顺利地完成接管,此时只有 PrimarySecondary 两个节点:
  1. shell> c=dba.create_cluster("mgr", {"adoptFromGR":"true"})
  2. A new InnoDB cluster will be created based on the existing replication group on instance '127.0.0.1:3306'.
  3. Creating InnoDB cluster 'mgr' on '192.168.5.170:3306'...
  4. Adding Seed Instance...
  5. Adding Instance '192.168.5.170:3307'...
  6. Adding Instance '192.168.5.170:3306'...
  7. Resetting distributed recovery credentials across the cluster...
  8. 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.
  9. Cluster successfully created based on existing replication group.
复制代码
查看下状态
  1. shell> c.status()
  2. {
  3.   "clusterName": "mgr",
  4.   "defaultReplicaSet": {
  5.      "name": "default",
  6.      "primary": "192.168.5.170:3306",
  7.      "ssl": "DISABLED",
  8.      "status": "OK_NO_TOLERANCE",
  9.      "statusText": "Cluster is NOT tolerant to any failures.",
  10.      "topology": {
  11.         "192.168.5.170:3306": {
  12.           "address": "192.168.5.170:3306",
  13.           "memberRole": "PRIMARY",
  14.           "mode": "R/W",
  15.           "readReplicas": {},
  16.           "replicationLag": null,
  17.           "role": "HA",
  18.           "status": "ONLINE",
  19.           "version": "8.0.32"
  20.         },
  21.         "192.168.5.170:3307": {
  22.           "address": "192.168.5.170:3307",
  23.           "memberRole": "SECONDARY",
  24.           "mode": "R/O",
  25.           "readReplicas": {},
  26.           "replicationLag": null,
  27.           "role": "HA",
  28.           "status": "ONLINE",
  29.           "version": "8.0.32"
  30.         }
  31.      },
  32.      "topologyMode": "Single-Primary"
  33.   },
  34.   "groupInformationSourceMember": "192.168.5.170:3306"
  35. }
复制代码
连接ARBITRATOR节点,启动MGR进程

连接 ARBITRATOR 节点,并执行 start group_replication 启动MGR进程,此时能看到各节点状态工作正常:
  1. greatsql> select * from performance_schema.replication_group_members;
  2. +---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
  3. | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
  4. +---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
  5. | group_replication_applier | 04b57be0-73a0-11ee-a450-00155d064000 | 192.168.5.170 |        3307 | ONLINE       | SECONDARY   | 8.0.32         | XCom                       |
  6. | group_replication_applier | 0b157081-73a7-11ee-899b-00155d064000 | 192.168.5.170 |        3308 | ONLINE       | ARBITRATOR  | 8.0.32         | XCom                       |
  7. | group_replication_applier | d4b877cf-16f0-11ee-9e98-00155d064000 | 192.168.5.170 |        3306 | ONLINE       | PRIMARY     | 8.0.32         | XCom                       |
  8. +---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
  9. 3 rows in set (0.00 sec)
复制代码
切换到 MySQL Shell 查看
  1. shell> c.status()
  2.     "clusterName": "mgr",
  3.     "defaultReplicaSet": {
  4.         "name": "default",
  5.         "primary": "192.168.5.170:3306",
  6.         "ssl": "DISABLED",
  7.         "status": "OK",
  8.         "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
  9.         "topology": {
  10.             "192.168.5.170:3306": {
  11.                 "address": "192.168.5.170:3306",
  12.                 "memberRole": "PRIMARY",
  13.                 "mode": "R/W",
  14.                 "readReplicas": {},
  15.                 "replicationLag": null,
  16.                 "role": "HA",
  17.                 "status": "ONLINE",
  18.                 "version": "8.0.32"
  19.             },
  20.             "192.168.5.170:3307": {
  21.                 "address": "192.168.5.170:3307",
  22.                 "memberRole": "SECONDARY",
  23.                 "mode": "R/O",
  24.                 "readReplicas": {},
  25.                 "replicationLag": null,
  26.                 "role": "HA",
  27.                 "status": "ONLINE",
  28.                 "version": "8.0.32"
  29.             },
  30.             "192.168.5.170:3308": {
  31.                 "address": "192.168.5.170:3308",
  32.                 "instanceErrors": [
  33.                     "WARNING: Instance is not managed by InnoDB cluster. Use cluster.rescan() to repair."
  34.                 ],
  35.                 "memberRole": "ARBITRATOR",
  36.                 "mode": "R/O",
  37.                 "readReplicas": {},
  38.                 "replicationLag": null,
  39.                 "role": "HA",
  40.                 "status": "ONLINE",
  41.                 "version": "8.0.32"
  42.             }
  43.         },
  44.         "topologyMode": "Single-Primary"
  45.     },
  46.     "groupInformationSourceMember": "192.168.5.170:3306"
  47. }
复制代码
可以看到已经能看到所有节点,包括 ARBITRATOR 节点,但是因为该节点无法对其进行读写,所以实际上 Shell 接入时的一些初始化工作还是没完全执行,所以才有上面的提示:
  1. "instanceErrors": [
  2. "WARNING: Instance is not managed by InnoDB cluster. Use cluster.rescan() to repair."
  3. ],
复制代码
不过并不影响,因为该节点只需参与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)
变通的办法有几个:

  • 第一个加入的ARBITRATOR节点,可以在加入成功后,关闭ARBITRATOR角色,然后删除所有用户数据,这时候就变成一个空实例了,再次重启后,再开启ARBITRATOR角色,不会再次 CLONE 数据。
  • 在上述第一个ARBITRATOR节点的基础上,在其关闭期间,做一次物理全备,然后这个备份就可以作为未来新的ARBITRATOR节点的datadir,再次加入MGR集群也不会再次 CLONE 数据。
实际上,在加入 MGR 时,判断是否需要 CLONE 数据的依据是看 gtid_purged ,因此还有第三个办法:

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

Enjoy GreatSQL
来源:https://www.cnblogs.com/greatsql/p/17866643.html
免责声明:由于采集信息均来自互联网,如果侵犯了您的权益,请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容,谢谢合作!

举报 回复 使用道具