none
两台SQL服务器 既做群集又做镜像? RRS feed

  • 问题

  • Hi There,

    我这边想按以下的方式来设计我的两台SQL服务器. 

    简单描述一下: 

    1. 两台服务器预装 WIN2008R2 + SQL SERVER 2008 R2

    2. 两个节点创建一个群集实例 SQL1

    3. 在节点2上创建另外一个实例SQL2, 并与SQL1做镜像

    这样, 这两台服务器, 就起到群集和镜像的功能. 平时无事故的时候, 让节点1为主机. 以获得良好的性能.

    但由于自己没在生产环境使用过, 心理不是很有底. 

    请教这样的设计会不会有哪些风险和问题? 如果有, 请明示. 谢谢!


    星星照亮全世界

    2014年8月19日 2:17

答案

  • 正常情况下

    结点2 不承载业务,两个实例没有什么问题,需要考虑的是两个结点之间的网络(镜像传递数据占用)

    (如果镜像是把数据放到共享存储上,那么这个方案没有什么意义,群集顾虑的单点失败是共享存储,镜像数据也放共享存储的话,意味着仍然有单点)

    结点1坏的话,结点2的压力就比较高了(两个实例,镜像的额外IO),如果你这个是业务繁忙的服务器,那么可能结点2的响应会出现一些问题

    结点2坏的话,短时间还好,长时间可能会出问题,因为结点1的日志会持续增长(在镜像恢复前不能重用日志空间)

    2014年8月19日 4:28
  • 大致就是这个意思:

    当数据库配置了镜像之后,日志文件重用的条件,除了完成日志备份(如果有事务复制,还包括日志读取)之外,还需要日志同步到镜像之后,日志空间才可以重用

    镜像失败,意味着日志空间一直战胜,新的操作需要写入的话,就需要分配新的日志空间,就意味着数据一直在变化的话,日志就会一直写,一直分配新的日志空间

    2014年8月19日 7:46

全部回复

  • 提供一篇文章

    http://www.cnblogs.com/diabloxl/p/3528229.html

    SQLServer 2012异常问题(一)--故障转移群集+镜像环境导致作业执行失败

    2014年8月19日 2:39
  • It works but you don't have DR if node2 goes down, so don't believe this is good practice for prod environment. 
    2014年8月19日 2:51
  • It works but you don't have DR if node2 goes down, so don't believe this is good practice for prod environment. 
    May I k now what DR is?

    星星照亮全世界

    2014年8月19日 3:39
  • Disaster Recovery, that's what db mirroring for. By the way, you may have performance issue when node1 goes down because node2 has to run 2 instances.
    2014年8月19日 3:49
  • 正常情况下

    结点2 不承载业务,两个实例没有什么问题,需要考虑的是两个结点之间的网络(镜像传递数据占用)

    (如果镜像是把数据放到共享存储上,那么这个方案没有什么意义,群集顾虑的单点失败是共享存储,镜像数据也放共享存储的话,意味着仍然有单点)

    结点1坏的话,结点2的压力就比较高了(两个实例,镜像的额外IO),如果你这个是业务繁忙的服务器,那么可能结点2的响应会出现一些问题

    结点2坏的话,短时间还好,长时间可能会出问题,因为结点1的日志会持续增长(在镜像恢复前不能重用日志空间)

    2014年8月19日 4:28
  • 为什么需要这样的架构?是为了做DR?

    Please Mark As Answer if it is helpful.

    2014年8月19日 4:33
  • 为什么需要这样的架构?是为了做DR?

    Please Mark As Answer if it is helpful.

    可以避免存储宕机而造成业务的瘫痪.

    星星照亮全世界

    2014年8月19日 6:13
  • Disaster Recovery, that's what db mirroring for. By the way, you may have performance issue when node1 goes down because node2 has to run 2 instances.

    Hi rmiao,

    Thanks for ur reply. You are right, when node1 goes down, node2 will suffer from the performance issue. 

    My idea is to stop mirroring job and 2nd instance SQL services to release the resources for the business until the node1 is recovered. 

    Will the steps bring other potential issue(s)? 


    星星照亮全世界

    2014年8月19日 6:21
  • 正常情况下

    结点2 不承载业务,两个实例没有什么问题,需要考虑的是两个结点之间的网络(镜像传递数据占用)

    (如果镜像是把数据放到共享存储上,那么这个方案没有什么意义,群集顾虑的单点失败是共享存储,镜像数据也放共享存储的话,意味着仍然有单点)

    结点1坏的话,结点2的压力就比较高了(两个实例,镜像的额外IO),如果你这个是业务繁忙的服务器,那么可能结点2的响应会出现一些问题

    结点2坏的话,短时间还好,长时间可能会出问题,因为结点1的日志会持续增长(在镜像恢复前不能重用日志空间)

    1. 的确, 这样的架构正是为了应付共享存储失败, 节点2的独立实例的数据库文件当然不会放在共享存储上;

    2. 节点1坏的话, 如果节点2实在吃不消, 我是打算停掉镜像的任务和独立实例的服务, 以释放资源;

    3. 关于你说的日志增长, 是否有详细的说明文档描述, 本人不是特别理解, 望赐教. 

    Thanks a lot.


    星星照亮全世界

    2014年8月19日 6:29
  • 大致就是这个意思:

    当数据库配置了镜像之后,日志文件重用的条件,除了完成日志备份(如果有事务复制,还包括日志读取)之外,还需要日志同步到镜像之后,日志空间才可以重用

    镜像失败,意味着日志空间一直战胜,新的操作需要写入的话,就需要分配新的日志空间,就意味着数据一直在变化的话,日志就会一直写,一直分配新的日志空间

    2014年8月19日 7:46
  • Disaster Recovery, that's what db mirroring for. By the way, you may have performance issue when node1 goes down because node2 has to run 2 instances.

    Hi rmiao,

    Thanks for ur reply. You are right, when node1 goes down, node2 will suffer from the performance issue. 

    My idea is to stop mirroring job and 2nd instance SQL services to release the resources for the business until the node1 is recovered. 

    Will the steps bring other potential issue(s)? 


    星星照亮全世界

    Then you have to break mirror otherwise db will be in disconnect status and no one can access it, that makes your DR solution worthless. So you are better to put mirror partner on separate machine, even on a VM.
    2014年8月19日 13:00
  • 理论上可行。但是只有两个物理节点,同时做群集和镜像意义不大,反而影响性能。

    我建议就做群集(如果有物理共享存储)。


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

    2014年8月24日 6:09
    版主