- [[AWS Relational Database Service - RDS|RDS]] Read Replica is a read-only copy of the DB instance. - RDS Read Replicas provide enhanced performance and durability for RDS. - RDS Read Replicas allow elastic scaling beyond the capacity constraints of a single DB instance for read-heavy database workloads. - RDS Read replicas enable increased scalability and database availability in the case of an AZ failure. - Read Replicas can help reduce the load on the source DB instance by routing read queries from applications to the Read Replica. - Read replicas can also be promoted when needed to become standalone DB instances. - RDS read replicas can be Multi-AZ i.e. set up with their own standby instances in a different AZ. - One or more replicas of a given source DB Instance can serve high-volume application read traffic from multiple copies of the data, thereby increasing aggregate read throughput. - RDS uses DB engines’ built-in replication functionality to create a special type of DB instance called a Read Replica from a source DB instance. It uses the engines’ native **asynchronous replication** to update the read replica whenever there is a change to the source DB instance. - Read Replicas are eventually consistent due to asynchronous replication. - RDS sets up a secure communications channel using public-key encryption between the source DB instance and the read replica, even when replicating across regions. - Read replica operates as a DB instance that allows only read-only connections. Applications can connect to a read replica just as they would to any DB instance. - Read replicas are available in RDS for MySQL, MariaDB, PostgreSQL, Oracle, and SQL Server as well as Aurora. - RDS replicates all databases in the source DB instance. - RDS supports replication between an RDS MySQL or MariaDB DB instance and a MySQL or MariaDB instance that is external to RDS using Binary Log File Position or  Global Transaction Identifiers (GTIDs) replication. ![[RDS_Read_Replicas.png|650]] ## Read Replicas Creation - Read Replicas can be created within the same AZ, different AZ within the same region, and cross-region as well. - Up to five Read Replicas can be created from one source DB instance. - Creation process - **Automatic backups must be enabled** on the source DB instance by setting the backup retention period to a value other than 0 - An existing DB instance needs to be specified as the source. - RDS takes a snapshot of the source instance and creates a read-only instance from the snapshot. - RDS then uses the **asynchronous replication** method for the DB engine to update the Read Replica for any changes to the source DB instance. - RDS replicates all databases in the source DB instance. - RDS sets up a secure communications channel between the source DB instance and the Read Replica if that Read Replica is in a different AWS region from the DB instance. - RDS establishes any AWS security configurations, such as adding security group entries, needed to enable the secure channel. - During the Read Replica creation, a brief I/O suspension on the source DB instance can be experienced as the DB snapshot occurs. - **I/O suspension typically lasts about one minute and can be avoided if the source DB instance is a Multi-AZ deployment (in the case of Multi-AZ deployments, DB snapshots are taken from the standby)**. - Read Replica creation time can be slow if any long-running transactions are being executed and should wait for completion - For multiple Read Replicas created in parallel from the same source DB instance, only one snapshot is taken at the start of the first create action. - A Read Replica can be promoted to a new independent source DB, in which case the replication link is broken between the Read Replica and the source DB. However, the replication continues for other replicas using the original source DB as the replication source ## Read Replica Deletion & DB Failover - Read Replicas must be explicitly deleted, using the same mechanisms for deleting a DB instance. - If the source DB instance is deleted without deleting the replicas, each replica is promoted to a stand-alone, single-AZ DB instance. - If the source instance of a Multi-AZ deployment fails over to the standby, any associated Read Replicas are switched to use the secondary as their replication source. ## Read Replica Storage & Compute requirements - A Read Replica, by default, is created with the same storage type as the source DB instance. - **For replication to operate effectively, each Read Replica should have the same amount of compute & storage resources as the source DB instance.** - Read Replicas should be scaled accordingly if the source DB instance is scaled. ## Read Replicas Promotion - A read replica can be promoted into a standalone DB instance. - When the read replica is promoted - New DB instance is rebooted before it becomes available. - New DB instance that is created retains the option group and the parameter group of the former read replica. - The promotion process can take several minutes or longer to complete, depending on the size of the read replica. - If a source DB instance has several read replicas, promoting one of the read replicas to a DB instance has no effect on the other replicas. - If you plan to promote a read replica to a standalone instance, AWS recommends that you enable backups and complete at least one backup prior to promotion. - Read Replicas Promotion can help with - Performing DDL operations (MySQL and MariaDB only) - DDL Operations such as creating or rebuilding indexes can take time and can be performed on the read replica once it is in sync with its primary DB instance. - Sharding - Sharding embodies the “share-nothing” architecture and essentially involves breaking a large database into several smaller databases. - Read Replicas can be created and promoted corresponding to each of the shards and then using a hashing algorithm to determine which host receives a given update. - Implementing failure recovery - Read replica promotion can be used as a data recovery scheme if the primary DB instance fails. ## Read Replicas Multi-AZ - RDS read replicas can be Multi-AZ and we can have read-only standby instances in a different AZ. - Read Replicas is currently supported for MySQL, MariaDB, PostgreSQL, and Oracle database engines. - Read Replicas with Multi-AZ help build a resilient disaster recovery strategy and simplify the database engine upgrade process. - Read replica as Multi-AZ, allows you to use the read replica as a DR target providing automatic failover. - Also, when you promote the read replica to be a standalone database, it will already be Multi-AZ enabled. ## Cross-Region Read Replicas - Supported for MySQL, PostgreSQL, MariaDB, and Oracle. - Not supported for SQL Server - Cross-Region Read Replicas help to improve - disaster recovery capabilities (reduces RTO and RPO), - scale read operations into a region closer to end users, - migration from a data center in one region to another region - A source DB instance can have cross-region read replicas in multiple AWS Regions. - Cross-Region RDS read replica can be created from a source RDS DB instance that is not a read replica of another RDS DB instance. - Replica lags are higher for Cross-region replicas. This lag time comes from the longer network channels between regional data centers. - RDS can’t guarantee more than five cross-region read replica instances, due to the limit on the number of access control list (ACL) entries for a VPC - Read Replica uses the default DB parameter group and DB option group for the specified DB engine. - Read Replica uses the default security group. - Deleting the source for a cross-Region read replica will result in - read replica promotion for MariaDB, MySQL, and Oracle DB instances - no read replica promotion for PostgreSQL DB instances and the replication status of the read replica is set to `terminated`. ![[Cross-Region-Read-Replicas.png|650]] ## Read Replica Features & Limitations - RDS does not support circular replication. - DB instance cannot be configured to serve as a replication source for an existing DB instance; a new Read Replica can be created only from an existing DB instance _for e.g., if `MyDBInstance` replicates to `ReadReplica1`, `ReadReplica1` can’t be configured to replicate back to `MyDBInstance`.  From `ReadReplica1`, only a new Read Replica can be created, such as `ReadRep2`._ - Read Replica can be created from other Read replicas as well. However, the replica lag is higher for these instances and there cannot be more than four instances involved in a replication chain. ![[Screen-Shot-2016-06-13-at-6.42.06-AM.png|650]] ## RDS Read Replicas Use Cases - Scaling beyond the compute or I/O capacity of a single DB instance for read-heavy database workloads, directing excess read traffic to Read Replica(s) - Serving read traffic while the source DB instance is unavailable _for e.g. If the source DB instance cannot take I/O requests due to backups I/O suspension or scheduled maintenance, the read traffic can be directed to the Read Replica(s)._ **However, the data might be stale.** - Business reporting or data warehousing scenarios where business reporting queries can be executed against a Read Replica, rather than the primary, production DB instance. - Implementing disaster recovery by promoting the read replica to a standalone instance as a disaster recovery solution, if the primary DB instance fails. ## [[AWS RDS Replication - Multi-AZ vs Read Replica|RDS Read Replicas vs Multi-AZ]] ![[RDS-Mulit-AZ-vs-Multi-Region-vs-Read-Replicas.png|650]] ## Sources [AWS\_RDS\_Read\_Replicas](https://aws.amazon.com/rds/features/read-replicas/) [AWS RDS Read Replicas](https://jayendrapatil.com/rds-read-replicas/)