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

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: Re: Hot standby problems: consistent state not reached, no connection to master server.
Дата
Msg-id 552B0E34.80607@aklaver.com
обсуждение исходный текст
Ответ на Re: Hot standby problems: consistent state not reached, no connection to master server.  (Ilya Ashchepkov <koctep@gmail.com>)
Список pgsql-general
On 04/12/2015 08:25 AM, Ilya Ashchepkov wrote:
> On Sun, 12 Apr 2015 08:10:48 -0700
> Adrian Klaver <adrian.klaver@aklaver.com> wrote:
>
>> On 04/12/2015 07:47 AM, Ilya Ashchepkov wrote:
>>> Hello.
>>>
>>> I'm setting up hot standby slave.
>>> It recovers from wal archive files, but I can't connect to it:
>>> $ psql
>>> psql: FATAL:  the database system is starting up
>>>
>>> On master:
>>> # select name,setting from pg_settings where name like 'wal_level';
>>>      name    |   setting
>>> -----------+-------------
>>>    wal_level | hot_standby
>>>
>>>
>>> My slave recovery.conf:
>>> $ cat recovery.conf
>>> # Note that recovery.conf must be in $PGDATA directory.
>>> # It should NOT be located in the same directory as postgresql.conf
>>>
>>> # Specifies whether to start the server as a standby. In streaming
>>> replication, # this parameter must to be set to on.
>>> standby_mode          = 'on'
>>>
>>> # Specifies a connection string which is used for the standby
>>> server to connect # with the primary.
>>> primary_conninfo      = 'host=192.168.0.101 port=5432
>>> user=replication password=*'
>>>
>>> # Specifies a trigger file whose presence should cause streaming
>>> replication to # end (i.e., failover).
>>> trigger_file = '/media/psqlbak/101/main/standup'
>>>
>>> # Specifies a command to load archive segments from the WAL
>>> archive. If # wal_keep_segments is a high enough number to retain
>>> the WAL segments # required for the standby server, this may not be
>>> necessary. But # a large workload can cause segments to be recycled
>>> before the standby # is fully synchronized, requiring you to start
>>> again from a new base backup. restore_command =
>>> '/usr/lib/postgresql/9.3/bin/pg_standby
>>> -t /tmp/pgsql.trigger.5432 /media/psqlbak/101/wals/main/ %f %p %r'
>>>
>>> I tried to comment 'restore_command' in recovery.conf on slave,
>>> then slave connects to master and starts receiving data, but I
>>> think it's not very good way. What should I change to receive data
>>> through connection and reach consistent state on slave?
>>
>> What have you set for hot_standby on the standby server?:
>>
>> http://www.postgresql.org/docs/9.3/interactive/runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-STANDBY
>>
>
> Oh! I missed this! Thank you!
> Now slave reached consistent state some time after start, but still no
> connection to master server and still restoring wal-files.

Not quite sure what you are getting at.

You are not seeing the streaming connection happening?

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?

Where are the WAL files coming from?

>
>>>
>>>
>>>
>>
>>
>
>
>
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com


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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Benchmarking partitioning triggers and rules
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Help with slow table update