Replicate subset of tables from AWS RDS mysql to another RDS/external mysql instance
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Replication in MySQL is a powerful feature that allows you to create copies of databases or specific tables and synchronize them between multiple instances. This is particularly useful for disaster recovery, geographical distribution of data, load balancing, and more. AWS RDS (Relational Database Service) provides managed MySQL instances, which simplify the deployment and maintenance of MySQL databases.
In this article, we'll walk through the process of replicating a subset of tables from an AWS RDS MySQL instance to another RDS MySQL instance or an external MySQL server.
Requirements
- AWS RDS Instance: Source RDS instance with MySQL that contains the tables to be replicated.
- Destination MySQL Instance: Another RDS instance or an external MySQL server where tables will be replicated.
- Network Configuration: Ensure that the destination instance can connect to the source instance. This might require changes in security groups and network ACLs.
- Replication User: Create a user with replication privileges on the source database.
Creating the Replication User
First, log in to your source RDS instance and create a user with replication privileges.
Configuring the Source RDS Instance
To enable replication, you need binlogging enabled on your source RDS instance. Verify that binary logging is enabled and configure the parameters appropriately:
- Check Binlog Configuration:
- Log into your RDS console.
- Navigate to the parameter groups for your RDS instance.
- Ensure that
binlog_formatis set toMIXEDorROW.
- Enable Binary Logging: Ensure
rds.enhanced_monitoring_intervalis set for real-time insights as needed.
Filtering Tables for Replication
To replicate only a subset of tables, you can use replication filters on the destination server. These can be set up by altering the MySQL configuration file (my.cnf or my.ini) on the destination instance.
Example configuration:
Full Configuration for Replication
On Source RDS:
- Find the Binlog File and Position:
It will output File and Position, which you'll use to configure the slave.
On Destination MySQL Instance:
- Stop the Slave:
- Change Master:
- Start the Slave:
- Verify Slave Status:
This command checks for "Slave_IO_Running: Yes" and "Slave_SQL_Running: Yes", which confirm replication is operational.
Monitoring and Error Handling
Regularly monitor the replication performance and address errors promptly. Use:
This will provide you with detailed status, including any errors that may have occurred. Check the Last_Error field for specifics on what went wrong.
Enhancements and Best Practices
- Secure Replication Traffic: Use SSL to encrypt the traffic between the source and destination instances.
- Regular Backups: Always have regular backup protocols in place for disaster recovery.
- Monitoring and Alerts: Use AWS CloudWatch to monitor the RDS performance and set up alerts for critical metrics.
Summary Table
| Step | Description | Commands/Details |
| Create Replication User | Create a user with appropriate privileges on the source | CREATE USER 'replication_user'@'%' IDENTIFIED BY 'strong_password';
GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'%'; |
| Enable Binlogging | Ensure binary logging is enabled on the source | Check binlog_format and rds.enhanced_monitoring_interval |
| Configure Destination | Set up replication filters and master configuration | CHANGE MASTER TO ...
Modify [mysqld] section |
| Start/Verify Replication | Execute commands to start and verify the replication | START SLAVE;
SHOW SLAVE STATUS\G; |
Conclusion
Replicating a subset of tables from an AWS RDS MySQL to another MySQL instance involves preparation of both the source and the destination instances. By following the steps outlined, and maintaining good practices such as secure connections and regular monitoring, you can ensure efficient and reliable replication. Always remember to regularly back up your data and maintain vigilance with replication health checks.

