1

We're looking to create a replica of a postgres RDS instance that our developers can write to (not just a simple read replica that AWS can easily provide). Currently we run a script nightly that restores a snapshot of the master instance as the replica. We've got 2 main issues with this approach.

The first issue is that the master instance is multi-az and has provisioned IOPS while the replica is single-az and magnetic IOPS, and this causes really long delays in getting the replica to the "available" state (upwards of 16 hours). We do this because we want the replica to be as cheap as possible. The replica is, in fact, usable while in the "modifying" state, but it sounds like we're getting charged for the provisioned IOPS while it's in this state.

The second issue is that while the replica is in the "modifying" state, the parameter group stays at the default. We have to wait until it's "available" before we can make this change.

I can't believe I couldn't find any solutions to this problem. It sounds like it would be a common request. Are we going about this the wrong way? How should one keep a separate, up to date replica of an rds instance?

Starfish
  • 2,716
  • 24
  • 28
user1272324
  • 31
  • 4
  • Are you just restoring the snapshot, or are you doing point in time? Is there a discrepancy of instance classes between master and replica? How large is the data set? – Michael - sqlbot Jul 20 '15 at 21:56
  • We are restoring the daily snapshot of the master. The instance class also differs (master is db.r3xlarge, replica is db.m3.medium). Size is ~200GB. – user1272324 Jul 20 '15 at 23:01
  • 1
    Sounds like what you really need is two replicas. One that you clone a day ahead and bring up to date, and another that's up to date and running as a read replica that you can detach and promote to a live master immediately. Yes, that means you'll be paying for two. – Craig Ringer Jul 22 '15 at 04:52

0 Answers0