Greg Stark wrote:
> What would be useful is a tool which given a list of standby
> databases and list of base backup images can apply a set of policy
> rules to determine which base backups and archived logs to delete.
>
> The policy might look something like "keep one base backup per
> week go
On Thu, Jan 21, 2010 at 1:48 AM, Josh Berkus wrote:
>> Huh? *Archived* segments aren't supposed to get deleted, at least not
>> by any automatic Postgres action. It would be up to the DBA how long
>> he wants to keep them around.
>
> OK. The docs indicated that the segments needed to be kept ar
On Thu, Jan 21, 2010 at 10:48 AM, Josh Berkus wrote:
> Presumably, however, if the slave falls sufficiently behind and there
> are no archive logs, then the slave would not be able to resynch with
> the master, no?
In that case, we would need to make a fresh backup of the primary,
and start the s
> Huh? *Archived* segments aren't supposed to get deleted, at least not
> by any automatic Postgres action. It would be up to the DBA how long
> he wants to keep them around.
OK. The docs indicated that the segments needed to be kept around in
case the slave fell behind. If that's not the cas
Mark Kirkwood wrote:
The likely typical use case for streaming replication makes a good
case and automated safe way of pruning these guys
Sorry, stupid typo: should read '...makes a good case for an automated
safe way of pruning these'
--
Sent via pgsql-hackers mailing list (pgsql-ha
Tom Lane wrote:
Mark Kirkwood writes:
Josh Berkus wrote:
Sure, but if the archived WAL segments are NOT needed, how are they
supposed to get deleted? It doesn't take long to run out of disk space
if they're not being rotated.
From what I am seeing at the moment (8.5 devel
Mark Kirkwood writes:
> Josh Berkus wrote:
>> Sure, but if the archived WAL segments are NOT needed, how are they
>> supposed to get deleted? It doesn't take long to run out of disk space
>> if they're not being rotated.
> From what I am seeing at the moment (8.5 devel from 2 days ago), the
>
Josh Berkus wrote:
Thanks Dimitri, I'd missed that thread. Ok, slave will need a suitable
restore_comand in addition to primary_conninfo in recovery.conf, and
then extended communication failures (or shutting down the slave for a
while!) will not break the streaming setup (FWIW I tried this just
> Thanks Dimitri, I'd missed that thread. Ok, slave will need a suitable
> restore_comand in addition to primary_conninfo in recovery.conf, and
> then extended communication failures (or shutting down the slave for a
> while!) will not break the streaming setup (FWIW I tried this just now).
Sure,
I've been having a look at this, one master + one replica and also one
master + 2 replicas. I gotta say this is a nice piece of functionality
(particularly the multiple replicas).
I've been using the wiki page
(http://wiki.postgresql.org/wiki/Streaming_Replication) as a guide, and
I notice th
Dimitri Fontaine wrote:
Mark Kirkwood writes:
I've been using the wiki page
(http://wiki.postgresql.org/wiki/Streaming_Replication) as a guide, and I
notice that it recommends the master (and replicas) have a non-trivial
archive_command even after the backup step is completed. ISTM that afte
Mark Kirkwood writes:
> I've been using the wiki page
> (http://wiki.postgresql.org/wiki/Streaming_Replication) as a guide, and I
> notice that it recommends the master (and replicas) have a non-trivial
> archive_command even after the backup step is completed. ISTM that after the
> backup the mas
I've been having a look at this, one master + one replica and also one
master + 2 replicas. I gotta say this is a nice piece of functionality
(particularly the multiple replicas).
I've been using the wiki page
(http://wiki.postgresql.org/wiki/Streaming_Replication) as a guide, and
I notice th
13 matches
Mail list logo
