A Post Commit Trigger (PCT, or ER2SPL) replicate, defined with
--splname or --jsonsplname, does not require a primary key or
other replication key on the source table - as there's no real
target table where rows had to be identified using such key.
And here's the first problem (#1): while all is well when
defining such replicate on a table having no primary key, a
slightly confusing message like the following would come to the
respective server's message log should the table there have a
primary key:
CDR: Master Replicate Error
Primary Key Check Failed
Master: primary key ()
Participant:primary key ()
In plain English: the master schema stored for this table
(replicate) omitted the primary key definition as it's not
needed, so a subsequent, undue Primary Key Check detects a
discrepancy: the participant table has a PK while the master
(schema) doesn't.
This message will NOT keep the replicate definition from
succeeding nor the replicate from working, so basically a
cosmetic problem, though clearly unsettling.
The second problem (#2) appears when the table, esp. the (dummy)
target table, gets altered (columns added, dropped, modified):
from this point on, everything would still 'replicate' nicely
judging by ER metrics (send/receive queue, data sync), yet the
ER2SPL UDR would no longer be invoked; so the data would
continue to replicate to the target(s), transactions would seem
to be applied there successfully, yet the data would not arrive
in the UDR nor anywhere else and would just be discarded.
The reason is that, after the alter, the target in-memory
representation of the replicate would have forgotten part of its
ER2SPL nature. Yet, since the replicate definition itself, in
syscdr database, is unaffected, a restart (ER only or whole
server) of the target system would cure this problem.
To get the alter's changes reflected in the replicate and e.g. a
new column included in replication, you'd have to either drop
and recreate the replicate, or to remaster it (both cases
requiring the alter to be conducted also on (dummy) target
tables.)
There are two more problems regarding remaster (no problems if
simply re-defining the replicate, but this creates a potential
replication gap):
First problem here (#3) is: the remaster does insist on primary
key, i.e. it disregards the lift of this restriction with ER2SPL
replicates and fails if no primary key exists, getting:
Table '@.' does not contain
primary key.
(Problem #3a: this table spec syntax is incorrect, should be
'@:.'.)
Next problem (#4), when trying with primary key: the remaster
will work, without any message, yet again nothing will arrive in
the target UDR, since the replicate will have forgotten
completely about splname/jsonsplname. In fact the replicate
will no longer be the same, detectable by its replid; instead
it will be a copy of the old replicate, the old one will
continue to exist as a shadow replicate of the new one, under a
different name - and with the SPL info still present, only this
info apparently didn't get copied to the new replicate.
Lastly (#5), "cdr list replicate [repl_name]" isn't helpful in
diagnosing this as it doesn't give the [json]splname info, i.e.
the UDR name. |
