Re: PG replication across DataCenters

>> > * Quick and easy movement of the master to any of the database in
>> >
>> > the cluster without destroying replication.
>> >
>> > Again, which version? Re-mastering is made simple in v9.3.

>> I'm not seeing that in the documentation. In fact, what I'm finding
>> seems to suggest the opposite: that each node's master is configured
>> in a config file, so in the case of a complicated replication setup,
>> I would have to run around editing config files on multiple servers
>> to move the master ... unless I'm missing something in the documentation.

Well, the pain can be minimized if you can write some simple shell scripts
for this. Or if you can have a floating/virtual IP.

>>> * Seeding of new slaves without interrupting existing nodes (assuming
>>>
>>> your hardware has a little free capacity)
>>>
>>> AFAIK, streaming replication does not cause any interruption while you
add
>>> a new node.

>>The process is still significantly more involved than Slony's subscription
>>commands. In our lab setups, I've watched junior DBA's fail time and time
>>again to get a proper seed with streaming replication.

Try the pg_basebackup options in v9.3. Creating a streaming replica has
been made easy. It's still a little painful if you want to move your WALs
to a different LUW/HDD on your replica

>>> I think if it's slony or streaming replication will depend on below
factors:
>>>
>>> 1) The change-set that you want to replicate contributes how much of
your
>>> total change set? e.g. on a per minute basis if it's 70% or above, I
will
>>> recommend you to go for streaming replication

>>While this is a strong argument in favor of streaming over Slony, the
>>70% number seems rather arbitrary, and you're advocating that this point
>>alone is enough to outweight the other advantages of Slony, which may be
>>more important in a particular case.

I gave an example. It will definately vary from case to case and
implementation to implementation.

>>> 4) To some extent your choice will be influenced by the motivation
behind
>>> replication, DR, HA, reporting application (esp if you are particular
about
>>> replicating only selective tables for reports)

>>In my experience, this is usually the largest factor.

>>>To some extent your choice will be influenced <<<
Let me correct myself:
To a large extent your choice will be influnced :)

>>Once argument in favor of streaming that you missed is when you have no
>>control over the schema (for example, when it's 3rd party, like an
openfire
>>database). In those cases, the application frequently omits things like
>>primary keys (which are required for slony) and has an upgrade process
that
>>assumes it can change database tables without impacting anything else.

That's a good one and quite apt too!

Regards
Sameer
Ashnik Pte. Ltd.
Singapore