22,209
社区成员
发帖
与我相关
我的任务
分享SQL SERVER 2005 大数据量(约2000W) 发布订阅 同步的问题
数据量非常的大，大概有2000W左右的文章还有相关的分类信息，IO操作可能在短时间内读写都非常频繁。
现在我使用的是 主从数据库读写分离的做法，采用的是快照发布
现在有几个问题：
1.订阅服务器有可能因为一段时间过于忙碌导致同步严重延迟，偶尔会发生忙碌过后无法正常同步的现象，在这种情况下只能进行重新订阅么？重新订阅的过程中是否需要重新发布快照，因为发布快照是一件非常耗时间的事情
2.快照同步大概最多支持多少数据量
另外还有些问题，希望热心的同学能一起讨论下：
我的QQ：52075922 MSN： yuhenyunchou@hotmail.com
现在我使用的是 主从数据库读写分离的做法，采用的是快照发布
现在有几个问题：
1.订阅服务器有可能因为一段时间过于忙碌导致同步严重延迟，偶尔会发生忙碌过后无法正常同步的现象，在这种情况下只能进行重新订阅么？重新订阅的过程中是否需要重新发布快照，因为发布快照是一件非常耗时间的事情
2.快照同步大概最多支持多少数据量
另外还有些问题，希望热心的同学能一起讨论下：
我的QQ：52075922 MSN： yuhenyunchou@hotmail.com
...全文
请发表友善的回复…
发表回复
7761098 2009-10-13
- 打赏
- 举报
[Quote=引用 16 楼 perfectaction 的回复:]
在sql 2008中，80有15分钟就够了。
4*4 cpu 16G内存
[/Quote]
这么夸张？我这边2005， 30G也需要将近一个小时，硬件差不多
在sql 2008中，80有15分钟就够了。
4*4 cpu 16G内存
[/Quote]
这么夸张？我这边2005， 30G也需要将近一个小时，硬件差不多
nzperfect 2009-10-13
- 打赏
- 举报
在sql 2008中，80有15分钟就够了。
4*4 cpu 16G内存
4*4 cpu 16G内存
redwolf_123 2009-10-13
- 打赏
- 举报
重新发布快照，还有订阅服务器同步
两个加起来大概要10来个小时
数据库大概有80G左右
两个加起来大概要10来个小时
数据库大概有80G左右
navy887 2009-10-13
- 打赏
- 举报
实在不行，重新来过吧，不过为什么需要10几个小时这么长时间？
redwolf_123 2009-10-13
- 打赏
- 举报
似乎现在订阅服务器在自动尝试 重新初始化 提示快照不可用
navy887 2009-10-13
- 打赏
- 举报
[Quote=引用 9 楼 redwolf_123 的回复:]
另外我想知道：
事务同步 他的事务全会记录下来么？ 我的意思是 订阅服务器隔了1天没同步 第二天他能将之前的事务也同步？
[/Quote]
事务同步 和快照的区别是事务是实时的，快照是定时的。
事务同步，如果订阅出错，同步这边有红叉，隔了1天没同步数据的话，启动同步以后会继续同步没有同步的数据。但是先要把红叉的原因解决，不然同步启动不了。
另外我想知道：
事务同步 他的事务全会记录下来么？ 我的意思是 订阅服务器隔了1天没同步 第二天他能将之前的事务也同步？
[/Quote]
事务同步 和快照的区别是事务是实时的，快照是定时的。
事务同步，如果订阅出错，同步这边有红叉，隔了1天没同步数据的话，启动同步以后会继续同步没有同步的数据。但是先要把红叉的原因解决，不然同步启动不了。
redwolf_123 2009-10-13
- 打赏
- 举报
理论上来说，如果在订阅服务器有记录最后的 事务时间
然后发布服务器保存了 所有的原始快照后的事务
那就可以实现。问题是我不知道原理，是否是这么做的
另外 我的发布服务器上的 复制监视器上 显示两台订阅服务器的状况都 很好
可是其中一台能正常同步 另外一台却停止了
现在我想恢复停止的那台，可是我除了重新发布原始快照，然后订阅外，（这个很耗时间，可能得10几个小时，不到万不得已 我不想这么做）不知道还有什么方法。
另外 当事务传递到订阅服务器，如果执行失败，不知道订阅服务器会不会将该事务保存下来，以待正常后继续同步
然后发布服务器保存了 所有的原始快照后的事务
那就可以实现。问题是我不知道原理，是否是这么做的
另外 我的发布服务器上的 复制监视器上 显示两台订阅服务器的状况都 很好
可是其中一台能正常同步 另外一台却停止了
现在我想恢复停止的那台，可是我除了重新发布原始快照，然后订阅外，（这个很耗时间，可能得10几个小时，不到万不得已 我不想这么做）不知道还有什么方法。
另外 当事务传递到订阅服务器，如果执行失败，不知道订阅服务器会不会将该事务保存下来，以待正常后继续同步
--小F-- 2009-10-13
- 打赏
- 举报
[Quote=引用 9 楼 redwolf_123 的回复:]
引用 8 楼 navy887 的回复:
在发布服务器重新启动同步处理就可以了
发布服务器的同步 一直没停过，我这边有两台 订阅服务器
其中一台很正常的在同步数据， 可是另外一台的数据却从昨天开始没同步了
大概我的数据库有80G左右 不算日志
另外我想知道：
事务同步 他的事务全会记录下来么？ 我的意思是 订阅服务器隔了1天没同步 第二天他能将之前的事务也同步？
[/Quote]
没这么智能吧
引用 8 楼 navy887 的回复:
在发布服务器重新启动同步处理就可以了
发布服务器的同步 一直没停过，我这边有两台 订阅服务器
其中一台很正常的在同步数据， 可是另外一台的数据却从昨天开始没同步了
大概我的数据库有80G左右 不算日志
另外我想知道：
事务同步 他的事务全会记录下来么？ 我的意思是 订阅服务器隔了1天没同步 第二天他能将之前的事务也同步？
[/Quote]
没这么智能吧
redwolf_123 2009-10-13
- 打赏
- 举报
[Quote=引用 8 楼 navy887 的回复:]
在发布服务器重新启动同步处理就可以了
[/Quote]
发布服务器的同步 一直没停过，我这边有两台 订阅服务器
其中一台很正常的在同步数据， 可是另外一台的数据却从昨天开始没同步了
大概我的数据库有80G左右 不算日志
另外我想知道：
事务同步 他的事务全会记录下来么？ 我的意思是 订阅服务器隔了1天没同步 第二天他能将之前的事务也同步？
在发布服务器重新启动同步处理就可以了
[/Quote]
发布服务器的同步 一直没停过，我这边有两台 订阅服务器
其中一台很正常的在同步数据， 可是另外一台的数据却从昨天开始没同步了
大概我的数据库有80G左右 不算日志
另外我想知道：
事务同步 他的事务全会记录下来么？ 我的意思是 订阅服务器隔了1天没同步 第二天他能将之前的事务也同步？
navy887 2009-10-13
- 打赏
- 举报
[Quote=引用 6 楼 redwolf_123 的回复:]
现在我想知道的是
某台订阅服务器在因为忙碌停止同步后
如果将它恢复？
[/Quote]
在发布服务器重新启动同步处理就可以了
现在我想知道的是
某台订阅服务器在因为忙碌停止同步后
如果将它恢复？
[/Quote]
在发布服务器重新启动同步处理就可以了
redwolf_123 2009-10-13
- 打赏
- 举报
--事务能接上就不用重新初始订阅
--重新订阅一般是需要重新生成快照的
问题是我不确定SQL SERVER 他事务能否接上
昨天中午订阅服务器比较忙碌，导致同步于12：06就停止了
结果到今天 他一直没有再进行同步了
在发布服务器的监测里 看到的状态是 很好 没有延迟
订阅服务器这边的代理也在正常运行
--重新订阅一般是需要重新生成快照的
问题是我不确定SQL SERVER 他事务能否接上
昨天中午订阅服务器比较忙碌，导致同步于12：06就停止了
结果到今天 他一直没有再进行同步了
在发布服务器的监测里 看到的状态是 很好 没有延迟
订阅服务器这边的代理也在正常运行
redwolf_123 2009-10-13
- 打赏
- 举报
现在我想知道的是
某台订阅服务器在因为忙碌停止同步后
如果将它恢复？
某台订阅服务器在因为忙碌停止同步后
如果将它恢复？
nzperfect 2009-10-13
- 打赏
- 举报
[Quote=引用楼主 redwolf_123 的回复:]
数据量非常的大，大概有2000W左右的文章还有相关的分类信息，IO操作可能在短时间内读写都非常频繁。
现在我使用的是 主从数据库读写分离的做法，采用的是快照发布
现在有几个问题：
1.订阅服务器有可能因为一段时间过于忙碌导致同步严重延迟，偶尔会发生忙碌过后无法正常同步的现象，在这种情况下只能进行重新订阅么？重新订阅的过程中是否需要重新发布快照，因为发布快照是一件非常耗时间的事情
2.快照同步大概最多支持多少数据量
另外还有些问题，希望热心的同学能一起讨论下：
我的QQ：52075922 MSN： yuhenyunchou@hotmail.com
[/Quote]
快照发布还是事务发布？
1.订阅服务器有可能因为一段时间过于忙碌导致同步严重延迟，偶尔会发生忙碌过后无法正常同步的现象，在这种情况下只能进行重新订阅么？重新订阅的过程中是否需要重新发布快照，因为发布快照是一件非常耗时间的事情
--事务能接上就不用重新初始订阅
--重新订阅一般是需要重新生成快照的
2.快照同步大概最多支持多少数据
--这个没有定论，取决于硬件，5亿的我也做过。
数据量非常的大，大概有2000W左右的文章还有相关的分类信息，IO操作可能在短时间内读写都非常频繁。
现在我使用的是 主从数据库读写分离的做法，采用的是快照发布
现在有几个问题：
1.订阅服务器有可能因为一段时间过于忙碌导致同步严重延迟，偶尔会发生忙碌过后无法正常同步的现象，在这种情况下只能进行重新订阅么？重新订阅的过程中是否需要重新发布快照，因为发布快照是一件非常耗时间的事情
2.快照同步大概最多支持多少数据量
另外还有些问题，希望热心的同学能一起讨论下：
我的QQ：52075922 MSN： yuhenyunchou@hotmail.com
[/Quote]
快照发布还是事务发布？
1.订阅服务器有可能因为一段时间过于忙碌导致同步严重延迟，偶尔会发生忙碌过后无法正常同步的现象，在这种情况下只能进行重新订阅么？重新订阅的过程中是否需要重新发布快照，因为发布快照是一件非常耗时间的事情
--事务能接上就不用重新初始订阅
--重新订阅一般是需要重新生成快照的
2.快照同步大概最多支持多少数据
--这个没有定论，取决于硬件，5亿的我也做过。
redwolf_123 2009-10-13
- 打赏
- 举报
更正下。。 我也是用的事务发布，因为更新频率比较大
dawugui 2009-10-13
- 打赏
- 举报
学习.
navy887 2009-10-13
- 打赏
- 举报
1.无法正常同步，出现错误以后，重新启动同步处理就可以了。不用重新发布订阅。
2.没试过支持多少数据，我是几千万的数据一直是事务同步的。
2.没试过支持多少数据，我是几千万的数据一直是事务同步的。
--小F-- 2009-10-13
- 打赏
- 举报
1。最好是重新订阅 重新订阅的话需要重新发布快照
2。理论上是没限制的 但是一般处理1000W以下比较合适
2。理论上是没限制的 但是一般处理1000W以下比较合适
redwolf_123 2009-10-13
- 打赏
- 举报
这个太令人惊讶了吧
看看样子我们公司得好好考虑下迁移到2008上去
看看样子我们公司得好好考虑下迁移到2008上去
nzperfect 2009-10-13
- 打赏
- 举报
快照和事务复制命令执行效率的提高
快照技术是指从发布者向订阅者复制数据，数据库对象和可以重建表，存储过程，函数，视图等的元数据。
微软博客上的这个帖子有一些关于提高可扩展性的内容，但是最令人感兴趣的部分是下面这段话：
“结果绝对令人瞠目。Pull方式的复制在Yukon平台（Windows Server 2003）的SQL Server 2005上运行需要223分钟，而在采用Katmai指令技术的Longhorrn Server平台（Windows 2008 Server）上只需要2分钟”；一份11.3GB大的快照在大约23分钟内被发送到2000英里之外（几乎每分钟500MB的速率）。这是按字节算的，而不是按位算的。可以讨论‘better together’了。
除了快照执行效率的提升，运行在Windows Server 2008上的SQL Server 2008可以利用TCP/IP网络协议栈改善复制命令的延迟时间。Windows Server 2008对于TCP/IP网络协议栈的改进使得我们可以自行调整TCP/IP包的参数（某些情况下是自动调整的）。涉及的具体参数有：
1、接收Window Auto-Tuning
2、发送缓冲自动扩展
3、接收Compound TCP
按照MSDN上白皮书介绍，微软的Engineering Operations团队在pull varbinary (max)类型数据复制上，达到了令人难以置信的性能提升：11345.13%。
快照技术是指从发布者向订阅者复制数据，数据库对象和可以重建表，存储过程，函数，视图等的元数据。
微软博客上的这个帖子有一些关于提高可扩展性的内容，但是最令人感兴趣的部分是下面这段话：
“结果绝对令人瞠目。Pull方式的复制在Yukon平台（Windows Server 2003）的SQL Server 2005上运行需要223分钟，而在采用Katmai指令技术的Longhorrn Server平台（Windows 2008 Server）上只需要2分钟”；一份11.3GB大的快照在大约23分钟内被发送到2000英里之外（几乎每分钟500MB的速率）。这是按字节算的，而不是按位算的。可以讨论‘better together’了。
除了快照执行效率的提升，运行在Windows Server 2008上的SQL Server 2008可以利用TCP/IP网络协议栈改善复制命令的延迟时间。Windows Server 2008对于TCP/IP网络协议栈的改进使得我们可以自行调整TCP/IP包的参数（某些情况下是自动调整的）。涉及的具体参数有：
1、接收Window Auto-Tuning
2、发送缓冲自动扩展
3、接收Compound TCP
按照MSDN上白皮书介绍，微软的Engineering Operations团队在pull varbinary (max)类型数据复制上，达到了令人难以置信的性能提升：11345.13%。
redwolf_123 2009-10-13
- 打赏
- 举报
[Quote=引用 16 楼 perfectaction 的回复:]
在sql 2008中，80有15分钟就够了。
4*4 cpu 16G内存
[/Quote]
不太可能吧？ 这意味着处理速度要达到 91M/s
在sql 2008中，80有15分钟就够了。
4*4 cpu 16G内存
[/Quote]
不太可能吧？ 这意味着处理速度要达到 91M/s
加载更多回复（1）
