The ongoing MySQL campaign

Posted Jan 4, 2010 6:37 UTC (Mon) by ringerc (subscriber, #3071)
In reply to: The ongoing MySQL campaign by robert_s
Parent article: The ongoing MySQL campaign

... or to find out that you need reliable, trustworthy and fast multi-master clustering to satisfy your load and uptime needs.

Right now, MySQL fails on "reliable" and "trustworthy" for its MM clustering, and PostgreSQL doesn't have it at all. I'm not equipped to evaluate the MM clustering add-ons to Pg like Bucardo, but I'm figuring the approach hasn't been integrated into Pg core for a reason.

Sometimes you really do need things the OSS databases don't yet provide.

That said: frequently, the reasons are lack of understanding, lack of sales materials targeted at middle/upper management, a belief that having another company "standing behind" the product makes it invulnerable to failure, "having someone to sue", or the nice week-long party cruise the salesman promised the TIO if they'll sign on the dotted line.

to post comments

The ongoing MySQL campaign

Posted Jan 4, 2010 7:45 UTC (Mon) by dlang (guest, #313) [Link] (2 responses)

for the postgres replication options, the reason they haven't been integrated into core isn't that they aren't good. it's that they can function without being integrated and the core developers have chosen to not give the appearance of blessing one of the options over the others.

different variations of replications have different advantages and disadvantages.

the replication that is going in requires core support, so it can't be maintained as a separate package

The ongoing MySQL campaign

Posted Jan 4, 2010 17:06 UTC (Mon) by foom (subscriber, #14868) [Link] (1 responses)

> the replication that is going in requires core support, so it can't be maintained as a separate
package

That seems like a terrible reason to bless one package and not any of the others. I hope that's not
all there is to it, and that the blessed one is, additionally, the best (overall, for most uses)
replication package for postgres.

Why is it in core?

Posted Jan 4, 2010 20:53 UTC (Mon) by mainpc (guest, #62803) [Link]

The replication solution is actually two separate non-replication features that are useful on their own, but when used together, create a solid replication solution.

PostgreSQL has been able to load point in time recovery (PITR) log files from one server onto another, creating a warm standby solution for fail-over. Recently, 8.5 gained the ability to serve read-only queries while performing recovery. This feature is called Hot Standby. In a separate feature, Streaming Replication, PostgreSQL will be able to send PITR data across a TCP stream in addition to the log files. Combining Hot Standby with Streaming Replication provides a solid master-slave replication solution, suitable for fail-over and load balancing of read-only queries.

This replication solution happens to be in core because that is the right place for Hot Standby and Streaming Replication to be. It is also a very low overhead design because it is based on log files that are created during normal operation anyway.