Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: sync_diff_inspector在对比时经常因为[FATAL] [diff.go:538] [“the count is not correct”]退出核对
The error content is as follows:
Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: sync_diff_inspector在对比时经常因为[FATAL] [diff.go:538] [“the count is not correct”]退出核对
The error content is as follows:
After looking at the source code, I found that the error logic is triggered when export-fix-sql = true
is enabled. To avoid this, you can set it to not export for now. According to the code logic, it seems to be related to not changing the isolation level, which causes data changes when reading data in shards to generate fix files, resulting in the count of the two shards combined being inconsistent with the original count. However, it is better to log an error in such cases and print the error reason in the final summary, rather than using the Fatal level to directly exit the entire program.
} else if !isEqual && df.exportFixSQL {
state = checkpoints.FailedState
// if the chunk's checksum differ, try to do binary check
info := rangeInfo
if upCount > splitter.SplitThreshold {
log.Debug("count greater than threshold, start do bingenerate", zap.Any("chunk id", rangeInfo.ChunkRange.Index), zap.Int64("upstream chunk size", upCount))
info, err = df.BinGenerate(ctx, df.workSource, rangeInfo, upCount)
if err != nil {
log.Error("fail to do binary search.", zap.Error(err))
df.report.SetTableMeetError(schema, table, err)
// reuse rangeInfo to compare data
info = rangeInfo
} else {
log.Debug("bin generate finished", zap.Reflect("chunk", info.ChunkRange), zap.Any("chunk id", info.ChunkRange.Index))
}
}
You’re very professional… However, I’ve encountered this problem before. You can refer to this https://asktug.com/t/topic/994800/12
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.