假设您有一个需要从MySQL迁移到Hbase的数据量很大的前台系统。 比较粗略的数据同步方法如下。
1、使整个前置系统为只读
2、总量dump MySQL数据
3、将MySQL数据导入Hbase
4、前台系统切换到Hbase，打开更新
此方案相对简单，易于保持数据一致性，但存在影响所有用户写入、耗时过长的缺点。
用户体验友好的数据同步方法如下。
1、将到某一时间点为止的数据全部dump，记录期间的增量日志a
2、记录APP日志a内的数据，记录期间的增量日志b
3、记录APP日志b内的数据，记录期间的增量日志c
4、重复步骤3直到日志c足够小
5、将整个前置系统设为只读，应用日志c中的数据
6、前台系统切换到Hbase，打开更新
该方案的实现很复杂，迭代日志方法看起来没完没了，容易出现部分用户数据不一致。 但是，只读时间非常短，大多数用户在数据同步期间可以自由使用APP应用程序。
简单概括一下：
方案1 :所有用户都受到长时间的小影响(只读) )。
场景2 )较少的用户在短时间内受到很大影响(数据不匹配) )。
问题：
牺牲大部分人来保护大部分人是正确的吗？
在这个问题上，聪明的彩虹(democracy )是最终的答案吗？
虽然我想不出这个问题的答案，
但是，对于反复日志是不是没完没了的疑问，增长的板栗悖论给了我一点线索：
挺拔的板栗是跑得很快的神话人物，芝诺建议：“只要乌龟比挺拔的板栗往前走1000米，挺拔的板栗就永远赶不上乌龟。” 这个结论的推理过程如下：
1 .乌龟比挺起的栗子往前走1000米
2、长高了的栗子追了1000米
3、乌龟前进了100米(假设是乌龟速度增长了的栗子的十分之一) ) ) ) ) ) ) ) ) )。
4、长高了的栗子追了100米
5、乌龟前进了10米。
6、挺起的栗子追赶了n米
7、乌龟前进了半米。
8、挺起的栗子无限逼近乌龟，但绝对追不上
挺起的栗子真的赶不上乌龟吗？ 当然不可能：
1000*(10.10.01…)=1000 * (11/9 )=10000/9
在10000/9米的地方，挺起的栗子和乌龟并排跑着，赶超。
返回到增量日志迭代同步问题。 在什么前提下，您认为迭代可以结束：
1、日志APP中没有停顿(挺起的栗子一直在跑) ) ) ) )。
如果APP结束日志，并且不是立即前往APP新生成的增量日志，迭代很可能不会结束
2、日志APP的速度大于增加日志的生成速度(伸长的板栗跑得比乌龟快) ) ) ) ) ) ) ) ) ) )。
这一点比较明显。 否则，日志只会累积，不会完成APP
这是我的看法。 希望今后在不影响用户的情况下实现完美的数据迁移。
原文地址： http://www.Taobao DBA.com/html/564 _增量日志迭代同步和地址悖论. html
转载于：https://blog.51cto.com/Hz csky/558190