Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
juan luis roca got a cyclic synchronization error defining loopback ER replication. Andreas Legner said to define the loopback server as a non-root child of the existing group with cdr define server -I g_loopback -S informix1410_grp -N, which worked. cdr sync on the post-commit-trigger replicate was unsupported (error 101); Nagaraju Inturi suggested filing an RFE and Andreas suggested a dummy update.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
juan luis roca — source: IBM Community (ConnectedCommunity.org) Informix forum
Hello guys,
When defining loopback replication, the followig error appears,
command failed -- remote/cyclic synchronization not allowed (64)
Verification of test@informix1410_grp:informix.t1 started
Verification of test@informix1410_grp:informix.t1 is successful
Verification of test@g_loopback:informix.t1 started
Verification of test@g_loopback:informix.t1 is successful
command failed -- undefined server (37)
participant test@g_loopback:informix.t1 'select t.c1, t.c2 from t1 t '
Executed commands:
cdr define server -I g_loopback
cdr define repl --connect=informix1410_grp rep1 -C always -S row -A -R --master=informix1410_grp --splname=logger4repl2spl "P test@informix1410_grp:informix.t1" "select * from t1" "R test@g_loopback:informix.t1" "select * from t1"
$INFORMIXSQLHOSTS:
informix1410_grp group - - i=139
ol_informix1410 onsoctcp informix14.aldextra.com ol_informix1410 g=informix1410_grp
dr_informix1410 drsoctcp informix14.aldextra.com dr_informix1410 g=informix1410_grp
lo_informix1410 onsoctcp 127.0.0.1 lo_informix1410 g=informix1410_grp
g_loopback group - - i=150
loopback onsoctcp informix14.aldextra.com 17002 g=g_loopback
encrypt onsoctcp informix14.aldextra.com 9043
demo_on_grp group - - i=140demo_on onsoctcp informixva 9088 g=demo_on_grp
migrado_grp group - - i=141
migrado onsoctcp informix14.aldextra.com 9042 g=migrado_grp
Any help/comments would be very much appreciated.
Thanks,
------------------------------
juan luis roca
------------------------------
#Informix
↪ replying to juan luis roca
Andreas Legner — source: IBM Community (ConnectedCommunity.org) Informix forum
Hi Juan,
try this instead: cdr define server -I g_loopback -S informix1410_grp -N
I.e. you need to define the new (pseudo) server as a descendant of an existing one (rather than as a separate, standalone server), and it should be defined as "non-root" server.
Let us know how this goes!
BR,
Andreas
------------------------------
Andreas Legner
------------------------------
↪ replying to Andreas Legner
juan luis roca — source: IBM Community (ConnectedCommunity.org) Informix forum
Thanks Andreas, I worked perfect.
Just one other question:
When I synchonize the replicate
:
cdr sync repl --connect=informix1410_grp -r rep1 -m informix1410_grp g_loopback
it fails saying:
command failed -- This feature of Enterprise Replication is not yet supported. (101)
Error Details:
Cannot sync data for post commit trigger replicate.
onstat -
IBM Informix Dynamic Server Version 14.10.FC1DE -- On-Line -- Up 08:15:52 -- 220040 KbytesIs it that Post Commited triggers are not implemented in Developer Edition ?
------------------------------
juan luis roca
------------------------------
↪ replying to juan luis roca
Nagaraju Inturi — source: IBM Community (ConnectedCommunity.org) Informix forum
Hi Juan,
We haven't yet implemented 'cdr sync' functionality for 'replication to SPL' type replicate. If you think that this is something higher priority for you, appreciate if you can open new RFE request
here
. We weren't sure how important the data synchronization functionality was for 'replication SPL' type replicate as we do fire SPL for each row that exist in the source table.
Thanks & Regards,
Nagaraju
------------------------------
Nagaraju Inturi
------------------------------
↪ replying to Nagaraju Inturi
Andreas Legner — source: IBM Community (ConnectedCommunity.org) Informix forum
Yet, if running all your table's rows through that stored procedure really is what you wanted (what else would you want to achieve using 'cdr sync' on a 'post commit trigger' replicate?), why not
either dummy-update your table
or run the stored procedure (slightly modified) on the table directly?
You'd of course have to take care of transaction size, i.e. do this on a number of rows at a time (which is what 'cdr sync' would be doing for you under the hood.)
------------------------------
Andreas Legner
------------------------------
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.