Re: Hot Backup with rsync fails at pg_clog if under load

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, linas(dot)virbalas(at)continuent(dot)com
Subject: Re: Hot Backup with rsync fails at pg_clog if under load
Date: 2011-09-21 17:23:49
Message-ID: CA+TgmoYBP-hxL+b3dzFq=9NRLkMMAKAxCn5NXjggask+_Ka5bw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 21, 2011 at 12:22 PM, Euler Taveira de Oliveira
<euler(at)timbira(dot)com> wrote:
> [This question doesn't belong to -hackers. Please post it in -general or
> -admin]

-hackers or -bugs seems appropriate to me; I think this is a bug.

>> 2.2. pg_start_backup(Obackup_under_loadš) on the master (this will take a
>> while as master is loaded up);
>
> No. if you use pg_start_backup('foo', true) it will be fast. Check the
> manual.

If the server is sufficiently heavily loaded that a checkpoint takes a
nontrivial amount of time, the OP is correct that this will be not
fast, regardless of whether you choose to force an immediate
checkpoint.

>> 2.3. rsync data/global/pg_control to the standby;
>
> Why are you doing this? If ...
>
>> 2.4. rsync all other data/ (without pg_xlog) to the standby;
>
> you will copy it again or no? Don't understand your point.

His point is that exercising the bug depends on doing the copying in a
certain order. Any order of copying the data theoretically ought to
be OK, as long as it's all between starting the backup and stopping
the backup, but apparently it isn't.

> The problem could be that the minimum recovery point (step 2.3) is different
> from the end of rsync if you are under load.

It seems pretty clear that some relevant chunk of WAL isn't getting
replayed, but it's not at all clear to me why not. It seems like it
would be useful to compare the LSN returned by pg_start_backup() with
the location at which replay begins when you fire up the clone.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-09-21 17:24:55 Re: sequence locking
Previous Message Andres Freund 2011-09-21 17:15:04 Re: sequence locking