Hello!
All!
I configure /u2/slave/pgsql/etc/slon_tools.conf
# $Id: slon_tools.conf-sample,v 1.5 2005/03/10 17:50:03 smsimms Exp $
# Author: Christopher Browne
# Copyright 2004 Afilias Canada
# Revised extensively by Steve Simms
# Keeping the following three lines for backwards compatibility in
# case this gets incorporated into a 1.0.6 release.
#
# TODO: The scripts should check for an environment variable
# containing the location of a configuration file. That would
# simplify this configuration file and allow Slony-I tools to still work
# in situations where it doesn't exist.
#
if ($ENV{"SLONYNODES"}) {
require $ENV{"SLONYNODES"};
} else {
# The name of the replication cluster. This will be used to
# create a schema named _$CLUSTER_NAME in the database which will
# contain Slony-related data.
$CLUSTER_NAME = '_golf1';
# The directory where Slony should record log messages. This
# directory will need to be writable by the user that invokes
# Slony.
$LOGDIR = '/u2/slave/slonyI/log';
# (Optional) If you would like to use Apache's rotatelogs tool to
# manage log output, uncomment the following line and ensure that
# it points to the executable.
#
# $APACHE_ROTATOR = '/usr/local/apache/bin/rotatelogs';
# Which node is the default master for all sets?
$MASTERNODE = 1;
# Include add_node lines for each node in the cluster. Be sure to
# use host names that will resolve properly on all nodes
# (i.e. only use 'localhost' if all nodes are on the same host).
# Also, note that the user must be a superuser account.
add_node(node => 1,
host => '10.10.10.67',
dbname => 'master',
port => 7543,
user => 'slave',
password => '123');
add_node(node => 2,
host => '10.10.10.67',
dbname => 'slave',
port => 7543,
user => 'slave',
password => '123');
# add_node(node => 3,
# host => 'server3',
# dbname => 'database',
# port => 5432,
# user => 'postgres',
# password => '');
# If the node should only receive event notifications from a
# single node (e.g. if it can't access the other nodes), you can
# specify a single parent. The downside to this approach is that
# if the parent goes down, your node becomes stranded.
# add_node(node => 4,
# parent => 3,
# host => 'server4',
# dbname => 'database',
# port => 5432,
# user => 'postgres',
# password => '');
}
# The $SLONY_SETS variable contains information about all of the sets
# in your cluster.
$SLONY_SETS = {
# A unique name for the set
"set1" => {
# The set_id, also unique
"set_id" => 1,
# Uncomment the following line to change the origin
# (a.k.a. master) for the set. The default is $MASTERNODE.
#
"origin" => 1,
# The first ID to use for tables and sequences that are added
# to the replication cluster. This must be unique across the
# cluster.
#
# TODO: This should be determined automatically, which can be
# done fairly easily in most cases using psql. create_set
# should derive it, and give an option to override it with a
# specific value.
"table_id" => 1,
"sequence_id" => 1,
# This array contains a list of tables that already have
# primary keys.
"pkeyedtables" => [
't_account_basic_info',
't_add_preorder',
],
# For tables that have unique not null keys, but no primary
# key, enter their names and indexes here.
"keyedtables" => {
't_player_score' => 'ak_t_player_score_t_player',
},
# If a table does not have a suitable key or set of keys that
# can act as a primary key, Slony can add one.
#
# Note: The Slony development team does not recomment this
# approach -- you should create your own primary keys instead.
"serialtables" => ["t_coach_fee_setup" ,
"t_player_score" ,],
# Sequences that need to be replicated should be entered here.
"sequences" => ['seq_my_course_id',
'seq_account_basic_info_account_id',
],
},
# "set2" => {
# "set_id" => 2,
# "table_id" => 6,
# "sequence_id" => 3,
# "pkeyedtables" => ["table6"],
# "keyedtables" => {},
# "serialtables" => [],
# "sequences" => [],
# },
};
# Keeping the following three lines for backwards compatibility in
# case this gets incorporated into a 1.0.6 release.
#
# TODO: The scripts should check for an environment variable
# containing the location of a configuration file. That would
# simplify this configuration file and allow Slony tools to still work
# in situations where it doesn't exist.
#
if ($ENV{"SLONYSET"}) {
require $ENV{"SLONYSET"};
}
# Please do not add or change anything below this point.
1;
then
cd /u2/slave/pgsql/admin/bin
$ ./slon_watchdog2 --help
Usage: ./slon_watchdog node sleep-time
$ slon_watchdog2 1 2
psql: warning: extra command-line argument "--tuples-only" ignored
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.0"?
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.0"?
/u2/slave/slonyI/log/slony1/node/*log: No such file or directory
or
$ ./slon_watchdog 1 2
sh: /u2/slave/pgsql/admin/bin/restart_node: not found
<stdin>:1: ERROR: syntax error at or near
Invoke slon for node 1 - /u2/slave/pgsql/bin/slon -s 1000 -d2 -g 80 _golf1 'host=10.10.10.67 dbname=master user=slave port=7543 password=123' 2>&1 > /u2/slave/slonyI/log/slony1/node1/master-2005-08-01_17:32:01.log &
sh: /u2/slave/pgsql/admin/bin/restart_node: not found
<stdin>:1: ERROR: syntax error at or near
Invoke slon for node 1 - /u2/slave/pgsql/bin/slon -s 1000 -d2 -g 80 _golf1 'host=10.10.10.67 dbname=master user=slave port=7543 password=123' 2>&1 > /u2/slave/slonyI/log/slony1/node1/master-2005-08-01_17:32:05.log &
sh: /u2/slave/pgsql/admin/bin/restart_node: not found
<stdin>:1: ERROR: syntax error at or near
if my usage is incorrect ? how to use is correct ? who use this perl admin tool ? maybe know how to use correct . If you know Please give me some advise . Thanks very much !
__________________________________________________
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com
RSS Feed