第一节 数据库集群技术的现状目前数据库集群系统应用得比较成功，应用范围比较广泛的是：Oracle公司的Oracle9与IBM公司DB2。Oracle9采用Shared-storage的技术，DB2选择了Shared-nothing的技术，二者各有长短。
最新的数据库集群系统的理论基础是分布式计算，将数据分布到每个节点，所有的计算节点并行处理数据，将结果汇总。这样的方式无疑是最完美的。但是目前仍然不能实现全部的功能。
·数据库人员面试：SQL Server常用测试题·PHP连接数据库的方法(3)·[冷枫推荐]：数据库操作，内外联查询，·用JSP从数据库中读取图片并显示在网页·图解MySQL数据库的安装和操作 （1）·PHP中使用类对数据库进行操作·InterBase 数据库函数库·Oracle数据库网络的安装和配置(1)·利用外部命令Oralce数据库导入导出·ACESS数据库与WEB页连接
对于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 多段信息传输的结束 空
第一节 数据库集群技术的现状目前数据库集群系统应用得比较成功，应用范围比较广泛的是：Oracle公司的Oracle9与IBM公司DB2。Oracle9采用Shared-storage的技术，DB2选择了Shared-nothing的技术，二者各有长短。
最新的数据库集群系统的理论基础是分布式计算，将数据分布到每个节点，所有的计算节点并行处理数据，将结果汇总。这样的方式无疑是最完美的。但是目前仍然不能实现全部的功能。
·数据库人员面试：SQL Server常用测试题·PHP连接数据库的方法(3)·[冷枫推荐]：数据库操作，内外联查询，·用JSP从数据库中读取图片并显示在网页·图解MySQL数据库的安装和操作 （1）·PHP中使用类对数据库进行操作·InterBase 数据库函数库·Oracle数据库网络的安装和配置(1)·利用外部命令Oralce数据库导入导出·ACESS数据库与WEB页连接
对于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 多段信息传输的结束 空
第一节 数据库集群技术的现状目前数据库集群系统应用得比较成功，应用范围比较广泛的是：Oracle公司的Oracle9与IBM公司DB2。Oracle9采用Shared-storage的技术，DB2选择了Shared-nothing的技术，二者各有长短。
最新的数据库集群系统的理论基础是分布式计算，将数据分布到每个节点，所有的计算节点并行处理数据，将结果汇总。这样的方式无疑是最完美的。但是目前仍然不能实现全部的功能。
·数据库人员面试：SQL Server常用测试题·PHP连接数据库的方法(3)·[冷枫推荐]：数据库操作，内外联查询，·用JSP从数据库中读取图片并显示在网页·图解MySQL数据库的安装和操作 （1）·PHP中使用类对数据库进行操作·InterBase 数据库函数库·Oracle数据库网络的安装和配置(1)·利用外部命令Oralce数据库导入导出·ACESS数据库与WEB页连接
对于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 多段信息传输的结束 空