no pg_hba.conf entry for replication connection from host
I have been configuring a slave server that needs to connect to the host.
Both the master and the standby servers have a pg_hba.conf that looks like
this:
# Allow anyone to connect remotely so long as they have a valid
username and
# password.
host replication ${REP_USER} 0.0.0.0/0 md5
host ${DB_NAME} ${DB_USER} 0.0.0.0/0 md5
This should allow access from every IP address, right? Evidently, though,
the standby server cannot connect using the REP_USER credentials via
`primary_conninfo`
primary_conninfo = 'host=${MASTER_PORT_5432_TCP_ADDR} port=5432
user=${REP_USER} password=${REP_PASS}'
I know this doesn't work because I never see in my logs:
LOG: streaming replication successfully connected to primary
Instead, what I see is
LOG: database system was interrupted; last known up at 2015-04-09
16:35:05 GMT
LOG: entering standby mode
LOG: redo starts at 0/E000028
LOG: consistent recovery state reached at 0/E0000F0
What am I doing wrong?
--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://bit.ly/1h1ebjy>
Three things:
1.
0.0.0.0 has the specific meaning "unspecified". So you really should
enter the specific ip address for the slave in the master pg_hba.conf.
2.
Is ${REP_USER} defined on BOTH master & slave?
IS ${REP_USER} defined as a valid user that can login in the database?
3.
I do not know of any case where I've seen a variable in a pg_hba.conf,
nor is it defined as a valid option in the documentation. You should
specify the replication user directly, which is usually postgres.
eg:
host replication postgres 999.1.1.1/32 md5
note: replace 999.1.1.1/32 with actual ip of slave.
After you have made changes:
in psql
SELECT pg_reload_conf();
Then check the postgres log on the master to verify connectcion.
On 4/9/15, Volkan Unsal <spocksplanet@gmail.com> wrote:
I have been configuring a slave server that needs to connect to the host.
Both the master and the standby servers have a pg_hba.conf that looks like
this:# Allow anyone to connect remotely so long as they have a valid
username and
# password.
host replication ${REP_USER} 0.0.0.0/0 md5
host ${DB_NAME} ${DB_USER} 0.0.0.0/0 md5This should allow access from every IP address, right? Evidently, though,
the standby server cannot connect using the REP_USER credentials via
`primary_conninfo`primary_conninfo = 'host=${MASTER_PORT_5432_TCP_ADDR} port=5432
user=${REP_USER} password=${REP_PASS}'I know this doesn't work because I never see in my logs:
LOG: streaming replication successfully connected to primary
Instead, what I see is
LOG: database system was interrupted; last known up at 2015-04-09
16:35:05 GMT
LOG: entering standby mode
LOG: redo starts at 0/E000028
LOG: consistent recovery state reached at 0/E0000F0What am I doing wrong?
--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://bit.ly/1h1ebjy>
--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 04/09/2015 10:15 AM, Volkan Unsal wrote:
I have been configuring a slave server that needs to connect to the
host. Both the master and the standby servers have a pg_hba.conf that
looks like this:# Allow anyone to connect remotely so long as they have a valid
username and
# password.
host replication ${REP_USER} 0.0.0.0/0 <http://0.0.0.0/0>
md5
host ${DB_NAME} ${DB_USER} 0.0.0.0/0 <http://0.0.0.0/0>
md5This should allow access from every IP address, right? Evidently,
though, the standby server cannot connect using the REP_USER credentials
via `primary_conninfo`primary_conninfo = 'host=${MASTER_PORT_5432_TCP_ADDR} port=5432
user=${REP_USER} password=${REP_PASS}'I know this doesn't work because I never see in my logs:
LOG: streaming replication successfully connected to primary
Instead, what I see is
LOG: database system was interrupted; last known up at 2015-04-09
16:35:05 GMT
LOG: entering standby mode
LOG: redo starts at 0/E000028
LOG: consistent recovery state reached at 0/E0000F0What am I doing wrong?
What interface is the primary database listening on?
listen_addresses (string)
Can you connect remotely from the standby using psql?
--
*Volkan Unsal*
/web and mobile development/
volkanunsal.com <http://bit.ly/1h1ebjy>
--
Adrian Klaver
adrian.klaver@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi Melvin,
0.0.0.0 has the specific meaning "unspecified". So you really should
enter the specific ip address for the slave in the master pg_hba.conf.
I tried this, but I am getting this error when I do that:
FATAL: no pg_hba.conf entry for replication connection from host
"104.131.66.183", user "rep", SSL off
DETAIL: Could not resolve client IP address to a host name: Name or
service not known.
Is ${REP_USER} defined on BOTH master & slave?
IS ${REP_USER} defined as a valid user that can login in the database?
Yes, the variables are defined in the environment for both master and
slave. These variables are passed through a preprocessor and replaced with
their actual values. But the REP_USER only exists in the master database.
--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://bit.ly/1h1ebjy>
HI Adrian,
Can you connect remotely from the standby using psql?
Yes, I can connect directly from the standby using psql and DB_USER and
DB_PASS.
--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://bit.ly/1h1ebjy>
On 04/09/2015 12:05 PM, Volkan Unsal wrote:
HI Adrian,
Can you connect remotely from the standby using psql?
Yes, I can connect directly from the standby using psql and DB_USER and
DB_PASS.
And you are sure the REP_USER is being correctly substituted in and that
it has the REPLICATION attribute.
Have you tried the primary_conninfo with the values directly entered?
http://www.postgresql.org/docs/9.4/interactive/sql-createrole.html
postgres@test=# create role rep_user with login replication;
CREATE ROLE
postgres@test=# \du rep_user
List of roles
Role name | Attributes | Member of
-----------+-------------+-----------
rep_user | Replication | {}
Also what file do you have primary_conninfo in?
--
*Volkan Unsal*
/web and mobile development/
volkanunsal.com <http://bit.ly/1h1ebjy>
--
Adrian Klaver
adrian.klaver@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
So did you make the following entry in pg_hba,conf?
host replication rep 104.131.66.183/32 md5
Is rep a valid postgres user in the cluster?
Did you remember to do:
SELECT pg_reload_conf();
After making the changes to pg_hba.conf?
On 4/9/15, Volkan Unsal <spocksplanet@gmail.com> wrote:
HI Adrian,
Can you connect remotely from the standby using psql?
Yes, I can connect directly from the standby using psql and DB_USER and
DB_PASS.--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://bit.ly/1h1ebjy>
--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi Adrian,
I can confirm that the REP_USER is a role with replication attribute in the
master
Role name | Attributes | Member of
-------------+------------------------------------------------+-----------
postgres | Superuser, Create role, Create DB, Replication | {}
replication | Replication +| {}
| 4 connections |
Also what file do you have primary_conninfo in?
This setting is in ${PGDATA}/recovery.conf and looks like this:
primary_conninfo = 'host=${MASTER_PORT_5432_TCP_ADDR} port=5432
user=${REP_USER} password=${REP_PASS}'
On Thu, Apr 9, 2015 at 3:16 PM, Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
On 04/09/2015 12:05 PM, Volkan Unsal wrote:
HI Adrian,
Can you connect remotely from the standby using psql?
Yes, I can connect directly from the standby using psql and DB_USER and
DB_PASS.And you are sure the REP_USER is being correctly substituted in and that
it has the REPLICATION attribute.Have you tried the primary_conninfo with the values directly entered?
http://www.postgresql.org/docs/9.4/interactive/sql-createrole.html
postgres@test=# create role rep_user with login replication;
CREATE ROLEpostgres@test=# \du rep_user
List of roles
Role name | Attributes | Member of
-----------+-------------+-----------
rep_user | Replication | {}Also what file do you have primary_conninfo in?
--
*Volkan Unsal*
/web and mobile development/
volkanunsal.com <http://bit.ly/1h1ebjy>--
Adrian Klaver
adrian.klaver@aklaver.com
--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://bit.ly/1h1ebjy>
On 04/09/2015 12:32 PM, Volkan Unsal wrote:
Hi Adrian,
I can confirm that the REP_USER is a role with replication attribute in
the masterRole name | Attributes | Member of
-------------+------------------------------------------------+-----------
postgres | Superuser, Create role, Create DB, Replication | {}
replication | Replication +| {}
| 4 connections |Also what file do you have primary_conninfo in?
This setting is in ${PGDATA}/recovery.conf and looks like this:
primary_conninfo = 'host=${MASTER_PORT_5432_TCP_ADDR} port=5432
user=${REP_USER} password=${REP_PASS}'
Best guess is something is not working properly in turning the ${}
variables into actual values.
What happens if you do not use the variable notation and use the actual
values in the above string?
Also what do the standby server logs show while you are trying to connect?
On Thu, Apr 9, 2015 at 3:16 PM, Adrian Klaver <adrian.klaver@aklaver.com
<mailto:adrian.klaver@aklaver.com>> wrote:On 04/09/2015 12:05 PM, Volkan Unsal wrote:
HI Adrian,
Can you connect remotely from the standby using psql?
Yes, I can connect directly from the standby using psql and
DB_USER and
DB_PASS.And you are sure the REP_USER is being correctly substituted in and
that it has the REPLICATION attribute.Have you tried the primary_conninfo with the values directly entered?
http://www.postgresql.org/__docs/9.4/interactive/sql-__createrole.html
<http://www.postgresql.org/docs/9.4/interactive/sql-createrole.html>postgres@test=# create role rep_user with login replication;
CREATE ROLEpostgres@test=# \du rep_user
List of roles
Role name | Attributes | Member of
-----------+-------------+----__-------
rep_user | Replication | {}Also what file do you have primary_conninfo in?
--
*Volkan Unsal*
/web and mobile development/
volkanunsal.com <http://volkanunsal.com> <http://bit.ly/1h1ebjy>--
Adrian Klaver
adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>--
*Volkan Unsal*
/web and mobile development/
volkanunsal.com <http://bit.ly/1h1ebjy>
--
Adrian Klaver
adrian.klaver@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi Melvin,
When I make this entry
host replication rep 104.131.66.183/32 md5
It complains that it cannot have both CIDR and mask number and fails to
start –– I assume it's referring to /32 –– and when I remove that it starts
alright, but it doesn't accept replication connections from that IP address.
(Also I changed REP_USER to "replication" in latest examples, but it's
consistent in both master and slave.)
| Did you remember to do: SELECT pg_reload_conf();
Yes, in a manner of speaking. The database is in a Docker container, so I'm
recreating the container everytime I change something in the configuration.
:)
On Thu, Apr 9, 2015 at 3:20 PM, Melvin Davidson <melvin6925@gmail.com>
wrote:
So did you make the following entry in pg_hba,conf?
host replication rep 104.131.66.183/32 md5
Is rep a valid postgres user in the cluster?
Did you remember to do:
SELECT pg_reload_conf();After making the changes to pg_hba.conf?
On 4/9/15, Volkan Unsal <spocksplanet@gmail.com> wrote:
HI Adrian,
Can you connect remotely from the standby using psql?
Yes, I can connect directly from the standby using psql and DB_USER and
DB_PASS.--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://bit.ly/1h1ebjy>--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://bit.ly/1h1ebjy>
HI Adrian,
Also what do the standby server logs show while you are trying to connect?
The logs show that pg_basebackup competed successfully. But then something
goes wrong.
LOG: database system was interrupted; last known up at 2015-04-09 19:22:50
GMT
LOG: entering standby mode
LOG: redo starts at 0/A000028
LOG: consistent recovery state reached at 0/A0000F0
--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://bit.ly/1h1ebjy>
Hi Amit,
My postgresql.conf file in the standby server looks like this:
wal_level = hot_standby
hot_standby = on
max_standby_streaming_delay = 15min
In the master server, it looks like this:
listen_addresses = '*'
wal_level = hot_standby
max_wal_senders = 10
max_connections=100
checkpoint_segments = 8
wal_keep_segments = 8
archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/archive/%f'
In my logs, I see this line just before the server enters the standby mode:
LOG: database system was interrupted; last known up at 2015-04-09 19:22:50
GMT
LOG: entering standby mode
On Thu, Apr 9, 2015 at 3:41 PM, pgorg_aav <kahitarich-postgresorg@yahoo.com>
wrote:
Can you share your postgresql.conf settings?
do you have the following set:
hot_standby = onThis is what i get for streaming in the log file:
00000:2015-04-09 15:32:05 EDT::@:[8792]:[2-1] LOG: entering standby mode
scp: x8= snipped =8x /pg_xlog_archive/00000001000000180000004A: No such
file or directory
scp failed
00000:2015-04-09 15:32:05 EDT::@:[8792]:[3-1] LOG: redo starts at
18/4AEA6740
00000:2015-04-09 15:32:05 EDT::@:[8792]:[4-1] LOG: consistent recovery
state reached at 18/4AF0F7A8
00000:2015-04-09 15:32:05 EDT::@:[8792]:[5-1] LOG: invalid record length
at 18/4AF0F7A8
00000:2015-04-09 15:32:05 EDT::@:[8786]:[4-1] LOG: database system is
ready to accept read only connections
00000:2015-04-09 15:32:05 EDT::@:[8804]:[1-1] LOG: started streaming WAL
from primary at 18/4A000000 on timeline 1Regards,
Amit VardeOn Thursday, April 9, 2015 3:20 PM, Melvin Davidson <
melvin6925@gmail.com> wrote:So did you make the following entry in pg_hba,conf?
host replication rep 104.131.66.183/32 md5
Is rep a valid postgres user in the cluster?
Did you remember to do:
SELECT pg_reload_conf();After making the changes to pg_hba.conf?
On 4/9/15, Volkan Unsal <spocksplanet@gmail.com> wrote:
HI Adrian,
Can you connect remotely from the standby using psql?
Yes, I can connect directly from the standby using psql and DB_USER and
DB_PASS.--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://bit.ly/1h1ebjy>--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://bit.ly/1h1ebjy>
Import Notes
Reply to msg id not found: 1596252065.1385092.1428608470125.JavaMail.yahoo@mail.yahoo.com
On 04/09/2015 12:39 PM, Volkan Unsal wrote:
Hi Melvin,
When I make this entry
host replication rep 104.131.66.183/32
<http://104.131.66.183/32> md5It complains that it cannot have both CIDR and mask number and fails to
start –– I assume it's referring to /32 –– and when I remove that it
starts alright, but it doesn't accept replication connections from that
IP address.
The above looks alright, I would expect the complaint if you did
something like this:
host replication rep 104.131.66.183/32 255.255.255.255 md5
(Also I changed REP_USER to "replication" in latest examples, but it's
consistent in both master and slave.)
The other variables where changed also?
| Did you remember to do: SELECT pg_reload_conf();
Yes, in a manner of speaking. The database is in a Docker container, so
I'm recreating the container everytime I change something in the
configuration. :)
Hmm, that is another variable in the mix. So more information is in order.
1) What version(s) of Postgres are you using on either end?
2) Are the primary and the standby in different containers?
3) What is the container/machine/network layout?
On Thu, Apr 9, 2015 at 3:20 PM, Melvin Davidson <melvin6925@gmail.com
<mailto:melvin6925@gmail.com>> wrote:So did you make the following entry in pg_hba,conf?
host replication rep 104.131.66.183/32
<http://104.131.66.183/32> md5Is rep a valid postgres user in the cluster?
Did you remember to do:
SELECT pg_reload_conf();After making the changes to pg_hba.conf?
On 4/9/15, Volkan Unsal <spocksplanet@gmail.com
<mailto:spocksplanet@gmail.com>> wrote:HI Adrian,
Can you connect remotely from the standby using psql?
Yes, I can connect directly from the standby using psql and DB_USER and
DB_PASS.--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://volkanunsal.com> <http://bit.ly/1h1ebjy>--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.--
*Volkan Unsal*
/web and mobile development/
volkanunsal.com <http://bit.ly/1h1ebjy>
--
Adrian Klaver
adrian.klaver@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 04/09/2015 12:46 PM, Volkan Unsal wrote:
Hi Amit,
My postgresql.conf file in the standby server looks like this:
wal_level = hot_standby
hot_standby = on
max_standby_streaming_delay = 15minIn the master server, it looks like this:
listen_addresses = '*'
wal_level = hot_standby
max_wal_senders = 10
max_connections=100
checkpoint_segments = 8
wal_keep_segments = 8
archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/archive/%f'
So in your recovery.conf is standby_mode set to on?
--
Adrian Klaver
adrian.klaver@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi Adrian,
1) What version(s) of Postgres are you using on either end?
I'm using Postgres 9:3.
2) Are the primary and the standby in different containers?
Yes, and they are on different servers as well.
3) What is the container/machine/network layout?
I created a gist of all the files in my setup.
https://gist.github.com/volkanunsal/ad2173e2649393fcd3b6
The init-slave.sh and init-master.sh scripts are executed before the server
is started, so that's where I do all my preprocessing of conf files. I
checked the results and the substituted values are indeed correct.
--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://bit.ly/1h1ebjy>
Hi Adrian,
So in your recovery.conf is standby_mode set to on?
Yes, here is that entire file:
standby_mode = 'on'
primary_conninfo = 'host=${MASTER_PORT_5432_TCP_ADDR} port=5432
user=${REP_USER} password=${REP_PASS}'
trigger_file = '/tmp/promote_db_slave'
On Thu, Apr 9, 2015 at 3:56 PM, Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
On 04/09/2015 12:46 PM, Volkan Unsal wrote:
Hi Amit,
My postgresql.conf file in the standby server looks like this:
wal_level = hot_standby
hot_standby = on
max_standby_streaming_delay = 15minIn the master server, it looks like this:
listen_addresses = '*'
wal_level = hot_standby
max_wal_senders = 10
max_connections=100
checkpoint_segments = 8
wal_keep_segments = 8
archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/archive/%f'So in your recovery.conf is standby_mode set to on?
--
Adrian Klaver
adrian.klaver@aklaver.com
--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://bit.ly/1h1ebjy>
On 04/09/2015 01:00 PM, Volkan Unsal wrote:
Hi Adrian,
1) What version(s) of Postgres are you using on either end?
I'm using Postgres 9:3.
2) Are the primary and the standby in different containers?
Yes, and they are on different servers as well.
3) What is the container/machine/network layout?
I created a gist of all the files in my setup.
https://gist.github.com/volkanunsal/ad2173e2649393fcd3b6
The init-slave.sh and init-master.sh scripts are executed before the
server is started, so that's where I do all my preprocessing of conf
files. I checked the results and the substituted values are indeed correct.
Well if I am understanding. This:
primary_conninfo = 'host=${MASTER_PORT_5432_TCP_ADDR} port=5432
is getting translated to:
host=0.0.0.0 port=5432
Now the primary can receive connections from 0.0.0.0, which basically
means it can receive from the Internet. The problem is that the standby
can not connect to 0.0.0.0, that would mean it is connecting to the
whole Internet. You will need to provide either the actual IP for the
primary or its hostname.
--
*Volkan Unsal*
/web and mobile development/
volkanunsal.com <http://bit.ly/1h1ebjy>
--
Adrian Klaver
adrian.klaver@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Oops. I used a dummy IP address in the yml file for privacy reasons. The
actual IP addresses would be placed there in my setup. The pg_basebackup
connection to the MASTER_PORT_5432_TCP_ADDR is successful, so I know that
slave can connect to the master at least. But it just cannot open a
streaming backup connection...
On Thu, Apr 9, 2015 at 4:11 PM, Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
On 04/09/2015 01:00 PM, Volkan Unsal wrote:
Hi Adrian,
1) What version(s) of Postgres are you using on either end?
I'm using Postgres 9:3.
2) Are the primary and the standby in different containers?
Yes, and they are on different servers as well.
3) What is the container/machine/network layout?
I created a gist of all the files in my setup.
https://gist.github.com/volkanunsal/ad2173e2649393fcd3b6
The init-slave.sh and init-master.sh scripts are executed before the
server is started, so that's where I do all my preprocessing of conf
files. I checked the results and the substituted values are indeed
correct.Well if I am understanding. This:
primary_conninfo = 'host=${MASTER_PORT_5432_TCP_ADDR} port=5432
is getting translated to:
host=0.0.0.0 port=5432
Now the primary can receive connections from 0.0.0.0, which basically
means it can receive from the Internet. The problem is that the standby can
not connect to 0.0.0.0, that would mean it is connecting to the whole
Internet. You will need to provide either the actual IP for the primary or
its hostname.--
*Volkan Unsal*
/web and mobile development/
volkanunsal.com <http://bit.ly/1h1ebjy>--
Adrian Klaver
adrian.klaver@aklaver.com
--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://bit.ly/1h1ebjy>
On 04/09/2015 01:14 PM, Volkan Unsal wrote:
Oops. I used a dummy IP address in the yml file for privacy reasons. The
actual IP addresses would be placed there in my setup. The pg_basebackup
connection to the MASTER_PORT_5432_TCP___ADDR is successful, so I know
that slave can connect to the master at least. But it just cannot open a
streaming backup connection...
Yeah, that would have been too easy:) I am not seeing anything else at
the moment.
On Thu, Apr 9, 2015 at 4:11 PM, Adrian Klaver <adrian.klaver@aklaver.com
<mailto:adrian.klaver@aklaver.com>> wrote:On 04/09/2015 01:00 PM, Volkan Unsal wrote:
Hi Adrian,
1) What version(s) of Postgres are you using on either end?
I'm using Postgres 9:3.
2) Are the primary and the standby in different containers?
Yes, and they are on different servers as well.
3) What is the container/machine/network layout?
I created a gist of all the files in my setup.
https://gist.github.com/__volkanunsal/__ad2173e2649393fcd3b6
<https://gist.github.com/volkanunsal/ad2173e2649393fcd3b6>The init-slave.sh and init-master.sh scripts are executed before the
server is started, so that's where I do all my preprocessing of conf
files. I checked the results and the substituted values are
indeed correct.Well if I am understanding. This:
primary_conninfo = 'host=${MASTER_PORT_5432_TCP___ADDR} port=5432
is getting translated to:
host=0.0.0.0 port=5432
Now the primary can receive connections from 0.0.0.0, which
basically means it can receive from the Internet. The problem is
that the standby can not connect to 0.0.0.0, that would mean it is
connecting to the whole Internet. You will need to provide either
the actual IP for the primary or its hostname.--
*Volkan Unsal*
/web and mobile development/
volkanunsal.com <http://volkanunsal.com> <http://bit.ly/1h1ebjy>--
Adrian Klaver
adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>--
*Volkan Unsal*
/web and mobile development/
volkanunsal.com <http://bit.ly/1h1ebjy>
--
Adrian Klaver
adrian.klaver@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Thanks for giving it a shot, Adrian. I'm scouring the Postgres source code
looking for some inspiration around the error message "database system was
interrupted". Let me know if you can think of anything else.
On Thu, Apr 9, 2015 at 4:32 PM, Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
On 04/09/2015 01:14 PM, Volkan Unsal wrote:
Oops. I used a dummy IP address in the yml file for privacy reasons. The
actual IP addresses would be placed there in my setup. The pg_basebackup
connection to the MASTER_PORT_5432_TCP___ADDR is successful, so I know
that slave can connect to the master at least. But it just cannot open a
streaming backup connection...Yeah, that would have been too easy:) I am not seeing anything else at the
moment.On Thu, Apr 9, 2015 at 4:11 PM, Adrian Klaver <adrian.klaver@aklaver.com
<mailto:adrian.klaver@aklaver.com>> wrote:On 04/09/2015 01:00 PM, Volkan Unsal wrote:
Hi Adrian,
1) What version(s) of Postgres are you using on either end?
I'm using Postgres 9:3.
2) Are the primary and the standby in different containers?
Yes, and they are on different servers as well.
3) What is the container/machine/network layout?
I created a gist of all the files in my setup.
https://gist.github.com/__volkanunsal/__ad2173e2649393fcd3b6
<https://gist.github.com/volkanunsal/ad2173e2649393fcd3b6>The init-slave.sh and init-master.sh scripts are executed before
the
server is started, so that's where I do all my preprocessing of
conf
files. I checked the results and the substituted values are
indeed correct.Well if I am understanding. This:
primary_conninfo = 'host=${MASTER_PORT_5432_TCP___ADDR} port=5432
is getting translated to:
host=0.0.0.0 port=5432
Now the primary can receive connections from 0.0.0.0, which
basically means it can receive from the Internet. The problem is
that the standby can not connect to 0.0.0.0, that would mean it is
connecting to the whole Internet. You will need to provide either
the actual IP for the primary or its hostname.--
*Volkan Unsal*
/web and mobile development/
volkanunsal.com <http://volkanunsal.com> <http://bit.ly/1h1ebjy>--
Adrian Klaver
adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>--
*Volkan Unsal*
/web and mobile development/
volkanunsal.com <http://bit.ly/1h1ebjy>--
Adrian Klaver
adrian.klaver@aklaver.com
--
*Volkan Unsal*
*web and mobile development*
volkanunsal.com <http://bit.ly/1h1ebjy>