9.4.2 Example of Adding Instances to a ReplicaSet

To add instances to a ReplicaSet, complete the following steps:

1. Use the ReplicaSet.addInstance(instance) operation to add secondary instances to the ReplicaSet. You specify the instance as a URI-like connection string. The user you specify must have the privileges required and must be the same on all instances in the ReplicaSet. For more information, see Section 9.2, “Configuring InnoDB ReplicaSet Instances”.

   For example, to add the instance at rs-2, port number 3306, and user rsadmin, issue:

   	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. In this case, we did not specify the recovery method, so the operation advises you on how to best proceed. In this example, we choose the Clone option because we do not have any existing transactions on the instance joining the ReplicaSet. Therefore, there is no risk of deleting data from the joining instance. For more information, see Recovery Methods for 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. Assuming the instance is valid for InnoDB ReplicaSet usage, recovery proceeds. In this case, the newly joining instance uses MySQL Clone to copy all the transactions it has not yet applied from the primary, then it joins the ReplicaSet as an online instance. To verify, use the rs.status() operation:

   	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"
   		}
   	}

   This output shows that the ReplicaSet named example now consists of two MySQL instances, and that the primary is rs-1. Currently, there is one secondary instance at rs-2, which is a replica of the primary. The ReplicaSet is online, which means that the primary and secondary are in synchrony. At this point, the ReplicaSet is ready to process transactions.

4. To override the interactive MySQL Shell mode, choose the most suitable recovery method. Use the recoveryMethod option to configure how the instance recovers the data required to be able to join the ReplicaSet. For more information, see Section 7.4.6, “Using MySQL Clone with InnoDB Cluster”.