自打上期开始了关于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来看，集群方案基本上已经固化，并且安装的方式越来越往自动化上进行，几条命令后面其实上白条命令的集合。后续还要继续研究后台到底做了什么，出现问题怎么知道是那个层面的问题。
