We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
我简单描述下现象: 比如我数据库中记录的最新同步点为 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同步点可以全部被处理,数据不会丢失。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
我简单描述下现象:
比如我数据库中记录的最新同步点为 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同步点可以全部被处理,数据不会丢失。
The text was updated successfully, but these errors were encountered: