MySQL 5.5.8 GA版本发布

在这几天的OOW上没怎么听到MySQL的消息,session少而且很多讲师是sales,忽悠成份居多。倒是今天一大早在Google Reader上看到MySQL5.5.8 GA版本发布了,真是期待了很久的消息。当然,官方网站上宣传的在windows性能提升540%,在Linux上性能提升370%,未必有那么靠谱,尤其是已经使用了innodb plugin的,那这么高的性能提升就更是浮云了。

但是,MySQL5.5还是有很多值得期待的特性,其中比较吸引人的,像semi-replication,replication heartbeat,以及partition的可用性提升等。MySQL5.5.8已经将Innodb Plugin1.1.4版本做为内建的Innodb引擎。

MySQL5.5.8源代码编译工具在Linux平台放弃了autotool,而是采用了跨平台的cmake。因此从源代码编译的过程有些不一样。如果系统中没有cmake,还需要先安装:

sudo apt-get install cmake
tar zxvf mysql-5.5.8.tar.gz
cd mysql-5.5.8

CFLAGS="-O3 -g" 
CXX=gcc 
CXXFLAGS="-O3 -g -felide-constructors -fno-exceptions -fno-rtti"
export CFLAGS CXX CXXFLAGS
cmake -DCMAKE_INSTALL_PREFIX=/opt/mysql -DSYSCONFDIR=/opt/mysql

make -j 2
make install

关于MySQL5.5.8更多cmake选项,请参考文档

淘宝网招聘MySQL数据库工程师

我不是HR,只是一个普通的技术人员,下面也不是标准的JD,只是我想到的一些要点,如果你能满足其中大部分要求,如果你对运维几百台上千台MySQL数据库有兴趣,如果你对研究MySQL源码有野心,如果你对PostgreSQL有研究,如果你对NoSQL有好奇,请给我简历 jiangfeng#taobao.com 或者 seaman.ning#gmail.com (请将其中的#替换成@),电话初面,合则约见。工作地点可以是杭州或者北京。

如需要进一步了解相关信息,欢迎在twitter或者新浪微博私信给我。

MySQL开发工程师(开发或者修改MySQL相关patch):
1. 对Linux很熟悉,如果有内核hack经验更佳
2. 对c/c++很熟悉,至少写过几千行Linux下的c/c++代码
3. 熟悉gdb调试工具,能debug程序问题
4. 熟悉关系数据库基本原理,了解MySQL/PostgreSQL数据库
5. 熟悉多线程和网络编程
6. 痴迷技术,热爱折腾

MySQL DBA
1. 对Linux很熟悉,会编译内核,了解ext3/xfs/ext4等文件系统
2. 了解c/c++或者java,有过实际编码经验尤佳
3. 熟悉MySQL或者PostgreSQL,有100台以上规模数据库运维经验更佳
4. 熟悉shell/perl/python等脚本语言中的一种,善于利用脚本解决重复问题
5. 痴迷技术,热爱折腾

PostgreSQL简介

上个周末,无聊的时候关注了一下PostgreSQL。第一次尝试去安装PostgreSQL,还是好几年前的事了,那是8.0版本刚出来,终于开始原生的支持windows了,所以在自己电脑上折腾了一个。不过那时候也仅限于安装了一次而已,甚至psql的命令行都不知道怎么用。

同样作为开源关系型数据库,MySQL在这几年获得了更多的关注。大量的互联网公司都基于MySQL来构架系统,也导致MySQL DBA开始火热,一大堆年轻有为的同学投入到其中,渐成燎原之势。MySQL数据库火热了,MySQL AB公司却被sun收购,现在又随着sun要投入Oracle的怀抱,而且欧盟已经无条件批准这个收购,只剩下中国和俄罗斯,大局已定。作为商业数据库的绝对老大,Oracle的这次收购,让MySQL的支持者感到了威胁,其创始人甚至发起了一场保护MySQL(有墙),阻击Oracle收购的运动。

这也是PostgreSQL的机会,最近PostgreSQL的开发节奏很快,8.5已经连续出到了alpha3版,在这个版本中,最吸引我的是hot standby,类似于Oracle11g的active data guard,hot standby也可以在恢复的同时提供读服务,而以往版本,PostgreSQL的物理备库warm standby,则只能处于恢复状态,一旦open,则需要重做,比较痛苦。PostgreSQL的很多特性,都和Oracle相当的类似,甚至有一家商业化的公司EnterpriseDB,在致力于将PostgreSQL打包,使得应用程序从Oracle迁移到PostgreSQL更方便,据说80%的Oracle应用代码甚至不需要做修改就能在PostgreSQL运行。因此,我在twitter上说,如果PostgreSQL在人机交互的工具和配置部分,能够更加友好一点,完全是一个影子版本的Oracle。

PostgreSQL也支持mvcc多版本一致性控制。不过其实现的机制和Oracle的不一样。Oracle是将变化的前映像记录到单独的undo段中,而PostgreSQL则只是将前映像(Tuples)上做个标记,如果是delete,则相当于是逻辑删除,实际的数据还是在原来的段中,如果是insert,相当于先delete,再insert,而且会在原来的记录上加一条指向新记录的指针,形成一个链表,查询的时候需要沿着这个链表找到一致的数据。这样会造成一个问题,一段时间以后,dml操作使得数据段和索引段中都有大量的前映像信息存在,会严重影响数据查询的效率。PostgreSQL的mvcc的这种实现方式,带来的一个好处是回滚非常快,只需要修改前映像上的几个标志位即可,而不像oracle需要从undo段将前映像再复制回来。但是,这种方便回滚,却会损失查询性能的设计思路,真的比较诡异。PostgreSQL中有一个专门用来清理这些旧版本数据的程序,叫做vacuum。在以前的版本中,需要定期执行vacuum来优化数据存储结构。这对于DBA来说,无疑是一件痛苦的事情。直到8.1版本,引入了autovacuum,系统可以自动来进行这些清理工作,终于人性化了一点点。

在8.3版本,引入了一个新的特性HOT(Heap Only Tuples),主要的目的是努力避免update造成的性能低下的问题。其实这个HOT,说白了很简单,对于update,要实现mvcc,其机制还是一样的,区别在于select,在沿着链表找一致性数据的过程中,如果发现这个检查过的版本已经没有任何事物在引用了,就会顺便把清理工作做掉,而不是像以前要等vacuum来做。因此这会加大一点select的压力,但前人栽树,后人乘凉,接下来需要访问这些数据的其他select就会快很多了,这和Oracle的延迟块清除其实有些类似的,当然两者的设计目的并不一样。

遭遇MySQL Replication Fatal Error 1236

一套Master-Master Replication的MySQL集群,版本5.1.37。其中一个节点A出现OS异常重启,数据库启动后表现正常。但是没过多久另外一个节点B报错:

091127 21:50:21 [ERROR] Error reading packet from server: Client requested master to start replication 
from impossible position ( server_errno=1236)
091127 21:50:21 [ERROR] Got fatal error 1236: 'Client requested master to start replication 
from impossible position' from master when reading data from binary log
091127 21:50:21 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000535', position 193022771

Slave_IO_Running线程终止。仔细看上面的报错信息,说slave进程试图从mysql-bin.000535日志的position 193022771开始启动恢复,但是该日志中是没有这个position的。

跑到A上通过mysqlbinlog查看该日志,发现最后一个有效position是193009460。而要求的193022771已经大于最后有效的position了。这个原因就搞不明白了,难道是因为A库异常关闭后导致A节点的binlog没有来得及刷到磁盘,而B节点slave已经恢复到前面去了?

$mysqlbinlog mysql-bin.000535 > 1.txt

$tail -n 7 1.txt
# at 193009460
#091127 20:50:21 server id 1  end_log_pos 193009487     Xid = 194299849
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

尝试将B节点change master到最后一个有效的position处,问题暂时得到解决:

change master to master_log_file='mysql-bin.000535', master_log_pos=193009460

网上搜索了一把,发现logzgh之前也碰到过同样的问题,版本是5.0.51。

无觅相关文章插件,快速提升流量