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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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 buti 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 = 60sWhat 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.
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
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 buti 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 = 60sWhat 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.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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 trustthank you in advance,
SvenWAL 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general