8 ms·

If you're evaluating databases based on their replication capabilities, don't stop with what MySQL has built-in. Take a look at http://www.percona.com/live/mysq

• briandear 14y ago
  Why bother? PostgreSQL is better.
  • sciurus 14y ago
    PostgreSQL may not be better on all possible points of comparison. PostgreSQL replcation alone isn't comparable to MySQL with Galera. I don't know enough about the various extensions to PostgreSQL to know which ones could give you * Synchronous replication * Active-active multi-master topology * Read and write to any cluster node * Automatic membership control, failed nodes drop from the cluster * Automatic node joining * True parallel replication, on row level * Direct client connections in a reliable and perfomant manner. Keep in mind I'm just atarting to play with Galera, I haven't used it in production yet, but it's making my planned architecure much simpler to manage than the traditional MySQL or PostgreSQL replication approaches.
    • baghali 14y ago
      repmgr[1] is a very good replication option for PostgreSQL [1]https://github.com/2ndQuadrant/repmgr https://github.com/2ndQuadrant/repmgr
      • jvdongen 14y ago
        Good mention. A small correction though: repmgr is not so much an replication option for postgres as well as a handy toolkit for using Postgres's own replication features in a more convenient way.
    • jeltz 14y ago
      For write scalability there is the Postgres-XC project. I do not know if it is ready just yet to run in production but it is getting there soon otherwise.
      • einhverfr 14y ago
        It looks to me as if Postgres-XC is largely waiting for 9.2 to be released. It's basically PostgreSQL plus some patches that allow for write-scalable clusters. From the timing of their betas, it looks like they are largely following the 9.2 release schedule.
  • taligent 14y ago
    But yet every major website chooses MySQL over PostgreSQL. Why is that ?
    • spudlyo 14y ago
      Because up until recently PostgreSQL replication didn't really exist, and you had to choose between 10 different trigger-be-using unscalable bag-on-the-side technologies to fill that void.
      • jeltz 14y ago
        Still I know of at least one quite large website (one of the largest in Sweden) that use Slony despite the performance hit from trigger based replication.
    • einhverfr 14y ago
      Because MySQL's history is one of specializing in content management. In fact if you look at things this way, many of the MySQL gotchas which make DB people cringe are actually content management features. Yes, this includes data truncation. When you move off the web site/content management side, PostgreSQL has long been the open source DB for complex business tools.
    • epo 14y ago
      Betamax/VHS (look it up). MySQL had earlier presence, perhaps because it was easier to install? Hence people expected to find it as it was what they knew.
      • z92 14y ago
        MySQL had earlier presence because it was the only available solution. PostgreSQL came much later. There was something called postgress95 which crashed on connection.
    • davidw 14y ago
      Don't Skype and Instagram use Postgres? http://en.wikipedia.org/wiki/PostgreSQL#Prominent_users http://en.wikipedia.org/wiki/PostgreSQL#Prominent_users
• einhverfr 14y ago
  The same goes with PostgreSQL. Replication isn't a one-size-fits-all need, and companies like Affilias will find Slony much easier to work with than the built in PostgreSQL replication because Slony allows for seemless, zero-downtime upgrades, partial replication, and a whole host of other features. On the other hand, Slony allows for partial replication..... You also have Bucardo which can do master-master replication between two nodes, and a few other solutions out there.