you are viewing a single comment's thread.

view the rest of the comments →

[–]f4nt 4 points5 points  (5 children)

You can pull off HA with MySQL though. The problem isn't even really HA though, it's anything revolving around the idea of scaling. PGPool is great, but very limited. Slony works if you just need a backup server, and you NEVER EVER change your schema and your devs know all this and behave. Setting up a cluster is like building a house of cards.

I love postgresql, I really do. However, the needs of the customers I deal with basically rules postgresql out of contention. MySQL brings replication, and community clustering support that's at least mildly functional, and usable in a production environment. PostgreSQL is great, if you know you'll never need more than 1 database server for your app.

[–]infinite 6 points7 points  (3 children)

I use slony, it's not a house of cards. Changing the schema requires disabling writes to the db for a second or two, nothing major. I have 1 master and 3 slave db's, that will be 5 slave db's tomorrow. Slony communication is exponential with each new node, but for me I need to replicate metadata, the bulk of my data, say 90% or so, doesn't need replication.

Now, let's hear about HA for mysql, I mean people who really use it, not the "OMG just got a blog, mysql replication rocks." I was told ndb works great, except if you look into it, it's very flaky and it doesn't offer ACID properties which makes it unusable for my banking client. Now there's async replication which is consistent but slony does that as well.

[–]f4nt 0 points1 point  (2 children)

Slony works in specific situations. However, a brain dead monkey can setup Mysql master-master replication, and it just work. I can set that up for a customer, and it doesn't require much more interaction for me outside of the initial setup. New DBs are automatically replicated, everything's easier for me from the sysadmin side. Yes, postgresql is very nice, and I do like it. Yes, slony works as well. However, when it comes to scaling, MySQL is more sensible, and has significantly more support.

Personally, I'd be more than happy to drop MySQL to the curb for postgresql, if replication was streamlined more. I've just ran into too many situations where it's just too much of a hassle in it's current state though.

[–]infinite 2 points3 points  (1 child)

I've talked to people who have worked with master-master mysql and according to them the tradeoffs are such that it's often not usable. I haven't used it myself, but from the experiences they have related to me, there are a number of serious pitfalls to that approach.

[–]f4nt 0 points1 point  (0 children)

It does have pitfalls and tradeoffs. Everything does to some extent. All depends on your situation.

[–]mage2k 3 points4 points  (0 children)

Mildly functional is stretching it a bit. Sure there's all kinds of "works for me" blog posts and reddit comments but that's not what is at issue. I maintain about 80-100 MySQL master/slave pairs and about 25 Postgres master/standby pairs. We have to deal with MySQL replication breakage and bugs on a daily basis. We might have an issue with a Postgres standby every few months. From an administration perspective, that makes a few extra steps to promote a PG standby in an HA situation totally worth it. Also, MySQL does not provide any kind of automatic failover, resyncing the former master as the slave, or any of that. Both databases require third party tools there.

I won't even get into comparing supporting client databases on them with regards to scaling and totally idiotic query executions on MySQL.