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?
2) When you uncomment restore_command you do not see a standby
connection, correct?
So:
1) When you are changing the restore_command status do you restart the
standby server?
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
3) I may have missed it, but what is your archive_command on the master?
>
>>
>> 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.
--
Adrian Klaver
adrian.klaver@aklaver.com