Working with MariaDB read replicas

To configure delayed replication during read replica creation

1. Using a MariaDB client, connect to the MariaDB DB instance to be the source for read replicas as the master user.

   Run the mysql.rds_set_configuration stored procedure with the target delay parameter.

   For example, run the following stored procedure to specify that replication is delayed by at least one hour (3,600 seconds) for any read replica created from the current DB instance.

   call mysql.rds_set_configuration('target delay', 3600);

   Note

   After running this stored procedure, any read replica you create using the AWS CLI or Amazon RDS API is configured with replication delayed by the specified number of seconds.

   Modifying delayed replication for an existing read replica

   To modify delayed replication for an existing read replica, run the mysql.rds_set_source_delay stored procedure.

   To modify delayed replication for an existing read replica

   1. Using a MariaDB client, connect to the read replica as the master user.

      Use the mysql.rds_stop_replication stored procedure to stop replication.

      Run the mysql.rds_set_source_delay stored procedure.

      For example, run the following stored procedure to specify that replication to the read replica is delayed by at least one hour (3600 seconds).

      call mysql.rds_set_source_delay(3600);

      Use the mysql.rds_start_replication stored procedure to start replication.

      Promoting a read replica

      After replication is stopped, in a disaster recovery scenario, you can promote a read replica to be the new source DB instance. For information about promoting a read replica, see Promoting a read replica to be a standalone DB instance .

      replicas with MariaDB

      Read replicas are designed to support read queries, but you might need occasional updates. For example, you might need to add an index to speed the specific types of queries accessing the replica. You can enable updates by setting the read_only parameter to 0 in the DB parameter group for the read replica.

      Working with Multi-AZ read replica deployments with MariaDB

      You can create a read replica from either single-AZ or Multi-AZ DB instance deployments. You use Multi-AZ deployments to improve the durability and availability of critical data, but you can't use the Multi-AZ secondary to serve read-only queries. Instead, you can create read replicas from high-traffic Multi-AZ DB instances to offload read-only queries. If the source instance of a Multi-AZ deployment fails over to the secondary, any associated read replicas automatically switch to use the secondary (now primary) as their replication source. For more information, see Configuring and managing a Multi-AZ deployment .

      You can create a read replica as a Multi-AZ DB instance. Amazon RDS creates a standby of your replica in another Availability Zone for failover support for the replica. Creating your read replica as a Multi-AZ DB instance is independent of whether the source database is a Multi-AZ DB instance.

      Using cascading read replicas with RDS for MariaDB

      RDS for MariaDB supports cascading read replicas. With cascading read replicas , you can scale reads without adding overhead to your source RDS for MariaDB DB instance.

      With cascading read replicas, your RDS for MariaDB DB instance sends data to the first read replica in the chain. That read replica then sends data to the second replica in the chain, and so on. The end result is that all read replicas in the chain have the changes from the RDS for MariaDB DB instance, but without the overhead solely on the source DB instance.

      You can create a series of up to three read replicas in a chain from a source RDS for MariaDB DB instance. For example, suppose that you have an RDS for MariaDB DB instance, mariadb-main . You can do the following:

      • Starting with mariadb-main , create the first read replica in the chain, read-replica-1 .

      • Next, from read-replica-1 , create the next read replica in the chain, read-replica-2 .

      • Finally, from read-replica-2 , create the third read replica in the chain, read-replica-3 .

   You can't create another read replica beyond this third cascading read replica in the series for mariadb-main . A complete series of instances from an RDS for MariaDB source DB instance through to the end of a series of cascading read replicas can consist of at most four DB instances.

   For cascading read replicas to work, each source RDS for MariaDB DB instance must have automated backups turned on. To turn on automatic backups on a read replica, first create the read replica, and then modify the read replica to turn on automatic backups. For more information, see Creating a read replica .

   As with any read replica, you can promote a read replica that's part of a cascade. Promoting a read replica from within a chain of read replicas removes that replica from the chain. For example, suppose that you want to move some of the workload from your mariadb-main DB instance to a new instance for use by the accounting department only. Assuming the chain of three read replicas from the example, you decide to promote read-replica-2 . The chain is affected as follows:

   • Promoting read-replica-2 removes it from the replication chain.

     It is now a full read/write DB instance.

   • It continues replicating to read-replica-3 , just as it was doing before promotion.