Comment 7 for bug 1389041

Setting as "Won't Fix" because the real problem is a fundamental design “flaw” of the tool. First of all, the current solution is a hard-coded +20% to —chunk-size-limit, like: —chunk-size-limit * 1.2. This is unnecessary because if —chunk-size-limit=2 then the user can already accomplish this by specifying —chunk-size-limit=2.4. So a new hard-coded threshold is simply not needed; the same effect can be achieved with existing options.

The real problem is that the tool can’t fall back to chunking a table if a single chunk is too large. When the table is too large on a slave (even if by 1 row, because we can’t do much about EXPLAIN estimates other than specify a higher value for —chunk-size-limit), instead of skipping the table, the tool should fall back to chunking the table. The way the tool is currently written precludes this.

I looked into adding an option to simply prevent single chunks in the first place, i.e. force chunking every table, but the tool’s design precludes this, too. The best solution, imho, is simply to remove single chunking altogether. It’s a special case of normal chunking that’s nice in theory but makes the code complex and difficult to change. I don’t see this happening soon, though, because it’d take a lot of work.

For now, the solution is: specify a larger —chunk-size-limit.

I’ll document this edge case behavior more clearly in the tool.