On Mon, Sep 28, 2015 at 12:53:37PM -0600, Scott Marlowe wrote:
> The issue was reported as omnipitr-cleanup is SLOOOW, so we run
> purgewal by hand, because the cleanup is so slow it can't keep up. But
> running it by hand is not supported.
>
> We fixed the problem though, we wrote out own script
On Mon, Sep 28, 2015 at 9:12 AM, Keith Fiske wrote:
>
>
> On Mon, Sep 28, 2015 at 10:54 AM, Scott Marlowe
> wrote:
>>
>> On Mon, Sep 28, 2015 at 8:48 AM, CS DBA
>> wrote:
>> > All;
>> >
>> > We have a 3 node replication
On Mon, Sep 28, 2015 at 8:48 AM, CS DBA wrote:
> All;
>
> We have a 3 node replication setup:
>
> Master (node1) --> Cascading Replication Node (node2) --> Downstream
> Standby node (node3)
>
> We will be deploying WAL archiving from the master for PITR backups and
>
On Mon, Sep 28, 2015 at 10:54 AM, Scott Marlowe
wrote:
> On Mon, Sep 28, 2015 at 8:48 AM, CS DBA
> wrote:
> > All;
> >
> > We have a 3 node replication setup:
> >
> > Master (node1) --> Cascading Replication Node (node2) --> Downstream
> >
On Mon, Sep 28, 2015 at 08:54:54AM -0600, Scott Marlowe wrote:
> Look up WAL-E. It's works really well. We tried using OmniPITR and
> it's buggy and doesn't seem to get fixed very quickly (if at all).
Any examples? I'm developer of OmniPITR, and as far as I know there are
(currently) no unfixed
All;
We have a 3 node replication setup:
Master (node1) --> Cascading Replication Node (node2) --> Downstream
Standby node (node3)
We will be deploying WAL archiving from the master for PITR backups and
we'll use the staged WAL files in the recovery.conf files in case the
standbys need to