talmacschen-arch commented on issue #1830: URL: https://github.com/apache/cloudberry/issues/1830#issuecomment-4789639045
Thanks — the logs make this clear, and your `pg_attribute` dumps rule out a schema mismatch (source and dest columns are identical), so this is **not** a column-layout problem. It's the interrupted-transfer case: **segment-to-segment network connectivity**. Reading the three logs together: - **Dest CB segment helper:** `Listener.Accept() failed: accept tcp [::]:1024: i/o timeout`. cbcopy's helper sets a 600-second listener deadline (`helper/server.go`). Your timestamps are 13:46:18 → 13:56:18 — exactly 10 minutes. So a destination segment listener waited the full 10 minutes for an inbound connection from a source segment that **never arrived**, then timed out. - **Source GP helper:** `failed to redirect stream: write tcp 192.168.14.29:...->192.168.14.8:1025: write: connection reset by peer` — a source segment was streaming data to a dest segment when the connection was torn down. - **Dest QE:** `missing data for column ... (SQLSTATE 22P04)` — it read a truncated row from the broken pipe. In push mode each destination segment listener expects a fixed number of inbound connections from the source segments (your `client-numbers 4,4,4,4,3,3,3,3`). At 13:46 a subset connected and data flowed (hence the ~334 MB). But at least one source→dest segment connection never established (the listener stuck on port 1024). After 10 minutes that listener timed out, the helper process group tore down, the connections that *were* streaming got reset, and the COPY aborted with 22P04. A single missing segment-to-segment link brings down the whole table — which is why large tables (transferred segment-to-segment) fail while small ones (coordinator-to-coordinator) succeed. This is an environment/firewall issue, not a cbcopy bug. To fix: 1. Verify **full-mesh** reachability: from **every source segment host** to **every destination segment host**, on the data ports. Note these are the **internal segment addresses** (`192.168.14.7` / `192.168.14.8`, from `gp_segment_configuration`), not just the `--dest-host` `10.195.157.19`. Test each pair, e.g. `nc -vz <dest-seg-host> <port>`. 2. The data port range defaults to 1024–65535. Narrow it with `--data-port-range` (e.g. `--data-port-range 22000-22100`) and open exactly that range in the firewall on all segment hosts. 3. If the destination segments cannot accept inbound connections (NAT / restricted network), use `--connection-mode=pull`. 4. To pin down the culprit, cross-reference the IP/port pairs in the two helper logs to find which source segment failed to reach which dest segment on port 1024 — that usually points straight at an iptables/firewalld/security-group rule on one host. `--copy-jobs 2` and `--compression` are unrelated to this failure. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
