On Fri, May 30, 2008 at 9:31 AM, Marko Kreen <markokr@gmail.com> wrote:
> On 5/30/08, Gurjeet Singh <singh.gurjeet@gmail.com> wrote:
>>
>> I think it would be best to not make the slave interfere with the master's
>> operations; that's only going to increase the operational complexity of such
>> a solution.
>
> I disagree - it's better to consider syncronized WAL-slaves
> as equal to master, so having queries there affect master is ok.
>
> You need to remeber this solution tries not to replace 100-node Slony-I
> setups. You can run sanity checks on slaves or use them to load-balance
> read-only OLTP queries, but not random stuff.
>
>> There could be multiple slaves following a master, some serving
>> data-warehousing queries, some for load-balancing reads, some others just
>> for disaster recovery, and then some just to mitigate human errors by
>> re-applying the logs with a delay.
>
> To run warehousing queries you better use Slony-I / Londiste. For
> warehousring you want different / more indexes on tables anyway,
> so I think it's quite ok to say "don't do it" for complex queries
> on WAL-slaves.
>
>> I don't think any one installation would see all of the above mentioned
>> scenarios, but we need to take care of multiple slaves operating off of a
>> single master; something similar to cascaded Slony-I.
>
> Again, the synchronized WAL replication is not generic solution.
> Use Slony/Londiste if you want to get totally independent slaves.
I strongly agree with Gurjeet. The warm standby replication mechanism
is pretty simple and is wonderfully flexible with the one big
requirement that your clusters have to be mirrors of each other.
Synchronous wal replication obviously needs some communication channel
from the slave back to the master. Hopefully, it will be possible to
avoid this for asynchronous shipping.
merlin
