- 浏览: 209033 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
Prepared:
Hadoop的几个明显缺点 -
CSunDNan:
...
openjdk jvm 方法字节码执行过程 -
幻影之蚀:
...
mysql 源码分析2 源码调试环境建立 -
shukongchengje:
紧急呼唤楼主,mysql代码从哪里弄?官网wiki上看的一头雾 ...
mysql源码分析 整体架构 -
yeshaoting:
好文章.不介意的话转载了.
jvm 字节码中文含义
您的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 请求的响应数据格式:
当FLAG=0 , 2的时候 CMD Code 与 Message 的定义
Client 对 Server 提交数据的格式:
Command ID 与 Command Data 的说明:
第八节 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
第一节 数据库集群技术的现状
目前数据库集群系统应用得比较成功,应用范围比较广泛的是: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 请求的响应数据格式:
当FLAG=0 , 2的时候 CMD Code 与 Message 的定义
Client 对 Server 提交数据的格式:
Command ID 与 Command Data 的说明:
第八节 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
发表评论
-
fuse-2.7.3.tar.gz开源代码学习心得
2010-03-30 14:06 2583fuse-2.7.3.tar.gz开源代码 ... -
Linux网络文件系统
2010-03-30 13:25 1980Linux网络文件系统 (NFS) ... -
fuse调用流程分析
2010-03-29 15:30 2027fuse处理请求的整个流程如下图所示,以unlink操作为例进 ... -
gearman 源码分析
2010-03-29 15:23 1984gearman 源码分析 -
lustre 基于对象存储的分布式实现
2010-03-29 15:20 1172lustre 基于对象存储的分布式实现 -
揭开j2ee集群面纱
2010-03-29 15:09 710揭开j2ee集群面纱 -
gearman 分布式图片转化处理框架
2010-03-29 15:07 901gearman 分布式图片转化处理框架 -
lustre文件架构 dht
2010-03-29 15:03 945lustre文件架构 dht ib总线 -
Quartz源码分析
2010-03-29 14:10 2402Quartz是运用最广的任务调度框架,它最核心的组成部分是Sc ... -
Terracotta/Quartz集成带来了基于内存集群的分布式任务调度功能
2010-03-18 13:21 1282Terracotta/Quartz集成带来了基于内存集群的分布 ... -
Lustre File System (转)
2010-03-16 17:03 1693Lustre File System 历史 Lustr ... -
Hadoop的几个明显缺点
2010-03-16 16:56 15049Hadoop的几个明显缺点如下: 1. 采用Java实现。Ja ... -
HDFS是一个不错的分布式文件系统
2010-03-16 16:55 1263HDFS是一个不错的分布式文件系统,它有很多的优点,但也存在有 ... -
Lustre系统的体系结构
2010-03-16 16:51 1122Lustre的主要组件有三个:先进的集群文件系统,基于对象的存 ... -
分布式文件系统 linux lustre
2010-03-16 16:48 2235Lustre名字是由Linux和Clusters演化而来,是为 ... -
gluster分析(转)
2010-03-16 16:45 4058引言 GlusterFS 是一个高层次的分布式文件系统解决方案 ... -
分布式文件系统 gluster
2010-03-16 16:44 1155分布式文件系统 gluster -
分布式锁资料
2010-03-16 16:44 863分布式锁服务 -
分布式调度框架 quartz
2010-03-16 16:39 1484分布式调度框架 quartz -
分布式调度 gearman(转)
2010-03-16 16:38 1436学学Gearman2009年07月11日 ...
相关推荐
本文讨论了基于Mysql的数据库集群设计与实现的相关知识点,涵盖Mysql数据库集群的意义和优势、设计、实现、管理等方面。 Mysql数据库集群的意义和优势 Mysql数据库集群是由多个Mysql数据库服务器组成的集合,通过...
MySQL作为一种流行的开源关系型数据库管理系统,虽然提供了一个基于日志的同步模式,但在实际应用中,尤其是在分布式数据库集群环境中,还面临着诸多挑战和问题。数据一致性监控、主从切换、灾难恢复后加入集群以及...
"基于Grid Infrastructure集群的MYSQL数据库高可用方案的研究与实现" Grid Infrastructure 是甲骨文公司在大数据、云计算时代创新性推出的高可用集群解决方案。当前基于 Grid Infrastructure 的数据库高可用架构...
**MySQL数据库集群+负载均衡(LVS)** 这个主题涵盖了构建一个高可用性、高性能的MySQL集群,并通过负载均衡技术来实现对集群中多个MySQL实例请求的智能分发。这种架构能够显著提高系统的稳定性和响应速度,适用于大...
MySQL数据库集群是一种高可用性、负载均衡的解决方案,广泛应用于全球开发者、DBA和IT管理者之中,因其可靠性、性能和易用性而受到热烈欢迎。MySQL的市场占有率高达25%,这表明开源数据库已经成为现代IT架构的核心...
总的来说,基于RHEL5的MySQL数据库集群是应对高并发、大数据量场景的有效解决方案。通过合理配置和管理,可以为电子商务、大型网站和其他对数据处理性能有高要求的应用提供稳定且高效的数据库服务。同时,这种集群...
基于主动TCP连接复制的高性能高可用MySQL数据库集群方案,通过原子多播和只读操作的分流,实现了数据库集群的高可用性和高性能。这种技术对于处理高并发读写操作的大型在线服务尤其有益,它能够保证在故障发生时系统...
本文主要探讨的是基于MySQL数据库的通信电源控制系统的设计与实现。通信电源是通信系统的基础,其稳定运行对整个通信系统的正常运作至关重要。随着通信质量要求的提升,对通信电源系统的监控和管理也变得更加严格。 ...
本文提出了一种基于Xen Server虚拟化平台的MySQL Cluster数据库集群系统配置部署方案,并通过与MySQL 5.1单机版进行性能对比,验证了该方案的有效性和优越性。 #### 二、背景及问题阐述 在物理主机环境下构建...
基于moduo实现的集群聊天服务器和客户端源码,使用mysql数据库存储相关数据。采用nginx实现负载均衡,结合redis发布-订阅模式来实现在不同服务器上客户端进行通信。 基于moduo实现的集群聊天服务器和客户端源码,...
cpp-Myproxy项目就是针对这种需求设计的一个MySQL数据库集群的分片代理,它允许开发者将数据分布到多个数据库节点上,从而实现负载均衡和数据水平扩展。 【分片技术介绍】 分片是一种数据库架构模式,其核心思想是...
设计与实现高可用性MySQL数据库在云平台中的应用 在云平台中,高可用性数据库 MySQL 的设计与实现对系统的稳定运行至关重要。随着移动互联网、物联网及各种社交软件的迅猛发展,各种不同环境下产生的数据量获得了...
集群聊天服务器(nginx tcp负载均衡模块、muduo网络库、基于发布-订阅的redis消息队列、mysql数据库) 集群聊天服务器(nginx tcp负载均衡模块、muduo网络库、基于发布-订阅的redis消息队列、mysql数据库) 集群聊天...
其中,基于MySQL Replication的数据库集群方案因其高性能、高可靠性、易扩展性等特点,成为了一种有效的解决方案。 MySQL作为全球最流行的开源数据库,被广泛应用于Google、Yahoo!、亚马逊、新浪、网易等大型机构和...
基于muduo网络库的集群聊天服务器和客户端源码,使用nginx tcp负载均衡,mysql数据库,redis发布-订阅数据库,redis发布-订阅 基于muduo网络库的集群聊天服务器和客户端源码,使用nginx tcp负载均衡,mysql数据库,...
基于主动TCP连接复制的高性能高可用MySQL数据库集群.pdf
基于zookeeper和强一致性复制实现MySQL分布式数据库集群.pdf