新功能 问题描述(Bug #18871046, Bug #72811)： 主要为了解决一个比较“古老”的MySQL在NUMA架构下的“swap insanity”问题，其表现为尽管为InnoDB buffer pool分配了足够多的内存，但依然会产生swap。而swap对数据库系统性能而言是比较致命的。 当我们配置的buffer pool超过单个node的内存时，例如总共64GB内存，每个节点32GB，分配buffer pool为40GB，默认情况下，会先用满node 0，再在node1上分配8GB内存。如果绑定到node 0上的线程需要申请新的内存时，不是从node1上申请（还有24GB空余），而是swap node0的内存，再做申请。 这个问题在社区讨论了很久，大神Jeremy Cole 对该问题有写博客做过详细的介绍（http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/） 解决： …

最近Percona的研发人员report了一个uk corruption的bug，这个Bug不同于之前发现的bug（见我的另外一篇博客http://mysqllover.com/?p=1041），而是影响从5.1 到5.8全系列MySQL版本，应该算是设计上的缺陷吧。 创建测试表 CREATE TABLE t1 ( a INT NOT NULL, b INT NOT NULL, PRIMARY KEY(b), UNIQUE KEY(a)) ENGINE=INNODB; INSERT INTO t1 VALUES (1,1),(2,2);   0. 停止Purge操作：SET GLOBAL innodb_purge_stop_now = ON; 防止标记删除的记录被purge掉 删除表上的数据：DELETE FROM t1;  //这时候表上物理记录还存在，只是被标记删除了。 1. SESSION 1: REPLACE INTO t1 VALUES (1,2); 由于有一条标记删除的记录，检查pk上duplicate key，在聚集索引上加锁：mode=1027 (1024 +3 = LOCK_REC_NOT_GAP | LOCK_X) 堆栈： row_ins_clust_index_entry […]

Tags:  

问题背景 今天，看到Twitter的DBA团队发布了其最新的MySQL分支：Changes in Twitter MySQL 5.5.28.t9，此分支最重要的一个改进，就是修复了MySQL 的Bug #67718：InnoDB drastically under-fills pages in certain conditions。关于此Bug的详细描述，以及如何重现此问题，可以阅读以上的Bug链接，以下简单描述下此Bug对应的问题：   InnoDB的索引分裂策略，在特定的情况下，索引页面的分裂存在问题，导致每个分裂出来的页面，仅仅存储一条记录，页面的空间利用率极低。   此Bug引起了我的兴趣，因此准备跟大家简单聊聊B+树索引的结构、B+树的分裂、B+树分裂操作的优化、Bug #67718的成因，以及个人对如何修复此Bug的一些建议等。   B+树索引结构 …

Bug现象描述 master为MySQL 5.5.20，slave用MySQL 5.1.49挂起，然后slave执行以下命令： change master to master_host=’127.0.0.1′, master_user=’backup’, master_password=’1234′, master_port=3306, master_log_file=’mysql-bin.000009′, master_log_pos=***; 若master_log_pos指定的位置出错，则master直接崩溃退出。 重现环境搭建 启动数据库(主库) D:\mysql\mydata12\master-bin\mysqld.exe –defaults-file=”D:\mysql\mydata12\master-bin\my.ini” 登录数据库(主库) D:\tnt0326\Src\client\Debug\mysql.exe –defaults-file=”D:\mysql\mydata12\master-bin\my.ini” –uroot grant replication slave,replication client on *.* to backup@127.0.0.1 identified by ’1234′; show master status \G 启动数据库(备库) MySQL 5.5.20 … 继续阅读 →

MySQL Bug 65745分析 BUG描述 MySQL 5.5.25，5.5.26版本，一个更新单行的操作，有可能存在死循环，一直持续更新，直至耗尽磁盘空间。详细的BUG描述及重新脚本，见下面的网址：http://bugs.mysql.com/bug.php?id=65745 接下来，本文将分步骤，详细分析此BUG的执行流程，以及产生此BUG的内在原因。 处理流程 – MySQL 5.5.25 判断出id1索引与primary key索引均以id1列开始，因此是一个 Rowid Ordered Retrieval (ROR) 2. ROR查询流程，首先根据查询条件(a is null and id1 = 2)，构造一个查询的range minkey[2,null], maxkey[2,null] 函数处理流程：     opt_range.cc::get_quick_keys();         range = new QUICK_RANGE();         insert_dynamic(&quick->ranges, (uchar*)&range); 3. …