SQL数据库服务器规划方案

一、目前数据库服务器情况概述

两台数据库服务器，分别为主、备数据库服务器，已做数据库镜像，数据实时同步，保证数据一致性；当主服务器故障时，可以在10秒钟内自动切换至备用数据库服务器提供服务，不间断服务。

·优点：高可用集群，保证数据的安全性，服务的不间断、持续性。

·缺点：在用户访问量不断上升的情况下，现有单台服务器将会面临服务器硬件资源无法满足需求。

二、服务器规划方案

1、升级服务器硬件、更换高配服务器

随着访问量上升，需要投入新服务器，增加服务器硬件性能，满足日益增长的流量需求。

缺点：增加了新服务器的成本，替换下的服务器浪费资源。

2、采用负载均衡设备及服务器集群技术，扩充系统的处理能力

数据库服务器集群概述

（1）、即数据库服务器集群，多台服务器共同分担数据库流量压力，增强带宽的利用率、资源使用率，提高性能和速度。

（2）、扩展性强：随着访问量上升,当系统要更高数据库处理速度时，只要简单地增加数据库服务器就可以得到扩展,无需增加高配服务器、避免升级硬件造成的资源浪费。

（3）、负载均衡可以真正的保证SQL Server数据库服务器不间断的提供服务，在服务器发生故障的时候实时切换到其他服务器上继续提供服务，切换时间为“零”。

优点：

(1)、扩展性强，无需增加高配服务器、只需要在集群节点中增加相应服务器、即可满足增长的流量压力，避免升级硬件造成的资源浪费，节省成本。

（2）、提高带宽利用率、资源使用率，提高性能和访问速度。

（3）、多台服务器数据冗余，保证了数据的安全性；服务的持续稳定运行；服务器零故障率切换。

缺点：

(1)、程序及数据库结构需要调整，具有风险性。

（2）、SQL服务器集群属于新技术，需要购入新设备及新技术，并且需要时间进行调试、测试，保证负载均衡的稳定性。

三、数据库集群实施方案

Ⅰ、技术要求

·增加带宽的利用率、缓解信息拥塞

·提高服务器硬件性能、系统访问速度

·分担数据库流量压力、提供服务器性能

·保证数据服务稳定、提高数据安全性、

·使各服务器集群实现系统的无缝扩展

Ⅱ、下列为几种可行性方案

·Moebius for SQL Server集群

·DBTwin数据库集群系统

·SQL转换到ORACLE平台, RAC集群

·数据库路由器—ICX,实现集群

·数据库读写分离,实现集群

Ⅲ、下述分别列出各方案原理及优缺点

1、Moebius for SQL Server集群 （中间件）

（1）拓扑图

（2）实现原理

实现数据库的集群，首先要有一个可以控制连接数据库的控制端。在这里，它截断了数据库和程序的直接连接，由所有的程序来访问这个中间层，然后再由中间层来访问数据库。这样就可以具体控制访问某个数据库了，然后可以根据数据库的当前负载采取有效的均衡策略，来调整每次连接到哪个数据库。

（3）Moebius for SQL Server数据同步原理

·Moebius for SQL Server集群采用将核心程序驻留在每个机器的数据库中的办法，核心程序为Moebius for SQL Server 中间件，主要作用是监测数据库内数据的变化，并将变化的数据同步到其他数据库中。数据同步完成后客户端才会得到响应，同步过程是并发完成的，所以同步到多个数据库和同步到一个数据库的时间基本相等；另外同步的过程是在事务的环境下完成的，保证了多份数据在任何时刻数据的一致性。正因为Moebius 中间件宿主在数据库中的创新，让中间件不但能知道数据的变化，而且知道引起数据变化的SQL语句，根据SQL语句的类型智能的采取不同的数据同步的策略以保证数据同步成本的最小化。

·数据条数很少，数据内容也不大，则直接同步数据。

·数据条数很少，但是里面包含大数据类型，比如文本，二进制数据等，则先对数据进行压缩然后再同步，从而减少网络带宽的占用和传输所用的时间。

·数据条数很多，此时中间件会拿到造成数据变化的SQL语句，

然后对SQL语句进行解析，分析其执行计划和执行成本，并选择是同步数据还是同步SQL语句到其他的数据库中。此种情况应用在对表结构进行调整或者批量更改数据的时候非常有用。

（4）优缺点

优点：

·扩展性强：当系统要更高数据库处理速度时，只要简单地增加数据库服务器就可以得到扩展。

·可维护性：当某节点发生故障时，系统会自动检测故障并转移故障节点的应用，保证数据库的持续工作。

·安全性：因为数据会同步的多台服务器上，可以实现数据集的冗余，通过多份数据来保证安全性。另外它成功地将数据库放到了内网之中，更好地保护了数据库的安全性。

·易用性：对应用来说完全透明，集群暴露出来的就是一个IP

缺点：

·不能够按照Web服务器的处理能力分配负载。

·负载均衡器(控制端)故障，会导致整个数据库系统瘫痪。

2、DBTwin数据库集群系统

(1)、拓扑图

（2）、工作原理

DBTwin是一个中间件服务软件，它工作在微软的数据库专用协议TDS层之上，如下图所示：

TDS(Tabular Data Stream表格数据流)是微软数据库客户端与SQL Server服务器进行通讯的未公开协议，DBTwin就工作在这一层，因此，DBTwin能支持所有的SQL Server客户端数据组件。正象1433是微软SQL Server的缺省服务端口那样，8106是DBTwin数据库集群的缺省服务端口，另外8105、8107、8108和8109是DBTwin或者它的代理端软件的固定工作端口，在选择端口的时候，避免选择这些端口，以免发生端口冲突。

DBTwin时刻检测来自客户端的事务。一旦接收到客户事务请求，DBTwin将此事务同时发给集群中的每个数据库，并且确保所有的集群数据库要么全部提交，要么全部回滚此事务，以此保证每个集群数据库的数据映象始终是处于一致状态，同时保持对数据库客户端的透明、无缝连接。

DBTwin是以批处理为单位来进行负载均衡的。也就是说，每当DBTwin接收到来自客户端的一次请求，这个请求其实就是一个批处理，这时候DBTwin会对此批处理进行语法检查，并判断出是否能负载均衡，若可以进行负载均衡，那么DBTwin将根据某一算法，挑选出其中某台集群数据库来执行此批处理；如果此批处理不能负载均衡，那么DBTwin就同时给所有的集群数据库发送此批处理请求。

在DBTwin集群启动之前，用户可以通过PRT高级同步工具作数据同步，或者也可以利用SQL Server提供的BACKUP/RESTORE命令来作到这一点。在DBTwin运行过程中，如果有数据库掉线了，这时，DBTwin会有两种方式来修复集群，一是定时自动方式，此方式是预先设置好在某个时间进行数据库同步和DBTwin网关的重启动，它适合于一些晚上进行批处理作业的系统。另一种方式是手工同步方式，此方式针对的是由随机错误，例如网络错误，服务器重启等导致的。无论哪种方式，在同步过程中，客户端是始终客户访问DBTwin集群系统的，这样整个数据库系统的可用性就提高了。

（3）、DBTwin技术指标

·非入侵部署

与所有的系统服务一样, DBTwin也是通过唯一的入口-一对(IP,port)来向外提供数据服务。 因此,应用程序及其数据库接口不需作任何修改。支持所有的数据库接口：ADO .Net、ADO、RDO、DAO、OLE DB、ODBC、DB-LIBRARY等。

·支持数据库

Microsoft SQL Server /6.5/7.0/2000/2005/2008的标准版和企业版。

·事务处理同步复制

通过常用的宽带网络, 快速的事务处理同步复制

·高系统可用性

自动的错误恢复，真正把意料之内和意料之外的停机时间缩至最短。网关在错误恢复期间的停止服务间隙达到小于10秒。

·零单点错误源

从DBTwin网关开始，整个数据库系统是完全、彻底地物理冗余。

·数据“零”丢失

DBTwin使得系统同时拥有多个实时一致的数据集，这样从理论上讲，就真正消除了数据丢失的任何可能性。数据库可靠性达到目5个9，即99.999%。

·动态负载均衡

DBTwin对只读数据库查询操作可以进行自动的判别和动态负载均衡，这是当前唯一实现的针对数据库的动态负载均衡技术，此技术可以大大改善整个数据库系统的性能。性能提升在30%~300%之间，具体提升比例取决于应用系统及网络结构和软硬的配置。

·可伸缩性

可伸缩的数据库性能(负载均衡+非入侵式的数据库阵列扩展)，使得数据库具有可伸缩性。需要更多的数据库性能的时候，只要增加数据库服务器就可以了。

·容灾能力

DBTwin自身的双机容错

DBTwin支持自身的双机主备容错切换，也可以采用第三方的HA方案解决DBTwin自身的容错问题。

（4）优缺点

优点：

·数据可靠性和安全性增强: 由于任何时刻系统同时拥有多份数据集，因此大大提高了整个系统的数据可靠性和安全性

·服务的可用性增强: 台数据库服务器出现问题，其它的数据库服务器仍然能够正常工作

·提升数据库系统性能: DBTwin能够在多个独立的数据库系统之间实现动态负载均衡，进而显著提升数据库系统的整体性能。

·充分利用已有投资，降低总体拥有成本

·保证数据库系统具有良好的伸缩性：通过增加新的数据库服务器即可提升系统的性能、可靠性等。

缺点：

·DBTwin运行原理模糊，需要实际测试稳定性、可用性。

·DBTwin网关访问数据库,扩展硬件资源。

3、SQL转换到ORACLE平台

转换数据到ORACLE平台，采用ORACLE “RAC”来解决， “RAC”采用共享缓存（Cache）的办法，来是实现锁的互换，多个实例同时分担负载。不但能负载均衡而且扩展性强。

（1）、工作原理

硬件上至少需要两台以上的服务器，一个共享存储设备。同时还需要两类软件，一个是集群软件，另外一个就是Oracle数据库中的RAC组件。同时所有服务器上的OS都应该是同一类OS,根据负载均衡的配置策略，当一个客户端发送请求到某一台服务的listener后，这台服务器根据我们的负载均衡策略，会把请求发送给本机的RAC组件处理也可能会发送给另外一台服务器的RAC组件处理，处理完请求后，RAC会通过集群软件来访问共享存储设备。

逻辑结构上看，每一个集群的节点有一个独立的instance，这些instance访问同一个数据库。节点之间通过集群软件的通讯层（communication layer）来进行通讯。同时为了减少IO的消耗，存在了一个全局缓存服务，因此每一个数据库的instance，都保留了一份相同的数据库cache。

(2)、ORACLE“RAC”、微软集群（MSCS） 、SQL2005 镜像对比

Ⅰ、微软的集群解决方案中缺点：

·数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份；

·因为始终只有一个节点在运行，在性能上得不到提升，系统也就不具备扩展的能力；

·当现有机器性能不能满足应用的负载时，只能更换更高配置机器；

Ⅱ、ORACLE“RAC”缺点：

·“RAC”的价格昂贵；

需增加共同存储设备，增加成本

其次要将应用移植，代码要重新编写，要面临很大风险的过程。

4、数据库路由器–ICX

数据库路由器是实时并发数据库事务处理同步复制器和负载平衡器。

　 数据库路由器–ICX（意思是：I SEE X DATABASE SERVERS），也就是说，在ICX后面可以同时连接N个数据库

　（1）、所有的数据库客户都通过ICX访问数据库。当访问、查询SQL Server数据库的时候ICX可以根据实际情况分配服务器来提供服务，大大提高服务速度和优化性能，完成负载均衡。

（2）、ICX可以同时连接多台数据库（2-16台，具体连多少台，看客户的具体需求而定），这若干台数据库的内容在任何时刻由ICX保证是完全一致的。也就是说，ICX采用了全新的并发事务处理的方式，向连接的N台数据库同步复制事务处理，使得系统在任何时刻具有多个一致的最新逻辑数据库数据集。当其中一台数据库服务器发生故障的时候，ICX可以实时的、第一时间切换到其他服务器上来继续提供服务。真正的实现零时间的服务器切换，大大提高安全性，真正意义的实现服务器不间断服务。

5、数据库的读写分离

（1）实现原理：

读写分离简单的说是把对数据库读和写的操作分开对应不同的数据库服务器，这样能有效地减轻数据库压力，也能减轻IO压力。主数据库提供写操作，从数据库提供读操作，其实在很多系统中，主要是读的操作。当主数据库进行写操作时，数据要同步到从的数据库，这样才能有效保证数据库完整性。

(ebay的读写比率是260:1,ebay的读写分离)

(微软数据库分发)

（2）实现方法：

在MS Sql server中可以使用发布定义的方式实现数据库复制，实现读写分离，复制是将一组数据从一个数据源拷贝到多个数据源的技术，是将一份数据发布到多个存储站点上的有效方式。使用复制技术，用户可以将一份数据发布到多台服务器上。复制技术可以确保分布在不同地点的数据自动同步更新，从而保证数据的一致性。SQL SERVER复制技术类型有三种，分别是：快照复制、事务复制、合并复制。SQL SERVER 主要采用出版物、订阅的方式来处理复制。源数据所在的服务器是出版服务器，负责发表数据。出版服务器把要发表的数据的所有改变情况的拷贝复制到分发服务器，分发服务器包含有一个分发数据库，可接收数据的所有改变，并保存这些改变，再把这些改变分发给订阅服务器。

因写入服务器为单台机器运行，为了增加安全性，所以需另增加一台写入服务器，两台写入服务器做数据库镜像，当主写入数据库服务器宕机，自动切换至备用写入数据库服务器。

（3）优缺点

优点：

①、读具有高性能高可靠性和可伸缩:只读服务器，因为没有写操作，会大大减轻磁盘IO等性能问题，大大提高效率；只读服务器可以采用负载均衡，主数据库发布到多个只读服务器上实现读操作的可伸缩性。

②、部署成本降低，无需购买额外特定集群设备。

缺点：

①、数据的实时性差:数据不是实时同步到自读服务器上的，当数据写入主服务器后，要在下次同步后才能查询到。

②、数据量大时同步效率差：单表数据量过大时插入和更新因索引,磁盘IO等问题，性能会变的很差,使用于写入量不大的数据库。

③、同时连接多个（至少两个）数据库：至少要连接到两个数据数据库，实际的读写操作是在程序代码中完成的，容易引起混乱。

四、方案总结：

1、方案对比

序号

名称

原理

部署过程

测试

资源协调

1

Moebius for SQL Server

清晰

不清晰

需测试可行性

2

DBTwin数据库集群

待验证

不清晰

需测试可行性

3

ORACLE平台, RAC集群

清晰

不清晰

需测试可行性

技术部配合

4

数据库路由器—ICX,

不清晰

不清晰

与厂家沟通可行性

5

数据库读写分离

清晰

不清晰

需测试可行性

技术部配合

2、方案说明

因数据库服务器集群方案资料有限，需要进行虚拟部署、测试，通过实际部署、测试，进一步验证集群方案的可行性，稳定性、安全性等。

部署、测试过程中根据实际需求，选择最为合适的规划方案。