Re: The current shape of PG master-slave replication - Mailing list pgsql-admin

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