Just bite the bullet and port to it. In the process, you may have to learn a bit about how databases are actually supposed to work, but that's probably good for you.
It is not that easy - Postgres right now is lacking in the area of replication and thus fails as a database for all those MySQL users that require replication for scaleout.
Postgres replication options usually are active-passive (WAL shipping solutions that recover the slave) or are trigger-based and syncronos such as Slony-I.
What MySQL users usually require is replication to be losely coupled and asynchronous in order for it to become a viable scaleout option.
You also get more flexibility; want to replicate your "current" tables but keep your "history" tables only on the master? Want to chain slaves to slaves instead of all slaves to one master? Want a special search database (you can have transactions and fulltext search at the same time) that only contains the ts_vector (fulltext search index) tables? Slony lets you do all of those.
I'm sorry, but Slony-I is not a serious replication solution.
I believe the PostgreSQL devs themselves have said as much (officially, on their site). They've also said that the reason for this situation is that the project had previously taken the stance that it should not include its own replication, but should instead allow third-parties to implement replication as they see fit.
However, they've now said that, since this hasn't worked so well in practice, the next version of PostgreSQL WILL include direct,
However, they've now said that, since this hasn't worked so well in practice, the next version of PostgreSQL WILL include direct, built-in support for basic replication, as well as making sure that heavyweight, third-party replication solutions are still supported.
Well, wake me when it's there. MySQL still gets bashed for its historical lack of transactions, so if Postgres wants credit for something, it can at least implement it. Last I checked, it was supposed to be in 8.4, then it wasn't, then it was supposed to be in 8.5, and if memory serves, it's slipping again.
Either way, I don't think these replication issues are a good enough reason to use MySQL instead. Worst case scenario, there ARE good replication options for PostgreSQL [wikivs.com].
So which one of those solutions is:
Easy to configure (as in, no harder than MySQL replication).
Scales linearly (Slony-I scales quadratically, which is why you can't get beyond a few nodes)
Can add a sla
GREAT MOMENTS IN HISTORY (#7): April 2, 1751
Issac Newton becomes discouraged when he falls up a flight of stairs.
PostgreSQL (Score:4, Insightful)
Just bite the bullet and port to it. In the process, you may have to learn a bit about how databases are actually supposed to work, but that's probably good for you.
Re: (Score:3, Informative)
It is not that easy - Postgres right now is lacking in the area of replication and thus fails as a database for all those MySQL users that require replication for scaleout.
Postgres replication options usually are active-passive (WAL shipping solutions that recover the slave) or are trigger-based and syncronos such as Slony-I.
What MySQL users usually require is replication to be losely coupled and asynchronous in order for it to become a viable scaleout option.
Re: (Score:4, Interesting)
Slony-I is asynchronous. Read postgres' excellent documentation [postgresql.org] for some other possibilities.
You also get more flexibility; want to replicate your "current" tables but keep your "history" tables only on the master? Want to chain slaves to slaves instead of all slaves to one master? Want a special search database (you can have transactions and fulltext search at the same time) that only contains the ts_vector (fulltext search index) tables? Slony lets you do all of those.
Re:PostgreSQL (Score:4, Informative)
Slony-I is a dreadful hack that misuses triggers, and doesn't scale past a few nodes.
I'm sorry, but Slony-I is not a serious replication solution.
Re: (Score:2)
I believe the PostgreSQL devs themselves have said as much (officially, on their site). They've also said that the reason for this situation is that the project had previously taken the stance that it should not include its own replication, but should instead allow third-parties to implement replication as they see fit.
However, they've now said that, since this hasn't worked so well in practice, the next version of PostgreSQL WILL include direct,
Re: (Score:2)
However, they've now said that, since this hasn't worked so well in practice, the next version of PostgreSQL WILL include direct, built-in support for basic replication, as well as making sure that heavyweight, third-party replication solutions are still supported.
Well, wake me when it's there. MySQL still gets bashed for its historical lack of transactions, so if Postgres wants credit for something, it can at least implement it. Last I checked, it was supposed to be in 8.4, then it wasn't, then it was supposed to be in 8.5, and if memory serves, it's slipping again.
Either way, I don't think these replication issues are a good enough reason to use MySQL instead. Worst case scenario, there ARE good replication options for PostgreSQL [wikivs.com].
So which one of those solutions is: