s***s
发帖数: 1301 | 1 我们现在需要对distribution server 硬件升级，但是我们又担心万一中间出问题，无
法恢复正常工作，然后需要重新reinitialize articles，而有些table很大的，重新
replication的话，需要很长时间 （6，7个小时），这是不允许的。这个distribution
server也不是cluster。 所以想请教有没有比较好的应急方式？
谢谢！ |
s**********o
发帖数: 14359 | 2 搞一个LOG SHIPPING的SERVER做BACKUP? |
a9
发帖数: 21638 | 3 备份，拷贝，还原，拔网线，再备份，再还原，改ip插网线？
distribution
【在 s***s 的大作中提到】
: 我们现在需要对distribution server 硬件升级，但是我们又担心万一中间出问题，无
: 法恢复正常工作，然后需要重新reinitialize articles，而有些table很大的，重新
: replication的话，需要很长时间 （6，7个小时），这是不允许的。这个distribution
: server也不是cluster。 所以想请教有没有比较好的应急方式？
: 谢谢！
|
s**********o
发帖数: 14359 | 4 你这个不行的，因为PUBLISHER老在变，DISTRIBUTION一旦离线就OUT OF SYNC了
就要重新SYNC，最好是DISTRIBUTION和SUBSCRIBER都去离线UPGRADE，
然后重新SYNC，SYNC好了再接APPLICATION,所以最好有个临时的SERVER用一用，
DISTRIBUTION一般跟PUBLISER在一个SERVER上，这样省去很多麻烦的
【在 a9 的大作中提到】
: 备份，拷贝，还原，拔网线，再备份，再还原，改ip插网线？
:
: distribution
|
s***s
发帖数: 1301 | 5 谢谢，我们就是publisher, distribution, subscriber分别在不同的server,
distribution的server就用比较差点的配置。你说的临时的server是指distribution
server还是指临时的subscriber server？ 一个publisher只能有一个distribution 的
，用临时的distribution server 也是相当中断，然后还是要重新sync的 。 如果是指
subscriber端的server，可以临时顶替用下（数据不是最新的），不过离线upgrade
distribtuion的话，再放回去，还是要重新resync 数据了。
【在 s**********o 的大作中提到】
: 你这个不行的，因为PUBLISHER老在变，DISTRIBUTION一旦离线就OUT OF SYNC了
: 就要重新SYNC，最好是DISTRIBUTION和SUBSCRIBER都去离线UPGRADE，
: 然后重新SYNC，SYNC好了再接APPLICATION,所以最好有个临时的SERVER用一用，
: DISTRIBUTION一般跟PUBLISER在一个SERVER上，这样省去很多麻烦的
|
s**********o
发帖数: 14359 | 6 除了REPLICATION还有DATABASE MIRRORING, LOG SHIPPING
也可以把APPLICATION暂时指向PUBLISER，发正就是只读么，
也是临时的，临时用一下没问题的，等DISTRIBUTION和SUBSCRIBER
做好了再换回来
【在 s***s 的大作中提到】
: 谢谢，我们就是publisher, distribution, subscriber分别在不同的server,
: distribution的server就用比较差点的配置。你说的临时的server是指distribution
: server还是指临时的subscriber server？ 一个publisher只能有一个distribution 的
: ，用临时的distribution server 也是相当中断，然后还是要重新sync的 。 如果是指
: subscriber端的server，可以临时顶替用下（数据不是最新的），不过离线upgrade
: distribtuion的话，再放回去，还是要重新resync 数据了。
|
s**********o
发帖数: 14359 | 7 就算是银行的系统，周末DOWN个几个小时维护也是正常的 |
s***s
发帖数: 1301 | 8 我们也知道，但是老板要求苛刻，恨不得要全部实时在线:(
【在 s**********o 的大作中提到】
: 就算是银行的系统，周末DOWN个几个小时维护也是正常的
|
s**********o
发帖数: 14359 | 9 DISTRIBUTION单独一个SERVER本身就增加很多NETWORK TRAFFIC和IO
反而比一个SERVER上慢的，出问题机会也大
【在 s***s 的大作中提到】
: 我们也知道，但是老板要求苛刻，恨不得要全部实时在线:(
|
a9
发帖数: 21638 | 10 重新sync也不需要太多时间吧。
sqlserver的发布就是log shipping吧？
【在 s**********o 的大作中提到】
: 你这个不行的，因为PUBLISHER老在变，DISTRIBUTION一旦离线就OUT OF SYNC了
: 就要重新SYNC，最好是DISTRIBUTION和SUBSCRIBER都去离线UPGRADE，
: 然后重新SYNC，SYNC好了再接APPLICATION,所以最好有个临时的SERVER用一用，
: DISTRIBUTION一般跟PUBLISER在一个SERVER上，这样省去很多麻烦的
|
|
|
w*******e
发帖数: 1622 | 11 硬件？无非是CPU，memory, HD, NIC, etc. 出什么问题？如果真出问题了，只是
subcriber out of sync 一两个小时(最多).
我们这儿就是distributor在自己的机器上的，到目前为止（三年），没什么问题,几乎
都忘了it的存在.
distribution
【在 s***s 的大作中提到】
: 我们现在需要对distribution server 硬件升级，但是我们又担心万一中间出问题，无
: 法恢复正常工作，然后需要重新reinitialize articles，而有些table很大的，重新
: replication的话，需要很长时间 （6，7个小时），这是不允许的。这个distribution
: server也不是cluster。 所以想请教有没有比较好的应急方式？
: 谢谢！
|
B****n
发帖数: 194 | 12 Initialize from backup , google it
distribution
★ 发自iPhone App: ChineseWeb 7.8
【在 s***s 的大作中提到】
: 我们现在需要对distribution server 硬件升级，但是我们又担心万一中间出问题，无
: 法恢复正常工作，然后需要重新reinitialize articles，而有些table很大的，重新
: replication的话，需要很长时间 （6，7个小时），这是不允许的。这个distribution
: server也不是cluster。 所以想请教有没有比较好的应急方式？
: 谢谢！
|
s***s
发帖数: 1301 | 13 那是 要求publisher端也离线吧，我们要求publisher端 production server还在
online的，很多数据不是insert，还有update的
【在 B****n 的大作中提到】
: Initialize from backup , google it
:
: distribution
: ★ 发自iPhone App: ChineseWeb 7.8
|
s***s
发帖数: 1301 | 14 主要有个关键的表有 52M records, total 171GB 大。 我们从来没有resync过这个，
据一个离职的dba说（他以前做过一次）resync这个表用了大概6， 7小时。
我们现在准备弄个测试环境测试一下，来评估一下到底要多久。
谢谢。
【在 w*******e 的大作中提到】
: 硬件？无非是CPU，memory, HD, NIC, etc. 出什么问题？如果真出问题了，只是
: subcriber out of sync 一两个小时(最多).
: 我们这儿就是distributor在自己的机器上的，到目前为止（三年），没什么问题,几乎
: 都忘了it的存在.
:
: distribution
|
B****n
发帖数: 194 | 15 不用离线
http://technet.microsoft.com/en-us/library/ms147834.aspx
★ 发自iPhone App: ChineseWeb 7.8
【在 s***s 的大作中提到】
: 那是 要求publisher端也离线吧，我们要求publisher端 production server还在
: online的，很多数据不是insert，还有update的
|
s**********o
发帖数: 14359 | 16 171G就算是RESTORE也要个把小时吧，你的SUBSCRIBER肯定要离线了 |
