postgres-xc-general

[Postgres-xc-general] FATAL: unrecognized recovery parameter "application_name"

[Theodotos A. <th...@ub...>]

Hi guys,

I am using Koichi's HA guide to setup a two node pgxc cluster:

wiki.postgresql.org/images/4/44/Pgxc_HA_20121024.pdf 
<https://duckduckgo.com/k/?u=https%3A%2F%2Fwiki.postgresql.org%2Fimages%2F4%2F44%2FPgxc_HA_20121024.pdf>

I am in page 48 "configuring coordinator slaves"

I have this config:

$ cat CN2/recovery.conf
standby_mode = on
primary_conninfo = 'host = node01 port = 5432 user = postgres-xc'
application_name = 'cnmaster01'
restore_command = 'cp CN2_ArchLog/%f %p'
archive_cleanup_command = 'pg_archivecleanup CN2_ArchLog %r'

$ cat CN2/postgresql.conf
listen_addresses = '*'
port = 5433
max_connections = 150
shared_buffers = 1024MB
work_mem = 64MB
maintenance_work_mem = 400MB
wal_level = hot_standby
synchronous_commit = on
archive_mode = on
archive_command = 'rsync %p node02:CN2_ArchLog/%f'
max_wal_senders = 5
synchronous_standby_names = 'cnmaster01'
hot_standby = on
cpu_tuple_cost = 0.1
effective_cache_size = 2048MB
logging_collector = on
log_rotation_age = 1d
log_rotation_size = 1GB
log_min_duration_statement = 250ms
log_checkpoints = on
log_connections = on
log_disconnections = on
log_lock_waits = on
log_temp_files = 0
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8'
lc_monetary = 'en_US.UTF-8'
lc_numeric = 'en_US.UTF-8'
lc_time = 'en_US.UTF-8'
default_text_search_config = 'pg_catalog.english'
pooler_port = 6668
gtm_host = 'localhost'
gtm_port = 6666
pgxc_node_name = 'cnmaster01'

When I try to start the slave node:

$  pg_ctl start -Z coordinator -D CN2

I get this in the logs:

LOG:  database system was interrupted; last known up at 2013-03-17 
06:29:44 EET
FATAL:  unrecognized recovery parameter "application_name"
LOG:  startup process (PID 6562) exited with exit code 1
LOG:  aborting startup due to startup process failure


Another question:
Why do I have to start the server:
'pg_ctl start -Z coordinator -D coordSlaveDir"

then reconfigure:
"cat >> coordMasterDir/postgresql.conf" <EOF
synchronous_commit = on
synchronous_standby_names = 'coordName'
EOF
"cat >> coordSlaveDir/postgresql.conf" <<EOF
hot_standby = on
port = coordPort
EOF

and then reload?
pg_ctl reload -Z coordinator -D coordMasterDir

Can I just use all the configuration at once and just start the server?

I am using postgres-xc 1.0.2

Re: [Postgres-xc-general] FATAL: unrecognized recovery parameter "application_name"

[Michael P. <mic...@gm...>]

On Sun, Mar 17, 2013 at 3:08 PM, Theodotos Andreou <th...@ub...>wrote:

>  $ cat CN2/recovery.conf
> standby_mode = on
> primary_conninfo = 'host = node01 port = 5432 user = postgres-xc'
> application_name = 'cnmaster01'
> restore_command = 'cp CN2_ArchLog/%f %p'
> archive_cleanup_command = 'pg_archivecleanup CN2_ArchLog %r'
>
application_name is a parameter of the connection string primary_conninfo,
and not an independent parameter. Such a configuration would also not work
with normal Postgres ;)
-- 
Michael

Re: [Postgres-xc-general] FATAL: unrecognized recovery parameter "application_name"

[Theodotos A. <th...@ub...>]

On 03/17/2013 08:25 AM, Michael Paquier wrote:
>
>
> On Sun, Mar 17, 2013 at 3:08 PM, Theodotos Andreou <th...@ub... 
> <mailto:th...@ub...>> wrote:
>
>     $ cat CN2/recovery.conf
>     standby_mode = on
>     primary_conninfo = 'host = node01 port = 5432 user = postgres-xc'
>     application_name = 'cnmaster01'
>     restore_command = 'cp CN2_ArchLog/%f %p'
>     archive_cleanup_command = 'pg_archivecleanup CN2_ArchLog %r'
>
> application_name is a parameter of the connection string 
> primary_conninfo, and not an independent parameter. Such a 
> configuration would also not work with normal Postgres ;)
> -- 
> Michael

I am also a postgresql newbie :)

Thanks Michael

[Postgres-xc-general] Split brain

[Chris B. <cb...@in...>]

Hi all,

I just read through:

wiki.postgresql.org/images/4/44/Pgxc_HA_20121024.pdf<https://duckduckgo.com/k/?u=https%3A%2F%2Fwiki.postgresql.org%2Fimages%2F4%2F44%2FPgxc_HA_20121024.pdf>

and I wanted to know how PG-XC solves the problem of split brain.

For example, let's say there is a pair:
  Box 1: datanode1-master, datanode2-slave, coordinator master, gtm master
  Box 2: datanode1-slave, datanode2-master, coordinator slave, gtm slave
and communication is severed between the two boxes.

Another example:
  Box 1: datanode1-master, datanode2-slave, coordinator master, gtm proxy
  Box 2: datanode1-slave, datanode2-master, coordinator slave, gtm proxy
  Box 3: gtm (no slave exists for simplicity)
and communication is severed between box 1 and 2, but both can still communicate with box 3.  (Or another network outage scenario - there are obviously several.)

Chris...

Re: [Postgres-xc-general] Split brain

[Nikhil S. <ni...@st...>]

Hi Chris,

Split brain is not solved internally by Postgres-XC. It's the job of
an external layer to ensure that such scenarios do not occur.

For example, one can use Corosync/Pacemaker to monitor XC nodes and
then use proper mechanisms to ensure failover and STONITH steps. CS/PM
solve the tricky problem of node membership and consistent cluster
view pretty well.

Regards,
Nikhils

On Tue, Mar 19, 2013 at 2:16 AM, Chris Brown <cb...@in...> wrote:
> Hi all,
>
> I just read through:
>
> wiki.postgresql.org/images/4/44/Pgxc_HA_20121024.pdf
>
> and I wanted to know how PG-XC solves the problem of split brain.
>
> For example, let's say there is a pair:
>   Box 1: datanode1-master, datanode2-slave, coordinator master, gtm master
>   Box 2: datanode1-slave, datanode2-master, coordinator slave, gtm slave
> and communication is severed between the two boxes.
>
> Another example:
>   Box 1: datanode1-master, datanode2-slave, coordinator master, gtm proxy
>   Box 2: datanode1-slave, datanode2-master, coordinator slave, gtm proxy
>   Box 3: gtm (no slave exists for simplicity)
> and communication is severed between box 1 and 2, but both can still
> communicate with box 3.  (Or another network outage scenario - there are
> obviously several.)
>
> Chris...
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>



-- 
StormDB - http://www.stormdb.com
The Database Cloud
Postgres-XC Support and Service

Re: [Postgres-xc-general] Split brain

[Koichi S. <koi...@gm...>]

In this case, even though each node can access to GTM, update
transaction fails. If a transaction is involved by an unreachable
node, such local update fails, and then global update fails.  This
maintains cluster-wide database consistency.   Naturally, if a
transaction is involved only by reachable nodes, such transaction
succeeds and maintains cluster-wide consistency too.

Serious split bran case is: if you run two different GTM at the same
time and try to connect different coordinators to different GTMs.   As
in the case of almost other case, as Nikhil pointed out, this should
be resolved by some external tools.
----------
Koichi Suzuki


2013/3/19 Nikhil Sontakke <ni...@st...>:
> Hi Chris,
>
> Split brain is not solved internally by Postgres-XC. It's the job of
> an external layer to ensure that such scenarios do not occur.
>
> For example, one can use Corosync/Pacemaker to monitor XC nodes and
> then use proper mechanisms to ensure failover and STONITH steps. CS/PM
> solve the tricky problem of node membership and consistent cluster
> view pretty well.
>
> Regards,
> Nikhils
>
> On Tue, Mar 19, 2013 at 2:16 AM, Chris Brown <cb...@in...> wrote:
>> Hi all,
>>
>> I just read through:
>>
>> wiki.postgresql.org/images/4/44/Pgxc_HA_20121024.pdf
>>
>> and I wanted to know how PG-XC solves the problem of split brain.
>>
>> For example, let's say there is a pair:
>>   Box 1: datanode1-master, datanode2-slave, coordinator master, gtm master
>>   Box 2: datanode1-slave, datanode2-master, coordinator slave, gtm slave
>> and communication is severed between the two boxes.
>>
>> Another example:
>>   Box 1: datanode1-master, datanode2-slave, coordinator master, gtm proxy
>>   Box 2: datanode1-slave, datanode2-master, coordinator slave, gtm proxy
>>   Box 3: gtm (no slave exists for simplicity)
>> and communication is severed between box 1 and 2, but both can still
>> communicate with box 3.  (Or another network outage scenario - there are
>> obviously several.)
>>
>> Chris...
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>
>
>
>
> --
> StormDB - http://www.stormdb.com
> The Database Cloud
> Postgres-XC Support and Service
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general