您的位置主页 > MYSQL

基于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的代码,目前我只了解到了这些。

偏移

区域

类型

长度(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