[SuJinpei]

Problem

The guide doesn't say what to do if the network breaks during a migration, and its checks can miss the result.

The Step 4 dump is streamed through two kubectl exec sessions. When a dump was cut off in a test, mysql exited with status 0 and reported no error:

Where the stream stops	mysql exit code	Target
Between statements	0	Table missing
Partway through an INSERT, where the remaining text is still valid SQL	0	Table short of rows (2 of 3)

The checks in the guide don't catch this reliably: the Step 5 command only compares table counts, and the Troubleshooting script compares TABLE_ROWS, which is only an estimate for InnoDB.

Changes

• Common Issues: add "Network Interruption During Migration", covering recovery before and after the application writes to the target, a check for a changed primary, and how to reduce the risk.
• Step 5: add a per-table COUNT(*) comparison on every target member, printing OK or MISMATCH, and say what each result means.
• Step 4: warn that a broken connection can leave a table short of rows with no error.
• Troubleshooting: replace the TABLE_ROWS comparison with a pointer to Step 5.

Verification

Tested on throwaway Percona Server 8.0.39 servers. Every runnable bash block from Getting Started through Step 6 ran in order under set -u on all three branches, with a kubectl test script pointing at the local servers. doom lint 2.10.0, the version CI installs, passes on all three.

Test	Result
Dump cut between statements, or partway through an INSERT	Exit 0, table missing or short of rows
Re-run the full dump over that partial state	All tables, rows, the view and the procedure restored
New comparison after a clean import	6 OK lines (2 tables, 3 members)
New comparison after deleting a row on the target	3 MISMATCH lines
Re-run the Step 4 loop, then compare again	0 MISMATCH, 6 OK
CREATE USER run twice	ERROR 1396

Not tested:

• A real network failure or real kubectl exec. The tests truncated a dump file instead, so that kubectl reports a broken connection, which FAILED relies on, is expected but unmeasured.
• MySQL 5.7, PXC or a real 3-member group. The test script pointed all three member names at one server, so replication lag and a changed primary were not exercised. The advice on those comes from how Group Replication behaves.
• The advice on tmux, proxies and load balancers, which is general guidance.

🤖 Generated with Claude Code

[youyongsong]

/test doc-pr-build-mysql-mgr

[cloudflare-workers-and-pages]

Deploying alauda-mysql-mgr with    Cloudflare Pages

Latest commit:	1a2a9a8
Status:	✅  Deploy successful!
Preview URL:	https://1e7571ae.alauda-mysql-mgr.pages.dev
Branch Preview URL:	https://docs-pxc-migration-network-i-4aan.alauda-mysql-mgr.pages.dev

View logs