[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [GENERAL] Missing WAL files - file-based replication
From:       Scott Briggs <scott.br () gmail ! com>
Date:       2013-04-30 6:20:53
Message-ID: CADKfymEP_OqYYGUHCQR9YPX4siA848LkgtCBiJPYTTy5m_Ev7Q () mail ! gmail ! com
[Download RAW message or body]

Tom, thanks for the quick reply.

Unfortunately, rebuilding the backup server from the master is not really
an option at this point.  This is a fairly large database (~1TB), are there
any other options that will allow us to get the backup server to ingest WAL
files without database corruption?

Thanks,
Scott


On Sun, Apr 28, 2013 at 11:22 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Scott Briggs <scott.br@gmail.com> writes:
> > So we're using 8.3 with file-based replication using rsync to a warm
> backup
> > server.  The problem is the backup server crashed and somehow WAL files
> got
> > lost so the backup server is continuously looking for WAL files that are
> no
> > longer available on the master.
>
> > My question is, how can I skip to a set WAL file so that the recovery
> > process can start ingesting WAL files again?  I realize there's going to
> be
> > a certain amount of data loss but that's not as important as getting the
> > backup server processing log files, in other words I don't care about the
> > data loss.
>
> There isn't any way to do that, and even if there were I wouldn't
> recommend it, because you wouldn't just end up with "lost" data, you'd
> end up with corrupted data.  Indexes in particular would probably be
> unusably inconsistent, leading to wrong answers, occasional PANICs
> on the backup server, etc.
>
> I'd recommend re-syncing the backup to the master using a fresh base
> backup.  Yeah, it's more work, but you'll have an actual backup not
> a useless pile of inconsistent bits.
>
>                         regards, tom lane
>

[Attachment #3 (text/html)]

<div dir="ltr">Tom, thanks for the quick reply.<div><br></div><div>Unfortunately, \
rebuilding the backup server from the master is not really an option at this point.  \
This is a fairly large database (~1TB), are there any other options that will allow \
us to get the backup server to ingest WAL files without database corruption?</div> \
<div><br></div><div style>Thanks,</div><div style>Scott</div></div><div \
class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 28, 2013 at 11:22 \
AM, Tom Lane <span dir="ltr">&lt;<a href="mailto:tgl@sss.pgh.pa.us" \
target="_blank">tgl@sss.pgh.pa.us</a>&gt;</span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="im">Scott Briggs &lt;<a \
href="mailto:scott.br@gmail.com">scott.br@gmail.com</a>&gt; writes:<br> &gt; So \
we&#39;re using 8.3 with file-based replication using rsync to a warm backup<br> &gt; \
server.  The problem is the backup server crashed and somehow WAL files got<br> &gt; \
lost so the backup server is continuously looking for WAL files that are no<br> &gt; \
longer available on the master.<br> <br>
&gt; My question is, how can I skip to a set WAL file so that the recovery<br>
&gt; process can start ingesting WAL files again?  I realize there&#39;s going to \
be<br> &gt; a certain amount of data loss but that&#39;s not as important as getting \
the<br> &gt; backup server processing log files, in other words I don&#39;t care \
about the<br> &gt; data loss.<br>
<br>
</div>There isn&#39;t any way to do that, and even if there were I wouldn&#39;t<br>
recommend it, because you wouldn&#39;t just end up with &quot;lost&quot; data, \
you&#39;d<br> end up with corrupted data.  Indexes in particular would probably \
be<br> unusably inconsistent, leading to wrong answers, occasional PANICs<br>
on the backup server, etc.<br>
<br>
I&#39;d recommend re-syncing the backup to the master using a fresh base<br>
backup.  Yeah, it&#39;s more work, but you&#39;ll have an actual backup not<br>
a useless pile of inconsistent bits.<br>
<br>
                        regards, tom lane<br>
</blockquote></div><br></div>



[prev in list] [next in list] [prev in thread] [next in thread]