Slony-I is intended to be an add-on to postgres and not part of the core. The reason for this is that slony upgrades are supposed to be separate from database upgrades. This allows you to use switchover to minimise the downtime of an upgrade. To upgrade from postgres 8.0 to 8.1 (currently running slony 1.1.2 on all databases, I think), we will be doing the following:
Upgrade to slony 1.1.5 at all nodes simultaneously (should require no more than 5 minutes of slony outage). This does not affect the production database at all.
Wait for slony to catch back up.
Pause replication, again not affecting production.
Upgrade subscriber database to 8.1 (full dump and restore required, or just drop the subscriber db, attach a new 8.1 subscriber db and do a sync).
Unpause replication.
Wait for slony to catch-up.
Switchover from the 8.0 database to the 8.1 database (just a few minutes of downtime).
Pause slony.
Upgrade the original provider database to 8.1.
The versions of slony at both the provider and subscriber must be compatible at all times. Keeping slony versioning separated from the versioning of postgres makes this much easier.
I have used slony-I, Mammoth Replicator, Oracle Advanced Replication, an early version of Oracle Streams in 10g (don't know if it's still called that), and an Oracle third-party replication scheme that I can not currently remember the name of.
Of them all, I would choose slony almost every time. Yes, you have to have a data design with PKs. As a fan or the relational model I think that's generally a good thing. But for those cases where you don't have a PK, slony lets you add one. Painlessly.
I have found building a slony replicated cluster to be way easier than with any other system. I have used slony's switchover in a live environment to upgrade the database, the server and the hardware, with only a 6 minute outage. I administer a 24*7 web-based site and hardly ever have to touch the database or slony.
It's way better than you make out. And if your database design really requires you not to have PKs, then you don't understand relational modelling.
Slony-I does not support multi-master, or synchronous replication. It is not designed to do so. It would be great to have this capability for Postgres but its lack should not be cause to criticise slony-I.
Yes, access to the source matters. Not because you want to hack it, but because you may want to put a debugger on it to track down a problem. With Oracle you don't have that option.
Instead you call Oracle support who ask a lot of questions. You answer the questions, they ask for a database dump. You spend time organising this only to be told that it's too big for them to deal with. You demand help. They ask more questions. You get nowhere.
I have been through this process many times. I have been an Oracle DBA since version 7, and a developer since version 5. I much prefer postgres. When things break, I can track down the problem myself. I probably can't fix it but I can provide useful information to those that can.
That is worth so much more to me than the ability to talk to an 'expert' at Oracle support.
Slashdot Mirror
Slony-I is intended to be an add-on to postgres and not part of the core. The reason for this is that slony upgrades are supposed to be separate from database upgrades. This allows you to use switchover to minimise the downtime of an upgrade. To upgrade from postgres 8.0 to 8.1 (currently running slony 1.1.2 on all databases, I think), we will be doing the following:
Upgrade to slony 1.1.5 at all nodes simultaneously (should require no more than 5 minutes of slony outage). This does not affect the production database at all.
Wait for slony to catch back up.
Pause replication, again not affecting production.
Upgrade subscriber database to 8.1 (full dump and restore required, or just drop the subscriber db, attach a new 8.1 subscriber db and do a sync).
Unpause replication.
Wait for slony to catch-up.
Switchover from the 8.0 database to the 8.1 database (just a few minutes of downtime).
Pause slony.
Upgrade the original provider database to 8.1.
The versions of slony at both the provider and subscriber must be compatible at all times. Keeping slony versioning separated from the versioning of postgres makes this much easier.
I have used slony-I, Mammoth Replicator, Oracle Advanced Replication, an early version of Oracle Streams in 10g (don't know if it's still called that), and an Oracle third-party replication scheme that I can not currently remember the name of.
Of them all, I would choose slony almost every time. Yes, you have to have a data design with PKs. As a fan or the relational model I think that's generally a good thing. But for those cases where you don't have a PK, slony lets you add one. Painlessly.
I have found building a slony replicated cluster to be way easier than with any other system. I have used slony's switchover in a live environment to upgrade the database, the server and the hardware, with only a 6 minute outage. I administer a 24*7 web-based site and hardly ever have to touch the database or slony.
It's way better than you make out. And if your database design really requires you not to have PKs, then you don't understand relational modelling.
Slony-I does not support multi-master, or synchronous replication. It is not designed to do so. It would be great to have this capability for Postgres but its lack should not be cause to criticise slony-I.
Yes, access to the source matters. Not because you want to hack it, but because you may want to put a debugger on it to track down a problem. With Oracle you don't have that option.
Instead you call Oracle support who ask a lot of questions. You answer the questions, they ask for a database dump. You spend time organising this only to be told that it's too big for them to deal with. You demand help. They ask more questions. You get nowhere.
I have been through this process many times. I have been an Oracle DBA since version 7, and a developer since version 5. I much prefer postgres. When things break, I can track down the problem myself. I probably can't fix it but I can provide useful information to those that can.
That is worth so much more to me than the ability to talk to an 'expert' at Oracle support.