sql server 作为目前主流的数据库,用户遍布世界各地。sql server也有一些比较成熟的主备方案,目前主要有:复制模式(发布-订阅模式)、镜像传输模式、日志传输模式、故障转移集群。后面会一一介绍介绍各自的优缺点。

(一)复制模式

  复制模式也被称为发布-订阅模式,是由主服务器进行发布消息,备份服务器进行订阅,当主服务器数据发生变更时,就会发布消息,备份服务器读取消息进行同步更新,中间过程延迟比较短。

  复制方式是以前很常见的一种主备,速度快,延迟小,可以支持部分同步等优点,但是也有一个很明显的缺点,因为是部分同步,如果是表修改,可以主动同步,但是如果是新增表、视图等操作,必须在发布属性中,将新加的表或者视图添加到同步配置中,否则对这个表做的任何操作都不会同步。

  复制模式同步,要求数据库名称和主机名称必须一致,否则查找不到数据库主机;要求数据库不能使用端口,必须是可以通过ip直接访问的;

  主要分为以下4种发布方式:

  1.快照发布

    快照发布,就是将所有要发布的内容,做成一个镜像文件,然后一次性复制到订阅服务器,两次快照之间的更新不会实时同步。这种方式占用带宽较多,因此比较适用内容不是很大,或者更新不需要很频繁的场景

  2.事务发布/具有可更新订阅的事务发布

    事务发布,是在第一次设置好事务复制之后,所有发布的内容都会进行镜像快照,订阅服务器收到已发布数据的初始快照后,发布服务器将事务流式传输到订阅服务器。当主服务器数据发生变更时,会通过日志传递同步给订阅服务器,数据近似于同步更新。

    此方式会对主服务器性能造成很大影响(实时同步每次变更,而不是最终变更),适用于对数据及时性要求比较严格主备方案,但是目前已被微软提供的集群Always On所取代。

 

  3.合并发布

    合并发布是相当于两台都是主服务器,都可以对数据进行更新修改等操作,然后定时将发布服务器上的内容与订阅服务器上的内容进行合并,并根据配置保留相应内容,此种很少用。

(二)镜像传输模式

  数据库镜像传输,严格来说不是主从架构,而是主备架构,将两台数据库服务器通过一台中间监控服务器关联起来,两台服务器通过镜像文件,实时同步数据(有延迟,延迟很短)。当主服务器宕机之后,监控服务器自动切换到备份服务器上。

  此方案优点是可以快速的切换主备方案,相比较Always on集群,可以不用共享磁盘即可实现,避免了数据库集群存储单点故障,导致整个集群崩溃。

  缺点也很明显,无论是主备服务器,要实现同步操作,都是依赖于性能低的那一端,因此两台服务器都要是高性能的才可以保证同步的及时性;同时备份服务器只是备份和故障转移,不能提供从服务器的只读访问,因此才说是主备服务器,而且是一对一,只能有一台备份服务器。

(三)日志传输模式

  与镜像传输模式类似,是将主数据库日志备份,发送到从服务器上,然后从服务器还原日志,更新数据。

  此方式优点在于从服务器可以有多台从服务器,而且当主服务器脚本操作异常后,只需要在日志同步之前,及时拦截日志传输,即可保留从服务器数据,减少灾难损失;此方式相较于“复制发布”模式,还有一个有点就是无论是新增表、视图等等,都会通过日志同步给从服务器,而复制模式不行

  而相应的缺点就是通过日志备份传输,在还原,会有较大的时间延迟。而且无法自动转移故障,只能手动转移。

(四)故障转移集群

  集群技术是微软提供的,可用性最高的主备方案。它是将多台服务器通过一个共享的外部存储区域(SAN),连接成一个资源共享的服务器群体,数据库文件和实例,都存放并运行在该共享区域节点上,每台服务器相当于一个节点,共同访问共享的节点实例。服务器只有一个节点处于活动状态,当活动节点出现故障,会有其他节点主动启动,取代当前故障点,整个过程只需要几秒钟,用户无法感知。

  集群有很多优点,是目前最高效的高可用技术,但是他也有很明显的缺点,所有的节点,都依赖于共享节点实例,如果共享节点出现故障,将会导致整个集群失去作用,且很难恢复。