Обсуждение: stand by is starting until I do some work in the primary
Today I reinstall a pg extension,then restart the primary and slave. the primary is OK and I can login,and the pg_stat_replication view show the slave is connected.
but when I try to login the slave,it shows:
FATAL:the database system is starting up
I wait several minutes,but it still show the same error. and the primary is no activities,the xlog dir in slave have only 2 WAL files,WAL receiver is there and seams do nothing.I try to restart the slave several times,but nothing help.I even try to use pg_xlogdump to analyze the 2 WAL files,but find nothing abnormal.
But,when I login to the primary,run:
create table xx as select * from big_table.
It produce many WAL，and then the slave became normal and I can login.
it is instresting.I always think that when the pg_stat_replication show the slave there,it means the slave is OK and can be send read stmt.We have some monitor use this and some udf get the alived slave for client read.Now I find I'm wrong.
Any comment？
Jov
blog: http:amutu.com/blog
On Sun, Feb 23, 2014 at 12:18 PM, Jov <amutu@amutu.com> wrote:
Today I reinstall a pg extension,then restart the primary and slave. the primary is OK and I can login,and the pg_stat_replication view show the slave is connected.but when I try to login the slave,it shows:FATAL:the database system is starting upI wait several minutes,but it still show the same error. and the primary is no activities,the xlog dir in slave have only 2 WAL files,WAL receiver is there and seams do nothing.I try to restart the slave several times,but nothing help.I even try to use pg_xlogdump to analyze the 2 WAL files,but find nothing abnormal.But,when I login to the primary,run:create table xx as select * from big_table.It produce many WAL，and then the slave became normal and I can login.it is instresting.I always think that when the pg_stat_replication show the slave there,it means the slave is OK and can be send read stmt.We have some monitor use this and some udf get the alived slave for client read.Now I find I'm wrong.Any comment？
Hot_standby parameter should be turned on at slave postresql.conf, is that checked ?
Jovblog: http:amutu.com/blog
Sure.Before the restart,I have login in the slave many times.
some more info ,but I don't think related:
centOS 6 ,amd64,128GB memory,24 core, pgsql-9.3.3,master and slave in the same host.
this is my first instance of 9.3，I don't exprence this before on 9.0~9.2.
Jov
blog: http:amutu.com/blog
2014-02-23 15:01 GMT+08:00 Raghavendra <raghavendra.rao@enterprisedb.com>:
On Sun, Feb 23, 2014 at 12:18 PM, Jov <amutu@amutu.com> wrote:Today I reinstall a pg extension,then restart the primary and slave. the primary is OK and I can login,and the pg_stat_replication view show the slave is connected.but when I try to login the slave,it shows:FATAL:the database system is starting upI wait several minutes,but it still show the same error. and the primary is no activities,the xlog dir in slave have only 2 WAL files,WAL receiver is there and seams do nothing.I try to restart the slave several times,but nothing help.I even try to use pg_xlogdump to analyze the 2 WAL files,but find nothing abnormal.But,when I login to the primary,run:create table xx as select * from big_table.It produce many WAL，and then the slave became normal and I can login.it is instresting.I always think that when the pg_stat_replication show the slave there,it means the slave is OK and can be send read stmt.We have some monitor use this and some udf get the alived slave for client read.Now I find I'm wrong.Any comment？Hot_standby parameter should be turned on at slave postresql.conf, is that checked ?Jovblog: http:amutu.com/blog
On Sun, Feb 23, 2014 at 8:25 AM, Jov <amutu@amutu.com> wrote:
Sure.Before the restart,I have login in the slave many times.some more info ,but I don't think related:centOS 6 ,amd64,128GB memory,24 core, pgsql-9.3.3,master and slave in the same host.this is my first instance of 9.3，I don't exprence this before on 9.0~9.2.
It will probably work again after a CHECKPOINT (manual or automatic), if there is *some* activity on the master. You may be experiencing what the patch ed46758381ff63a422fcb0b1f2763eb13273640f, which will be included in 9.4. But the workaround is to make sure something happens on the master and do a checkpoint.
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/