roctaiwan wrote:
> I did tried. but ev_origin error keeps happening. But I wouldn't find the
> answer from anywhere. I guess people who know how to do this don't bother=
 to
> answer. =

>
>   =

You have an old schema in there that's prohibiting this.  Go into the
database on the CLIENT that is dysfunctional/broken (DO NOT DO THIS ON
THE MASTER - YOU HAVE BEEN WARNED!) and execute:

$ drop schema _clustername cascade

Note that "clustername" is the name of the cluster (usually the same as
the database name but it doesn't have to be.)

This will drop the old Slony schema AND all the triggers that got added
to the tables.  If you forget the "cascade" you have a hell of a mess to
clean up by hand, so don't.

Once you have a CLEAN database (can have old data in it, it will be
automatically copied over) that has the IDENTICAL schema to the master,
here's how you add a new node, assuming you have ONE node running now
(Node #1) with no clients (you're going to add Node #2)

Have a file called "slonik.preamble" containing:

CLUSTER NAME =3D your-cluster
node 1 admin conninfo=3D'dbname=3Dyour-db host=3Dexisting-host user=3Dslony
port=3D5432 password=3Dwhatever';
node 2 admin conninfo=3D'dbname=3Dyour-db host=3Dnew-host user=3Dslony port=
=3D5432
password=3Dwhatever';

This assumes "existing-host" is running the master, and "new-host" is
where you want the new replication to be set up.

Start the SLON on the new host.  It will complain about not being
configured in the logfile every 10 seconds or so.  That's fine.

Then you run the following three files with "slonik filename"

step1:
include <slonik.preamble>;
store node (id=3D2, comment=3D'Client #1, Node #2', event node=3D1);

(Sets up the base definitions and schema for the database and tells it
what this node is along with the node to deliver events to - the master
node.)

step2:
include <slonik.preamble>;
store path (server=3D1, client=3D2, conninfo=3D'dbname=3Dyour-db
host=3Dexisting-host user=3Dslony port=3D5432 password=3Dwhatever');
store path (server=3D2, client=3D1, conninfo=3D'dbname=3Dyour-db host=3Dnew=
-host
user=3Dslony port=3D5432 password=3Dwhatever');

(Tell Slony how to find both the master and your new slave hosts as a
pair of reciprocal paths)

step3:
include <slonik.preamble>;
subscribe set (id=3D1, provider=3D1, receiver=3D2, forward=3Dfalse);

(Subscribe the set)

You can put all of this into one file (only one "include" of course),
but I prefer not to because with each step I want to look at the logfile
and see that slon has picked up the changes, and this also reduces the
risk of a disaster (slon is pretty well protected against it, but....)
if I make a mistake.  I also like to have "Step2" separate because if I
move a database (hostname address, etc) I can run JUST THAT ONE even on
a running cluster without trashing things - that SHOULD (when things are
working properly) propagate to all the affected nodes.

Note that this will cause a COPY to be done of the entire subscriber
set.  Once you drop the node (either with a failover or controlled drop
with a "drop node") if the drop succeeds and notification is delivered
the schema containing the necessary sync information is removed and thus
you cannot recover via only the changed transactions, as the baseline
checkpoint is lost.

Within a few seconds of when you give the last "step3" command you
should see COPY commands being logged into the SLON logfile as the
system pulls over the data from the master.

This all assumes a "standard" (not log-shipping or other complex)
configuration.

-- Karl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: karl.vcf
Type: text/x-vcard
Size: 265 bytes
Desc: not available
Url : http://lists.slony.info/pipermail/slony1-general/attachments/20090825=
/6606ea2e/karl-0001.vcf