大讨论：在SQL Server上能否实现负载均衡集群？(tech.2008有感)

lijiu3134

做数据同步的有好些呢,真正能实时的不多,否则用微软的复制,订阅就可以了,就是因为实时差,还有使用起来DBA管理的时候同步数据太慢,因为他是基于日志的串行同步.

clshao2006

谢谢啦！

lijiu3134

现在有一台SQL 2005服务器，数据实例存放在共享的磁盘阵列中。由于这台服务器经常CPU100%，现在想增加一台SQL 2005的服务器，也连接到共享的磁盘阵列中的这个数据实例。2台SQL服务器都会接收到写和读的动作。

问题1.能否这样操作？

问题2.这样操作能否缓解目前这台服务器的CPU压力？

问题3.是否有更好的办法？

非常期待并感谢。

rrqq

在页面上有个游戏，每秒要读取数据库一次，而且每玩一次（差不多5秒）就要执行后台方法，后台方法很复杂，至少要执行8次数据库操作
只要人多点就卡死了（一次信息：事务一释放，文件被另一个进程占用等），

请问大家怎么在保证访问量的同时防止上面的错误呢
是不是因为人太多，造成线程抢占呢?
不知道前面聊的技术能否解决此问题?????

luckyrandom

TO 楼上的楼上：
   理解错了集群概念哈，MSSQL不支持此种架构，应该从MSSQL性能上着手，像索引、SQL指令、数据结构、流程
TO楼上：
   这个游戏应该改进机制吧，也或许这个游戏设计时就仅支持几个人或几十个人为定位？

kaerkailiu

大家前面讨论的问题不就是,解决此类问题的吗?                                           Moebius的三大核心部分
1.3        Moebius数据库集群可以解决的问题，给客户带来的价值
1.3.1显著提升数据库的性能，提高设备利用率：           
Microsoft SQL Cluster Server、SQL2005镜像、或第三方的HA(高可用性)集群都存在以下问题：
        数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份；
        因为始终只有一个节点在运行，在性能上得不到提升，系统也就不具备扩展能力；
        当现有机器的性能不能满足应用的负载时，只能更换更高配置的机器。
在Moebius所构建的集群中，每个节点都具有同等地位，改变了传统集群中主节点和备用节点的模式，
        Moebius集群中，任何时刻都有多个实时同步的数据库，当出现故障时，冗余的结构可以保证系统正常运行；
        当现有机器的性能不能满足应用负载时，只需要简单增加服务器就可以了，这样可以大大减少硬件投资的风险；
        集群中各节点共同支撑业务，相互可以负载均衡，系统的压力得到均匀的分担。这种横向扩展的结构可以提高设备利用率，显著提升数据库的性能；


3.Moebius集群的突出特点
3.1Moebius集群的高可用性
冗余结构：在由Moebius for SQL Server构建的数据库集群系统中，系统任何时刻同时拥有多份一致的数据，消除了单点故障。即使某节点发生故障，其余节点仍然可以支撑业务。
虚拟IP连接：Moebius集群为每个服务器配置了虚拟IP，应用程序通过这个虚拟IP连接到数据库集群上，若某节点发生故障，虚拟IP会立即飘移到集群中另外的节点来响应连接请求。
持续工作：在由Moebius for SQL Server构建的数据库集群系统中，可以提供持续的服务来应对企业计划或非计划停机，若某节点（或实例）失败，其他节点可以照常提供服务，可以在不停机的情况下完成维护和重新上线。
3.2负载均衡
数据库负载均衡是有由Moebius集群的架构来支撑的，集群中的每个节点都具有等同地位，具有相同的数据库，实现了真正的冗余，应用程序连接组件中提供了数据库连接的负载均衡分担功能，可以有效的均衡所有的连接请求，实现了集群中各服务器负载的均衡，进而显著提升数据库系统的性能。
3.2.1如何保证各节点数据的一致性，实现数据实时同步？
中间件驻留在每个机器的数据库中，监测数据库内数据的变化并将变化的数据同步到其他数据库中。数据同步完成后客户端才会得到响应，同步过程是并发完成的，所以同步到多个数据库和同步到一个数据库的时间基本相等；另外同步的过程是在事务的环境下完成的，保证了多份数据在任何时刻数据的一致性。
正因为中间件宿主在数据库中的创新，让中间件不但能知道数据的变化，而且知道引起数据变化的SQL语句，根据SQL语句的类型智能的采取不同的数据同步的策略以保证数据同步成本的最小化。
        数据条数很少，数据内容也不大，则直接同步数据
        数据条数很少，但是里面包含大数据类型，比如文本，二进制数据等，则先对数据进行压缩然后再同步，从而减少网络带宽的占用和传输所用的时间。
        数据条数很多，此时中间件会拿到造成数据变化的SQL语句， 然后对SQL语句进行解析，分析其执行计划和执行成本，并选择是同步数据还是同步SQL语句到其他的数据库中。此种情况应用在对表结构进行调整或者批量更改数据的时候非常有用。

大家来看看这个东西实现的如何?

kaerkailiu

在使用复制订阅的时候,大家有没有遇到下面的类似问题:
       1.数据同步的实时性得不到保障，当访问负荷很高或者中心数 据库在整理数据时，将出现大量DML操作时延迟时间比较长或者出现堵塞的情况；
     2. 某些修改操作需要重新建立复制关系并初始化，这期间需要停止数据库的读取服务，规模越大的应用停止的时间越长，严重影响了数据库的可用性。

不知道大家都怎么解决???

kaerkailiu

因为这影响到了一些业务的正常开展,比如说一些人才网站,有个业务就是大家可以对感兴趣的东西进行打标签,采用复制订阅,等数据到了订阅服务器会有很长的时间,而对用户来说他打过标签提交后,没什么变化,用户以为哪里出错了,明明自己标记了怎么会没有显示,原因就是复制订阅的时间延迟太厉害了.所以就导致这类的业务不能正常使用,不知道大家有没有什么高招?????

chengdunn

楼主 的问题怎么都有点刁钻,没遇到过,学习

lijiu3134

我们也遇到了类似的问题,后来采用一个数据实时同步的中间件,采用一种并行技术,解决了时间滞后的问题.