On Tue, 14 Apr 2015 10:34:29 +0000 Sameer Kumar <sameer.kumar@xxxxxxxxxx> wrote: Problem solved, thanks for attention. > On Tue, 14 Apr 2015 11:59 Ilya Ashchepkov <koctep@xxxxxxxxx> wrote: > > On Mon, 13 Apr 2015 12:24:11 -0700 > Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote: > > > On 04/13/2015 11:25 AM, Ilya Ashchepkov wrote: > > > On Mon, 13 Apr 2015 10:06:05 -0700 > > > Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote: > > > > > >> On 04/13/2015 09:42 AM, Ilya Ashchepkov wrote: > > >>> On Sun, 12 Apr 2015 17:30:44 -0700 > > >>> Adrian Klaver <adrian.klaver@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
