# Setting up binary log replication for Aurora MySQL Setting up MySQL replication with Aurora MySQL involves the following steps, which are discussed in detail: **Contents** + [1. Turn on binary logging on the replication source](#AuroraMySQL.Replication.MySQL.EnableBinlog) + [2. Retain binary logs on the replication source until no longer needed](#AuroraMySQL.Replication.MySQL.RetainBinlogs) + [3. Create a copy or dump of your replication source](#AuroraMySQL.Replication.MySQL.CreateSnapshot) + [4. Load the dump into your replica target (if needed)](#AuroraMySQL.Replication.MySQL.LoadSnapshot) + [5. Create a replication user on your replication source](#AuroraMySQL.Replication.MySQL.CreateReplUser) + [6. Turn on replication on your replica target](#AuroraMySQL.Replication.MySQL.EnableReplication) + [Setting a location to stop replication to a read replica](#AuroraMySQL.Replication.StartReplicationUntil) + [7. Monitor your replica](#AuroraMySQL.Replication.MySQL.Monitor) + [Synchronizing passwords between replication source and target](#AuroraMySQL.Replication.passwords) ## 1. Turn on binary logging on the replication source Find instructions on how to turn on binary logging on the replication source for your database engine following. | Database engine | Instructions | | --- | --- | | Aurora MySQL | **To turn on binary logging on an Aurora MySQL DB cluster**
Set the `binlog_format` DB cluster parameter to `ROW`, `STATEMENT`, or `MIXED`. `MIXED` is recommended unless you have a need for a specific binlog format. (The default value is `OFF`.)
To change the `binlog_format` parameter, create a custom DB cluster parameter group and associate that custom parameter group with your DB cluster. You can't change parameters in the default DB cluster parameter group.
If you're changing the `binlog_format` parameter from `OFF` to another value, reboot your Aurora DB cluster for the change to take effect.
For more information, see [Amazon Aurora DB cluster and DB instance parameters](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups) and [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md). | | RDS for MySQL | **To turn on binary logging on an Amazon RDS DB instance**
You can't turn on binary logging directly for an Amazon RDS DB instance, but you can turn it on by doing one of the following: + Turn on automated backups for the DB instance. You can turn on automated backups when you create a DB instance, or you can turn on backups by modifying an existing DB instance. For more information, see [Creating a DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html) in the *Amazon RDS User Guide*.
+ Create a read replica for the DB instance. For more information, see [Working with read replicas](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) in the *Amazon RDS User Guide*. | | MySQL (external) | **To set up encrypted replication**
To replicate data securely with Aurora MySQL version 2, you can use encrypted replication. If you don't need to use encrypted replication, you can skip these steps.
The following are prerequisites for using encrypted replication: + Secure Sockets Layer (SSL) must be enabled on the external MySQL source database.
+ A client key and client certificate must be prepared for the Aurora MySQL DB cluster.
During encrypted replication, the Aurora MySQL DB cluster acts a client to the MySQL database server. The certificates and keys for the Aurora MySQL client are in files in .pem format. 1. Ensure that you are prepared for encrypted replication: If you don't have SSL enabled on the external MySQL source database and don't have a client key and client certificate prepared, turn on SSL on the MySQL database server and generate the required client key and client certificate. If SSL is enabled on the external source, supply a client key and certificate for the Aurora MySQL DB cluster. If you don't have these, generate a new key and certificate for the Aurora MySQL DB cluster. To sign the client certificate, you must have the certificate authority key that you used to configure SSL on the external MySQL source database.
For more information, see [ Creating SSL certificates and keys using openssl](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html) in the MySQL documentation.
You need the certificate authority certificate, the client key, and the client certificate.
2. Connect to the Aurora MySQL DB cluster as the master user using SSL.
For information about connecting to an Aurora MySQL DB cluster with SSL, see [TLS connections to Aurora MySQL DB clusters](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL).
3. Run the `mysql.rds_import_binlog_ssl_material` stored procedure to import the SSL information into the Aurora MySQL DB cluster.
For the `ssl_material_value` parameter, insert the information from the .pem format files for the Aurora MySQL DB cluster in the correct JSON payload.
The following example imports SSL information into an Aurora MySQL DB cluster. In .pem format files, the body code typically is longer than the body code shown in the example. 
call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');

For more information, see [mysql.rds\_import\_binlog\_ssl\_material](mysql-stored-proc-replicating.md#mysql_rds_import_binlog_ssl_material) and [TLS connections to Aurora MySQL DB clusters](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL). After running the procedure, the secrets are stored in files. To erase the files later, you can run the [mysql.rds\_remove\_binlog\_ssl\_material](mysql-stored-proc-replicating.md#mysql_rds_remove_binlog_ssl_material) stored procedure.
**To turn on binary logging on an external MySQL database** 1. From a command shell, stop the mysql service. 
sudo service mysqld stop

2. Edit the `my.cnf` file (this file is usually under `/etc`). 
sudo vi /etc/my.cnf

Add the `log_bin` and `server_id` options to the `[mysqld]` section. The `log_bin` option provides a file name identifier for binary log files. The `server_id` option provides a unique identifier for the server in source-replica relationships.
If encrypted replication isn't required, ensure that the external MySQL database is started with binlogs enabled and SSL is turned off.
The following are the relevant entries in the `/etc/my.cnf` file for unencrypted data. 
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
sync_binlog=1

If encrypted replication is required, ensure that the external MySQL database is started with SSL and binlogs enabled.
The entries in the `/etc/my.cnf` file include the .pem file locations for the MySQL database server. 
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
sync_binlog=1

# Setup SSL.
ssl-ca=/home/sslcerts/ca.pem
ssl-cert=/home/sslcerts/server-cert.pem
ssl-key=/home/sslcerts/server-key.pem

Additionally, the `sql_mode` option for your MySQL DB instance must be set to 0, or must not be included in your my.cnf file.
While connected to the external MySQL database, record the external MySQL database's binary log position. 
mysql> SHOW MASTER STATUS;

Your output should be similar to the following: 
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000031 |      107 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

For more information, see [Setting the replication source configuration](http://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html) in the MySQL documentation.
3. Start the mysql service. 
sudo service mysqld start
| ## 2. Retain binary logs on the replication source until no longer needed When you use MySQL binary log replication, Amazon RDS doesn't manage the replication process. As a result, you need to ensure that the binlog files on your replication source are retained until after the changes have been applied to the replica. This maintenance helps you to restore your source database in the event of a failure. Use the following instructions to retain binary logs for your database engine. | Database engine | Instructions | | --- | --- | | Aurora MySQL | **To retain binary logs on an Aurora MySQL DB cluster**
You don't have access to the binlog files for an Aurora MySQL DB cluster. As a result, you must choose a time frame to retain the binlog files on your replication source long enough to ensure that the changes have been applied to your replica before the binlog file is deleted by Amazon RDS. You can retain binlog files on an Aurora MySQL DB cluster for up to 90 days.
If you're setting up replication with a MySQL database or RDS for MySQL DB instance as the replica, and the database that you are creating a replica for is very large, choose a large time frame to retain binlog files until the initial copy of the database to the replica is complete and the replica lag has reached 0.
To set the binary log retention time frame, use the [mysql.rds\_set\_configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) procedure and specify a configuration parameter of `'binlog retention hours'` along with the number of hours to retain binlog files on the DB cluster. The maximum value for Aurora MySQL version 2.11.0 and higher and version 3 is 2160 (90 days).
The following example sets the retention period for binlog files to 6 days:
CALL mysql.rds_set_configuration('binlog retention hours', 144);

After replication has been started, you can verify that changes have been applied to your replica by running the `SHOW SLAVE STATUS` (Aurora MySQL version 2) or `SHOW REPLICA STATUS` (Aurora MySQL version 3) command on your replica and checking the `Seconds behind master` field. If the `Seconds behind master` field is 0, then there is no replica lag. When there is no replica lag, reduce the length of time that binlog files are retained by setting the `binlog retention hours` configuration parameter to a smaller time frame.
If this setting isn't specified, the default for Aurora MySQL is 24 (1 day).
If you specify a value for `'binlog retention hours'` that is higher than the maximum value, then Aurora MySQL uses the maximum. | | RDS for MySQL | **To retain binary logs on an Amazon RDS DB instance**
You can retain binary log files on an Amazon RDS DB instance by setting the binlog retention hours just as with an Aurora MySQL DB cluster, described in the previous row.
You can also retain binlog files on an Amazon RDS DB instance by creating a read replica for the DB instance. This read replica is temporary and solely for the purpose of retaining binlog files. After the read replica has been created, call the [mysql.rds\_stop\_replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) procedure on the read replica. While replication is stopped, Amazon RDS doesn't delete any of the binlog files on the replication source. After you have set up replication with your permanent replica, you can delete the read replica when the replica lag (`Seconds behind master` field) between your replication source and your permanent replica reaches 0. | | MySQL (external) | **To retain binary logs on an external MySQL database**
Because binlog files on an external MySQL database are not managed by Amazon RDS, they are retained until you delete them.
After replication has been started, you can verify that changes have been applied to your replica by running the `SHOW SLAVE STATUS` (Aurora MySQL version 2) or `SHOW REPLICA STATUS` (Aurora MySQL version 3) command on your replica and checking the `Seconds behind master` field. If the `Seconds behind master` field is 0, then there is no replica lag. When there is no replica lag, you can delete old binlog files. | ## 3. Create a copy or dump of your replication source You use a snapshot, clone, or dump of your replication source to load a baseline copy of your data onto your replica. Then you start replicating from that point. Use the following instructions to create a copy or dump of the replication source for your database engine. | Database engine | Instructions | | --- | --- | | Aurora MySQL | **To create a copy of an Aurora MySQL DB cluster**
Use one of the following methods:+ Restore from a DB cluster snapshot: Create a DB cluster snapshot of your Amazon Aurora DB cluster. For more information, see [Creating a DB cluster snapshot](USER_CreateSnapshotCluster.md). Create a new Aurora DB cluster by restoring from the DB cluster snapshot that you just created.
Be sure to retain the same DB parameter group for your restored DB cluster as your original DB cluster. Doing this ensures that the copy of your DB cluster has binary logging enabled. For more information, see [Restoring from a DB cluster snapshot](aurora-restore-snapshot.md).
+ Clone your DB cluster. For more information, see [Cloning a volume for an Amazon Aurora DB cluster](Aurora.Managing.Clone.md).
**To determine the binlog file name and position**
Use one of the following methods:+ In the AWS Management Console: Choose **Databases**, then choose the primary instance (writer) for your new Aurora DB cluster to show its details. Scroll to **Recent Events**. An event message shows that includes the binlog file name and position. The event message is in the following format. 
Binlog position from crash recovery is {{binlog-file-name}} {{binlog-position}}
Save the binlog file name and position values for when you start replication.
+ Call the [describe-events](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-events.html) AWS CLI command, as in the following example. 
aws rds describe-events

{
    "Events": [
        {
            "EventCategories": [],
            "SourceType": "db-instance",
            "SourceArn": "arn:aws:rds:us-west-2:123456789012:db:sample-restored-instance",
            "Date": "2016-10-28T19:43:46.862Z",
            "Message": "Binlog position from crash recovery is mysql-bin-changelog.000003 4278",
            "SourceIdentifier": "sample-restored-instance"
        }
    ]
}

+ Check the MySQL error log for the last MySQL binlog file position.
**To create a dump of an Aurora MySQL DB cluster**
If your replica target is an external MySQL database or an RDS for MySQL DB instance, then you must create a dump file from your Aurora DB cluster.
Be sure to run the `mysqldump` command against the copy of your source DB cluster that you created. This is to avoid locking considerations when taking the dump. If the dump were taken on the source DB cluster directly, it would be necessary to lock the source tables to prevent concurrent writes to them while the dump is in progress.1. Connect to your DB cluster using a MySQL client.
2. Issue the `mysqldump` command. For example: 
PROMPT> mysqldump --databases {{database_name}} --single-transaction
--order-by-primary -r backup.sql -u {{local_user}}s -p

3. After you create the dump file, you can delete the DB cluster copy. | | RDS for MySQL | **To create a snapshot of an Amazon RDS DB instance**
Create a read replica of your Amazon RDS DB instance. For more information, see [Creating a read replica](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create) in the *Amazon Relational Database Service User Guide*. 1. Connect to your read replica and stop replication by running the [mysql.rds\_stop\_replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) procedure.
2. While the read replica is **Stopped**, Connect to the read replica and run the `SHOW SLAVE STATUS` (Aurora MySQL version 2) or `SHOW REPLICA STATUS` (Aurora MySQL version 3) command. Retrieve the current binary log file name from the `Relay_Master_Log_File` field and the log file position from the `Exec_Master_Log_Pos` field. Save these values for when you start replication.
3. While the read replica remains **Stopped**, create a DB snapshot of the read replica. For more information, see [Creating a DB snapshot](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html) in the *Amazon Relational Database Service User Guide*.
4. Delete the read replica. | | MySQL (external) | **To create a dump of an external MySQL database**1. Before you create a dump, you need to ensure that the binlog location for the dump is current with the data in your source instance. To do this, you must first stop any write operations to the instance with the following command: 
mysql> FLUSH TABLES WITH READ LOCK;

2. Create a dump of your MySQL database using the `mysqldump` command as shown following: 
PROMPT> sudo mysqldump --databases {{database_name}} --master-data=2  --single-transaction \
--order-by-primary -r backup.sql -u {{local_user}} -p

3. After you have created the dump, unlock the tables in your MySQL database with the following command: 
mysql> UNLOCK TABLES;
| ## 4. Load the dump into your replica target (if needed) If you plan to load data from a dump of a MySQL database that is external to Amazon RDS, you might want to create an EC2 instance to copy the dump files to. Then you can load the data into your DB cluster or DB instance from that EC2 instance. Using this approach, you can compress the dump file(s) before copying them to the EC2 instance in order to reduce the network costs associated with copying data to Amazon RDS. You can also encrypt the dump file or files to secure the data as it is being transferred across the network. **Note** If you create a new Aurora MySQL DB cluster as your replica target, then you don't need to load a dump file: You can restore from a DB cluster snapshot to create a new DB cluster. For more information, see [Restoring from a DB cluster snapshot](aurora-restore-snapshot.md). You can clone your source DB cluster to create a new DB cluster. For more information, see [Cloning a volume for an Amazon Aurora DB cluster](Aurora.Managing.Clone.md). You can migrate the data from a DB instance snapshot into a new DB cluster. For more information, see [Migrating data to an Amazon Aurora MySQL DB cluster](AuroraMySQL.Migrating.md). Use the following instructions to load the dump of your replication source into your replica target for your database engine. | Database engine | Instructions | | --- | --- | | Aurora MySQL | **To load a dump into an Aurora MySQL DB cluster** 1. Copy the output of the `mysqldump` command from your replication source to a location that can also connect to your Aurora MySQL DB cluster.
2. Connect to your Aurora MySQL DB cluster using the `mysql` command. The following is an example. 
PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p

3. At the `mysql` prompt, run the `source` command and pass it the name of your database dump file to load the data into the Aurora MySQL DB cluster, for example: 
mysql> source backup.sql;
| | RDS for MySQL | **To load a dump into an Amazon RDS DB instance**1. Copy the output of the `mysqldump` command from your replication source to a location that can also connect to your MySQL DB instance.
2. Connect to your MySQL DB instance using the `mysql` command. The following is an example. 
PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p

3. At the `mysql` prompt, run the `source` command and pass it the name of your database dump file to load the data into the MySQL DB instance, for example: 
mysql> source backup.sql;
| | MySQL (external) | **To load a dump into an external MySQL database**
You can't load a DB snapshot or a DB cluster snapshot into an external MySQL database. Instead, you must use the output from the `mysqldump` command.1. Copy the output of the `mysqldump` command from your replication source to a location that can also connect to your MySQL database.
2. Connect to your MySQL database using the `mysql` command. The following is an example. 
PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p

3. At the `mysql` prompt, run the `source` command and pass it the name of your database dump file to load the data into your MySQL database. The following is an example. 
mysql> source backup.sql;
| ## 5. Create a replication user on your replication source Create a user ID on the source that is used solely for replication. The following example is for RDS for MySQL or external MySQL source databases. ``` mysql> CREATE USER '{{repl_user}}'@'{{domain_name}}' IDENTIFIED BY '{{password}}'; ``` For Aurora MySQL source databases, the `skip_name_resolve` DB cluster parameter is set to `1` (`ON`) and can't be modified, so you must use an IP address for the host instead of a domain name. For more information, see [skip\_name\_resolve](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_skip_name_resolve) in the MySQL documentation. ``` mysql> CREATE USER '{{repl_user}}'@'{{IP_address}}' IDENTIFIED BY '{{password}}'; ``` The user requires the `REPLICATION CLIENT` and `REPLICATION SLAVE` privileges. Grant these privileges to the user. If you need to use encrypted replication, require SSL connections for the replication user. For example, you can use one of the following statements to require SSL connections on the user account `repl_user`. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO '{{repl_user}}'@'{{IP_address}}'; ``` ``` GRANT USAGE ON *.* TO '{{repl_user}}'@'{{IP_address}}' REQUIRE SSL; ``` **Note** If `REQUIRE SSL` isn't included, the replication connection might silently fall back to an unencrypted connection. ## 6. Turn on replication on your replica target Before you turn on replication, we recommend that you take a manual snapshot of the Aurora MySQL DB cluster or RDS for MySQL DB instance replica target. If a problem arises and you need to re-establish replication with the DB cluster or DB instance replica target, you can restore the DB cluster or DB instance from this snapshot instead of having to import the data into your replica target again. Use the following instructions to turn on replication for your database engine. | Database engine | Instructions | | --- | --- | | Aurora MySQL | **To turn on replication from an Aurora MySQL DB cluster** 1. Find the starting place for replication. You need the binlog file name and binlog position.
If your DB cluster replica target was created from the following: DB cluster snapshot or clone – Retrieve the binlog file name and position from the recent events for your new DB cluster, as shown in [3. Create a copy or dump of your replication source](#AuroraMySQL.Replication.MySQL.CreateSnapshot). DB snapshot – You retrieved the binlog file name and position from the `SHOW SLAVE STATUS` (Aurora MySQL version 2) or `SHOW REPLICA STATUS` (Aurora MySQL version 3) command when you created the snapshot of your replication source.
2. Connect to the DB cluster and call the following procedures to start replication with your replication source using the binary log file name and location from the previous step: [mysql.rds\_set\_external\_source (Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) [mysql.rds\_set\_external\_master (Aurora MySQL version 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) [mysql.rds\_start\_replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) (all versions)
The following example is for Aurora MySQL version 3. 
CALL mysql.rds_set_external_source ('mydbinstance.123456789012.us-east-1.rds.amazonaws.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
CALL mysql.rds_start_replication;

To use SSL encryption, set the final value to `1` instead of `0`. | | RDS for MySQL | **To turn on replication from an Amazon RDS DB instance** 1. If your DB instance replica target was created from a DB snapshot, then you need the binlog file and binlog position that are the starting place for replication. You retrieved these values from the `SHOW SLAVE STATUS` (Aurora MySQL version 2) or `SHOW REPLICA STATUS` (Aurora MySQL version 3) command when you created the snapshot of your replication source.
2. Connect to the DB instance and call the [mysql.rds\_set\_external\_master (Aurora MySQL version 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) or [mysql.rds\_set\_external\_source (Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) and [mysql.rds\_start\_replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) procedures to start replication with your replication source. Use the binary log file name and location from the previous step. The following is an example. 
CALL mysql.rds_set_external_master ('mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
CALL mysql.rds_start_replication;

To use SSL encryption, set the final value to `1` instead of `0`. | | MySQL (external) | **To turn on replication from an external MySQL database** 1. Retrieve the binlog file and binlog position that are the starting place for replication. You retrieved these values from the `SHOW SLAVE STATUS` (Aurora MySQL version 2) or `SHOW REPLICA STATUS` (Aurora MySQL version 3) command when you created the snapshot of your replication source. If your external MySQL replica target was populated from the output of the `mysqldump` command with the `--master-data=2` option, then the binlog file and binlog position are included in the output. The following is an example. 
--
-- Position to start replication or point-in-time recovery from
--

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;

2. Connect to the external MySQL replica target, and issue `CHANGE MASTER TO` and `START SLAVE` (Aurora MySQL version 2) or `START REPLICA` (Aurora MySQL version 3) to start replication with your replication source using the binary log file name and location from the previous step, for example: 
CHANGE MASTER TO
  MASTER_HOST = 'mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com',
  MASTER_PORT = 3306,
  MASTER_USER = 'repl_user',
  MASTER_PASSWORD = 'password',
  MASTER_LOG_FILE = 'mysql-bin-changelog.000031',
  MASTER_LOG_POS = 107;
-- And one of these statements depending on your engine version:
START SLAVE; -- Aurora MySQL version 2
START REPLICA; -- Aurora MySQL version 3
| If replication fails, it can result in a large increase in unintentional I/O on the replica, which can degrade performance. If replication fails or is no longer needed, you can run the [mysql.rds\_reset\_external\_master (Aurora MySQL version 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) or [mysql.rds\_reset\_external\_source (Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) stored procedure to remove the replication configuration. ### Setting a location to stop replication to a read replica In Aurora MySQL version 3.04 and higher, you can start replication and then stop it at a specified binary log file location using the [mysql.rds\_start\_replication\_until(Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) stored procedure. **To start replication to a read replica and stop replication at a specific location** 1. Using a MySQL client, connect to the replica Aurora MySQL DB cluster as the master user. 1. Run the [mysql.rds\_start\_replication\_until(Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) stored procedure. The following example initiates replication and replicates changes until it reaches location `120` in the `mysql-bin-changelog.000777` binary log file. In a disaster recovery scenario, assume that location `120` is just before the disaster. ``` call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120); ``` Replication stops automatically when the stop point is reached. The following RDS event is generated: `Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure`. If you use GTID-based replication, use the [mysql.rds\_start\_replication\_until\_gtid(Aurora MySQL version 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) stored procedure instead of the [mysql.rds\_start\_replication\_until(Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) stored procedure. For more information about GTID-based replication, see [Using GTID-based replication](mysql-replication-gtid.md). ## 7. Monitor your replica When you set up MySQL replication with an Aurora MySQL DB cluster, you must monitor failover events for the Aurora MySQL DB cluster when it is the replica target. If a failover occurs, then the DB cluster that is your replica target might be recreated on a new host with a different network address. For information on how to monitor failover events, see [Working with Amazon RDS event notification](USER_Events.md). You can also monitor how far the replica target is behind the replication source by connecting to the replica target and running the `SHOW SLAVE STATUS` (Aurora MySQL version 2) or `SHOW REPLICA STATUS` (Aurora MySQL version 3) command. In the command output, the `Seconds Behind Master` field tells you how far the replica target is behind the source. **Important** If you upgrade your DB cluster and specify a custom parameter group, make sure to manually reboot the cluster after the upgrade finishes. Doing so makes the cluster use your new custom parameter settings, and restarts binlog replication. ## Synchronizing passwords between replication source and target When you change user accounts and passwords on the replication source using SQL statements, those changes are replicated to the replication target automatically. If you use the AWS Management Console, the AWS CLI, or the RDS API to change the master password on the replication source, those changes are not automatically replicated to the replication target. If you want to synchronize the master user and master password between the source and target systems, you must make the same change on the replication target yourself.