Re: Time-Delayed Standbys

From: Mitsumasa KONDO <kondo(dot)mitsumasa(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp>, fabriziomello(at)gmail(dot)com, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Time-Delayed Standbys
Date: 2013-12-04 13:47:47
Message-ID: CADupcHU+WAaadvaX3MOETZd6LBXnog15pdD8_sWU94PNiUDHmg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2013/12/4 Andres Freund <andres(at)2ndquadrant(dot)com>

> On 2013-12-04 11:13:58 +0900, KONDO Mitsumasa wrote:
> > >4) Start the slave and connect to it using psql and in another session
> I can see
> > >all archive recovery log
> > Hmm... I had thought my mistake in reading your email, but it reproduce
> again.
> > When I sat small recovery_time_delay(=30000), it might work collectry.
> > However, I sat long timed recovery_time_delay(=3000000), it didn't work.
>
> > My reporduced operation log is under following.
> > >[mitsu-ko(at)localhost postgresql]$ bin/pgbench -T 30 -c 8 -j4 -p5432
> > >starting vacuum...end.
> > >transaction type: TPC-B (sort of)
> > >scaling factor: 10
> > >query mode: simple
> > >number of clients: 8
> > >number of threads: 4
> > >duration: 30 s
> > >number of transactions actually processed: 68704
> > >latency average: 3.493 ms
> > >tps = 2289.196747 (including connections establishing)
> > >tps = 2290.175129 (excluding connections establishing)
> > >[mitsu-ko(at)localhost postgresql]$ vim slave/recovery.conf
> > >[mitsu-ko(at)localhost postgresql]$ bin/pg_ctl -D slave start
> > >server starting
> > >[mitsu-ko(at)localhost postgresql]$ LOG: database system was shut down
> in recovery at 2013-12-03 10:26:41 JST
> > >LOG: entering standby mode
> > >LOG: consistent recovery state reached at 0/5C4D8668
> > >LOG: redo starts at 0/5C4000D8
> > >[mitsu-ko(at)localhost postgresql]$ FATAL: the database system is
> starting up
> > >FATAL: the database system is starting up
> > >FATAL: the database system is starting up
> > >FATAL: the database system is starting up
> > >FATAL: the database system is starting up
> > >[mitsu-ko(at)localhost postgresql]$ bin/psql -p6543
> > >psql: FATAL: the database system is starting up
> > >[mitsu-ko(at)localhost postgresql]$ bin/psql -p6543
> > >psql: FATAL: the database system is starting up
> > I attached my postgresql.conf and recovery.conf. It will be reproduced.
>
> So, you brought up a standby and it took more time to become consistent
> because it waited on commits? That's the problem? If so, I don't think
> that's a bug?
>
When it happened, psql cannot connect standby server at all. I think this
behavior is not good.
It should only delay recovery position and can seen old delay table data.
Cannot connect server is not hoped behavior.
If you think this behavior is the best, I will set ready for commiter. And
commiter will fix it better.

Rregards,
--
Mitsumasa KONDO
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Boszormenyi Zoltan 2013-12-04 13:51:19 Re: Review: ECPG infrastructure changes part 1, was: Re: ECPG fixes
Previous Message Tom Lane 2013-12-04 13:46:24 Re: ruleutils vs. empty targetlists