Hi All:

    Problem solved!  As I missed; the set add table commands was =

apparently missing 5 statements :(.

Thank you!

Ouray

Ouray Viney wrote:
> Hi All:
>
> I have recently been troubleshooting why slony only sets up =

> replication triggers for 6 of 11 tables (I verified this two ways; =

> one: in the slave slon logs:
>
>  "2008-01-29 14:11:58 EST DEBUG2 remoteWorkerThread_1: syncing set 1 =

> with 6 table(s) from provider 1"
>
> two; by running \d against each of the tables to see what triggers =

> existed); even though I have the required "set add table" (see below =

> for complete example) for each of the tables that I want replicated.
>
> set add table (set id =3D 1, origin =3D 1, id =3D 1,
>                  full qualified name =3D =

> 'public.nonmanagednumbestfitrouteset',
>                  comment =3D 'Table public.nonmanagednumbestfitrouteset =

> with candidate primary key public.normalization');
>
> When I run the slonik script; slonik < createReplicationSet.ik; I =

> don't have any complaints.
>
> After completing the rest of the setup; i.e. subscribing the slave to =

> the master's replication set.
>
> I figure out that there were missing triggers by looking at each of =

> the tables:
>
> Example:
>
> I defined the table in the replication set definition slonik script:
>
> set add table (set id =3D 1, origin =3D 1, id =3D 5,
>                  full qualified name =3D 'public.managednumberrouteset',
>                  comment =3D 'Table public.managednumberrouteset with =

> candidate primary key public.mediationstrategy');
>   echo 'Add candidate primary keyed table public.managednumberrouteset';
>
> You will notice that since our table 'public.managednumberrouteset' =

> has a primary key; I opt to not define it (since according to the =

> docs, is OK and will tell slony to use the one that it detects)
>
> Here is the create statement for the table in question:
>
> <snippet>
>     create table public.mediationstrategy (
>         strategyname varchar(255) not null unique,
>         description varchar(2000),
>         extbindingname varchar(255) not null,
>         primary key (strategyname)
>     );
> </snippet>
>
> I completed the cluster configuration; started the slon process for =

> both master and slave; and started inserting data into that particular =

> tables; but I noticed that there were 0 INSERTS reported by the slave =

> slon daemon.   I inspected the database on both sides:
>
> master:
> ssm=3D# select * from mediationstrategy;
>  strategyname | description | extbindingname
> --------------+-------------+----------------
>  cmstrategy   | cmstrategy  | cmstrategy
>  pstn         | pstn        | pstn
> (2 rows)
>
> ssm=3D# \d mediationstrategy
>            Table "public.mediationstrategy"
>      Column     |          Type           | Modifiers
> ----------------+-------------------------+-----------
>  strategyname   | character varying(255)  | not null
>  description    | character varying(2000) |
>  extbindingname | character varying(255)  | not null
> Indexes:
>     "mediationstrategy_pkey" PRIMARY KEY, btree (strategyname)
>
> Note: That is how I figured that slony didn't obey the replication set =

> script (as outlined above)
>
> Slave:
>
> ssm_slave=3D# select * from mediationstrategy;
>  strategyname | description | extbindingname
> --------------+-------------+----------------
> (0 rows)
>
> ssm_slave=3D# \d mediationstrategy
>            Table "public.mediationstrategy"
>      Column     |          Type           | Modifiers
> ----------------+-------------------------+-----------
>  strategyname   | character varying(255)  | not null
>  description    | character varying(2000) |
>  extbindingname | character varying(255)  | not null
> Indexes:
>     "mediationstrategy_pkey" PRIMARY KEY, btree (strategyname)
>
>
> Question:  Could someone explain what I may have done incorrectly to =

> define the replication set. =

>
> Note:  I used the slonik_build_env script as outlined below to =

> populate my slon_tools.conf.
>
> [root at caotta000381 ~]# slonik_build_env -node pgmaster:ssm:ssm -node =

> pgslave1:ssm_slave:ssm
> &add_node(host =3D> 'pgmaster', dbname =3D> 'ssm', port =3D>5432,
>         user=3D>'ssm', password=3D>'', node=3D>1 );
> &add_node(host =3D> 'pgslave1', dbname =3D> 'ssm_slave', port =3D>5432,
>         user=3D>'ssm', password=3D>'', node=3D>2 , parent=3D>1);
> @KEYEDTABLES=3D(
>         "public.managednumberrouteset",
>         "public.mediationstrategy",
>         "public.nonmanagednumbestfitrouteset",
>         "public.normalization",
>         "public.normalizationtype",
>         "public.numberforwarding",
>         "public.outboundrouteorder",
>         "public.outboundrouteset",
>         "public.route",
>         "public.routetype",
>         "public.routetype_normalization",
> );
> @SEQUENCES=3D(
>         "public.nonmanagednumbestfitrouteset_outboundroutelogicid_seq",
>         "public.normalization_normalizationid_seq",
> );
>
> According to the documenation; this is suitable to be added to the =

> slony_tools.conf; which is exactly what I did.
>
> Thank you kindly for your help!
>
>
> -- =

> Ouray Viney
> https://www.viney.ca
> ------------------------------------------------------------------------
>
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
>   =



-- =




    Ouray Viney | Software Developer Engineer II | Avaya | 515 Legget
    Drive | Suite 400 | Ottawa, ON, K2G6Z6 |
    Voice: +1.613.271.5072 | Fax +1.613.271.8817 | oviney at avaya.com

    www.avaya.ca <http://www.avaya.ca>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: oviney.vcf
Type: text/x-vcard
Size: 269 bytes
Desc: not available
Url : http://lists.slony.info/pipermail/slony1-general/attachments/20080129=
/8dfb704d/oviney.vcf