自打上期开始了关于innodb cluster的安装文字后,感觉突然就一股innodb cluster 的风扑面而来,新技术的掌握看来是热情很高。
今天这期其实是开始对一些细节进行盘点,先对周边的命令进行一次盘点,然后,总结一下在安装中的一些配置参数,以及相关的信息的存储位置
1 获取当前的 innodb cluster的状态, 在通过 connect 连接到 innodb cluster中的一台机器后,我们通过 getCluster() 命令来获得集群的信息,然后在通过信息中的指定的命令进行信息的展现
var cluster_1 = dba.getCluster()
cluster_1.describe()
cluster_1.status()
在传统的MYSQL 中我们通过performace_schema replication_group_members 来查看系统的集群状态,但现在我们可以通过 status() 来更快的查看集群的状态,图中可以很清晰的看到 mgr3 已经处于 missing的状态。
这样的操作方式和展现方式让人有点像在操作MONGODB 的感觉。
实际上 cluster_1.status({'extended':3}) 通过获取 status 可以获得更多的信息
实际上通过二次开发,在此判断节点间的数据复制的延迟,已经有了更好的方法。
2 关于clone时的状态,这个是比较好的一个状态显示,从一个主库clone到一个从库,那到底这个状态拷贝了多少,还差多少,对操作人员是有意义的
例如官方文档中提到的在clone中 currentStageProcess 可以显示当前的clone的状态是什么百分比是多少。从中可以感受到MYSQL 8 对于集成性和人性化的改变。
———————————————————————————————
重新整理安装,这次并不是从三台单机开始,此次是从一个已经组建好的集群开始。
1 解散集群
首先确认集群的状态
var cluster_v = dba.getCluster()
cluster_v.status()
2 cluster_v.dissolve()
然后通过手动的确认,集群就直接解散了。
然后在每个集群中运行dba.dropMetadataSchema()
否则后续会产生遗留信息还存在无法建立集群的问题
3 开始搭建集群,确认每个节点的当前是否可以具备搭建集群的状态
在每台机器中都要运行,检测相关的状态,这里截图是OK 的状态,如果不OK,需要通过他的报错信息对你的MYSQL 进行调整。
4 创建新的集群,并在此添加相关的权重,以及白名单信息
5 开始加入其他节点
实际上上面的添加集群的命令可以总结为4条
dba.createCluster('repl', {memberWeight:80,ipWhitelist: "192.168.198.0/24"})
var cluster_v = dba.getCluster()
cluster_v.addInstance('admin:1234.com@192.168.198.101:3306', {memberWeight:60})
cluster_v.addInstance('admin:1234.com@192.168.198.102:3306', {memberWeight:40})
仅仅这四条命令一个 INNODB CLUSTER 就搭建成功了,那实际上的背后做了什么。
这大大降低了安装集群的难度和复杂度,所以通过mysqsh 命令来管理 MGR 集群是大势所趋,如果要用,基本上是逃不掉的。
最后设置整体的集群的 group-replication-consistency (如果不知道什么是 group-replication-consistency 可以看我之前有一期关于这个说明)
从目前最新的8.019版本的mysql来看,集群方案基本上已经固化,并且安装的方式越来越往自动化上进行,几条命令后面其实上白条命令的集合。后续还要继续研究后台到底做了什么,出现问题怎么知道是那个层面的问题。