mysql集群系统的设计实现

您的WebApp系统是否正在使用一个MySQL的数据库 系 统？您的客户是不是总是抱怨页面结果反馈的非常慢？您的MySQL系统的负载是不是总是维持在一个非常高的状态下？本文将为您提供一个分担MySQL系统 的负载的方法，以及由此派生出来的一个MySQL-HA-Proxy的开发项目。使用本文提供的方法，您将以最小的源代码改动，获得MySQL系统的高效 运转。

第一节 数据库 集群 技术的现状

目前数据库 集群 系统应用得比较成功，应用范围比较广泛的是：Oracle公司的Oracle9与IBM公司DB2。Oracle9采用Shared-storage的技术，DB2选择了Shared-nothing的技术，二者各有长短。

最新的数据库 集群 系统的理论基础是分布式计算，将数据分布到每个节点，所有的计算节点并行处理数据，将结果汇总。这样的方式无疑是最完美的。但是目前仍然不能实现全部的功能。



对于Shared-storage以及Shared-nothing的技术请参考Oracle以及IBM网站上的相关资料。

第二节 目前数据库 应用状况

目前数据库 应用状况大致分为两类，第一类是数据量在100G以下，数据库 访问频繁，请求密集。主要是Web APP类型的应用，例如：网站，论坛等。这些Web APP类型的应用访问数据库 的特点是：访问频繁，数据库 每秒钟要接受几千次以上的查询，需要经常追加数据，同时对数据的响应速度要求比较高。另一类是用于科学计算、存储历史数据的应用，数据量往往达到几百G。这些应用访问数据库 的特点是：多为查询操作，数据都是分批、定时、集中倒入数据库 ，数据库 的记录非常多，积累了大量的数据，对数据库 的响应速度没有太高要求。

第三节 暴露出来的问题

第一类应用，由于访问比较频繁，而且为了支持更多的访问，Web Server一般都使用了负载均衡的集群 ，但是对于数据库 来说，由于无法实现集群 操作，每秒钟的请求不断增加，随着服务器负载的增加，响应单个请求的速度越来越慢，如果库文件比较大，出现写操作的时候还会出现锁表时间过长等影响访问效率的事情。

第二类应用，主要是数据文件太大，每次处理数据都需要大量的时间，如果写错一个语句就需要花几个小时来重做查询。

第四节 如何解决

首先应当从硬件、软件、程序、索引、SQL语句这几个方面进行优化，如果仍然不能解决问题，我们就要考虑数据库 系统的集群 （并行处理）了。

对于第一类的应用，在数据库 服务器正常运行，负载不高的情况下，应用对数据库 系统的状况还是满意的。但是数据库 系统负载过高之后，就会出现完成请求的时间加长，达不到系统的要求时间。既然负载是由于过多的请求造成的，我们就采取分担请求的方式，让一部分的请求去访问另外一台服务器，让单台服务器的负载降低，从而解决问题。

对于第二类的应用，就需要分布式计算的系统来解决了，一般的系统是无能为力了。

第五节 针对于"Linux+Apache+PHP+MySQL"的第一类应用问题的解决方式

一个实际案例的解决：
我在工作当中遇到了这样的问题，我们的Web Server是Linux+Apache+Php的三台机器组成的集群 ，MySQL运行在SUN450，2G内存的平台上。由于WEB的访问量在高峰的时候几乎满负荷运转，LoadAvg(就是一分钟之内处于Running状态的进程数量)都在10-20之间，反映出来就是大量的请求都在访问数据库 的时候被挂住了，导致一个请求没有完成，下一个请求又进来，最后恶性循环。LoadAvg会在瞬间飙升至800以上。数据库 那边就更糟糕了，LoadAvg达到300多，数据库 的线程非常多，CPU忙于切换线程状态，这个时候除非Restart MySQL，否则怎么都不会好。在对SQL语句优化完成后还是不能很好的解决问题，我们增加了一台数据库 服务器，通过MySQL的数据同步机制，让两台数据库 上的数据保持同步，修改了一部分只会发生读取操作的php程序，让这些程序连接另外一台数据库 ，算是把负载分离出去一部分，问题得到了初步的解决。但是后来业务做大，我们又增加了多台服务器，修改了很多程序，分离他们对数据库 的读取操作，访问不同的服务器。

第六节 MySQL-HA-Proxy方案的提出

通过修改程序的方式实现将系统的负载分离，是件很痛苦的事情，工程浩大，而且不能弄错，因为除了主服务器可以写入、修改数据，而其它的服务器只能通过数据同步更新自身的数据，所以如果你对那些数据库 进行了写操作，结果将是灾难性的。

如 果我们能够有一个程序分拣SQL语句，根据他的类型（读取/写入），分别传送给不同的服务器，然后再将结果返回。采用一种类似HTTP的PROXY的方 式，这样我们就不需要通过修改源程序的方式来分担负载了，如果再能够根据服务器的负载状况，或者是表的状态（可用/锁定），来判断应该将这个请求分配到哪 台服务器，那就比我们修改源程序所能达到的效果还要好。

第七节 MySQL Client 与 Server之间如何通信

四处寻找，也没有找到一篇关于Mysql通讯协议的文章，看来只有分析Mysql的源程序了。于是找来mysql 3.23.49的代码，打开sniffer工具。MySQL的通讯协议可能变更过多次，在3.23.49的版本里面，通讯协议的版本竟然是10。

简单的分析了一下通讯协议，现在规整如下，有些地方还不是很完善，由于我实在没有太多的时间仔细研读mysql的代码，目前我只了解到了这些。

Server 对 Client 请求的响应数据格式：
偏移    区域    类型    长度(byte)    说明    
0    HEAD    Data Length    3         
1         
2         
3         FLAG    1    =0普通信息
=1多段信息
=2认证返回
>2段结束字    
4    DATA    CMD Code    1         
5         Message    DataLength - 1         

当FLAG=0 , 2的时候 CMD Code 与 Message 的定义
CMDCode    类型    Message的结构    
00    状态码    偏移    类型    Length(byte)         
         0    Affect rows    2         
0A    服务器版本号    偏移    类型    Length(byte)         
    只有在刚刚连接上Server的时候有效，Server会马上返回一个数据节段的信息    0    VersionString    8    end of '/0'    
    8    Session ID    4    32bits    
    12    UnKnown    11         
                        
FF    当出现错误的时候返回信息    偏移    类型    Length(byte)         
         0    ErrCode    2         
         2    ErrMsg    END         
FE    多段信息传输的结束    空    

Client 对 Server 提交数据的格式：
偏移    区域    类型    Length(byte)    
0    HEAD    Data Length    3    
1                   
2                   
3         Compressed    1    
4    DATA    Command ID    1    
5        Command Data    Data Length - 1    

Command ID 与 Command Data 的说明：
ID     类型    数据格式    
0    COM_SLEEP         
1    COM_QUIT    NULL    
2    COM_INIT_DB    Database name    
3    COM_QUERY    stand query string    
4    COM_FIELD_LIST    table name [128] wildcard[128]    
5    COM_CREATE_DB    Database name    
6    COM_DROP_DB    Database name    
7    COM_REFRESH    options(bits)    
8    COM_SHUTDOWN    NULL    
9    COM_STATISTICS    NULL    
10    COM_PROCESS_INFO    NULL    
11    COM_CONNECT         
12    COM_PROCESS_KILL    sid[4]    
13    COM_DEBUG    NULL    
14    COM_PING    NULL    
15    COM_TIME         
16    COM_DELAYED_INSERT         
17    COM_CHANGE_USER    [user][passwd][db]    
18     COM_BINLOG_DUMP         
19    COM_TABLE_DUMP         
20    COM_CONNECT_OUT         

第八节 Client 如何通过 Server 的用户认证

协 议分析完成了，我尝试着让它工作起来，可是认证这个部分遇到了麻烦，Mysql Server在Client连接上它的时候，会首先返回给Client一个数据包，包含协议的版本号，版本信息，SessionID，一个8字节的 Key，就是这个Key的原因。Client会使用这个Key来加密 密码 ，然后将用户名，密码 ，需要打开的数据库 等信息发送给Server，这样就完成认证了。我不知道Client是如何利用这个Key来加密 的，所以我打算跳过密码 ，我将Client的数据包重组，去掉Password的信息之后，我成功了，但是集群 里面的Mysql用户都是没有密码 的，安全性多多少少有些问题，不过这些服务器都是放在HA后面的，没有外部的IP地址，应该问题不大，不过多多少少是个缺憾。

但是我总要知道用户的密码 是否正确吧？怎么办呢？使用一个专用的Mysql来完成密码 认证。安装一个最小化资源的Mysql Server用来做MysqlAuth（专用认证服务器），当Client连接后，就将MysqlAuth的第一个数据包返回给Client，这里面当然就包含着Key，然后Client会使用这个Key，加密 密码 之后，将认证信息发回来，这个时候，MysqlHA系统就会将这个信息转发给MysqlAuth，并且自己保留一份，如果认证通过了，就把保留的那一份进行重组，去掉密码 信息，然后用重组后的认证信息去连接集群 中的服务器。

第九节 系统的结构与流程



图中HA就是使用HeartBeat方式建立的高可靠性系统（具体实现方法请参考 http://www.linuxvirtualserver.org/ ）。Proxy为Mysql-Proxy系统，MysqlAuth是专用的认证服务器。红色的RealServer为主要服务器，可以进行数据更新操作，同时将数据同步到其它的RealServer。




上图描述的就是Client认证过程


上图描述的是认证不通过以及认证通过后与RealServer建立联接的过程


上图讲述了连接建立后，系统处理SQL Query请求的过程

第十节 结束语

我 现在已经基本完成了mysql-proxy的程序的开发，但是目前仍然处于测试阶段，最新的版本是0.0.4，下一个版本仍然还在修订中。从0.0.3版 本开始，mysql-proxy已经可以完整的跑完mysql自身提供的sql-bench了，但是这个sql-bench只能提供单点的性能，没有对集群 的mysql系统提供测试功能。

系统提供了动态采集RealServer上的LoadAvg然后反馈给Mysql Proxy的程序，但是由于这部分我没有进行测试，所以我在前面的测试中采用的请求分配方式是轮询方式，如果出现两个负载一样的RealServer系统会自动的在它们之间轮换选择。

Mysql-proxy的源代码您可以到我的网站下载：http://netsock.org/bbs/ Mysql-HA-Cluster项目。还有一部分测试的数据我也会在那里公布。

如何进行系统测试？

既然是专门为Linux+Apache+Php+Mysql这样的系统做的集群 ，就应该找一个实际的应用来跑跑看，然后模拟大量的访问，来进行测试。

选择一个论坛系统也许不错，VBB吧，用的比较多，也比较流行。模拟访问就用Apache自身提供的AB来做。

测试系统的最小环境就是：（五台机器）

1 x Apache + PHP
1 x AB
1 x Mysql Proxy + Mysql Auth Server
2 x Mysql Real Server

参考资料：

第九节的幻灯片可以在 http://www.netsock.org/mysqlha/mysql-ha.ppt 得到
最新版本的源代码可以在 http://www.netsock.org/mysqlha/mysql-proxy_0.0.4.zip 得到
安装说明可以参考 http://netsock.org/bbs/showthread.php?threadid=5
一个sql-bench的运行结果可以在http://netsock.org/bbs/showthread.php?threadid=9 得到

作者简介：

徐超，任职于TOM.COM北京公司，从事网络系统技术支持及系统维护工作。业余时间致力于以NetSocket技术为基础的网络应用的开发。开发网站：http://netsock.org/bbs/ 目前正在开发的项目包括：SocketChat, MySQL-HA-Proxy, Php Session Server