我简单描述下现象：
比如我数据库中记录的最新同步点为 mysql-bin.000576:316432992
这个同步点有10000条记录需要处理，我在处理5000条时重启了应用，重启后会重新导数据库查询最新同步点 mysql-bin.000576:316432992 ，然后接着处理业务。
这时问题出现了，按道理应该从 mysql-bin.000576:316432992 这个同步点的第1条开始dump数据，结果现象却不是，我看日志打印显示是从 下一个同步点（mysql-bin.000576:317387349）开始dump数据的，导致上次重启还剩余5000条没有处理，就丢了数据。
我是在监控数据一致性发现的，发现条数对不上，我就看了那个时间的日志，发现了这个问题，不知道是不是存在这个问题，所以目前我只能用笨办法解决：每次都保存当前正在处理的同步点 （如mysql-bin.000576:316432992）之前的最近一个同步点，这样可以保证下次重启之后，mysql-bin.000576:316432992同步点可以全部被处理，数据不会丢失。
我简单描述下现象：
比如我数据库中记录的最新同步点为 mysql-bin.000576:316432992
这个同步点有10000条记录需要处理，我在处理5000条时重启了应用，重启后会重新导数据库查询最新同步点 mysql-bin.000576:316432992 ，然后接着处理业务。
这时问题出现了，按道理应该从 mysql-bin.000576:316432992 这个同步点的第1条开始dump数据，结果现象却不是，我看日志打印显示是从 下一个同步点（mysql-bin.000576:317387349）开始dump数据的，导致上次重启还剩余5000条没有处理，就丢了数据。
我是在监控数据一致性发现的，发现条数对不上，我就看了那个时间的日志，发现了这个问题，不知道是不是存在这个问题，所以目前我只能用笨办法解决：每次都保存当前正在处理的同步点 （如mysql-bin.000576:316432992）之前的最近一个同步点，这样可以保证下次重启之后，mysql-bin.000576:316432992同步点可以全部被处理，数据不会丢失。