Migrating Large Heroku Postgres Instances to AWS Aurora Without Downtime

Re:Migrating Large Heroku Postgres Instances to AWS Aurora W... by mnutt on Thursday November 12, 2020 @12:56PM (#25072565)

Aurora (Postgres) looked like it would be great, and the performance for our use case was much better than RDS. But there was a showstopper for us with the replication: If the cluster leader fails, _every read replica will force a restart_ to elect a new leader, resulting in minimum ~30s complete cluster downtime. In our situation we have no problem with a short downtime in write availability, but the fact that we can't maintain read availability via replicas is a deal breaker.

[ Parent | on HN ]

Re:Migrating Large Heroku Postgres Instances to AWS Aurora W... by hyperdimension on Thursday November 12, 2020 @01:40PM (#25073153)

I'm no DBA, but is that not the entire point of a cluster/replicas?

Sure, maybe writes won't be accepted or replicated until a new master is elected, but you can't even read from the cluster?

I'm curious at this point: what is it exactly that you gain from a cluster? Is it only having to wait 30s vs. however long it takes for the master to come back online?

[ Parent | on HN ]

Re:Migrating Large Heroku Postgres Instances to AWS Aurora W... by mnutt on Thursday November 12, 2020 @04:02PM (#25075005)

That was the mind-boggling part to me. After testing failover and noticing the behavior we had a number of discussions with AWS reps and support engineers that confirmed it. And Aurora's failover documentation hints at it but downplays the severity.

[ Parent | on HN ]

Re:Migrating Large Heroku Postgres Instances to AWS Aurora W... by aetherson on Friday November 13, 2020 @08:41AM (#25082001)

The thing you gain from the replicas is removing read load from the primary during normal operations.

[ Parent | on HN ]