Re: The current shape of PG master-slave replication

On Thu, 15 Nov 2018, Laurenz Albe wrote:

> PostgreSQL has had streaming replication since version 9.0, and by now
> it is rock solid technology. It operates on the same principles as the
> crash- and point-in-time-recovery that you already trust.

Okay, that is great news. Your help is very much appreciated.

This gives me extra confidence that I have absolutely no need to use
MariaDB anywhere. In my workplace there are probably a few more admins who
go for MariaDB, but PG is certainly closing in even though this is not
a "competition" at all.

And actually the *specialized DB admins* who focus mostly on DB stuff
only, seem to favour PG over MariaDB. I mean in my workplace, I do not
make any claims about this being so in general.

Their Oracle background could explain part of the PG preference, since
they are pretty similar on surface, but I am pretty sure those DB guys
have evaluated MariaDB too, and yet they choose PG over it.

PG documentation is also just fantastic. I cannot believe how complete it
is, and well-organized, too. The scope is broad, it includes a brief
tutorial sections for beginners, so it makes PG accessible to many people
who do not even know SQL yet, and in addition to that the documentation
contains concise information about the advanced topics as well.

With lots of software projects, the information is scattered all over the
world, and you have to use search engines to find out about things. With
PG, I know if I am lagging behind the new releases and their features, I
can always go to to PG website and I will find *all the relevant
information* easily from there.

I have spent some time learning PG during all these years, and I have
always some preferred the PG way to do things, but I bet that MariaDB is
also great for those who like it. I can live with it if I have to, I know
the basics. Lots of folks do. It is good to have competition and working,
stable, efficient relational DB alternatives available.

By the way, speaking of raw, low-level DB technology, I only learned about
LMDB yesterday:

https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database

It could indeed be a good replacement for BerkeleyDB in many cases. I read
that of MTAs, Postfix has already deprecated BDB in favour of LMDB, and I
suppose OpenLDAP is going the same route. If I remember right, LMDB even
originates from OpenLDAP project's needs.

Modern 64-bit CPUs now enable larger address space and the mmap() model of
LMDB seems to work fine with it, enabling direct pointers to OS
virtual memory. According to Wikipedia and common sense, it makes
things simpler and avoids data copying. And unlike using BDB, needs for
library level caching in userspace are replaced by OS doing the caching?

That's how I understood it. I have used BerkeleyBD since the early 2000s
with Sendmail, but I have little knowledge of its internal working. I
studied the C API years ago, maybe wrote some simple test programs, but
reading the actual BerkeleyDB source code I have feared too much.

> On top of that, it is amazingly simple to configure, especially since
> v10, since now all parameter defaults are already set up for replication.

I have well over twenty years of Unix/Linux experience and I have worked
with many kinds of server software, mostly on Linux. We used to have SPARC
Solaris Unix machines, Tru64 and whatever, but those days are long gone.

It's been the world of AMD64 and Red Hat Enterprise Linux for many, many
years for us.

In any case, I am perhaps deviating too much here.

So it is a great bonus if the PG master-slave replication configuration is
indeed simple and has sane default values! That's good design. It is best
to leave the details to DB experts who know their systems inside and
out.

Unneeded complexity is, well, *unneeded*.

Best regards,
Unto Sten