[feld]

MySQL's replication is not mature. There are too many edge cases / pitfalls where it doesn't replicate to slaves. It requires you to monitor for these situations and build systems to work around it. I don't know why anyone thinks this is OK.

Postgres is late to the replication game but they have worked hard to make sure that replication doesn't have surprises.

The character set is another nightmare that surprises novice MySQL admins... and then the fact that it allows schema operations to destroy data by default...

[evanelias]

Can you cite examples in recent versions? In my experience, the defaults in recent versions (mixed or row-based replication, strict sql mode) are quite sane and prevent most historic problems.

I don't have enough pg experience to make a valid comparison, but I have worked extensively on the largest mysql environment in the world (among many others), and can say that properly-configured mysql replication does not encounter the problems you are describing.

Yes, there are a lot of pitfalls for novice admins to avoid. That's true of all databases to some degree. MySQL may well have more pitfalls than others, but it also has a much wider net of experts who can help you avoid these pitfalls.

Anyway, by "mature" I was also referring to the sheer number of solutions offered, most of which are now battle-tested by many large users. Out-of-the-box in the latest version you get 2 types of logical replication (and a third type mixing the two), 3 options for level of synchronicity (async, semi-sync, and now sync via the new group replication), bidirectional replication, and multi-source replication. And there are additional third-party solutions for other synchronous replication setups (e.g. Galera), and even physical replication has been implemented internally by both Amazon and Alibaba.

[feld]

Looks like floating point values still aren't handled:

https://dev.mysql.com/doc/refman/5.7/en/replication-features...

This is scary

https://dev.mysql.com/doc/refman/5.7/en/replication-features...

These look like something rare, but scary to those who don't know about them

https://dev.mysql.com/doc/refman/5.7/en/replication-features...

I used to hit issues with replication and IF EXISTS and it was a nightmare: http://bugs.mysql.com/bug.php?id=77684 ... glad to see they (allegedly) fixed it

edit: I don't have anywhere near the experience you do with MySQL, but the odds of the average web developer / sysadmin configuring it properly is unlikely. The advantage of Postgres is that it protects your data first and there are much fewer foot-shooting options.

[evanelias]

First link: Floating point values replicate fine. The manual says you may have problems if your master and replica are running different computer architectures, or were built using different compilers (and you're compiling MySQL yourself from source). Both situations are exceedingly rare.

Second link: Despite the admittedly scary wording, these things only impact two scenarios: either you're using MyISAM, and/or you're using MySQL 5.7's new LOGICAL_CLOCK multi-threaded replication but with a vital safety option disabled. Multi-threaded replication is not enabled by default anyway, and only users with extremely high write rates will ever need it.

Third link: these are all edge-cases relating to statement-based replication, which is no longer the default binlog format as of MySQL 5.7. Even with statement-based replication, these are rare; in 13 years of working with MySQL I've personally never encountered any of these specific issues.

Overall: I sort of get your point, yes there's a lot of knobs. But none of the things you've mentioned affect 99.9% of people running MySQL in the first place. MySQL replication works quite well out of the box, but provides a lot of options for advanced users to handle special cases. If you play with those options without knowing what you're doing, yes, you'll shoot yourself in the foot. That's true of most complex computing infrastructure.

The defaults in MySQL used to suck. They don't anymore, and haven't for a while.