Using cbcopy the schema migrated successfully but when it comes to data copy these issues occurring

Also, try a re-run with --debug and you may be able to pull the untruncated error from ~/gpAdminLogs/cbcopy_*.log

Hi — we have run into this class of issue with GPDB migrations, so hopefully some of this is useful. Taking your questions in order. 1 & 2 — the ~130s Broken pipe

could not write to COPY program: Broken pipe

is emitted by the source when the program behind

COPY ... TO PROGRAM

exits — so the local cbcopy_helper died, and in our experience that's almost always because its TCP session to the destination helper got reset underneath it. The consistency of the timing is the tell. Helpers bind and connect up front, then some sit idle waiting their turn while other partitions stream. A stateful device (conntrack, NAT, LB) times out the idle-but-established flow, and the helper only discovers it on the next write. 120s is a common default. Worth trying on both clusters:

net.ipv4.tcp_keepalive_time = 45
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 6

Run

conntrack -L

during the idle window and watch whether the entry ages out around the 120s mark — that confirms or kills the theory quickly. On firewall requirements: every source segment host needs to reach every destination segment host across the whole

--data-port-range

. Coordinator-to-coordinator is not enough, and that catches people out. The direction depends on `--connection-mode`:

push

(the default) is source → dest,

pull

is dest → source. If your rules are asymmetric, flipping to

pull

is a cheap test. 3 — the 40000-40050 hang 51 ports is very likely too few. Listeners scale roughly with destination segments per host ×

--copy-jobs

, and partitioned tables multiply it further. When the range is exhausted, a failed bind presents exactly as you're seeing: metadata retrieved, then 0% forever with no helper logs. Try

40000-41000

with

--copy-jobs=1

to isolate. While a run is stalled,

ss -tnp | grep 400

on the destination segment hosts will tell you immediately whether anything actually bound. 4 — the row count error Separate issue, and not a network one. cbcopy compares rows read by COPY TO against rows written by COPY FROM and fails the table on any mismatch. The full message carries both numbers, which is the part you need — grab it from

~/gpAdminLogs/cbcopy_*.log

rather than the console, where it gets truncated. Once you have both figures it's usually obvious whether it's a distribution/segment-count artifact or something real. 5 — debugging order Cheapest to most expensive: 1.

nc -zv

from each source host to each destination host across the range — do this before anything else 2.

ss -tnp

on destination segment hosts mid-run 3.

conntrack -L

during the idle window 4. Re-run with

--debug

and pull the untruncated errors from the log 5. tcpdump only if the above leaves it ambiguous If you post back the untruncated row-count error and what

nc

shows across the range, happy to keep digging. — Tushar Synx Data Labs — we work on Cloudberry and build SynxDB on top of it. Always glad to help with migration issues like this, here or offline.