Re: Missing WALs when doing pg_basebackup from slave...

From: Venkata Balaji N <nag1010(at)gmail(dot)com>
To: marin(at)kset(dot)org
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Missing WALs when doing pg_basebackup from slave...
Date: 2015-06-11 04:48:44
Message-ID: CAEyp7J98N0_UNJURr2kM-kTfHGRf1EhynaUHQjOuwkDwNW-FRw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Jun 10, 2015 at 6:47 PM, <marin(at)kset(dot)org> wrote:

Is it normal that pg_basebackup runs successfully (rc=0) and there is no
> WAL files present?
>

Yes, it is normal. "pg_basebackup" ensures that required WALs are backed
along with the data directory. This is to ensure backup is consistent.

> The master and slave are sitting idle, after only a few transaction on the
> master at the beginning of the day. I noted that all WAL switches are
> caused by the backup running on the master. Is it possible the slave is in
> a consistent state when it has applied all changes from the previous WAL
> and the new WAL hasn't been created yet on the master (so actually no WAL-s
> are needed to restore it to a consistent state)?
>

I am not sure if I got your question correct. The amount of transactions in
the master database may be low or high, the WALs will be replicated to
slave.
To ensure slave is receiving all the WALs, you need to check the sync
status between master and slave. If there is no new WAL generated at
master, then slave must be in consistent state should have applied all the
previous WALs, if not, then all the previous WALs are needed to get the
slave to a consistent state. Nothing can be advised straight without
knowing your replication configuration/architecture details.

Regards,
Venkata Balaji N

Fujitsu Australia

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message marin 2015-06-11 06:00:20 Re: Missing WALs when doing pg_basebackup from slave...
Previous Message Noah Misch 2015-06-11 02:16:34 Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1