Setting Up Binary Log File Position Based Replication -> SOURCE_PASSWORD=’ replication_password ’, -> SOURCE_LOG_FILE=’ recorded_log_file_name ’, -> SOURCE_LOG_POS= recorded_log_position ; Note Replication cannot use Unix socket files. You must be able to connect to the source MySQL server using TCP/IP. The  CHANGE REPLICATION SOURCE TO  |  CHANGE MASTER TO  statement has other options as well. For example, it is possible to set up secure replication using SSL. For a full list of options, and information about the maximum permissible length for the string-valued options, see Section 13.4.2.1, “CHANGE MASTER TO Statement” . Important As noted in Section 17.1.2.3, “Creating a User for Replication” , if you are not using a secure connection and the user account named in the  SOURCE_USER  | MASTER_USER  option authenticates with the  caching_sha2_password  plugin (the default from MySQL 8.0), you must specify the  SOURCE_PUBLIC_KEY_PATH |  MASTER_PUBLIC_KEY_PATH  or  GET_SOURCE_PUBLIC_KEY  | GET_MASTER_PUBLIC_KEY  option in the  CHANGE REPLICATION SOURCE TO  |  CHANGE MASTER TO  statement to enable RSA key pair-based password exchange. 17.1.2.8 Adding Replicas to a Replication Environment You can add another replica to an existing replication configuration without stopping the source server. To do this, you can set up the new replica by copying the data directory of an existing replica, and giving the new replica a different server ID (which is user-specified) and server UUID (which is generated at startup). Note If the replication source server or existing replica that you are copying to create the new replica has any scheduled events, ensure that these are disabled on the new replica before you start it. If an event runs on the new replica that has already run on the source, the duplicated operation causes an error. The Event Scheduler is controlled by the  event_scheduler  system variable, which defaults to  ON  from MySQL 8.0, so events that are active on the original server run by default when the new replica starts up. To stop all events from running on the new replica, set the  event_scheduler  system variable to  OFF  or  DISABLED  on the new replica. Alternatively, you can use the  ALTER EVENT  statement to set individual events to DISABLE  or  DISABLE ON SLAVE  to prevent them from running on the new replica. You can list the events on a server using the  SHOW  statement or the Information Schema  EVENTS  table. For more information, see Section 17.5.1.16, “Replication of Invoked Features” . As an alternative to creating a new replica in this way, MySQL Server’s clone plugin can be used to transfer all the data and replication settings from an existing replica to a clone. For instructions to use this method, see Section 5.6.7.6, “Cloning for Replication” . To duplicate an existing replica without cloning, follow these steps: 1. Stop the existing replica and record the replica status information, particularly the source binary log file and relay log file positions. You can view the replica status either in the Performance Schema replication tables (see Section 27.12.11, “Performance Schema Replication Tables” ), or by issuing SHOW REPLICA | SLAVE STATUS  as follows: 3448