细说数据库集群技术
2011-06-21 15:34
218 查看
细说数据库集群技术
Jeffrey
March 2007
引言
信息系统作为企业的神经中枢，在企业的发展过程中起着极其重要的作用，成为保障企业快速发展的重要因素。数据库是用来保存最终计算结果的，所以是整个信息系统中最重要的组成部分，企业的数据库系统应该非常稳健，可是在企业中，决策者可能会发现，为什么我无法访问决策所需的数据，为什么我的应用系统引用的是上周的数据，为什么用户不能查询到实时准确的数据，为什么系统经常出现无法访问，为什么用户经常反映系统的速度非常缓慢，用户体验很差，为什么经常会造成数据丢失？为什么总是不停地更换更高配置的服务器也不能解决这些问题？
这些问题的答案其实很简单，传统的数据处理方式由于技术限制已无法满足企业需求。只有实时的数据采集方式，才能为正确的决策提供精准分析的数据支撑，降低信息延迟，保证快速的业务响应，并推动业务价值的提升，只有合理的分担用户的访问压力，才能提升系统的反映速度，带来更好的用户体验，只有保证冗余的数据结构才能保证数据的安全，只有系统具备非常好的伸缩性才具备良好的扩展能力。在接下来的内容中我们将探讨如何解决这些问题。
1.数据库集群的背景
随着经济的高速发展，企业规模的迅猛扩张，企业的用户数量、数据量呈爆炸式增长，在这样一个不断增长的环境下，对数据库提出了严峻的考验。对于所有的数据库而言，除了记录正确的处理结果之外，还面临着以下几方面的挑战：如何提高处理速度，实现数据库的负载均衡；如何保证数据库的可用性、数据安全性以及如何实现数据集可扩性？怎么综合解决这些问题成为众多企业关注的焦点。
随着计算机硬件技术的高速发展， PC服务器以其高性能和低廉的价格而倍受广大客户青睐，在WEB应用或高性能计算中，为了追求更高的性能、以及可用性，大家都采用计算机集群技术（将多台服务器联合起来组成集群来实现综合性能优于单个大型服务器的技术）来实现，这种技术不但能满足应用的需要，而且大幅度地节约了投资成本；在数据库上，组建集群也是同样的道理，主要有以下几个原因：
原因一：伴随着企业的成长，在业务量提高的同时，数据库的访问量和数据量快速增长，其处理能力和计算强度也相应增大，使得单一设备根本无法承担。在此情况下，若扔掉现有设备做大量的硬件升级，势必造成现有资源的浪费，而且下一次业务量提升时，又将面临再一次硬件升级的高额投入。于是，人们希望通过几个中小型服务器组建集群，实现数据库的负载均衡及持续扩展；在需要更高数据库处理速度时，只要简单地增加数据库服务器就可以得到扩展。
原因二：数据库作为信息系统的核心，起着非常重要的作用，单一设备根本无法保证系统的持续运行，若发生系统故障，将严重影响系统的正常运行，甚至带来巨大的经济损失。于是，人们希望通过组建数据库集群，实现数据库的高可用，当某节点发生故障时，系统会自动检测故障并转移故障节点的应用，保证数据库的持续工作。
搭建数据库集群的原因
原因三：企业的数据库保存着企业的重要信息，一些核心数据甚至关系着企业的命脉，单一设备根本无法保证数据的安全性，一旦发生丢失，很难再找回来。于是，人们希望通过组建数据库集群，实现数据集的冗余，通过多份数据来保证安全性。
1.1数据库集群的分类
一般来讲，数据库集群软件根据侧重的方向和试图解决的问题划分为三大类：负载均衡集群（Load balance cluster，LBC）侧重于数据库的横向扩展，提升数据库的性能；高可用性集群（High availability cluster，HAC）侧重保证数据库应用持续不断；高安全性集群（High Security cluster，HSC）侧重于容灾。
按照集群的架构可分为：共享磁盘型，非共享磁盘型。
1.2当前各大主要商业数据库上应用的集群
Oracle's Real Application Cluster (RAC)
Microsoft SQL Cluster Server (MSCS)
IBM's DB2 UDB High Availability Cluster(UDB)
Sybase ASE High Availability Cluster (ASE)
MySQL High Availability Cluster (MySQL CS)
基于IO、磁盘或操作系统等非数据库引擎的集群
总结：以上六类数据库集群技术中，前五个是数据库厂商提供的，其中仅Oracle’s Real Application Cluster (RAC)实现数据库的负载均衡、横向扩展及应用的高可用性；其余数据库集群技术都是以高可用为主，基本上是共享磁盘型的。第六类是第三方集群公司提供的，就是我们常说的“双机”是一种热备或互备技术，即：当某节点故障，另一个节点来接管业务。
1.3问题的提出与分析
在数据库上，保证可用性固然重要，但是随着信息化向前的推进，用户在数据库上遇到的困惑不只“可用性”一个，往往是综合几种需求，于是乎，用户的数据库上将出现如下情景：可能同时部署了负载均衡软件、双机软件、镜像软件、备份软件等等（有专业技术实力的公司可能不是这样，如互联网企业可以通过DBA来进行合理的优化及管理），可是，用户想要的是“一个可以为之稳定提供应用服务的数据库平台”，一个整体的数据库解决方案，而不是一堆HA、备份、复制、负载均衡等等零散的软件，或者是它们之间的简单集成。
以微软的SQL Server数据库为例，因为其简单易用等优点占据了很大一部分客户，但SQL Server数据库集群解决方案以数据库的可用性为主，不能实现负载均衡及横向扩展，不论是失败转移集群（MSCS）或镜像（Mirror）仅仅是一种备份的方案，数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份，在性能上是没有提升的。
或许有人说，那你可以不用SQL Server，可以用Oracle，但是每个数据量都有其各自的优点，有其适用的环境。
基于这样一个现状，一些国外的专业技术公司，甚至国内的一些拥有深厚背景的公司也在数据库平台上开发出了综合解决这些问题的集群产品，这些技术多数基于数据库开发（在开源数据库中也有类似的产品或方案推出）。其实回顾历史，Oracle的RAC就是一个很好的例子，RAC在Oracle8中还叫OPS，也是从一家第三方集群公司收购，如又收购了金门软件（Golden Gate），也是从事类似技术的公司，于2009年7月被Oracle收购。 当然也不排除，未来各数据库厂商自己推出这样的产品。
国内外此类技术的介绍：
PCTIhttp://www.pcticorp.com
金门软件http://www.goldengate.com
红门软件http://www.redgate.com
格瑞趋势http://www.grqsh.com
我所了解的这些数据库集群技术中，主要以SQL Server或MySQL居多，分析其原因也很简单，在国内能买得起Oracle的用户，也不在乎多花些钱买RAC；银行的客户也不惜多花钱叫IBM解决；由于MySQL免费的特点，所以其用户是两个极端，要们很大，自己有能力在上面开发，如国内的大型互联网企业，要么很小，如一些小型软件，在这样的背景下，MySQL的集群技术只是大企业内部拥有，没有作为产品推向社会；SQL Server 更能适合中国的国情，以其简单适用，方便管理等特点占据了很大的市场，相应的SQL Server的数据库集群技术也成为通用的技术在行业内快速发展。
２数据库集群技术的实现机理
在本章我们将探讨数据库上各种集群技术以及实现机理。
2.1基于共享磁盘的HA集群
这类技术严格不属于数据库集群，其出发点就是保证应用的可用性，所以这类技术的核心点就是当某一节点发生故障，备用节点可以快速接管业务；这类技术可以说是一个传统的技术了，市场上相当广泛，可以用在应用程序服务器，也可用在数据库服务器或其服务器，Windows中也包含了此技术，用户只需在SQL Server中配置即可，第三方的集群也很多。其基本结构如下：
HA
基本特点：两个节点，一个处于工作，另一个处于备份状态，数据存与共享磁盘中，由主节点接管，双方通过“心跳”机制来检测对方的运行状态，当主节点故障，备用节点来接管数据，对外提供服务，这类技术只保证了数据库应用的可用性，没有保证数据的可用性。
2.2基于数据库事务日志的复制技术
这类技术各大商业数据库基本都支持，如MSSQL Server的数据库镜像（Mirror）、复制（Replication）、日志传送等，这些复制技术主要以实现数据库的可用性为主。
这种技术是把事务先交给主服务器来完成，然后这些事务再被串行地交给备份服务器执行同样的操作以保证数据的一致性。这种技术生成的数据集和主数据集有一个时间差，所以仅适用于灾难恢复、数据挖掘、报表统计以及有限的在线应用。这种办法的难度在于复制队列的管理上，这个队列是用来屏蔽主服务器和备份服务器之间的速度差异的。因为主服务器可以尽可能地利用所有软硬件的并发性来处理并发的事务，而备份服务器只能串行地复制，在高负荷事务处理的情况下，复制队列经常可能溢出。因为没有任何办法来控制事务处理请求的速度，在高负荷事务处理的情况下，复制队列只能经常性地重建。因为所有现代数据库系统都支持热备份和LOG SHIPPING。通过精心策划，应该可以实现不关闭主 服务器而重建队列。
Mirror
尽管数据库镜像（Mirror）中也提供了同步复制的模式，但是这种同步模式也不是真正意义上的同步，在日志同步过程中，事务日志是在生成后进行的，也就是不具备SQL Serve当时的执行环境，无上下文关系，所以事务日志就只能是一个串行的方式逐条传送，镜像服务器也就处于recovering状态。在数据库中，有些操作的语句并不复杂，但产生的日志的数量却是很多，造成的结果是同步的效率非常低下。这类技术降低了用户实现可用性的门槛，无需共享磁盘，从构成上讲是一个冗余的结构，即可以同时实现应用和数据的可用性。
2.3基于磁盘的复制技术
这类技术并不是只为数据库而生，可以用在所有的数据文件，例如磁盘镜像（EMC的TimeFinder系列）、数据库文件复制（如DoubleTake, Veritas and Legato）、数据灾备软件以及数据库厂商自带的数据库备份工具都只能产生被动复制数据集。通常，为了实现复制功能，需要消耗掉主服务器5%（异步）到30%（同步）的处理能力。被动更新的数据一般只用于灾难恢复.被动更新数据集还有两个致命的问题：一旦主处理机故障造成数据损坏，被动更新的数据集也会被破坏。另外，和主动更新系统相比，被动更新系统对数据网络的带宽要求更高。这是因为它缺少交易的信息，很多数据复制是盲目的。
2.4基于SQL语句解析的集群技术
这类技术通过在多个数据库（一般以2个为主）前增加一层，专门用来解析SQL 语句，当解析到写入操作时，同时向多个数据库写入，当解析到查询操作时，可以随机选取，可以实现数据库上的负载均衡及高可用，但是由于其实现的原理决定了此类系统只能用于一些小系统且是一些无关紧要的应用。原因主要有以下几个方面：
并非应用程序传来的所有内容都可以解析，如存储过程等就不可以；并发向多个数据库写入，由于向两个数据库写入的速度不同，在高并发下可能导致死锁。
SQL解析
３Moebius集群的技术实现
Moebius集群是一个数据库的技术，是在数据库层实现的，是解决数据库的问题的。前端Load Balancing Director对应用程序和数据库进行了隔离，应用程序面对的还是一个数据库，保证应用的透明性，同时Load Balancing Director对应用程序提交的SQL 语句进行分析，合理地分配，保证一些关联操作的正确性，避免引起并发冲突及脏读等，同时结合负载均衡策略，实行多台服务器压力的均衡。
Moebius集群
Moebius中件宿主于数据库的引擎中，监测数据的变化，在SQL Server的执行环境下进行数据同步，同步完成后应用程序才得到响应，保证应用程序获取的数据是实时的，当然同步肯定是有消耗，这是无法避免，但是达到的效果是增加更多的数据库资源供应用使用，而且这些数据库是对等的，都是可读可写的。接下来我们来分析，如何减小同步的消耗， Moebius 中间件在数据库内部工作，可以获取SQL Server当时的执行环境，可以结合上下文关系，对事物日志进行分析，并采取多种同步策略，这样，在同步过程中就不是串行的逐条同步。主要采用了如下同步策略：
数据压缩：如果需要同步的数据中包含文本、二进制等大数据类型， 则先对数据进行压缩然后再同步，从而减少对网络带宽的消耗和数据在传输过程中所用的时间。尤其对于网络带宽资源非常稀缺的场景。
批量执行重复性数据：如果需要同步的数据中包含重复性的数据，则中间件会把重复性的数据合并到一个同步命令中只执行一次，从而减少执行的次数。
例如：执行语句 UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE LastLoginDate < '2008-08-08' 共修改了600条数据，这600条数据的DeleteFlag列具有相同的值，中间件会把这些相同的值合并到一个同步命令中去，同步的SQL语句为：UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID IN(1， 3， 4， 5， 7， 10， 13， 15， ......， 895， 897， 899， 1000)。而不是逐条的去同步：
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 1
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 3
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 4
.
.
.
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 899
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 1000
该策略对数据进行批量更新、批量删除的场景下比较适用。?
升级数据库锁：如果更新的数据量非常大，SQL Server本身会对锁进行升级，将大量较细粒度的锁（例如行）转换为少量较粗粒度的锁（例如表）从而减少系统开销。中间件在同步之前先检查当前SQL Server的锁的粒度，如果锁已经升级，则中间件先对目标数据库直接进行锁升级然后再同步数据。从而避免了目标数据库锁升级的过程。
同步SQL语句：如果更新的数据量非常大，超过了设定的阀值，同步大量的数据势必会消耗大量的网络带宽并且延长同步的时间，甚至会造成网络拥堵。这时候中间件首先获取导致数据变化的SQL语句，分析该SQL语句的类型以及执行成本，并选择是把变化的数据同步过去还是把导致数据变化的SQL语句同步过去。该策略在对表结构进行调整或批量更改数据的时候非常有用，大量的减少网络带宽的消耗，降低同步时间。
并发执行SQL语句：即使使用了同步SQL语句策略，总的执行时间也相当于执行两次SQL语句的时间。如果这个时间还是不能接受。可以通过中间件提供的系统存储过程usp_MBS_CMD在集群中的各个节点数据库中并发执行SQL语句，使执行时间降低到相当于在单机数据库中执行一次的时间。
以上技术意见仅代表本人的观点，当然数据库上还有好多集群技术，如oracle’RAC ,更多关于这方面的介绍请参考后续文档，同时也欢迎研究此类技术的朋友一起交流。
Jeffrey
Mail:Jeffrey-data@live.cn
Jeffrey
March 2007
引言
信息系统作为企业的神经中枢，在企业的发展过程中起着极其重要的作用，成为保障企业快速发展的重要因素。数据库是用来保存最终计算结果的，所以是整个信息系统中最重要的组成部分，企业的数据库系统应该非常稳健，可是在企业中，决策者可能会发现，为什么我无法访问决策所需的数据，为什么我的应用系统引用的是上周的数据，为什么用户不能查询到实时准确的数据，为什么系统经常出现无法访问，为什么用户经常反映系统的速度非常缓慢，用户体验很差，为什么经常会造成数据丢失？为什么总是不停地更换更高配置的服务器也不能解决这些问题？
这些问题的答案其实很简单，传统的数据处理方式由于技术限制已无法满足企业需求。只有实时的数据采集方式，才能为正确的决策提供精准分析的数据支撑，降低信息延迟，保证快速的业务响应，并推动业务价值的提升，只有合理的分担用户的访问压力，才能提升系统的反映速度，带来更好的用户体验，只有保证冗余的数据结构才能保证数据的安全，只有系统具备非常好的伸缩性才具备良好的扩展能力。在接下来的内容中我们将探讨如何解决这些问题。
1.数据库集群的背景
随着经济的高速发展，企业规模的迅猛扩张，企业的用户数量、数据量呈爆炸式增长，在这样一个不断增长的环境下，对数据库提出了严峻的考验。对于所有的数据库而言，除了记录正确的处理结果之外，还面临着以下几方面的挑战：如何提高处理速度，实现数据库的负载均衡；如何保证数据库的可用性、数据安全性以及如何实现数据集可扩性？怎么综合解决这些问题成为众多企业关注的焦点。
随着计算机硬件技术的高速发展， PC服务器以其高性能和低廉的价格而倍受广大客户青睐，在WEB应用或高性能计算中，为了追求更高的性能、以及可用性，大家都采用计算机集群技术（将多台服务器联合起来组成集群来实现综合性能优于单个大型服务器的技术）来实现，这种技术不但能满足应用的需要，而且大幅度地节约了投资成本；在数据库上，组建集群也是同样的道理，主要有以下几个原因：
原因一：伴随着企业的成长，在业务量提高的同时，数据库的访问量和数据量快速增长，其处理能力和计算强度也相应增大，使得单一设备根本无法承担。在此情况下，若扔掉现有设备做大量的硬件升级，势必造成现有资源的浪费，而且下一次业务量提升时，又将面临再一次硬件升级的高额投入。于是，人们希望通过几个中小型服务器组建集群，实现数据库的负载均衡及持续扩展；在需要更高数据库处理速度时，只要简单地增加数据库服务器就可以得到扩展。
原因二：数据库作为信息系统的核心，起着非常重要的作用，单一设备根本无法保证系统的持续运行，若发生系统故障，将严重影响系统的正常运行，甚至带来巨大的经济损失。于是，人们希望通过组建数据库集群，实现数据库的高可用，当某节点发生故障时，系统会自动检测故障并转移故障节点的应用，保证数据库的持续工作。
搭建数据库集群的原因
原因三：企业的数据库保存着企业的重要信息，一些核心数据甚至关系着企业的命脉，单一设备根本无法保证数据的安全性，一旦发生丢失，很难再找回来。于是，人们希望通过组建数据库集群，实现数据集的冗余，通过多份数据来保证安全性。
1.1数据库集群的分类
一般来讲，数据库集群软件根据侧重的方向和试图解决的问题划分为三大类：负载均衡集群（Load balance cluster，LBC）侧重于数据库的横向扩展，提升数据库的性能；高可用性集群（High availability cluster，HAC）侧重保证数据库应用持续不断；高安全性集群（High Security cluster，HSC）侧重于容灾。
按照集群的架构可分为：共享磁盘型，非共享磁盘型。
1.2当前各大主要商业数据库上应用的集群
Oracle's Real Application Cluster (RAC)
Microsoft SQL Cluster Server (MSCS)
IBM's DB2 UDB High Availability Cluster(UDB)
Sybase ASE High Availability Cluster (ASE)
MySQL High Availability Cluster (MySQL CS)
基于IO、磁盘或操作系统等非数据库引擎的集群
总结：以上六类数据库集群技术中，前五个是数据库厂商提供的，其中仅Oracle’s Real Application Cluster (RAC)实现数据库的负载均衡、横向扩展及应用的高可用性；其余数据库集群技术都是以高可用为主，基本上是共享磁盘型的。第六类是第三方集群公司提供的，就是我们常说的“双机”是一种热备或互备技术，即：当某节点故障，另一个节点来接管业务。
1.3问题的提出与分析
在数据库上，保证可用性固然重要，但是随着信息化向前的推进，用户在数据库上遇到的困惑不只“可用性”一个，往往是综合几种需求，于是乎，用户的数据库上将出现如下情景：可能同时部署了负载均衡软件、双机软件、镜像软件、备份软件等等（有专业技术实力的公司可能不是这样，如互联网企业可以通过DBA来进行合理的优化及管理），可是，用户想要的是“一个可以为之稳定提供应用服务的数据库平台”，一个整体的数据库解决方案，而不是一堆HA、备份、复制、负载均衡等等零散的软件，或者是它们之间的简单集成。
以微软的SQL Server数据库为例，因为其简单易用等优点占据了很大一部分客户，但SQL Server数据库集群解决方案以数据库的可用性为主，不能实现负载均衡及横向扩展，不论是失败转移集群（MSCS）或镜像（Mirror）仅仅是一种备份的方案，数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份，在性能上是没有提升的。
或许有人说，那你可以不用SQL Server，可以用Oracle，但是每个数据量都有其各自的优点，有其适用的环境。
基于这样一个现状，一些国外的专业技术公司，甚至国内的一些拥有深厚背景的公司也在数据库平台上开发出了综合解决这些问题的集群产品，这些技术多数基于数据库开发（在开源数据库中也有类似的产品或方案推出）。其实回顾历史，Oracle的RAC就是一个很好的例子，RAC在Oracle8中还叫OPS，也是从一家第三方集群公司收购，如又收购了金门软件（Golden Gate），也是从事类似技术的公司，于2009年7月被Oracle收购。 当然也不排除，未来各数据库厂商自己推出这样的产品。
国内外此类技术的介绍：
PCTIhttp://www.pcticorp.com
金门软件http://www.goldengate.com
红门软件http://www.redgate.com
格瑞趋势http://www.grqsh.com
我所了解的这些数据库集群技术中，主要以SQL Server或MySQL居多，分析其原因也很简单，在国内能买得起Oracle的用户，也不在乎多花些钱买RAC；银行的客户也不惜多花钱叫IBM解决；由于MySQL免费的特点，所以其用户是两个极端，要们很大，自己有能力在上面开发，如国内的大型互联网企业，要么很小，如一些小型软件，在这样的背景下，MySQL的集群技术只是大企业内部拥有，没有作为产品推向社会；SQL Server 更能适合中国的国情，以其简单适用，方便管理等特点占据了很大的市场，相应的SQL Server的数据库集群技术也成为通用的技术在行业内快速发展。
２数据库集群技术的实现机理
在本章我们将探讨数据库上各种集群技术以及实现机理。
2.1基于共享磁盘的HA集群
这类技术严格不属于数据库集群，其出发点就是保证应用的可用性，所以这类技术的核心点就是当某一节点发生故障，备用节点可以快速接管业务；这类技术可以说是一个传统的技术了，市场上相当广泛，可以用在应用程序服务器，也可用在数据库服务器或其服务器，Windows中也包含了此技术，用户只需在SQL Server中配置即可，第三方的集群也很多。其基本结构如下：
HA
基本特点：两个节点，一个处于工作，另一个处于备份状态，数据存与共享磁盘中，由主节点接管，双方通过“心跳”机制来检测对方的运行状态，当主节点故障，备用节点来接管数据，对外提供服务，这类技术只保证了数据库应用的可用性，没有保证数据的可用性。
2.2基于数据库事务日志的复制技术
这类技术各大商业数据库基本都支持，如MSSQL Server的数据库镜像（Mirror）、复制（Replication）、日志传送等，这些复制技术主要以实现数据库的可用性为主。
这种技术是把事务先交给主服务器来完成，然后这些事务再被串行地交给备份服务器执行同样的操作以保证数据的一致性。这种技术生成的数据集和主数据集有一个时间差，所以仅适用于灾难恢复、数据挖掘、报表统计以及有限的在线应用。这种办法的难度在于复制队列的管理上，这个队列是用来屏蔽主服务器和备份服务器之间的速度差异的。因为主服务器可以尽可能地利用所有软硬件的并发性来处理并发的事务，而备份服务器只能串行地复制，在高负荷事务处理的情况下，复制队列经常可能溢出。因为没有任何办法来控制事务处理请求的速度，在高负荷事务处理的情况下，复制队列只能经常性地重建。因为所有现代数据库系统都支持热备份和LOG SHIPPING。通过精心策划，应该可以实现不关闭主 服务器而重建队列。
Mirror
尽管数据库镜像（Mirror）中也提供了同步复制的模式，但是这种同步模式也不是真正意义上的同步，在日志同步过程中，事务日志是在生成后进行的，也就是不具备SQL Serve当时的执行环境，无上下文关系，所以事务日志就只能是一个串行的方式逐条传送，镜像服务器也就处于recovering状态。在数据库中，有些操作的语句并不复杂，但产生的日志的数量却是很多，造成的结果是同步的效率非常低下。这类技术降低了用户实现可用性的门槛，无需共享磁盘，从构成上讲是一个冗余的结构，即可以同时实现应用和数据的可用性。
2.3基于磁盘的复制技术
这类技术并不是只为数据库而生，可以用在所有的数据文件，例如磁盘镜像（EMC的TimeFinder系列）、数据库文件复制（如DoubleTake, Veritas and Legato）、数据灾备软件以及数据库厂商自带的数据库备份工具都只能产生被动复制数据集。通常，为了实现复制功能，需要消耗掉主服务器5%（异步）到30%（同步）的处理能力。被动更新的数据一般只用于灾难恢复.被动更新数据集还有两个致命的问题：一旦主处理机故障造成数据损坏，被动更新的数据集也会被破坏。另外，和主动更新系统相比，被动更新系统对数据网络的带宽要求更高。这是因为它缺少交易的信息，很多数据复制是盲目的。
2.4基于SQL语句解析的集群技术
这类技术通过在多个数据库（一般以2个为主）前增加一层，专门用来解析SQL 语句，当解析到写入操作时，同时向多个数据库写入，当解析到查询操作时，可以随机选取，可以实现数据库上的负载均衡及高可用，但是由于其实现的原理决定了此类系统只能用于一些小系统且是一些无关紧要的应用。原因主要有以下几个方面：
并非应用程序传来的所有内容都可以解析，如存储过程等就不可以；并发向多个数据库写入，由于向两个数据库写入的速度不同，在高并发下可能导致死锁。
SQL解析
３Moebius集群的技术实现
Moebius集群是一个数据库的技术，是在数据库层实现的，是解决数据库的问题的。前端Load Balancing Director对应用程序和数据库进行了隔离，应用程序面对的还是一个数据库，保证应用的透明性，同时Load Balancing Director对应用程序提交的SQL 语句进行分析，合理地分配，保证一些关联操作的正确性，避免引起并发冲突及脏读等，同时结合负载均衡策略，实行多台服务器压力的均衡。
Moebius集群
Moebius中件宿主于数据库的引擎中，监测数据的变化，在SQL Server的执行环境下进行数据同步，同步完成后应用程序才得到响应，保证应用程序获取的数据是实时的，当然同步肯定是有消耗，这是无法避免，但是达到的效果是增加更多的数据库资源供应用使用，而且这些数据库是对等的，都是可读可写的。接下来我们来分析，如何减小同步的消耗， Moebius 中间件在数据库内部工作，可以获取SQL Server当时的执行环境，可以结合上下文关系，对事物日志进行分析，并采取多种同步策略，这样，在同步过程中就不是串行的逐条同步。主要采用了如下同步策略：
数据压缩：如果需要同步的数据中包含文本、二进制等大数据类型， 则先对数据进行压缩然后再同步，从而减少对网络带宽的消耗和数据在传输过程中所用的时间。尤其对于网络带宽资源非常稀缺的场景。
批量执行重复性数据：如果需要同步的数据中包含重复性的数据，则中间件会把重复性的数据合并到一个同步命令中只执行一次，从而减少执行的次数。
例如：执行语句 UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE LastLoginDate < '2008-08-08' 共修改了600条数据，这600条数据的DeleteFlag列具有相同的值，中间件会把这些相同的值合并到一个同步命令中去，同步的SQL语句为：UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID IN(1， 3， 4， 5， 7， 10， 13， 15， ......， 895， 897， 899， 1000)。而不是逐条的去同步：
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 1
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 3
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 4
.
.
.
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 899
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 1000
该策略对数据进行批量更新、批量删除的场景下比较适用。?
升级数据库锁：如果更新的数据量非常大，SQL Server本身会对锁进行升级，将大量较细粒度的锁（例如行）转换为少量较粗粒度的锁（例如表）从而减少系统开销。中间件在同步之前先检查当前SQL Server的锁的粒度，如果锁已经升级，则中间件先对目标数据库直接进行锁升级然后再同步数据。从而避免了目标数据库锁升级的过程。
同步SQL语句：如果更新的数据量非常大，超过了设定的阀值，同步大量的数据势必会消耗大量的网络带宽并且延长同步的时间，甚至会造成网络拥堵。这时候中间件首先获取导致数据变化的SQL语句，分析该SQL语句的类型以及执行成本，并选择是把变化的数据同步过去还是把导致数据变化的SQL语句同步过去。该策略在对表结构进行调整或批量更改数据的时候非常有用，大量的减少网络带宽的消耗，降低同步时间。
并发执行SQL语句：即使使用了同步SQL语句策略，总的执行时间也相当于执行两次SQL语句的时间。如果这个时间还是不能接受。可以通过中间件提供的系统存储过程usp_MBS_CMD在集群中的各个节点数据库中并发执行SQL语句，使执行时间降低到相当于在单机数据库中执行一次的时间。
以上技术意见仅代表本人的观点，当然数据库上还有好多集群技术，如oracle’RAC ,更多关于这方面的介绍请参考后续文档，同时也欢迎研究此类技术的朋友一起交流。
Jeffrey
Mail:Jeffrey-data@live.cn
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 