Investigate the possibility of removing the IterativeVerifier about ghostferry

[shuhaowu]

Another fact: If the query that we use to SELECT from the source database is incorrect, the current implementation of IterativeVerifier is unable to detect an error, as the ITerativeVerifier relies on effectively the same query.

It's unclear if anything could detect an error in that SELECT statement. It may be one of those things that we have to just get right.

[shuhaowu]

I looked through some of our records and I've not seen any errors due to the IterativeVerifier. I cannot definitively say if we see any errors due to the IterativeVerifier besides encoding issues, however, as we didn't keep the most detailed error logs.

Looking through our existing code, the only test case that asserts if the IterativeVerifier finds some sort of algorithm corruption is done as follows: After the binlog streamer quits, we delibrately modify a row on the target in the test, and see if the reverify of the iterative verifier catches this. If a row is not copied to the target, any sort of inline verification would catch it immediately.

At this point I'm reasonably confident that the only thing we check is encoding issues.

[shuhaowu]

After some thought, there's a big blocker for this: there is no easy way to retrieve the source row MD5 directly from MySQL when streaming the binlog. To get around this problem, you would basically need a another goroutine that constantly reverifies binlog entries in the background similar to how the existing IterativeVerifier works.

This idea would still get rid of the data iteration during the IterativeVerifier's execution. This might reduce the total runtime of Ghostferry by a large amount. It may also make the interrupt/resume code easier to write, as there's only a copy phase to deal with, not a separate verification phase. However, it's not certain if the code will be easier to understand as a result.

Going forward some things to find out are:

• How long does it take to run the verifier.
• How much time would we save if the verification is inline to the DataIterator, with a background reverification queue for the binlogs.
• Are there some refactors we can do to make the existing IterativeVerifier easier to understand and work with?
  • I think yes, as I've done some of this as a part of interrupt/resume.

[shuhaowu]

We are going ahead with this mainly because making the iterative verifier interruptible/resumable will make the codebase much more difficult to understand. Since the IterativeVerifier is almost the same as the InlineVerifier in terms of the corruption events it protects us against, implementing the InlineVerifier is preferred as it will allow us to get resumability for very little changes to that system.

[shuhaowu]

The InlineVerifier has been fully merged and at some point I'll need to remove the IterativeVerifier.