Re: Time-Delayed Standbys

Поиск
Список
Период
Сортировка
От Mitsumasa KONDO
Тема Re: Time-Delayed Standbys
Дата
Msg-id CADupcHU+WAaadvaX3MOETZd6LBXnog15pdD8_sWU94PNiUDHmg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Time-Delayed Standbys  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Time-Delayed Standbys
Список pgsql-hackers

2013/12/4 Andres Freund <andres@2ndquadrant.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@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@localhost postgresql]$ vim slave/recovery.conf
> >[mitsu-ko@localhost postgresql]$ bin/pg_ctl -D slave start
> >server starting
> >[mitsu-ko@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@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@localhost postgresql]$ bin/psql -p6543
> >psql: FATAL:  the database system is starting up
> >[mitsu-ko@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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ruleutils vs. empty targetlists
Следующее
От: Boszormenyi Zoltan
Дата:
Сообщение: Re: Review: ECPG infrastructure changes part 1, was: Re: ECPG fixes