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

2015-04-14 Thread Adrian Klaver

On 04/13/2015 01:05 PM, Guillaume Lelarge wrote:

Le 12 avr. 2015 16:50, "Ilya Ashchepkov" mailto:koc...@gmail.com>> a écrit :
 >



 > restore_command = '/usr/lib/postgresql/9.3/bin/pg_standby -t
/tmp/pgsql.trigger.5432 /media/psqlbak/101/wals/main/ %f %p %r'
 >

Don't use pg_standby if you want to use streaming. Use cp, scp, rsync,
or anything else but not pg_standby. Streaming starts when archive
recovery fails to get next archive.



I have not used pg_standby, so the above was helpful. I now see that 
warning in the docs:


http://www.postgresql.org/docs/9.3/static/warm-standby.html

25.2.4. Setting Up a Standby Server

"Note: Do not use pg_standby or similar tools with the built-in standby 
mode described here. restore_command should return immediately if the 
file does not exist; the server will retry the command again if 
necessary. See Section 25.4 for using tools like pg_standby."


Going to section 25.4 explained a lot. Thanks for the information.



--
Adrian Klaver
adrian.kla...@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


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

2015-04-13 Thread Guillaume Lelarge
Le 12 avr. 2015 16:50, "Ilya Ashchepkov"  a écrit :
>
> 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'
>

Don't use pg_standby if you want to use streaming. Use cp, scp, rsync, or
anything else but not pg_standby. Streaming starts when archive recovery
fails to get next archive.

> 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?
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general


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

2015-04-12 Thread Adrian Klaver

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








--
Adrian Klaver
adrian.kla...@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