MySQL支持

    作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究。

      Innodb的表空间是在配置文件中定义（说是表空间有时觉的有点羞愧，和Oracle比真的差太远了），这里简单列一下表空间里的基本概念及表的分配情况。
       表空间是在配置文件中定义的几个文件简单的耦合起来，在使用中互不可少（少一个就面临DB完蛋的危险）。对于共享表空间无法确定表所在的表空间上。
      独立表空间可以做到每个表有自已的表空间（羞一下）。
       针对共享表空间，表空间中包括：回滚段,段（segment），区域（extent),数据页(page size)在表空间的体现为：
  表空间由默认16k的数据页面（page)组成，每64个连续的页面组成一个区域（extent,Oracle里熟悉的一个东东）。对于表空间的“文件(file)”在Innodb中被称为段(segment)。 回滚段(rollback segment）是一个特殊的例子，实际上rollback segment包含了多个段。对于Innodb表的索引都被分配成两个段：一个是为了 B-tree 的无叶结点(non-leaf nodes)，另一个是为了叶结点(leaf nodes)。
  这是为了达到包含数据的叶结点的更好的顺序(sequentiality for the leaf nodes)。
         当表空间中的一个段增长时，InnoDB 为它个别地分配最初的 32 个页面。之后 InnoDB 再分配段的整个区域(extents)。InnoDB 会以每次 4 个区域(extents)来增加一个大段以确保数据的良好顺序。
         表空间中的某些页面包含其它页面的位图(bitmaps)，所以在 InnoDB 表空间内的一些区域(extents)不能以一个整体分配给段，而只能作为个体页面。
          当发出一个查询 SHOW TABLE STATUS FROM … LIKE … 来询问表空间的剩余空间时，InnoDB 将报告表空间中所有空闲区域(extents)中确实可用的部分。InnoDB 通常会保留一些区域用于 clean-up 和其它的内部目的；这些保留的区域并不包含在剩余可用空间中。

         当从一个表中删除数据时，InnoDB 将收缩 B-tree 中相应的索引。这是依赖于释放个别的页面或区域(extents)以让其他用户使用剩余空间的删除模式。 移除(drop)一个表或删除所有记录可以保证释放空间给其他用户，但是删除记录行只有在事务回滚或 consistent read 后并不需要时才会被物理的移除

        对于独立表空间也是存一样的概念和行为，唯一区别就是每个表的数据存到指定的表空间中，rollback segment不和数据的segment在一个竞争。使用独立表空间的一个好处就是可以使数据分布相对于磁盘上更连续一点。

     作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究。
         我们知道Innodb的数据页是16K,而且是一个硬性的规定，系统里没更改的办法，希望将来MySQL也能也Oracle一样支持多种数据页的大小。
但实际应用中有时16K显的有点大了，特别是很多业务在Oracle或是SQL SERVER运行的挺好的情况下迁到了MySQL上发现IO增长太明显的情况下，
就会想到更改数据页大小了。
　　实际上innodb的数据页大小也是可以更改的，只是需要在源码层去更改，然后重新rebuild一下MySQL.
    更改办法：
    (以MySQL-5.1.38源码为例）
    位置在storage/innobase/include/univ.i ，在univ.i中查找：UNIV_PAGE_SIZE

/*
   DATABASE VERSION CONTROL
   ========================
*/
 
/* The universal page size of the database */
#define UNIV_PAGE_SIZE          (2 * 8192) /* NOTE! Currently, this has to be a
     power of 2 */
/* The 2-logarithm of UNIV_PAGE_SIZE: */
#define UNIV_PAGE_SIZE_SHIFT 14
 
/* Maximum number of parallel threads in a parallelized operation */
#define UNIV_MAX_PARALLELISM 32

   UNIV_PAGE_SIZE就是数据页大小，默认的是16K. 后面的备注里标明，该值是可以设置必须为2的次方。对于该值可以设置成4k,8k,16k,32K,64K，在大也没意义了。
同时更改了UNIV_PAGE_SIZE后需要更改 UNIV_PAGE_SIZE_SHIFT 该值是2的多少次方为UNIV_PAGE_SIZE，所以设置数据页分别情况如下：

#define UNIV_PAGE_SIZE_SHIFT 12  if UNIV_PAGE_SIZ=4K
#define UNIV_PAGE_SIZE_SHIFT 13  if UNIV_PAGE_SIZ=8K
#define UNIV_PAGE_SIZE_SHIFT 15  if UNIV_PAGE_SIZ=32K

例子：
　更改innodb的数据页为8K,相应修改为：

/*
   DATABASE VERSION CONTROL
   ========================
*/
 
/* The universal page size of the database */
#define UNIV_PAGE_SIZE          8192   /* NOTE! Currently, this has to be a
     power of 2 */
/* The 2-logarithm of UNIV_PAGE_SIZE: */
#define UNIV_PAGE_SIZE_SHIFT 13
 
/* Maximum number of parallel threads in a parallelized operation */
#define UNIV_MAX_PARALLELISM 32

重新编译，然后测试测试，再测试。Good luck!

　作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究。
     

来源：http://www.mysqlperformanceblog.com/2006/05/30/innodb-memory-usage/

译这个文章的目的：
　　最近经常被问起Innodb是如何使用内存的。该问题早已被原MySQL公司的Vadim论证过。我这里译一下他的文章供大家参考。
开始：
　　这里有许多关于Innodb如何使用内存的问题。我这里将会以innodb启动时的分配情况做一个解释。一些重要的概念：
　　NBLOCKS＝Innodb_buffer_pool有多个页(block)＝innodb_buffer_pool_size/16384(16k)
  　OS_THREADS= if ( innodb_buffer_pool_size >= 1000Mb) = 50000
 　　else if (innodb_buffer_pool_size >= 8Mb) = 10000
　　 else  = 1000 (该值只用在*nixes系统上，对于Windows有一点小的区别计算OS_THREADS)

所以Innodb 使用的内存包括：
　innodb_buffer_pool_size
    innodb_additional_mem_pool_size
    innodb_log_buffer_size
    adaptive index hash ,size (innodb buffer 索引管理区)= innodb_buffer_pool_size/64
    system dictionary hash,size(innodb内部字典区) = 6 * innodb_buffer_pool_size/512
    memory for sync_array,size(用于Innodb内部syncronzation的开销)=OS_THREAD * 512
    memory for os_event,size(用于innodb内存的syncronzation的开销)=OS_THREAD * 216
    memory for locking system(内存的锁管理系统),size = 5 * 4 *NBBLOCKS
 
 最终得到innodb内存使用的计算公式为：
     Innodb_buffer_pool_size + innodb_log_buffer_size + innodb_additional_mem_pool_size + 812/16384 * innodb_buffer_pool_size + OS_THREADS * 368
 对于812/16384 * Innodb_buffer_pool_size 可以简单的用 innodb_buffer_pool_size / 20　计算，

对于OS_THREADS * 368　　
    OS_THREADS * 368 = 17.5 MB  if innodb_buffer_pool_size > 1000MB
   OS_THREADS * 368 = 3.5 MB  if innodb_buffer_pool_size > 8MB

举一个例子：
　　 如果你的innodb_buffer_pool_size有1500MB,innodb_additional_mem_pool_size =20 MB,innodb_log_buffer_size = 8M,
 　　Innodb 将会向系统申请内存为= 1500M + 20M + 8M + 1500/20 M +17.5 = 1620.5M

　　根据以上的条件可以算出Innodb最根本最需要多少内存，这样对于服务器的内存使用也可以有一个规划了。

　作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究。
　
      近段一直在一个项目中恶战，所以对于Blog更新慢了一点。该项目中使用了MySQL 5.1.X,使用这个版本是在我加入这个项目前就决定的。该项目基本上可以达到每秒3W的QPS(大多是基于主建的等于逻辑读写)记录都是比较长的。
近段遇到一些问题列举：
　　使用MySQL-5.1.31 进行数据迁移，从SQL SERVER到MySQL迁移，共享表空间，每表一个线程，一次从SQL SERVER读取20条记录写入MySQL,迁移完毕后一个大表巨然是只能读不能写了
关闭连接池程序，保持只有一个连接进入MySQL但对那个大表也无法进行update操作，可以进行insert操作。该表有差不多2亿的数据，当时那个无语真的没法说。最终解决方法，把该表
dump了出来，又导回去可以更新。
　　最新的业务上线后开着swap，没过几天就出现swap占用明显，DB反应慢的不能忍受。最终解决方法：禁用了swap分区。
　　因为truncate　table不能被复制及一系列问题，最终升级到mysql-5.1.31sp1（无语一个垃圾升级版本），我的意思当时升级到MySQL-5.1.37。这样就引出了另一外问题:Sort aborted,
内存溢出。以至于出现了几次严重的内存使用完毕后MySQLD被KILL掉，MySQLD进程重启，数据文件恢复造成Down机时间过长。巨汗的一次。
　　痛中思痛，最终把MySQL－5.1.41，现在看来内存正常了。使用中出现了一个更可怕的问题，对一个dump出来后，导入时对该表show create table不显示结果，按ctrl+c,MySQLD就Crash,巨汗。
　　万恶的MySQL-5.1.X,准备升级到MySQL-5.1.x的同学，还是我多思考一下吧。

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究。

  该文档只用于一般服务器的安装，其它专用服务器安装仅供参考。

系统安装步骤：
1)输入linux text选择text安装模式。
2)安装时语言环境选English。
3)键盘类型选us。
4)鼠标选择No-mouse。
5)安装类型选Custom。
6)分区设置为：
/dev/sda
/dev/sda1 512M ext3 /boot
/dev/sda2 5G ext3 /home
/dev/sda3 3G ext3 /
/dev/sda4 Extended
/dev/sda5 5G ext3 /var
/dev/sda6 2G ext3 swap
/dev/sda7 余空间 /data
7)使用GRUB Boot loader。
8)不增加参数在Boot Loader Configuration。
9)不为Boot Loader设置密码。
10)设置Boot Loader启动Linux。
11)将Boot Loader安装在硬盘的MBR。
12)网络设置，按分配的IP配置网卡。
/etc/sysconfig/network-scripts/
#ls ifcfg-*
ifcfg-eth0 ifcfg-eth1 ifcfg-lo
编辑相应文件
/sbin/service network restart

13)主机名称视情况而定，预定为WEB-数字,数字为ＩＰ最后３位。
14)防火墙的安全级别设为No firewall,禁用SEClinux
15)语言支持选English (USA) 和Chinese (P.R. of China)。
16)默认语言为English (USA)。
17)时区选Asia/Shanghai。
18)Root Password为：redhat
19)Authentication Configuration启用Use Shadow Passwords和Enable MD5 Passwords。
20)Package Group选择：
@ Editors
@ Text-based Internet
@ Server Configuration Tools
@ Development Tools
@ Kernel Development
@ Administration Tools
@ System Tools
21)不必创建Boot Diskette。
22)配置显示选项，指定启动时进入文本模式。
OS安装完毕。

安装后配置
1) 禁用ssh1登录
vi /etc/ssh/sshd_config
#Port 22
#Protocol 2,1
修改为
Port 22
Protocol 2
2) 禁用多于服务
rm /etc/rc.d/rc3.d/* -rf

chkconfig network on
chkconfig rsync on

chkconfig sshd on
chkconfig syslog on
chkconfig crond on
chkconfig xinetd on

根据需要加入自已的相应服务。
3）限制登录IP
vi /etc/hosts.allow
加入
all:ＩＰ.:allow
all:all:deny
ＩＰ为允许进入管理的ＩＰ。当然这个文件也可以不用。
4）定时同步时间
crontab -e
加入
0 0 * * * rdate -s time-a.nist.gov
or
10 03 * * * /usr/sbin/ntpdate -u tick.ucla.edu tock.gpsclock.com ntp.nasa.gov timekeeper.isi.edu usno.pa-x.dec.com
5）关闭ipv6
echo “alias net-pf-10 off” >> /etc/modprobe.conf.dist

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究。

　　MySQL创始人韦德纳斯(Michael Widenius)从MySQL被Sun收购后，就去了MariaDB工作。从MariaDB的介绍上总体来看应该也不错的。以后也要多关注一下这个数据库了。

　　可以关注的：
innodb-plugin
PBXT storage engine
XtraDB storage engine
Maria storage engine

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究。
innodb-plugin 出现差不多有一年了。从功能上性能上都表现的不错。自MySQL-5.1.38后发行的版本中已包括了该功能。（推荐使用MySQL-5.1.40)

http://dev.mysql.com/doc/refman/5.1/en/innodb.html

http://planet.mysql.com/entry/?id=20926

该版本的特性:

http://www.innodb.com/wp/products/innodb_plugin/license/third-party-contributions-in-innodb-plugin-1-0-4/

Multiple Background Threads
==把后面进程的IO进程,细化并可以分配成多个.以前Linux下该IO只能是四个.现在可以最大调到64个.

Master Thread I/O Capacity Tuning
==内部IO限制.我们现在用的Innoddb内部有同时可以操作100个IO限制.这个限制对于现在高端的磁盘显的太少了

Asynchronous Read Ahead
==这是 Google and Percona 的一个Patch对增强MySQL的IO性能及Buffer中读取速度有所改善.

Group Commit
==该功能是MySQL一直支持的,但支持的不够好.在5.1.38的innodb-plugin-1.0.4中的支持是使用的percona的支持.把该性能支持的更好.

Adaptive Flushing
==自适应的刷新脏页,该功能也是来自percona的支持.对于Innodb checkpoint在原来的情况下在某种条件的触发下要进行一个checkpoint因为某些机制,有时并不能很好的完成,
出现系统的抖动现象.如:文件的锁问题,文件系统fsync一大片更新数据，对系统io冲击较大。若分隔成多个小数据fsync，能够减少对读的影响。同时结合mysql代码，发现mysql保证两次fsync之间至少有20ms的sleep，这样的话，若将一次fsync变成多次小数据操作，应该能够减少慢查询的比例。（从目前来看，杜绝是不太可能的）。这也是为什么近几年来percona,innodb的barrauda在推独表空间的一个原因吧.
对于该Patch的引入,它利用10%的IO去做checkpoint从而减少对系统的压力.

Additional Patches
==这部分是Sun的支持.加入了对Solaris的一些特别支持.
对我们有用的是: 对innodb spin loops做了更好的处理.增大了spin的值.
对DBA增加一个诱人的地方:
创建非cluster index时,不用是在Copy表这样一个复杂过程了.
另外:
加入了一种新的Innodb文件格式:barracuda ,据说该文件格式对性能提升很高.但要求使用独立表空间.

http://www.mysqlperformanceblog.com/2008/04/23/real-life-use-case-for-barracuda-innodb-file-format/

该功能需要加入innodb_file_format=barracuda ,并且需要在配置中文件中声明:innodb_file_per_table
所以需要使用该功能的朋友建义Dump出来数据后在[mysqld]中设置这两个参数后在导入:

[mysqld]
ignore_builtin_innodb
plugin_dir=/usr/local/mysql/lib/plugin
plugin-load=innodb=ha_innodb_plugin.so;innodb_trx=ha_innodb_plugin.so;innodb_locks=ha_innodb_plugin.so;innodb_cmp=ha_innodb_plugin.so;innodb_cmp_reset=ha_innodb_plugin.so;innodb_cmpmem=ha_innodb_plugin.so;innodb_cmpmem_reset=ha_innodb_plugin.so
innodb_file_format=barracuda
innodb_file_per_table

Innodb plugin是一个比较让人企待的版本.其实这些功能基本上都被pernoca公司在mysql5.0中实现了.而且我以前使用相关的版本后都是表现良好的.
所以我觉的对于MySQL5.1.38可以导一份基于独立表空间的数据做一个对比.
文中提及的percona: http://www.percona.com/
Google: http://code.google.com/p/google-mysql-tools/wiki/Mysql5Patches
更多关于innodb 的信息可以参考:http://www.innodb.com

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究。

          bug说明： 该BUG在是MySQL5.1.X中存在的一个问题。
重现方法：
        利用 5.1.31-enterprise-gpl-pro-log (Or 5.1.31-sp1-enterprise) 搭建master/slave结构同步正常进行（确认同步进行）
 注意参数：
事务隔级为： READ-COMMITTED
日值格式为： mixed

然后在主库建表：

create database wubx;
create table t1 (id int) engine=innodb;
insert into t1 values(1),(2),(3),(4),(5);
select * from t1;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+------+

从库：

use wubx;
select * from t1 ;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+------+

主库上：

use wubx;
mysql> truncate table t1;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from t1;
Empty set (0.01 sec)

从库：

use wubx;
select * from t1 ;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+------+

解决办法：
先删除该表，然后创建该表。
如: truncate table wubx;改变为：

drop table wubx;
create table wubx( id int) engine=innodb;

另一种方式：
修改事务隔离级别为默认的。可以MySQL的版本升级到MySQL-5.1.37后的版本。

     作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究。      

         今天看一个水友说他的MySQL现在变的很慢。问什么情况时。说单表超过2个G的一个MyISAM。真垃圾的回答方式。

    简单答复：换一个强劲的服务器。换服务器很管用的：）

………
       最终让取到慢查询：

    SELECT * FROM pw_gbook WHERE uid='N' ORDER BY postdate DESC LIMIT N,N;

如：

   SELECT * FROM pw_gbook WHERE uid='48' ORDER BY postdate DESC LIMIT 1275480,20;

        看到这个语句我都吐血了（BT的PHPWIND分页啊，这个语句是PHP初学者写出来的还正常，但PHPWIND那么成熟的社区了还有这样的问题）。
        我这里简单说一下LIMIT的原理。这里以LIMIT N,M为基础：LIMIT首先要找查N+M行，然后从N行处，取M行。那么这样的SQL对一次查询1275500一个操作应该是一个昂贵的开销。对于LIMIT这类的优化，第一个目标就是让N变的尽可能的小或是不用。
     怎么才能使这个N尽可能小呢。我们能做的其实就是用相对的值，给分页一个提示。如现在我们看的是第5页，看完看想看第6页，第6页同样显示是20条记录。我们就可以想到，以这个例子为准：我们可以肯定的是第6页的日值应小于第5页的，如果第5页的最小日值为：2009-11-4，那我们就可以用：

     SELECT * FROM pw_gbook WHERE uid='48' and postdate<’2009-11-1’ ORDER BY postdate DESC LIMIT  20;

这样来查询第6页的内容。同样对于查看第4页的内容（假设第5页的最大日期为：2009-11-3）则第4页的内容为：

     SELECT * FROM pw_gbook WHERE uid='48' and postdate>’2009-11-3’ ORDER BY postdate DESC LIMIT  20;

         这是一个基本的思想。接下来讨论一下怎么展现的问题。

         再说一下这种业务的SQL怎么实现：对于分页的展示可以用多用类型。这里说三种常用的类型：

第一种：显示“上一页” “下一页”这种类型

         这种方式相对简单也就出现了我们看到那种SQL不思考的写法。合理的做法：

         第一页：

     SELECT * FROM pw_gbook WHERE uid='48' ORDER BY postdate DESC LIMIT  20;

         第二页：根据第一页的postdate进行查询如：

      SELECT * FROM pw_gbook WHERE uid='48'  and postdate<’2009-11-3’  ORDER BY postdate DESC LIMIT  20;

         为什么说这个简单呢，这个不存在跳页的问题。接下来这种就存在一个跳页的问题了。

第二种：显示 “ 1,2,3,4,5…”

         第一页： 还是以第一页的方式实现：

         SELECT * FROM pw_gbook WHERE uid='48' ORDER BY postdate DESC LIMIT  20;

         第二页：和原来一样。如果跳页，如从第二页跳到第5页，这里有一个第二页的最小日期为：2009-11-3（假设值，可以由第二页的程序查询得到），第二到第5，差2页，每页20条记录，那么就可以用：

SELECT * FROM pw_gbook WHERE uid='48'  and postdate<’2009-11-3’  ORDER BY postdate DESC LIMIT  40，20;

        看到这里明白为什么大型网站的分页不是一下标识出来完了，让都能点了吧。也不会给你一个框让你输入一个页跳过去了。如果跳的页面过多，也就存在N值过大的问题了。所以要想办法必免。

第三种：显示 “1，2，3，4，5，…. 末页” 或是 “首页，<<100,101,102,103 >>末页”

这里有一个特殊的一地方：

别的页面的跳转的上面一样。这里就加一个末页，这里又分两种情况，如果知道最后一页是多少页，也就知道了前一页的最小日期（分页提示值），这样就可以用上面的方法查看最后一页的内容（会出现不足20条的现象），另一种，我就不知道最后是第几页，我就是想看看最后什么样子，那么就可以用（一定是显示20条）：

SELECT * FROM pw_gbook WHERE uid='48' ORDER BY postdate ASC limit 20;

         首页这里就不在说了。

         具体怎么实现搞明白了，就可以做PHP代码的修改了。稍稍修改一下，就会带来意想不到的效果。

这里只是一个通用的分页处理方法。不同的业务有可能还有不同的方法处理。如果在条件可能和情况可以考用:between … and .. 带代替limit分页操作。

第三种方法：        
简单的逻辑转换。

   SELECT * FROM pw_gbook WHERE uid='48' ORDER BY postdate DESC LIMIT 1275480,20;

转换成：

   SELECT * FROM pw_gbook WHERE id>1275480 and  uid='48' ORDER BY postdate DESC LIMIT 20;

本站提供专业：PHPWIND优化，DISCUZ优化，DRUPAL优化 及相关咨询

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式：select unhex(’777562696E67786940676D61696C2E636F6D’); 载请注明作/译者和出处，并且不能用于商业用途，违者必究。
       众所周知MySQL5.1的Replication是比较烂的。MySQL的每一个版本更新关于同步方面每次都是可以看到一大堆。但MySQL 5.1性能是比较突出的。所以经不住诱惑使用MySQL 5.1。所以也要经常遇到一些Bug。如： 

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.10.118
                  Master_User: repl_wu
                  Master_Port: 3306
                Connect_Retry: 30
              Master_Log_File: mysql-bin.005121
          Read_Master_Log_Pos: 64337286
               Relay_Log_File: relay-bin.003995
                Relay_Log_Pos: 18446697137031827760
        Relay_Master_Log_File: mysql-bin.005121
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1594
                   Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 4
              Relay_Log_Space: 64337901
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1594
               Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
1 row in set (0.00 sec)
 

        从上面可以看到是中继日值或是Master上的日值出问题了。
        首先如果是中继日值坏掉，那只需要找到同步的时间点，然后重新同步，这样就可以有新的中继日值了。如果Master上的日值坏了就麻烦了。
从经验来看，这是中继日值出问题了。处理方法：

    需要找到同步的点。

日值为：Master_Log_File: mysql-bin.005121，Relay_Master_Log_File: mysql-bin.005121以Relay_Master_Log_File为准，Master_Log_File为参考。

日值执行时间点：

Exec_Master_Log_Pos: 4

那么现在就可以：

  
      mysql>stop slave;
 
    mysql>change master to Master_Log_File=’mysql-bin.005121’, Master_Log_Pos=4;
   
    mysql>start slave;
 
    mysql>show slave status\G;

    进行确认。

   建议：

    在使用MySQL-5.1.36以下的版本的同学，请尽快升级到MySQL-5.1.40 & MySQL-5.1.37sp1