pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
WAL log management w/ multiple slaves
4+ messages / 4 participants
[nested] [flat]

* WAL log management w/ multiple slaves
@ 2014-12-02 18:30 Wells Oliver <wellsoliver@gmail.com>
  2014-12-03 08:30 ` Re: WAL log management w/ multiple slaves Albe Laurenz <laurenz.albe@wien.gv.at>
  2015-03-14 12:01 ` Re: WAL log management w/ multiple slaves jaime soler <jaime.soler@gmail.com>
  0 siblings, 2 replies; 4+ messages in thread

From: Wells Oliver @ 2014-12-02 18:30 UTC (permalink / raw)
  To: pgsql-admin

Hi all. I currently have one master and one slave, and the slave cleans up
the unneeded WAL files via pg_archivecleanup.

I'm adding a third slave and I was wondering what the best practices are in
terms of managing these WAL files when there's more than one dependent
server, in a situation where you can't have a slave removing the files.

I thought I could just cron up a removal of logs older than X days, which
seems pretty easy, but not sure.

Thanks!

-- 
Wells Oliver
wellsoliver@gmail.com

^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: WAL log management w/ multiple slaves
  2014-12-02 18:30 WAL log management w/ multiple slaves Wells Oliver <wellsoliver@gmail.com>
@ 2014-12-03 08:30 ` Albe Laurenz <laurenz.albe@wien.gv.at>
  2014-12-03 10:06   ` Re: WAL log management w/ multiple slaves Vasilis Ventirozos <v.ventirozos@gmail.com>
  1 sibling, 1 reply; 4+ messages in thread

From: Albe Laurenz @ 2014-12-03 08:30 UTC (permalink / raw)
  To: Wells Oliver *EXTERN* <wellsoliver@gmail.com>; pgsql-admin

Wells Oliver wrote:
> Hi all. I currently have one master and one slave, and the slave cleans up the unneeded WAL files via
> pg_archivecleanup.
> 
> I'm adding a third slave and I was wondering what the best practices are in terms of managing these
> WAL files when there's more than one dependent server, in a situation where you can't have a slave
> removing the files.
> 
> I thought I could just cron up a removal of logs older than X days, which seems pretty easy, but not
> sure.

cron would work fine.

My scripts clean up old archived WAL as part of the backup job - that way I can be sure
that no archives are deleted unless they have been backed up first.

Yours,
Laurenz Albe

-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin


^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: WAL log management w/ multiple slaves
  2014-12-02 18:30 WAL log management w/ multiple slaves Wells Oliver <wellsoliver@gmail.com>
  2014-12-03 08:30 ` Re: WAL log management w/ multiple slaves Albe Laurenz <laurenz.albe@wien.gv.at>
@ 2014-12-03 10:06   ` Vasilis Ventirozos <v.ventirozos@gmail.com>
  0 siblings, 0 replies; 4+ messages in thread

From: Vasilis Ventirozos @ 2014-12-03 10:06 UTC (permalink / raw)
  To: Wells Oliver *EXTERN* <wellsoliver@gmail.com>; pgsql-admin

On Wed, Dec 3, 2014 at 10:30 AM, Albe Laurenz <laurenz.albe@wien.gv.at>
wrote:

> Wells Oliver wrote:
> > Hi all. I currently have one master and one slave, and the slave cleans
> up the unneeded WAL files via
> > pg_archivecleanup.
> >
> > I'm adding a third slave and I was wondering what the best practices are
> in terms of managing these
> > WAL files when there's more than one dependent server, in a situation
> where you can't have a slave
> > removing the files.
> >
> > I thought I could just cron up a removal of logs older than X days,
> which seems pretty easy, but not
> > sure.
>
> cron would work fine.
>
> My scripts clean up old archived WAL as part of the backup job - that way
> I can be sure
> that no archives are deleted unless they have been backed up first.
>
> Yours,
> Laurenz Albe
>


check out OmniPITR it rocks when it comes to wal management
https://github.com/omniti-labs/omnipitr

Regards,
Vasilis Ventirozos

^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: WAL log management w/ multiple slaves
  2014-12-02 18:30 WAL log management w/ multiple slaves Wells Oliver <wellsoliver@gmail.com>
@ 2015-03-14 12:01 ` jaime soler <jaime.soler@gmail.com>
  1 sibling, 0 replies; 4+ messages in thread

From: jaime soler @ 2015-03-14 12:01 UTC (permalink / raw)
  To: Wells Oliver <wellsoliver@gmail.com>; +Cc: pgsql-admin

El mar, 02-12-2014 a las 10:30 -0800, Wells Oliver escribió:
> Hi all. I currently have one master and one slave, and the slave
> cleans up the unneeded WAL files via pg_archivecleanup.
> 
> 
> I'm adding a third slave and I was wondering what the best practices
> are in terms of managing these WAL files when there's more than one
> dependent server, in a situation where you can't have a slave removing
> the files.

Maybe you should use new feature of postgresql 9.4, replication slot:

"Replication slots provide an automated way to ensure that the master
does not remove WAL segments until they have been received by all
standbys, and that the master does not remove rows which could cause a
recovery conflict even when the standby is disconnected."
> 
> I thought I could just cron up a removal of logs older than X days,
> which seems pretty easy, but not sure.
> 
> 
> Thanks!
> 
> 
> -- 
> Wells Oliver
> wellsoliver@gmail.com




-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin



^ permalink  raw  reply  [nested|flat] 4+ messages in thread


end of thread, other threads:[~2015-03-14 12:01 UTC | newest]

Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2014-12-02 18:30 WAL log management w/ multiple slaves Wells Oliver <wellsoliver@gmail.com>
2014-12-03 08:30 ` Albe Laurenz <laurenz.albe@wien.gv.at>
2014-12-03 10:06   ` Vasilis Ventirozos <v.ventirozos@gmail.com>
2015-03-14 12:01 ` jaime soler <jaime.soler@gmail.com>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox