Re: Multi-master replication

On Fri, Aug 13, 2021, 5:05 PM Zahir Lalani <ZahirLalani(at)oliver(dot)agency>
wrote:

> Confidential
>
> Thx Laura
>
> So here is the dilemma - everything in the cloud world tends toward
> horizontal scaling. We do that with PG using single master and multiple
> slaves. But we are write heavy and of course the load on the master is
> quite high. It does seem that multi-master has risks (everyone seems to
> talk about conflict resolution!) so I wonder whether the sensible route is
> simply to scale vertically on the master?
>
>
>

http://bdr-project.org/docs/stable/conflicts.html

There are claims from other databases that they offer multi master
(cockroachdb, yugabyte, etc) out of the box, but there is little clarity on
what would one has to compromise with.

You can always try sharding, postgres fdw can help you with that setup. In
my implementation, we agreed on write locally, read globally. That way
writes could scale without compromise, but reads would be scatter gather
(fdw support for parallel scan in pg14 is promising)

Then, there is citusdb that can help you shard seamlessly and rebalance too.

https://www.citusdata.com/

https://about.gitlab.com/handbook/engineering/development/enablement/database/doc/fdw-sharding.html

https://blog.timescale.com/blog/building-a-distributed-time-series-database-on-postgresql/

As you read more, multi master is not so simple, from what I read.
I think there needs to be a good amount of thoughts for long term growth of
apps, is sharding does not scale well.

In out case, apps were broken down from monoliths to small microservi es to
deal with growth issues, and now it works well as single db as growth is
not exponential ( also small dbs, less tuning, defaults work) but then one
has to upgrade all the dbs periodically to catch up on releases.

As this is a postgresql list, I should not be posting mongo, but never the
less a good read.
https://www.mongodb.com/developer/article/active-active-application-architectures/