Re: [GENERAL] wired problem for a 9.1 slave:receive wal but do not replay it?

From: Soni M <diptatapa(at)gmail(dot)com>
To: Jov <amutu(at)amutu(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: [GENERAL] wired problem for a 9.1 slave:receive wal but do not replay it?
Date: 2014-08-12 19:56:40
Message-ID: CAAMgDXmhzmvBW9U0fQabNWgtMbtRctrhpdnrvHpeJpG+X=RoVA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Do you run intensive read query on slave ?
If yes, query conflict can cause that,
http://www.postgresql.org/docs/9.1/static/hot-standby.html#HOT-STANDBY-CONFLICT
On conflict, xlog stream will be saved on xlog dir on slave instead of
replaying it. This happen until slave has opportunity to write all xlog
into disk.

On Mon, Aug 11, 2014 at 5:24 PM, Jov <amutu(at)amutu(dot)com> wrote:

> Today,our monitor report a pg slave instance'disk space usage reach 96%,I
> login in to the machine,and find the pg_xlog dir take up more than
> 2TB,which is abnormal.
> the number of WAL file in the pg_xlog dir is more than 130k,while we set
> the wal keep number to 8192.
> I think there is something stop the replay,so I check the
> pg_stat_activity,pg_prepare_statement,pg_xact etc,but find all normal.
> I run:
> ps auxwww | grep postgres
> and can find the wal receiver and streaming receiver work happily,because
> the wal file name,the streaming log id changed.
>
> So I have no idea.
>
> I then restart the slave PG,and find it recover from a very old wal which
> is one month ago.
> We are now set up a new slave for the master while let the recover from
> this slave go.
>
> the PG version is 9.1.9,OS is CentOS 6 x86-64.
>
> Jov
> blog: http:amutu.com/blog <http://amutu.com/blog>
>

--
Regards,

Soni Maula Harriz

In response to

Browse pgsql-general by date

  From Date Subject
Next Message pinker 2014-08-12 21:41:19 Database block lifecycle
Previous Message Adrian Klaver 2014-08-12 19:13:51 Re: pgcluu