创建 ReplicaSet 后可以使用 ReplicaSet.addInstance() 操作将实例添加为 ReplicaSet 当前主副本的只读辅助副本。

在此操作期间ReplicaSet 的主副本必须可访问且可用。MySQL 复制在添加的实例和主实例之间配置使用带有随机密码的自动创建的 MySQL 帐户。在实例可以成为操作辅助实例之前它必须与主实例处于同步安排中。此过程称为 恢复InnoDB ReplicaSet 支持使用 recoveryMethod 选项配置的不同方法。

要使实例能够加入 ReplicaSet 必须满足各种先决条件。ReplicaSet.addInstance() 会自动检查它们如果发现任何问题操作将失败。

在添加实例之前使用 dba.configureReplicaSetInstance() 验证和配置二进制日志和复制相关选项。M ySQL Shell 使用用于获取 ReplicaSet 句柄对象的相同用户名和密码连接到目标实例。ReplicaSet 的所有实例都应具有相同的管理员帐户并具有相同的权限和密码。使用 dba.configureReplicaSetInstance() 选项配置实例时可以使用所需的权限创建自定义管理员帐户。参见第 9.2 节 “配置 InnoDB ReplicaSet 实例”。

9.4.1 为 InnoDB ReplicaSet 配置实例

向 InnoDB ReplicaSet 添加新实例时需要使用 ReplicaSet 包含的现有数据来配置实例。您可以使用以下方法之一自动执行此配置

• MySQL Clone 从联机实例获取快照然后用快照替换新实例上的任何数据。MySQL Clone 非常适合将新的空白实例加入 InnoDB ReplicaSet。MySQL Clone 不依赖于 InnoDB ReplicaSet 应用的所有事务的完整二进制日志。

  警告
  添加实例时MySQL Clone 操作会销毁实例的所有先前数据。

• 增量恢复依靠 MySQL 复制在新实例上应用所有丢失的事务。如果新实例上只缺少几个事务增量恢复是最快的方法。但是只有在 InnoDB ReplicaSet 的至少一个联机实例具有完整的二进制日志其中包含 InnoDB ReplicaSet 的整个事务历史时才能使用此方法。

  以下情况不能使用此方法

  • 如果已清除所有成员的二进制日志。
  • 如果在实例中已存在数据库之后启用二进制日志。

  如果您有许多事务要应用那么在实例加入 InnoDB ReplicaSet 之前可能会有相当长的延迟。

当实例加入 ReplicaSet 时恢复的使用方式与 InnoDB Cluster 中的恢复方式大致相同。MySQL Shell 尝试自动选择合适的恢复方法。如果无法安全地选择方法MySQLShell 会提示使用什么。有关更多信息请参阅 第 7.4.6 节 “将 MySQL 克隆与 InnoDB 集群一起使用” 。本节介绍向 ReplicaSet 添加实例时的差异。

9.4.2 向副本集添加实例的示例

要将实例添加到 ReplicaSet 请完成以下步骤

1. 使用 ReplicaSet.addInstance(instance) 操作将辅助实例添加到 ReplicaSet。 将实例指定为类似 URI 的连接字符串。您指定的用户必须具有所需的权限并且在 ReplicaSet 中的所有实例上必须相同。有关更多信息请参阅 第 9.2 节“配置 InnoDB ReplicaSet 实例”) 。

   例如要在 rs-2 、 端口号 3306 和用户 rsadmin 处添加实例请执行

   mysql-js> rs.addInstance('rsadmin@rs-2:3306')
   
   Adding instance to the replicaset...
   
   * Performing validation checks
   
   This instance reports its own address as rsadmin@rs-2
   rsadmin@rs-2: Instance configuration is suitable.
   
   * Checking async replication topology...
   
   * Checking transaction state of the instance...
   
   NOTE: The target instance 'rsadmin@rs-2' has not been pre-provisioned (GTID set
   is empty). The Shell is unable to decide whether replication can completely
   recover its state.  The safest and most convenient way to provision a new
   instance is through automatic clone provisioning, which will completely
   overwrite the state of 'rsadmin@rs-2' 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 processed 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'.
   Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone):
   

2. 在这种情况下我们没有指定恢复方法因此操作会建议您如何最好地继续。在本例中我们选择 Clone 选项因为在加入 ReplicaSet 的实例上没有任何现有事务。因此不存在从联接实例中删除数据的风险。有关更多信息请参阅 InnoDB ReplicaSet 的恢复方法 。

   Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone): C
   * Updating topology
   Waiting for clone process of the new member to complete. Press ^C to abort the operation.
   * Waiting for clone to finish...
   NOTE: rsadmin@rs-2 is being cloned from rsadmin@rs-1
   ** Stage DROP DATA: Completed
   ** Clone Transfer
   FILE COPY  ############################################################  100%  Completed
   PAGE COPY  ############################################################  100%  Completed
   REDO COPY  ############################################################  100%  Completed
   ** Stage RECOVERY: \
   NOTE: rsadmin@rs-2 is shutting down...
   
   * Waiting for server restart... ready
   * rsadmin@rs-2 has restarted, waiting for clone to finish...
   * Clone process has finished: 59.63 MB transferred in about 1 second (~1.00 B/s)
   
   ** Configuring rsadmin@rs-2 to replicate from rsadmin@rs-1
   ** Waiting for new instance to synchronize with PRIMARY...
   
   The instance 'rsadmin@rs-2' was added to the replicaset and is replicating from rsadmin@rs-1.
   

3. 假设该实例对 InnoDB ReplicaSet 的使用有效则恢复继续。在这种情况下新加入的实例使用MySQLClone 从主实例复制尚未应用的所有事务然后作为联机实例加入 ReplicaSet 。要验证请使用 rs.status() 操作

   	mysql-js> rs.status()
   {
   	"replicaSet": {
   		"name": "example",
   		"primary": "rs-1:3306",
   		"status": "AVAILABLE",
   		"statusText": "All instances available.",
   		"topology": {
   			"rs-1:3306": {
   				"address": "rs-1:3306",
   				"instanceRole": "PRIMARY",
   				"mode": "R/W",
   				"status": "ONLINE"
   			},
   			"rs-2:3306": {
   				"address": "rs-2:3306",
   				"instanceRole": "SECONDARY",
   				"mode": "R/O",
   				"replication": {
   					"applierStatus": "APPLIED_ALL",
   					"applierThreadState": "Replica has read all relay log; waiting for more updates",
   					"receiverStatus": "ON",
   					"receiverThreadState": "Waiting for source to send event",
   					"replicationLag": null
   				},
   				"status": "ONLINE"
   			}
   		},
   		"type": "ASYNC"
   	}
   }
   

   此输出显示名为 example 的 ReplicaSet 现在由两个 MySQL 实例组成主要实例是 rs-1 。目前rs-2 上有一个辅助实例它是主实例的副本。ReplicaSet 处于联机状态这意味着主副本和辅助副本处于同步状态。此时ReplicaSet已准备好处理事务。

4. 要覆盖交互式 MySQL Shell 模式请选择最合适的恢复方法。使用 recoveryMethod 选项配置实例如何恢复加入 ReplicaSet 所需的数据。有关更多信息请参阅 第 7.4.6 节 “将 MySQL 克隆与InnoDB 集群一起使用” 。