Re: Hot standby problems: consistent state not reached, no connection to master server.

On Tue, 14 Apr 2015 10:34:29 +0000
Sameer Kumar <sameer.kumar@ashnik.com> wrote:

Problem solved, thanks for attention.

>  On Tue, 14 Apr 2015 11:59 Ilya Ashchepkov <koctep@gmail.com> wrote:
>
> On Mon, 13 Apr 2015 12:24:11 -0700
> Adrian Klaver <adrian.klaver@aklaver.com> wrote:
>
> > On 04/13/2015 11:25 AM, Ilya Ashchepkov wrote:
> > > On Mon, 13 Apr 2015 10:06:05 -0700
> > > Adrian Klaver <adrian.klaver@aklaver.com> wrote:
> > >
> > >> On 04/13/2015 09:42 AM, Ilya Ashchepkov wrote:
> > >>> On Sun, 12 Apr 2015 17:30:44 -0700
> > >>> Adrian Klaver <adrian.klaver@aklaver.com> wrote:
> > >>>
> > >>
> > >>>>>>
> > >>>>>
> >
> > >>>> If a connection is not being made:
> > >>>>
> > >>>> 1) Dose user replication have REPLICATION rights?
> > >>>> 2) Is the pg_hba.conf on the master set up to allow a
> > >>>> connection from the standby for user replication and database
> > >>>> replication?
> > >>>
> > >>> I commented 'restore_command' in recovery.conf and after start
> > >>> slave connected to master.
> > >>> Then I uncomment it back. Is it possible to have a both,
> > >>> streaming connection and restoring from wal files from NFS
> > >>> share?
> > >>
> > >> Yes:
> > >>
> > >>
> http://www.postgresql.org/docs/9.3/interactive/warm-standby.html#STREAMING-REPLICATION
> > >>
> > >> I wonder if your master is recycling WALs fast enough that the
> > >> streaming can't find them and the standby has to go to the
> > >> archive instead.
> > >>
> > >> What is your wal_keep_segments on the master set to?:
> > > # select name,setting from pg_settings where name like
> > > 'wal_keep_segments'; name        | setting
> > > -------------------+---------
> > >   wal_keep_segments | 128
> > >
> > >
> > > I run tcpdump -ni eth0 port 5432 on slave and didn't see any
> > > packet from slave to master after restart.
> >
> > Just to be clear:
> >
> > 1) When you comment out the restore_command the standby connects to
> > the master, correct?
>
> Yes.
>
> >
> > 2) When you uncomment restore_command you do not see a standby
> > connection, correct?
>
> Yes.
>
> >
> > So:
> >
> > 1) When you are changing the restore_command status do you restart
> > the standby server?
>
> Yes.
>
> >
> > 2) What does  select * from pg_stat_replication show, in either
> > case?
> >
> >
> www.postgresql.org/docs/9.3/static/monitoring-stats.html#PG-STAT-REPLICATION-VIEW
>
> 0 rows on master
> 0 rows on slave
>
> >
> > 3) I may have missed it, but what is your archive_command on the
> > master?
>
> # select name,setting from pg_settings where name like
> 'archive_command'; name       |
> setting
> -----------------+----------------------------------------------------------------------------
> archive_command | test ! -f /media/psqlbak/wals/main/%f && cp
> %p /media/psqlbak/wals/main/%f
>
> >
> > >
> > >>
> > >>
> http://www.postgresql.org/docs/9.3/interactive/runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-SENDER
> > >>
> > >>>
> > >>>>
> > >>>> Where are the WAL files coming from?
> > >>>
> > >>> NFS share on master.
> >
> >
>
>
>
> Can you share the cluster log for your standby database and also your
> primary database? Sorry if you have already shared it and I have
> missed it. If there is an error in connection there are good chances
> that some hint about it must be logged. Generally the logs will be
> placed in pg_log inside your data directory. And log_collector must
> be set to on.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>