Re: PG replication across DataCenters - Mailing list pgsql-general
| From | Sameer Kumar |
|---|---|
| Subject | Re: PG replication across DataCenters |
| Date | |
| Msg-id | CADp-Sm4YH6-0Qj8LeW==omZFaF4DAjB0vjF3PQk0uM_qsTb_Vw@mail.gmail.com Whole thread Raw |
| In response to | Re: PG replication across DataCenters (Bill Moran <wmoran@potentialtech.com>) |
| Responses |
Re: PG replication across DataCenters
(Bill Moran <wmoran@potentialtech.com>)
|
| List | pgsql-general |
>> > * 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
pgsql-general by date: