一个事务复制的bug--更新丢失 续
2013-10-23 07:04
357 查看
阅读本文之前请参考/article/4846735.html
最近又做了一个case,环境是sql server 2008 R2. 客户添加了一个'replication support only'的订阅,之后发现现存订阅出现了更新丢失。 丢失的数据恰巧是添加订阅前的几秒钟内生成的。
我开始以为是log reader没有开启造成的,检查了distribution database的MSlogreader_history
,发现期间log reader并没有停止过。
如果Log reader停止,那么添加订阅前的更新肯定是丢失了。因为产生的数据的LSN小于"添加订阅"的LSN, 并且distribution agent把"添加订阅"的LSN先传递到了订阅。可是log reader一直处于运行状态,那么还有什么可能呢? 如果log reader的效率很低,没有即时地将数据更新传递到distribution agent,那么也会产生这个问题吧?我想理论上是这样的,如果效率非常低,可以等同于log reader没有运行! 那么如何证明这一点呢?reproduce的过程可能会很复杂,而且客户的磁盘性能也很好…
我想到了另外一种可能,这个问题实际上和log reader的工作方式有关系:
当log reader启动后,会去读取publication database的日志,如果一次读取完后,如果publication database的日志中仍然有需要处理的数据,log reader会继续读;如果读取后没有数据需要处理,log reader会休息一段时间, 时间长度为PollingInterval的值(默认为5秒中)。 那么我们假设这样的情景。
PollingInterval为五秒。Log reader启动后发现没有数据需要读取,开始休息。
在第1秒的时候,其中的article a产生了数据更新
在第2秒的时候,其中的article b产生了数据更新
在第3秒的时候,添加了一个非snapshot方式初始化的订阅。
在第4秒的时候,其中的article c产生了数据更新
在第5秒的时候,其中的article d产生了数据更新
同时log reader开始继续扫描日志, 我们就会发现第一秒和第二秒的数据更新丢失了。
更多信息
1 向任意一个包含'replication support only' 订阅的发布添加article时都可能会导致这个发布库的所有发布的所有现存订阅出现更新丢失的问题。
向不包含'replication support only'订阅的发布添加不会有这个问题。
2 如果在添加一个'replication support only'的订阅时 ,该发布对应的发布数据库的所有已存在订阅也会出现更新丢失的情况,无论这些都订阅通过何种方式初始化,或属于那个发布。
解决方法之前文章介绍的相同
解决办法
===
升级至sql servr 2012
如果您暂时没有办法升级,可以采用以下两种方法:
添加一个新的发布,将新的article或订阅添加到发布中。
在添加article前将Log reader和Distribution agent停止。添加完成后,启动Log reader,确认Log reader已经将之前的数据传送到了Distribution数据库后(可以使用tracer token来确认Log reader是否已经完成同步), 启动Distribution agent。这样就可以避免数据丢失了。
更多信息
========
1 向任意一个包含’replication support only’ 订阅的发布添加article时, 都可能导致这个发布库的所有发布的所有现存订阅出现更新丢失的问题。 向不包含’replication support only’订阅的发布添加article不会有这个问题。
2 如果在添加一个’replication support only’的订阅时 ,该发布对应的发布数据库的所有发布的所有已存在订阅都会受到影响,无论这些订阅是通过何种方式初始化,或属于哪个发布。
最近又做了一个case,环境是sql server 2008 R2. 客户添加了一个'replication support only'的订阅,之后发现现存订阅出现了更新丢失。 丢失的数据恰巧是添加订阅前的几秒钟内生成的。
我开始以为是log reader没有开启造成的,检查了distribution database的MSlogreader_history
,发现期间log reader并没有停止过。
如果Log reader停止,那么添加订阅前的更新肯定是丢失了。因为产生的数据的LSN小于"添加订阅"的LSN, 并且distribution agent把"添加订阅"的LSN先传递到了订阅。可是log reader一直处于运行状态,那么还有什么可能呢? 如果log reader的效率很低,没有即时地将数据更新传递到distribution agent,那么也会产生这个问题吧?我想理论上是这样的,如果效率非常低,可以等同于log reader没有运行! 那么如何证明这一点呢?reproduce的过程可能会很复杂,而且客户的磁盘性能也很好…
我想到了另外一种可能,这个问题实际上和log reader的工作方式有关系:
当log reader启动后,会去读取publication database的日志,如果一次读取完后,如果publication database的日志中仍然有需要处理的数据,log reader会继续读;如果读取后没有数据需要处理,log reader会休息一段时间, 时间长度为PollingInterval的值(默认为5秒中)。 那么我们假设这样的情景。
PollingInterval为五秒。Log reader启动后发现没有数据需要读取,开始休息。
在第1秒的时候,其中的article a产生了数据更新
在第2秒的时候,其中的article b产生了数据更新
在第3秒的时候,添加了一个非snapshot方式初始化的订阅。
在第4秒的时候,其中的article c产生了数据更新
在第5秒的时候,其中的article d产生了数据更新
同时log reader开始继续扫描日志, 我们就会发现第一秒和第二秒的数据更新丢失了。
更多信息
1 向任意一个包含'replication support only' 订阅的发布添加article时都可能会导致这个发布库的所有发布的所有现存订阅出现更新丢失的问题。
向不包含'replication support only'订阅的发布添加不会有这个问题。
2 如果在添加一个'replication support only'的订阅时 ,该发布对应的发布数据库的所有已存在订阅也会出现更新丢失的情况,无论这些都订阅通过何种方式初始化,或属于那个发布。
解决方法之前文章介绍的相同
解决办法
===
升级至sql servr 2012
如果您暂时没有办法升级,可以采用以下两种方法:
添加一个新的发布,将新的article或订阅添加到发布中。
在添加article前将Log reader和Distribution agent停止。添加完成后,启动Log reader,确认Log reader已经将之前的数据传送到了Distribution数据库后(可以使用tracer token来确认Log reader是否已经完成同步), 启动Distribution agent。这样就可以避免数据丢失了。
更多信息
========
1 向任意一个包含’replication support only’ 订阅的发布添加article时, 都可能导致这个发布库的所有发布的所有现存订阅出现更新丢失的问题。 向不包含’replication support only’订阅的发布添加article不会有这个问题。
2 如果在添加一个’replication support only’的订阅时 ,该发布对应的发布数据库的所有发布的所有已存在订阅都会受到影响,无论这些订阅是通过何种方式初始化,或属于哪个发布。
相关文章推荐
- 一个事务复制的bug--更新丢失
- 今天解决了一个bug,是一个页面渲染丢失页面的bug
- RO39 – 在一个事务中实现多个ClientDataSets 更新
- 使用复制存储过程执行解决“事务复制中的表大量更新导致无法及时同步”的问题 (转)
- 浙江电信网上营业厅的一个BUG(有更新)
- Spring中事务的(特性,传播行为,隔离级别,不合理现象,丢失更新,案例..)
- 一个简易的四则运算单元...(15.12.15 BUG更新)
- Codeigniter框架的更新事务(transaction)BUG及解决方法
- 一个由于spring事务引起的bug
- mysql主从复制一个小错误导致从库不更新数据
- 一个分发复制+mirror的bug
- 对于事务复制更新启用Singleton 新跟踪标志
- Codeigniter框架的更新事务(transaction)BUG及解决方法
- Codeigniter框架的更新事务(transaction)BUG及解决方法
- 安装 LaserJet 1020 时这个设备的驱动程序丢失了一个必需的项,这可能是由于 inf 是为 Windows 95 或更新版本而写的。联系您的硬件供应商。
- Spring 五个事务隔离级别和七个事务传播行为和数据读取出现的四个问题(丢失或覆盖更新、脏读、非重复读、幻想读)
- 可更新订阅的事务复制错误:列名 'msrepl_tran_version' 无效
- linux - shell 将7天内更新的文件复制到另外一个文件夹
- [工作bug]一个weblogic跨应用导致session丢失的bug之旅
- 关于事务 --- 丢失更新