Part of the issue is that there is no such thing as "simple" replication unless one means "unreliable" replication. Simple replication is just shooting off the same SQL insert/update query on two servers. In the best scenario, that means that if you use a time function, you're likely to get two different results. In the worst case, it fails on one server and data gets out of sync.
Really, it's not that PostgreSQL needs more replication or built-in replication. It needs better replication than any of the current solutions. pgpool, while great as a connection pooler, is a terrible replication solution. Slony-I is based off triggers and its communication costs grow in quadratically (O(n^2) - yuck!). Plus, Slony-I requires an immense amount of setup for every table and every key. Mammoth replicator, which seems to be the closest to the right track, has a website that doesn't show much life and only a beta release for download. Plus, it still looks like there's a good amount of setup.
What we all really want is for PostgreSQL to implement a log-shipping based replication system where we can say "replicate this database" or "replicate these tables" to another server and have it just work. But there's nothing simple about that.
I completely agree there's nothing simple about that, but ever since we switched from Slony-I to Londiste at Justin.tv I couldn't be happier. It's been completely bulletproof, recovers from errors easily, and makes schema upgrades a breeze.
Postgres already has a asynchronous log shipping replication system similar to MySQL's, but the rub is that you can't read from the slave, so it's only good as a "warm standby" solution.
Work was happening to make it possible to read from the slave, and this was meant to go into 8.4. However, there were some issues and it got pulled from the release.
Hopefully we'll see it in 8.5. This is the only real way MySQL is beating Postgres at the moment.
Comments
Part of the issue is that there is no such thing as "simple" replication unless one means "unreliable" replication. Simple replication is just shooting off the same SQL insert/update query on two servers. In the best scenario, that means that if you use a time function, you're likely to get two different results. In the worst case, it fails on one server and data gets out of sync.
Really, it's not that PostgreSQL needs more replication or built-in replication. It needs better replication than any of the current solutions. pgpool, while great as a connection pooler, is a terrible replication solution. Slony-I is based off triggers and its communication costs grow in quadratically (O(n^2) - yuck!). Plus, Slony-I requires an immense amount of setup for every table and every key. Mammoth replicator, which seems to be the closest to the right track, has a website that doesn't show much life and only a beta release for download. Plus, it still looks like there's a good amount of setup.
What we all really want is for PostgreSQL to implement a log-shipping based replication system where we can say "replicate this database" or "replicate these tables" to another server and have it just work. But there's nothing simple about that.
I completely agree there's nothing simple about that, but ever since we switched from Slony-I to Londiste at Justin.tv I couldn't be happier. It's been completely bulletproof, recovers from errors easily, and makes schema upgrades a breeze.
What do you think about Londiste (https://developer.skype.com/SkypeGarage/DbProjects/SkyTools)?
Postgres already has a asynchronous log shipping replication system similar to MySQL's, but the rub is that you can't read from the slave, so it's only good as a "warm standby" solution.
Work was happening to make it possible to read from the slave, and this was meant to go into 8.4. However, there were some issues and it got pulled from the release.
Hopefully we'll see it in 8.5. This is the only real way MySQL is beating Postgres at the moment.