4、此时我们使用rs.addInstance命令加入第2个节点，并使用rs.status查看状态。
这里需要注意，加入第二个节点的时候，有一个数据同步的过程，这个数据同步有2中策略：
策略一：全量恢复
使用MySQL Clone组件，然后使用克隆快照来覆盖新实例上面的所有数据。这种方法非常适合空白实例加入到Innodb 副本集中。
策略二：增量恢复
它依赖MySQL的复制功能，将所有的丢失的事务复制到新实例上，如果新实例上的事务很少，则这个过程会很快。这个方法需要保证集群中至少存在一个实例，它保存了这些缺失事务的binlog，如果缺失的事务的binlog已经清理，则这个方法不能使用。
当一个实例加入一个集群的时候，MySQL Shell会自动尝试挑选一个合适的策略来同步数据，不需要人为干预，如果它无法安全的选择同步方法，则会提供给DBA一个选项，让你选择是通过Clone或者增量同步的方法来实现数据同步。
下面的例子中，就是通过自动选择增量同步的方法来同步数据的：
MySQL 192.168.1.10:5607 ssl JS > rs.addInstance("192.168.1.20:5607")
WARNING: Concurrent execution of ReplicaSet operations is not supported because the required MySQL lock service UDFs could not be installed on instance '10.41.28.127:5607'.
Make sure the MySQL lock service plugin is available on all instances if you want to be able to execute some operations at the same time. The operation will continue without concurrent execution support.
Adding instance to the replicaset...
* Performing validation checks
This instance reports its own address as 192.168.1.20:5607
192.168.1.20:5607: Instance configuration is suitable.
* Checking async replication topology...
* Checking transaction state of the instance...
The safest and most convenient way to provision a new instance is through automatic clone provisioning, which will completely overwrite the state of '192.168.1.20:5607' with a physical snapshot from an existing replicaset member. To use this method by default, set the 'recoveryMethod' option to 'clone'.
WARNING: It should be safe to rely on replication to incrementally recover the state of the new instance if you are sure all updates ever executed in the replicaset were done with GTIDs enabled, there are no purged transactions and the new instance contains the same GTID set as the replicaset or a subset of it. To use this method by default, set the 'recoveryMethod' option to 'incremental'.
Incremental state recovery was selected because it seems to be safely usable.
* Updating topology
** Configuring 192.168.1.20:5607 to replicate from 192.168.1.10:5607
** Waiting for new instance to synchronize with PRIMARY...
The instance '192.168.1.20:5607' was added to the replicaset and is replicating from 192.168.1.20:5607.
MySQL 192.168.1.10:5607 ssl JS >
MySQL 192.168.1.10:5607 ssl JS > rs.status()
{
"replicaSet": {
"name": "yeyz_test",
"primary": "192.168.1.10:5607",
"status": "AVAILABLE",
"statusText": "All instances available.",
"topology": {
"192.168.1.10:5607": {
"address": "192.168.1.10:5607",
"instanceRole": "PRIMARY",
"mode": "R/W",
"status": "ONLINE"
},
"192.168.1.20:5607": {
"address": "192.168.1.20:5607",
"instanceRole": "SECONDARY",
"mode": "R/O",
"replication": {
"applierStatus": "APPLIED_ALL",
"applierThreadState": "Slave has read all relay log; waiting for more updates",
"receiverStatus": "ON",
"receiverThreadState": "Waiting for master to send event",
"replicationLag": null
},
"status": "ONLINE"
}
},
"type": "ASYNC"
}
}
加入第二个节点之后，可以看到，再次使用rs.status来查看副本集的结构，可以看到Secondary节点已经出现了，就是我们新加入的192.168.1.20：5607
当然我们可以分别使用下面的命令查看更详细的输出：
rs.status({extended:0})
rs.status({extended:1})
rs.status({extended:2})
不同的级别，显示的信息有所不同，等级越高，信息约详细。
这里不得不说一个小的bug，官方文档建议写法是：
ReplicaSet.status(extended=1)
原文如下：
The output of ReplicaSet.status(extended=1) is very similar to Cluster.status(extended=1), but the main difference is that the replication field is always available because InnoDB ReplicaSet relies on MySQL Replication all of the time, unlike InnoDB Cluster which uses it during incremental recovery. For more information on the fields, see Checking a cluster's Status with Cluster.status().
但是实际操作过程中，这种写法会报错，如下：
MySQL 192.168.1.10:5607 ssl JS > sh.status(extended=1) You are connected to a member of replicaset 'yeyz_test'. ReplicaSet.status: Argument #1 is expected to be a map (ArgumentError)
不知道算不算一个bug。
5.搭建好副本集之后，查看primary节点的元信息库表，并在primary写入数据，查看数据是否可以同步。
[(none)] 17:41:10>show databases; +-------------------------------+ | Database | +-------------------------------+ | information_schema | | mysql | | mysql_innodb_cluster_metadata | | performance_schema | | sys | | zjmdmm | +-------------------------------+ 6 rows in set (0.01 sec) [(none)] 17:41:29>use mysql_innodb_cluster_metadata Database changed [mysql_innodb_cluster_metadata] 17:45:12>show tables; +-----------------------------------------+ | Tables_in_mysql_innodb_cluster_metadata | +-----------------------------------------+ | async_cluster_members | | async_cluster_views | | clusters | | instances | | router_rest_accounts | | routers | | schema_version | | v2_ar_clusters | | v2_ar_members | | v2_clusters | | v2_gr_clusters | | v2_instances | | v2_router_rest_accounts | | v2_routers | | v2_this_instance | +-----------------------------------------+ 15 rows in set (0.00 sec) [mysql_innodb_cluster_metadata] 17:45:45>select * from routers; Empty set (0.00 sec) [(none)] 17:45:52>create database yeyazhou; Query OK, 1 row affected (0.00 sec)
可以看到，Primary节点上有一个元信息数据库mysql_innodb_cluster_metadata，里面保存了一些原信息，我们查看了router表，发现里面没有数据，原因是我们没有配置MySQL Router。后面的文章中会写到MySQL Router的配置过程。
在Primary上创建一个数据库yeyazhou，可以发现，在从库上也已经出现了对应的DB，
192.168.1.20 [(none)] 17:41:41>show databases; +-------------------------------+ | Database | +-------------------------------+ | information_schema | | mysql | | mysql_innodb_cluster_metadata | | performance_schema | | sys | | yeyazhou | | zjmdmm | +-------------------------------+ 7 rows in set (0.00 sec)
说明副本集的复制关系无误。
至此，整个MySQL Shell连接MySQL实例并创建ReplicatSet的过程搭建完毕。
下一篇文章讲述MySQL Router的搭建过程，以及如何使用MySQL Router来访问底层的数据库。
以上就是MySQL Shell的介绍以及安装的详细内容，更多关于MySQL Shell的资料请关注其它相关文章！
更多相关Mysql内容来自木庄网络博客
标签：Mysql
相关阅读 >>
更多相关阅读请进入《mysql》频道 >>
数据库系统概念 第6版
本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。
