Jan Wieck | 1 Dec 2008 23:29
Picon
Favicon

Re: Log Shipping fails after Switchover

On 12/1/2008 6:21 PM, Troy Wolf wrote:
> First, a question that I know has been asked before, but after
> grepping and perusing months of the maillist archives, I did not find
> the answer: Why is it required to use a Subscriber to generate log
> files? Why can't the Origin slon process be started with the option to
> generate logs? It just so happens that in my case, I have an Origin
> and a normal Subscriber and a third node that I replicate via Log
> Shipping. However, I imagine lots of people would have a need for a
> single Origin and a single, WAN-connected node they want to replicate
> via Log Shipping.
> 
> And now onto the issue at hand...
> 
> PostgreSQL 8.2 on SUSE ES 10
> Slony1-1.2.12
> 
> The documentation at http://slony.info/documentation/logshipping.html states:
> ----------------------------------------------------------------------------------------------------------------------------
> 
> 14.2. What takes place when a FAILOVER/ MOVE SET takes place?
> 
> Nothing special. So long as the archiving node remains a subscriber,
> it will continue to generate logs.
> 
> If the archiving node becomes the origin, on the other hand, it will
> continue to generate logs.
> 
> ----------------------------------------------------------------------------------------------------------------------------
> Hmmm..."If the archiving node becomes the origin, on the other hand,
> it will continue to generate logs.". Yes, indeed, it continues to
(Continue reading)

Troy Wolf | 2 Dec 2008 03:54

Re: Log Shipping fails after Switchover

Thanks for the reply, Jan!

On Mon, Dec 1, 2008 at 4:29 PM, Jan Wieck <JanWieck@...> wrote:
> Well, it certainly is a bug that it continues to generate logs ... we will
> see to fix it and stop it from creating useless files.
>

So you confirm the 14.2 documentation is incorrect. That part will be
easy to fix at least! :)

> The reason is the same as for not being able to create such a setup in the
> first place. Log shipping is implemented as a byproduct of the normal
> replication process done by a subscriber. That includes keeping track of
> what has been replicated thus far.

I say this with limited knowledge of how Slony works under the hood,
but it seems obvious that the Slony origin knows about all the changes
because it communicates them to the subscriber, right? In any case,
yes, the ability to generate log files directly from the origin would
be useful to people I think.

Can you speak to Slony II and it's Log Shipping capabilities? Is Log
Shipping improved, enhanced, or otherwise in version 2?
Jan Wieck | 2 Dec 2008 05:48
Picon
Favicon

Re: Log Shipping fails after Switchover

On 12/1/2008 9:54 PM, Troy Wolf wrote:
> Thanks for the reply, Jan!
> 
> On Mon, Dec 1, 2008 at 4:29 PM, Jan Wieck <JanWieck@...> wrote:
>> Well, it certainly is a bug that it continues to generate logs ... we will
>> see to fix it and stop it from creating useless files.
>>
> 
> So you confirm the 14.2 documentation is incorrect. That part will be
> easy to fix at least! :)
> 
>> The reason is the same as for not being able to create such a setup in the
>> first place. Log shipping is implemented as a byproduct of the normal
>> replication process done by a subscriber. That includes keeping track of
>> what has been replicated thus far.
> 
> I say this with limited knowledge of how Slony works under the hood,
> but it seems obvious that the Slony origin knows about all the changes
> because it communicates them to the subscriber, right? In any case,
> yes, the ability to generate log files directly from the origin would
> be useful to people I think.

The information is all there, that much is true.

The original idea was to create a separate process that "acts" like 
another node based on a "spool node", which the origin never connects 
to. That separate process would then write those logs.

> Can you speak to Slony II and it's Log Shipping capabilities? Is Log
> Shipping improved, enhanced, or otherwise in version 2?
(Continue reading)


Gmane