none
最近留意sql2005灾难性恢复的方案,三种方案的比较哪种比较好 RRS feed

  • 问题

  • 看来一些文章,sql2005灾难性恢复主要有3种方案:1 镜像技术 2复制技术  3传送事务日志技术

    我想知道从经济性 ,可靠性,性能性(暂且这麽定吧,性能方面的)的方面说一下哪种方案适合哪种情况

    比如

    1、性能与经济性:事务日志传送,辅助数据库服务器的硬盘够大就可以了,服务器配置不用太高,而且一般15分钟还原一次

    2、可靠性:镜像技术,除了镜像服务器还需要监视服务器,而且sql版本是要企业版,不过比较贵,但是可靠性高

    3、经济性:复制技术,复制技术的话之前在论坛里有人说如果插入数据量很大,比如过百万,那么对于事务复制的阻塞严重,但是可以做到读写分离,减轻主数据库的负担

    但是使用复制技术的话,会在每个表增加一个同步字段,使用事务复制的话,感觉不是很好

    如果这样分类不对希望大家指正


    给我写信: QQ我:点击这里给我发消息


    2012年9月8日 5:25

答案

  • 镜像算是管理配置最简单的一种吧,程序上也可以通过连接字符串中配置镜像服务器,达到故障时自动连接镜像,无需人工干预的目的

    事务日志传送的同步效率比镜像低,它是依赖Job定时去做的,而且因为是Job备份+还原,所以涉及的东西比较多,任何一个环节出问题,都会导致这个过程中断,所以可靠性上比镜像差

    复制不算是标准的灾难恢复方案,因为它只是对数据库中的对象进行同步(而且一般都配置为同步表,像存储过程什么的,很难会配置为复制同步),所以它同步的东西存在一定的缺失。另外,它也是对象级别的,新增薄雾删除对象时,都要去调整复制配置,所以如果你用它来做灾难恢复方案的话,管理和配置的复杂程度会比较高。当然,最大的好处是,你可以根据情况对不同的表选择不同的复制技术,可控性高,也可以做到一定程度的负载均衡

    2012年9月10日 1:15
  • failover的最佳方案还是clustered。不过楼主的意思如果是异地容灾的话,用镜像或者log shipping比较方便。

    想不想时已是想,不如不想都不想。

    2012年9月10日 2:13
    版主

全部回复

  • Replication is not designed for DR. Regarding log shipping and mirroring, can't say which one is better without mention business requirement.
    2012年9月8日 14:36
  • 我知道复制不是设计用于灾难恢复,但是技术怎麽用是由我们来决定的

    第二个就是虽然每种方案是根据业务,但是这里可以讨论一下嘛

    比如 镜像需要3台服务器  而事务日志传送只需要两台,那么可以从成本角度去看,我是指实现方案


    给我写信: QQ我:点击这里给我发消息

    2012年9月8日 14:51
  • You can set db mirroring without witness.
    2012年9月9日 0:18
  • 我知道使用数据库镜像可以不用监视服务器。谢谢rmiao大侠的回答,看来这个问题冷清啊

    给我写信: QQ我:点击这里给我发消息

    2012年9月9日 12:49
  • SQL Server还有集群也是高可用性的解决方案,在SQL Server 2012中新增了AlwaysOn.

    其实讨论那种方案比较合适还是要看自己的真正应用了。

    2012年9月9日 13:04
  • 可更新的复制才会加字段。

    想不想时已是想,不如不想都不想。

    2012年9月9日 16:18
    版主
  • 镜像算是管理配置最简单的一种吧,程序上也可以通过连接字符串中配置镜像服务器,达到故障时自动连接镜像,无需人工干预的目的

    事务日志传送的同步效率比镜像低,它是依赖Job定时去做的,而且因为是Job备份+还原,所以涉及的东西比较多,任何一个环节出问题,都会导致这个过程中断,所以可靠性上比镜像差

    复制不算是标准的灾难恢复方案,因为它只是对数据库中的对象进行同步(而且一般都配置为同步表,像存储过程什么的,很难会配置为复制同步),所以它同步的东西存在一定的缺失。另外,它也是对象级别的,新增薄雾删除对象时,都要去调整复制配置,所以如果你用它来做灾难恢复方案的话,管理和配置的复杂程度会比较高。当然,最大的好处是,你可以根据情况对不同的表选择不同的复制技术,可控性高,也可以做到一定程度的负载均衡

    2012年9月10日 1:15
  • 一般来说,比较推荐镜像的方案

    如果有足够的硬件设备,再结合群集则更佳

    2012年9月10日 1:18
  • failover的最佳方案还是clustered。不过楼主的意思如果是异地容灾的话,用镜像或者log shipping比较方便。

    想不想时已是想,不如不想都不想。

    2012年9月10日 2:13
    版主
  • 镜像就OK了

    如果要见证自动FailOver,装个Express顶上

    LogShipping估计也就是遗留系统用了。。复制的目标不是灾备与高可用,虽然可完成任务,但不适合


    Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com

    2012年9月10日 3:02
  • 事务复制嘛

    给我写信: QQ我:点击这里给我发消息

    2012年9月10日 12:38
  • 请教邹建大侠,是不是用另外一个程序定时去判断数据库服务器的可用性呢?如果主数据库服务器宕机,那么程序就修改配置文件,

    通知web程序去读取最新的连接字符串?


    给我写信: QQ我:点击这里给我发消息

    2012年9月10日 12:44
  • 那么我总结一下,正规与不正规的灾难恢复方案:1、镜像    2、事务日志传送   3、复制    4、群集

    给我写信: QQ我:点击这里给我发消息

    2012年9月10日 12:45
  • 请教邹建大侠,是不是用另外一个程序定时去判断数据库服务器的可用性呢?如果主数据库服务器宕机,那么程序就修改配置文件,

    通知web程序去读取最新的连接字符串?


    给我写信: QQ我:点击这里给我发消息


    Not the case for db mirroring if app uses .net2 or above for sql connection.
    2012年9月10日 14:30
  • ?   

    给我写信: QQ我:点击这里给我发消息

    2012年9月11日 0:50
  • You can put failover partner in .net2 connection string for db mirroring, so that app doesn't need to check server status. 
    2012年9月11日 1:17
  • 你的意思是  :你可以把备份服务器放入.net2里的连接字符串 作为数据库镜像,所以app不需要检查服务器的状态

    你说的.net2是什么意思?


    给我写信: QQ我:点击这里给我发消息

    2012年9月11日 4:01
  • .net version 2.
    2012年9月11日 13:18
  • database mirroring db connection:

    "Server=Partner_A; Failover_Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"

    http://msdn.microsoft.com/en-us/library/ms175484.aspx

    如果用集群直接用Virtual server name, Failoever之后程序会自动连接到UP的Node上面。


    2012年9月12日 13:59