Hadoop Learning Resources

  • Increase font size
  • Default font size
  • Decrease font size

Amazon WebService Certification Practice Questions Total 354 Lifetime Access($55/2500INR)

Hadoop Training @ 50% Discounted Price (Just $69/3500INR) : Free Demo

Hadoop Developer Certification 335 Practice Questions(Just $55/2500INR)

Hadoop Admin Certification 307 Practice Questions(Just $55/2500INR)

Hadoop HBase Certification 214 Practice Questions(Just $55/2500INR)


Go To Page :   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27   Download Pdf

RDS and Read Replicas


You can create a second-tier Read Replica from an existing first-tier Read Replica.  By creating a second-tier Read Replica, you may be able to move some of the replication load from the master database instance to a first-tier Read Replica. Please note that a second-tier Read Replica may lag further behind the master because of additional replication latency introduced as transactions are replicated from the master to the first tier replica and then to the second-tier replica.


A Read Replica will stay active and continue accepting read traffic even after its corresponding source DB Instance has been deleted. If you desire to delete the Read Replica in addition to the source DB Instance, you must explicitly delete the Read Replica using the DeleteDBInstance API or AWS Management Console.


Scaling up the storage or compute resources on a source MySQL instance should be applied

as well in the read replicas in order to avoid storage scarcity or replication lags in your replication setting. You can create up to 5 read replicas from one DB instance. In order for replication to operate effectively, each read replica should have as much compute and storage resources as the source DB instance. If you scale the source DB instance, you should also scale the read replicas.


You may find in some cases that your Read Replica(s) arent able to receive or apply updates from their source Multi-AZ DB Instance after a Mulit-AZ failover. This is because some MySQL binlog events were not flushed to disk at the time of the failover. After the failover, the Read Replica may ask for binlogs from the source that it doesnt have.


To resolve the current issue, you will need to delete the Read Replica and create a new one to replace it. To avoid this issue in the future, setting sync-binlog=1 will greatly reduce the chance that MySQL binlogs needed by the Read Replica will be lost during a crash/failover scenario. As the MySQL documentation explains, even this doesnt completely resolve the issue. To further reduce the likelihood of hitting this issue, set innodb_support_xa=1. Note that there may be a performance penalty for setting these variables. Both sync_binlog and innodb_support_xa are dynamic variables, so if you find that the performance penalty is too great, you can reset them without taking an outage.


This is ultimately a choice between performance and improving the automatic resynchronization of Read Replicas after a source Multi-AZ failover. One of the advantages of Amazon RDS Read Replicas is that they can be quickly re-instantiated when synchronization issues arise by deleting and re-creating them. As such, you dont have to take the performance hit from setting sync-binlog and/or innodb_support_xa if manually dropping out of sync Read Replicas and re-creating them meets your needs.


At this point in time, Amazon RDS allows you to create up to five (5) Read Replicas for a given source DB Instance.


If you promote a read replica that is in turn replicating to other read replicas, those replications stay active. Consider an example where MyDBInstance1 replicates to MyDBInstance2, and MyDBInstance2 replicates to MyDBInstance3. If you promote MyDBInstance2, there will no longer be any replication from MyDBInstance1 to MyDBInstance2, but MyDBInstance2 will still replicate to MyDBInstance3.


The following steps show the general process for promoting a read replica to a Single-AZ DB instance.


1.Stop any transactions from being written to the read replica source DB instance, and then wait for all updates to be made to the read replica. Database updates occur on the read replica after they have occurred on the source DB instance, and this replication "lag" can vary significantly. Use the Replica Lag metric to determine when all updates have been made to the read replica.


2.To be able to make changes to the read replica, you must the set the read_only parameter to 0 in the DB parameter group for the read replica.


3.Perform all needed DDL operations, such as creating indexes, on the read replica. Actions taken on the read replica do not affect the performance of the source DB instance.


4.Promote the read replica by using the Promote Read Replica option on the Amazon RDS console, the CLI command rds-promote-read-replica, or the PromoteReadReplica API operation.



The promotion process takes a few minutes to complete. When you promote a read replica, replication is stopped and the read replica is rebooted. When the reboot is complete, the read replica is available as a Single-AZ DB instance.

Go To Page :   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27   Download Pdf



Click to View What Learners Say about us : Testimonials

We have training subscriber from TCS, IBM, INFOSYS, ACCENTURE, APPLE, HEWITT, Oracle , NetApp , Capgemini etc.


Contact Us

Phone : 022-42669636
Mobile : +91-8879712614
Hadoop Learning Resource
B-902 Trade Center
Mumbai 400097


Yeah the material is helpful to test our knowledge. I passed the exam.
Thanks for your help! Read More
--Sudha Udatha, USA

"I wish I had bought your exam prep during my first attempt. More than anything else your tests made me feel confident to crack the CCD-410 exam. It would not have been possible without you. My best wishes to your team"
Read More
-- Sandeep Swami Banglore

Login Form