Join / Log in
I'm just a font of intriguing issues lately. In our environment, 12.10.FC14, I have a send-only ER server that supports multiple receive-only nodes. One on of the receive-only nodes, I found this:
$ time cdr check repl -R -r myrepl -d -e delete -m gprim__sendonly gtarg__recvonly
Sep 16 2020 14:31:52 ------ Table scan for myrepl start --------
WARNING:node gprim__sendonly for myrepl is sendonly.
Skipping evaluation of all other sendonly nodes
Check contains send only nodes*
Node Rows Extra Missing Mismatch Processed
---------------- --------- --------- --------- --------- ---------
gprim__sendonly* 7648 0 0 0 0
gtarg__recvonly 7651 0 0 0 0
Sep 16 2020 14:31:58 ------ Table scan for myrepl end ---------
Notice that there are no "extra" or "missing" records, despite the fact that the row counts don't match.
I've opened a ticket with support, and they've given the dreaded response: "expected behavor"; specifically,
WTAH?! Expected by whom? Why does this even make sense, especially when "-e delete" is explicitly specified?
Hi Tom,the 'send-only' participant mode got introduced for "single hub vs. multiple spokes" scenarios, with the hub consolidating the send-only spokes' data, so it is quite expected, from a given spoke's perspective, that the hub has "extra rows", and it's on purpose that extra target row deletion is suppressed with replicates containing send-only participants. A check (and potential repair) would only ever consider a single send-only spoke participant (the current check command's '-m' master) vs. the central hub, and only rows that exist on spoke, yet not on hub, would be considered a report/repair worthy error.The way you're using 'send-only' doesn't look to be the anticipated one: send-only hub sending out changes to multiple 'receive-only' spokes, so a data distribution rather than consolidation scheme. I guess you're trying to safeguard against accidential new non-receive-only spokes which then could send back data to your hub?I'm not saying what you're intending isn't making sense, it only currently is conflicting with potentially too implicite intention of send-only.It might be debatable whether an explicite "-e delete" shouldn't be supported (so only the -e default behavior changes with send-only), at the full risk of the user, though, which is what traditionally is being avoided.Let us know your thoughts!BR, Andreas
$ time cdr check repl -R -r myrepl -d -e delete -m gprim__sendonly gtarg__recvonly Sep 16 2020 14:31:52 ------ Table scan for myrepl start --------WARNING:node gprim__sendonly for myrepl is sendonly. Skipping evaluation of all other sendonly nodesCheck contains send only nodes*Node Rows Extra Missing Mismatch Processed ---------------- --------- --------- --------- --------- ---------gprim__sendonly* 7648 0 0 0 0gtarg__recvonly 7651 0 0 0 0 Sep 16 2020 14:31:58 ------ Table scan for myrepl end ---------real 0m6.26suser 0m0.84ssys 0m0.37s
There are two plausible scenarios for using send-only vs. receive-only nodes. The first, the one you describe, is data consolidation. The other, which is our use case, is data distribution. In both cases, it's entirely conceivable that the user wants the source not to ever be updated by the targets. The -e flag on cdr check actually allows for both of these (plus the update-anywhere scenario). The -e keep option behaves as you suggest for data consolidation, where extra rows on the targets are kept. The -e delete option behaves as is necessary for data distribution, adjusting the targets to look like the source. The -e merge option is for update-anywhere scenarios.
We had originally set these nodes up as primary-target replication, but a scripting issue caused the wrong node to be specified as the master on a cdr check -R command, and that caused the primary node's data to be overwritten in favor of what existed on the target. Being able to explicitly state that a node is send-only, and should never receive replicated data from another node under any circumstances, seemed like the logical solution to that problem.
But the issue here is nomenclature, I think. I do in fact want my primary node to be send-only, and I do in fact want my target nodes to be receive-only. The same nomenclature being used for data consolidation also applies to data distribution, thus creating confusion.
Bottom line, though, is that if I explicitly tell cdr check to eliminate extra nodes from a receive-only node, it should do so; and if that isn't supported, it should at least warn that the option is being ignored (and why) -- or, preferably, reject the command as invalid -- rather than silently ignoring the option.