Re: checkpoints taking much longer than expected

On Sun, Jun 16, 2019 at 7:30 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> Ok, so you want fewer checkpoints because you expect to failover to a
> replica rather than recover the primary on a failure. If you're doing
> synchronous replication, then that certainly makes sense. If you
> aren't, then you're deciding that you're alright with losing some number
> of writes by failing over rather than recovering the primary, which can
> also be acceptable but it's certainly much more questionable.
>

Yes, in our setup that's the case: a few lost transactions will have a
negligible impact to the business.

> I'm getting the feeling that your replicas are async, but it sounds like
> you'd be better off with having at least one sync replica, so that you
> can flip to it quickly.

They are indeed async, we traded durability for performance here, because
we can accept some lost transactions.

> Alternatively, having a way to more easily make
> the primary to accepting new writes, flush everything to the replicas,
> report that it's completed doing so, to allow you to promote a replica
> without losing anything, and *then* go through the process on the
> primary of doing a checkpoint, would be kind of nice.
>

I suppose that would require being able to demote a master to a slave
during runtime.
That would definitely be nice-to-have.

>
>
> Thanks,
>
> Stephen
>