Thread: postgresql 9.4 streaming replication

I have the following problem: i am trying to set up a streaming
replication scenario with load balancing. I read various tutorials but
i cannot find the mistake. The replication does not work. I do not
have a "wal sender/receiver process". The archiving works and
everytime the master restarts, the archived wal files are copied to
the slave. I even do not get any error. And in configuration file(s)
everything looks like fine for me, e.g. master:

wal_level = hot_standby
wal_keep_segments = 32
max_wal_senders = 5
max_replication_slots = 5
wal_sender_timeout = 60s

What irritates me the most is that there is no "wal sender process"
and there is no error thrown.

Thank you for any idea,
Sven

My client recovery.conf looks this way:

standby_mode = 'on'
primary_conninfo = 'host=arcserver1 port=5432 user=postgres pass=postgres'
restore_command = 'pg_standby /db/pg_archived %f %p >> /var/log/standby.log'
primary_slot_name='standby1'


Zitat von Andreas Kretschmer <andreas@a-kretschmer.de>:

> Do you have a client with a propper recovery.conf running?
>
> Am 19. Oktober 2015 09:58:40 MESZ, schrieb "Sven Löschner" <sven@someko.de>:
>> I have the following problem: i am trying to set up a streaming
>> replication scenario with load balancing. I read various tutorials but
>>
>> i cannot find the mistake. The replication does not work. I do not
>> have a "wal sender/receiver process". The archiving works and
>> everytime the master restarts, the archived wal files are copied to
>> the slave. I even do not get any error. And in configuration file(s)
>> everything looks like fine for me, e.g. master:
>>
>> wal_level = hot_standby
>> wal_keep_segments = 32
>> max_wal_senders = 5
>> max_replication_slots = 5
>> wal_sender_timeout = 60s
>>
>> What irritates me the most is that there is no "wal sender process"
>> and there is no error thrown.
>>
>> Thank you for any idea,
>> Sven
>>
>>
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

I inserted the following in my pg_hba.conf to test, but it does not work:

host    replication     rep_user        0.0.0.0/0                 trust
host    all             postgres        0.0.0.0/0                 trust

thank you in advance,
Sven

> WAL sender process starts when streaming client is active. The connection
> is initiated by the client. That's why you cannot see it. It also uses the
> TCP-port that is used by any other pg client. There is a special entry in
> the pg_hba.conf for the replication clients. Refer to this please:
> http://www.postgresql.org/docs/9.4/static/auth-pg-hba-conf.html.
>
> cheers
> Matthias

On 19 October 2015 at 09:41, Sven Löschner <sven@someko.de> wrote:
> I inserted the following in my pg_hba.conf to test, but it does not work:
>
> host    replication     rep_user        0.0.0.0/0                 trust
> host    all             postgres        0.0.0.0/0                 trust
>
> thank you in advance,
> Sven
>
>> WAL sender process starts when streaming client is active. The connection
>> is initiated by the client. That's why you cannot see it. It also uses the
>> TCP-port that is used by any other pg client. There is a special entry in
>> the pg_hba.conf for the replication clients. Refer to this please:
>> http://www.postgresql.org/docs/9.4/static/auth-pg-hba-conf.html.

Have you checked that the host name you provided resolves to the IP
address you're expecting?  Have you also tried connecting to the
primary server from the standby server manually?

e.g.: psql -h arcserver1 -p 5432 postgres

And perhaps look at the database logs for the standby server to see if
any error messages have come up when trying to connect to the primary.

Thom

On 2015-10-19 08:34:51 +0000, Sven Löschner wrote:
> My client recovery.conf looks this way:
>
> standby_mode = 'on'
> primary_conninfo = 'host=arcserver1 port=5432 user=postgres pass=postgres'
> restore_command = 'pg_standby /db/pg_archived %f %p >> /var/log/standby.log'
> primary_slot_name='standby1'

pg_standby is for a "warm standby" - instead of signalling an error if
an archive file does not exist it'll sleep. Thus this node will never
enter streaming replication. Use cp or something instead.

Greetings,

Andres Freund