Thinking of timing synchronization data table

Timed tasks:

Once an hour:
1. Agreed value time: time = min (main server time - 1 hour and 5 minutes, last agreed time + 1 hour)
The 5 minutes here is the time used for the biggest thing. It is assumed that the length of time for all things can not exceed 5 minutes.
Because we often set the update time in the program first, then insert into the database, then do something else (wasted some time), and
finally commit the thing. Then according to mvcc mode, non-locking read is a read snapshot. As a result, the update time should have been synchronized in this synchronization, but it was not synchronized
(invisible), and the next synchronization time was greater than this update time. As a result, updates will be lost. So every time you synchronize, 5 minutes of data will be synchronized.
I'm afraid to throw away the data in this gap.

2. Synchronize data with the agreed value time.
Primary server data cannot be deleted, only tombstoned.

3. Compensation for deleted data:
Get the local id in the form of paging and ask whether the remote has it. When the deletion situation is relatively low, we can first judge whether the amount of data in the two places is equal.

Tell the remote server to give me 1 hour and 5 minutes (why is there an extra 5 minutes, not just an hour. This needs to consider
the problem caused by the mvcc of mysql InnoDB, non-locking read. It may not be the latest data) Update later The data sent to me
here is based on the time of the remote server, not the time passed by the client.


There is a problem. The remote server suddenly adjusts the time forward at a certain time (there is no problem in adjusting the time backward),
then the data from the server will be lost and updated!
Solution: When the slave server fetches data from the master server, it takes a