山羊博客

用 Valgrind 剖析 MySQL 内存使用

Sun, 23 Jul 2017 00:00:00 +0800

前言

最近在线上遇到一个实例经常 OOM(Out Of Memory)，通过监控看，内存使用在短时间内快速上涨，最终超过 CGroup 上限。从以往经验来看，这种一般是连接数短时间内爆涨（几百~上千）导致的，因为每个连接对应 MySQL 内的一个用户线程，每个用户线程都挂了一 THD 对象用来维护上下文，以及各种 thread local cache，可能在几百 KB或者 MB 级别，但是从监控数据看最多也就几十个连接；还有一种可能是 Memory Leak，但是这种通常内存是慢慢涨上去的，不是爆涨，但是不排除这种可能。

问题分析

对于这种陌生的问题，第一个想法是能否复现（可以复现的问题都不是问题），观察了下用户的语句和表结构：

就一张表，用的是分区表，有 149 个分区，引擎是 TokuDB；
语句非常简单，都是 SELECT + ORDER BY + LIMIT，但是 Where 条件里没有指定分区字段，因此所有分区都会被访问。

根据这2个特征，线下很容易就复现出来了。

用 64 个并发线程来压测，可以看到物理内存(RSS)从 500M 左右迅速涨到 20G 左右，tokudb_cache_size 配置为 2.4G 左右。

04:14:38 PM       PID  minflt/s  majflt/s     VSZ    RSS   %MEM  Command
04:14:39 PM     32552      0.00      0.00 5255548 293956   0.06  mysqld
04:14:40 PM     32552      0.00      0.00 5255548 293956   0.06  mysqld
04:14:41 PM     32552  70980.00      0.00 6537852 568712   0.11  mysqld
04:14:42 PM     32552 2369116.00      0.00 17990268 10008148   1.89  mysqld
04:14:43 PM     32552 1347716.00      0.00 23970428 8793920   1.66  mysqld
04:14:44 PM     32552 669286.00      0.00 24920700 11250280   2.13  mysqld
04:14:45 PM     32552 1378265.00      0.00 29225596 14673244   2.77  mysqld
04:14:46 PM     32552 1164854.00      0.00 29225596 18549660   3.50  mysqld
04:14:47 PM     32552 117668.00      0.00 29225596 19010792   3.59  mysqld
04:14:48 PM     32552  30837.00      0.00 29225596 19133736   3.61  mysqld
04:14:49 PM     32552  74417.00      0.00 29225596 19422264   3.67  mysqld
04:14:50 PM     32552  32878.00      0.00 29225596 19553356   3.69  mysqld
04:14:51 PM     32552  73059.00      0.00 29225596 19836520   3.75  mysqld
04:14:52 PM     32552  32665.00      0.00 29229692 19966784   3.77  mysqld
04:14:53 PM     32552  68573.00      0.00 29545084 20232064   3.82  mysqld
04:14:54 PM     32552  33559.00      0.00 29749884 20365884   3.85  mysqld
04:14:55 PM     32552 781718.00      0.00 30765692 16992452   3.21  mysqld
04:14:56 PM     32552 1052088.00      0.00 31748732 15055824   2.84  mysqld
04:14:57 PM     32552 1137534.00      0.00 32707196 17160700   3.24  mysqld
04:14:58 PM     32552 797537.00      0.00 32707196 20223936   3.82  mysqld
04:14:59 PM     32552  10240.00      0.00 32707196 20160464   3.81  mysqld
04:15:00 PM     32552  34351.00      0.00 32707196 20116904   3.80  mysqld

Valgrind 是一个非常好用的内存检测工具，通过它我们可以快速来定位 Memory Leak 问题，我们用 valgrind --tool=memcheck 来重新启动 mysqld，然后跑复现压测，但是并没有检测到内存泄漏。

那么究竟是哪里把内存吃掉了呢？这就该本文的主角了——Massif 登场了，和 memcheck 类似，massif 也是 Valgrind 套装中一个工具，主要用来做 memory profiling：

Massif is a heap profiler. It measures how much heap memory your program uses.

用起来也比较简单 valgrind --tool=massif prog 即可，压测完后，会生成一个 massif.out.<pid> 的文件，这是一个 txt 文件，虽然可以直接打开看，但是为了更好的看结果，valgrind 提供了另一个工具 ms_print 来展示，官方认为将数据采集和展示分开，是为了将来更好更方便的对展示工具做扩展 :)

    GB
22.80^                                       :
     |                      :@@:::::@::::::#::
     |                 @@::::@ :::::@: ::::#::                     ::::::@::::
     |                 @@: ::@ :::::@: ::::#::                  :::@:::::@::::
     |                 @@: ::@ :::::@: ::::#::              @::::::@:::::@::::
     |                @@@: ::@ :::::@: ::::#::::        ::::@::::::@:::::@::::
     |                @@@: ::@ :::::@: ::::#::: :::@::::::::@::::::@:::::@::::
     |                @@@: ::@ :::::@: ::::#::: :::@::::::::@::::::@:::::@::::
     |               :@@@: ::@ :::::@: ::::#::: :::@::::::::@::::::@:::::@::::
     |    ::::::::::::@@@: ::@ :::::@: ::::#::: :::@::::::::@::::::@:::::@::::
     |    :::::: :::::@@@: ::@ :::::@: ::::#::: :::@::::::::@::::::@:::::@::::
     |    :::::: :::::@@@: ::@ :::::@: ::::#::: :::@::::::::@::::::@:::::@::::
     |    :::::: :::::@@@: ::@ :::::@: ::::#::: :::@::::::::@::::::@:::::@::::
     |    :::::: :::::@@@: ::@ :::::@: ::::#::: :::@::::::::@::::::@:::::@::::
     |  :::::::: :::::@@@: ::@ :::::@: ::::#::: :::@::::::::@::::::@:::::@::::
     | :: :::::: :::::@@@: ::@ :::::@: ::::#::: :::@::::::::@::::::@:::::@::::
     | @: :::::: :::::@@@: ::@ :::::@: ::::#::: :::@::::::::@::::::@:::::@::::
     | @: :::::: :::::@@@: ::@ :::::@: ::::#::: :::@::::::::@::::::@:::::@::::
     | @: :::::: :::::@@@: ::@ :::::@: ::::#::: :::@::::::::@::::::@:::::@::::
     | @: :::::: :::::@@@: ::@ :::::@: ::::#::: :::@::::::::@::::::@:::::@::::
   0 +----------------------------------------------------------------------->Gi
     0                                                                   281.7

Number of snapshots: 82
 Detailed snapshots: [1, 15, 16, 17, 22, 28, 34 (peak), 41, 54, 64, 74]

massif 会对程序运行过程中的内存使用做 snapshot，上图中纵坐标代表内存使用量，横坐标可以看作是一种时间单位，默认是 CPU 指令条数；图中每一列代表一次内存 snapshot，不同的字符有不同的含义，其中 : 表示一次正常的 snapshot，@ 表示一次 detailed snapshot，# 表示本次采集的峰值(peak 一定是 detailed)。

我们这里只关心 detailed snapshot，因为它包含内存使用的 stack trace 信息，通过这个我们就知道当前的内存使用，是哪些代码路径引起的。

--------------------------------------------------------------------------------
  n        time(i)         total(B)   useful-heap(B) extra-heap(B)    stacks(B)
--------------------------------------------------------------------------------
  2  8,139,138,982    7,192,367,296    7,068,742,047   123,625,249            0
  3 12,518,919,899    7,674,937,104    7,519,173,315   155,763,789            0
  4 18,630,130,824   14,528,934,960   14,433,389,357    95,545,603            0
  5 23,053,916,332   14,528,940,728   14,433,394,482    95,546,246            0
  6 28,667,255,552   14,530,496,688   14,434,920,681    95,576,007            0
  7 31,442,322,447   14,530,513,504   14,434,933,623    95,579,881            0
  8 36,910,366,437   14,530,583,456   14,434,985,999    95,597,457            0
  9 40,736,846,313   14,530,640,472   14,435,028,200    95,612,272            0
 10 46,739,261,418   14,530,667,992   14,435,049,267    95,618,725            0
 11 50,685,776,389   14,530,668,784   14,435,049,971    95,618,813            0
 12 57,194,337,509   14,530,670,152   14,435,051,187    95,618,965            0
 13 60,902,677,929   14,551,221,560   14,456,544,294    94,677,266            0
 14 65,578,137,351   15,263,985,032   15,014,333,631   249,651,401            0
 15 69,870,684,301   19,339,915,904   17,864,686,175 1,475,229,729            0
92.37% (17,864,686,175B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.92.37% (17,864,686,175B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->39.91% (7,718,060,098B) 0x973463: my_malloc (my_malloc.c:xxx)
| ->28.51% (5,513,971,756B) 0xBE989B: ha_tokudb::unpack_blobs(unsigned char*, unsigned char const*, unsigned int, bool) (hatoku_defines.h:xxx)
| | ->19.31% (3,734,605,089B) 0xCAE6BD: c_getf_set_callback(unsigned int, void const*, unsigned int, void const*, void*, bool) (ydb_cursor.cc:xxx)
| | | ->19.31% (3,734,605,089B) 0xC8B1B5: ft_cursor_search_eq_k_x_getf(unsigned int, void const*, unsigned int, void const*, void*, bool) (cursor.cc:38
2)
| | |   ->19.31% (3,734,605,089B) 0xC4A000: ft_search_node(ft_handle*, ftnode*, ft_search*, int, int (*)(unsigned int, void const*, unsigned int, void
const*, void*, bool), void*, bool*, ft_cursor*, unlockers*, ancestors*, pivot_bounds const&, bool) (ft-ops.cc:xxx)
| | |     ->19.30% (3,732,546,926B) 0xC494AA: ft_search_node(ft_handle*, ftnode*, ft_search*, int, int (*)(unsigned int, void const*, unsigned int, voi
d const*, void*, bool), void*, bool*, ft_cursor*, unlockers*, ancestors*, pivot_bounds const&, bool) (ft-ops.cc:xxx)
| | |     | ->19.30% (3,732,546,926B) 0xC494AA: ft_search_node(ft_handle*, ftnode*, ft_search*, int, int (*)(unsigned int, void const*, unsigned int, void const*, void*, bool), void*, bool*, ft_cursor*, unlockers*, ancestors*, pivot_bounds const&, bool) (ft-ops.cc:xxx)

->30.41% (5,882,175,012B) 0x9735BC: my_realloc (my_malloc.c:xxx)
| ->26.92% (5,206,093,356B) 0xBE989B: ha_tokudb::unpack_blobs(unsigned char*, unsigned char const*, unsigned int, bool) (hatoku_defines.h:xxx)
| | ->24.27% (4,693,513,693B) 0xCAE6BD: c_getf_set_callback(unsigned int, void const*, unsigned int, void const*, void*, bool) (ydb_cursor.cc:xxx)
| | | ->24.27% (4,693,513,693B) 0xC8B1B5: ft_cursor_search_eq_k_x_getf(unsigned int, void const*, unsigned int, void const*, void*, bool) (cursor.cc:xxx)
| | |   ->24.27% (4,693,513,693B) 0xC4A000: ft_search_node(ft_handle*, ftnode*, ft_search*, int, int (*)(unsigned int, void const*, unsigned int, void const*, void*, bool), void*, bool*, ft_cursor*, unlockers*, ancestors*, pivot_bounds const&, bool) (ft-ops.cc:xxx)
| | |     ->24.27% (4,693,513,693B) 0xC494AA: ft_search_node(ft_handle*, ftnode*, ft_search*, int, int (*)(unsigned int, void const*, unsigned int, void const*, void*, bool), void*, bool*, ft_cursor*, unlockers*, ancestors*, pivot_bounds const&, bool) (ft-ops.cc:xxx)

从上面的 stack trace 中可以看到，在第15个 snapshot中, 有70%+(39.91% + 30.41%) 的内存是通过 ha_tokudb::unpack_blobs 这里占用的。

这个栈的逻辑是将 TokuDB engine 返回的数据，转换成 MySQL server 层的数据格式，而在 blob 字段转换过程中，会用到临时的 buffer(blob_buf)，问题就出在这个 buffer 使用上。这个 buffer 是弹性的，但是只能往上弹，并且只有在表 close 时才会释放。

加了调试代码后，我们发现 blob_buff 非常大，平均在 2M 左右，最大可以到20M左右，每一个 TokuDB handler 都有这样的一个buffer，而用户的 sql 又会打开所有的分区表(149个)，这样一个用户连接就会占 149*2M = 298M 左右的内存，64 个连接差不多用掉 18G 左右的内存。

至此问题已经非常清楚了，一个简单的解法就是尽快释放 blob_buffer，而不是等到 close 表的时候才释放。

总结

从上面的分析过程可以看出，massif 给出内存使用信息是关键，帮助我们快速定位到内存使用大头的stack。如果没有 massif，我们可能就要在内存 malloc 的地方埋点打印信息，然后人肉汇总分析。

valgrind massif 是一个通用的工具，本文是以 MySQL 为例分享一个 case，如果有其它程序也出现内存使用异常的，也可以拿来 profiling 一把。

Tips：

massif 默认是统计 *alloc/new 这些相对来说 high level 的函数的，如果程序里用了 mmap/brk 这些函数，是不是会统计的，需要使用 --pages-as-heap=yes 这个参数开关；
stack 使用默认不会统计，--stacks=yes 可以打开，如果用了 --pages-as-heap=yes，就不需要 --stack=yes，因为已经包含了；
程序 gcc 编译参数中应该包括 -g 选项。

官方文档有详细的关于各个参数的介绍，参数并不多，在使用前建议看一看。

Have fun!

AliSQL 源码编译

Sun, 23 Oct 2016 00:00:00 +0800

前言

AliSQL 在 2016 云栖大会宣布开放源代码之后，迅速就获得了广泛的关注，目前(2016-10-23) star 数目已达 1187，欢迎访问 AliSQL GitHub 项目关注。社区反应也非常活跃，在 Issue 中提了不少反馈建议，其中有一部分是和编译安装相关的，因为官方目前并没有提供 binary，有同学可能没有 GNU/Linux 环境下编译代码的经验，导致不能直接使用。针对这个问题，本文提供一个非官方 (unofficial) 的编译指导，希望对大家有所帮助。

目前只提供使用最普遍的 GNU/Linux 发行版 Ubuntu 和 CentOS 的编译指导。

Ubuntu 16.04

编译环境准备

编译需要 gcc >= 4.7, cmake >= 2.8，16.04 apt 源里的版本 (gcc = 5.4, cmake = 3.5) 已经够用了，直接安装使用。
```
 apt-get update -y
 apt-get install git gcc g++ cmake -y
 apt-get install bison libncurses5-dev zlib1g-dev libssl-dev -y
```

从 GitHub clone 代码

 git clone https://github.com/alibaba/AliSQL.git

cmake 配置

MySQL 有非常多的 cmake 参数，大家可以参考官方这个页面，这里的配置只是个参考，大家根据需要修改：

 cmake .                              \
 -DCMAKE_BUILD_TYPE="Release"         \
 -DCMAKE_INSTALL_PREFIX="/opt/alisql" \
 -DWITH_EMBEDDED_SERVER=0             \
 -DWITH_EXTRA_CHARSETS=all            \
 -DWITH_MYISAM_STORAGE_ENGINE=1       \
 -DWITH_INNOBASE_STORAGE_ENGINE=1     \
 -DWITH_PARTITION_STORAGE_ENGINE=1    \
 -DWITH_CSV_STORAGE_ENGINE=1          \
 -DWITH_ARCHIVE_STORAGE_ENGINE=1      \
 -DWITH_BLACKHOLE_STORAGE_ENGINE=1    \
 -DWITH_FEDERATED_STORAGE_ENGINE=1    \
 -DWITH_PERFSCHEMA_STORAGE_ENGINE=1   \
 -DWITH_TOKUDB_STORAGE_ENGINE=1

编译安装
```
 make -j4 && make install
```
-j4 表示开 4 个并发编译进程，加速编译，根据机器 CPU 核数调整，一般是 CPU 核数 + 1，最终二进制安装在 /opt/alisql 目录下。

CentOS 6.8

编译环境准备

CentOS 和 Ubuntu 环境的区别就在这一步，CentOS yum 源里的 gcc 版本是 4.4 的，不满足需求，可以通过我之前介绍过的 devtoolset 来安装高版本 gcc，devtoolset 目前最新套装是 devtoolset-4，包含 gcc 5.2。
```
 yum install centos-release-scl -y
 yum install devtoolset-4-gcc-c++ devtoolset-4-gcc -y
 yum install cmake git -y
 yum install ncurses-devel openssl-devel bison -y
```

从 GitHub clone 代码

 git clone https://github.com/alibaba/AliSQL.git

cmake 配置

在配置前，要先设置下环境变量，这样才能用到 devtoolset-4 套装里的gcc。

 scl enable devtoolset-4 bash
 cmake .                              \
 -DCMAKE_BUILD_TYPE="Release"         \
 -DCMAKE_INSTALL_PREFIX="/opt/alisql" \
 -DWITH_EMBEDDED_SERVER=0             \
 -DWITH_EXTRA_CHARSETS=all            \
 -DWITH_MYISAM_STORAGE_ENGINE=1       \
 -DWITH_INNOBASE_STORAGE_ENGINE=1     \
 -DWITH_PARTITION_STORAGE_ENGINE=1    \
 -DWITH_CSV_STORAGE_ENGINE=1          \
 -DWITH_ARCHIVE_STORAGE_ENGINE=1      \
 -DWITH_BLACKHOLE_STORAGE_ENGINE=1    \
 -DWITH_FEDERATED_STORAGE_ENGINE=1    \
 -DWITH_PERFSCHEMA_STORAGE_ENGINE=1   \
 -DWITH_TOKUDB_STORAGE_ENGINE=1

编译安装
```
 make -j4 && make install
```

玩的开心 ^_^ ！

CentOS/RHEL 开发环境之 devtoolset

Sun, 13 Mar 2016 00:00:00 +0800

前言

CentOS/RHEL Linux 发行版以稳定性著称，所有的软件都要尽可能 stable，导致的一个结果就是基础软件的版本非常的低，比如 CentOS 6.7（15年发布）中 gcc 版本还是 4.4.7（12年的版本）。这对开发来说就不是很友好，比如我们想用 C++ 11 中的某个特性，就必须自己编译一个高版本的 gcc 出来，但是这会有另外一个问题，开发环境不好维护，如果自己有多台电脑或者多个人合作的项目，每台机器上都要自己编一份，维护起来就比较麻烦。

那么有没有法子像正常的安装 rpm 包一样，yum install 一个呢？有：

自己打个 rpm 包，维护个 yum 源，这个代价太大 ==!；
用别人提供的 rpm 包。

本文介绍的就是第二种，推荐 devtoolset + scl，也是绝配。

devtoolset 是由 Linux @ CERN 维护的，scl 是方便 RedHat Software Collections 软件包使用的工具。

关于 Software Collections RedHat 官方是这样介绍的：

For certain applications, more recent versions of some software components are often needed in order to use their latest new features. Red Hat Software Collections is a Red Hat offering that provides a set of dynamic programming languages, database servers, and various related packages that are either more recent than their equivalent versions included in the base Red Hat Enterprise Linux system, or are available for this system for the first time.

RedHat 推出 Software Collections 的目的就是为了解决前面说的问题，想在 RedHat 系统下能使用新版本的工具，让同一个工具（如gcc）的不同版本能在系统中共存，在需要的时候切换到对应的版本中，是不是有点像 rvm(ruby) 或者 nvm(node)呢，不过这个可是系统级别的哦，对所有软件都适用。

而 devtoolset 就是按照 Software Collections 的规范打出来的一套 rpm 包，目前的最新版本是 Developer Toolset 3.0。

看到 gcc 4.9 是不是很激动，别急，下面我们就介绍下怎么来安装和使用。

安装方法

关于 devtoolset 的安装，Software Collections 官方有一个指导，这里介绍的也差不多，只不过会更详细一些。

安装 scl-utils，yum install scl-utils，如果你的 yum 源里找不到这个包的话，可以这样

 rpm -ivh "http://vault.centos.org/6.6/updates/x86_64/Packages/scl-utils-20120927-27.el6_6.x86_64.rpm"

安装 devtoolset-3 yum 源

 rpm -ivh "https://www.softwarecollections.org/repos/rhscl/devtoolset-3/epel-6-x86_64/noarch/rhscl-devtoolset-3-epel-6-x86_64-1-2.noarch.rpm"

安装需要的 rpm 包，官方给的是 yum install devtoolset-3，这样会安装 devtoolset-3 源里的所有 rpm 包，完全没必要，如果我们需要 gcc 的话，只需要这样：
```
 yum install devtoolset-3-gcc devtoolset-3-gcc-c++ devtoolset-3-gdb
```
激活 devtoolset-3
```
 scl enable devtoolset-3 bash
```
然后 gcc --version 就会看到已经变成 4.9 啦，或者可以这样
```
 scl enable devtoolset-3 "gcc --version"
```

关于使用，这里多说一点，scl-utils 只是方便 Software Collections 使用，比如要查看当前安装了哪些 Software Collections，可以 scl --list，我们其实可以安全不用这个工具。devtoolset-3 中的 gcc 安装在 /opt/rh/devtoolset-3/root/usr/bin/gcc，我们可以

export CC=/opt/rh/devtoolset-3/root/usr/bin/gcc

或者直接 source 环境变量

source /opt/rh/devtoolset-3/enable

scl enable 命令也是 source 这个 enable 文件，只不是临时的，只对对当前命令有效。

Software Collections 官网除了 devtoolset-3 外，还有大把其它的 collections，如 ruby2.2、python3.4 等，有需要的自己安装，方法和 devtoolset-3 差不多。

玩的开心 ^_^ ！

Optimize MyISAM 表导致索引文件损坏

Thu, 25 Feb 2016 00:00:00 +0800

前言

最近线上遇到一个问题，用户对表执行了 Optimize 后，发现数据都不见了，select count(*) xxx 返回值为 0。在了解了用户的场景后，本地复现了下，确实是这样，如下：

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|    10230 |
+----------+
1 row in set (0.00 sec)

mysql> optimize table t1;
+---------+----------+----------+--------------------------------------+
| Table   | Op       | Msg_type | Msg_text                             |
+---------+----------+----------+--------------------------------------+
| test.t1 | optimize | error    | myisam_sort_buffer_size is too small |
| test.t1 | optimize | status   | OK                                   |
+---------+----------+----------+--------------------------------------+
2 rows in set (0.00 sec)

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)

通过观察文件变化，可以快速确认的是索引文件坏掉了。在 Optimize 之前，文件大小和 MD5 如下：

$du -s test/t1.*
12      test/t1.frm
1924    test/t1.MYD
216     test/t1.MYI

$md5sum test/t1.*
b1da352c2ba355f940e26bd57e1a9f48  test/t1.frm
46785a243dec91f4df9601921d6d801d  test/t1.MYD
313d82d2960dae4a0e58594d2f1c97e1  test/t1.MYI

Optimize 之后：

$du -s test/t1.*
12      test/t1.frm
1924    test/t1.MYD
4       test/t1.MYI

$md5sum test/t1.*
b1da352c2ba355f940e26bd57e1a9f48  test/t1.frm
46785a243dec91f4df9601921d6d801d  test/t1.MYD
e739452f3313de04af12e5d38d1b4661  test/t1.MYI

bug 分析

有了复现 case 后，查问题就不难了，整个代码中报 “myisam_sort_buffer_size is too smal” 这个错的只有 2 处，掏出 gdb 全都加上断点。

代码用的是目前最新的 5.6.29 版本，堆栈如下：

#0  _create_index_by_sort() at mysql-server/storage/myisam/sort.c:156
#1  mi_repair_by_sort() at mysql-server/storage/myisam/mi_check.c:2436
#2  ha_myisam::repair() at mysql-server/storage/myisam/ha_myisam.cc:1101
#3  ha_myisam::optimize() at mysql-server/storage/myisam/ha_myisam.cc:1015
#4  handler::ha_optimize() at mysql-server/sql/handler.cc:4270
#5  mysql_admin_table() at mysql-server/sql/sql_admin.cc:648
#6  Sql_cmd_optimize_table::execute() at mysql-server/sql/sql_admin.cc:1126
#7  mysql_execute_command() at mysql-server/sql/sql_parse.cc:4975
#8  mysql_parse() at mysql-server/sql/sql_parse.cc:6385
#9  dispatch_command() at mysql-server/sql/sql_parse.cc:1339
...

Optimize 实际是通过 repair 表来实现的，这里 MySQL 判断需要通过排序的方式来做 repair，但是在 _craete_index_by_sort() 中因为 myisam_sort_buffer_size 设置的 buffer 空间太小，就返回错误了，然后 mi_repair_by_sort 设置 param->retry_repair=1，表示再做一次 repair。重试逻辑在 ha_myisam.cc:1015：

if ((error= repair(thd,param,1)) && param.retry_repair)
{
  sql_print_warning("Warning: Optimize table got errno %d on %s.%s, retrying",
                    my_errno, param.db_name, param.table_name);
  param.testflag&= ~T_REP_BY_SORT;
  error= repair(thd,param,1);
}

索引文件损坏就在第二次 repair 过程中，stack 如下：

#0  mi_sort_index () at mysql-server/storage/myisam/mi_check.c:1986
#1  ha_myisam::repair () at mysql-server/storage/myisam/ha_myisam.cc:1125
#2  ha_myisam::optimize () at mysql-server/storage/myisam/ha_myisam.cc:1020
#3  handler::ha_optimize () at mysql-server/sql/handler.cc:4270
#4  mysql_admin_table () at mysql-server/sql/sql_admin.cc:648
#5  Sql_cmd_optimize_table::execute () at mysql-server/sql/sql_admin.cc:1126
#6  mysql_execute_command () at mysql-server/sql/sql_parse.cc:4975
#7  mysql_parse () at mysql-server/sql/sql_parse.cc:6385
#8  dispatch_command () at mysql-server/sql/sql_parse.cc:1339
...

在 mi_sort_index() 中会重建索引，但是在第一次 repairt 时，会调用 mi_drop_all_indexes() 将所有的删掉，state->key_del[i]= HA_OFFSET_ERROR;，所以 mi_sort_index() 中重建索引时，会跳过所有的 index，导致新生成的索引文件是空的，代码在 mi_check.cc:1986：

  if (share->state.key_root[key] != HA_OFFSET_ERROR)
  {
    index_pos[key]=param->new_file_pos;       /* Write first block here */
    if (sort_one_index(param,info,keyinfo,share->state.key_root[key],
                       new_file))
      goto err;
  }

总结

这个 bug 已经提给官方了，见 #80503。在分析 bug 之前，我先 Google 了一把，发现 12 年就有人发现了这个 bug，还是 5.1 版本的，不过有意思的是作为系统的 bug 提给了 Debian 社区，而不是给 MySQL 社区。

官方对 MyISAM 引擎已经基本放弃冶疗了，所以这个 bug 估计也不太会修，即使修的话也比较慢。

在 bug 修复之前，如果遇到这个问题，可以采用下面的 workaround：

optimize 出现问题后，通过 repair table xxx 先把表索引修好；
调大 myisam_sort_buffer_size 的值，确保后续的 optimize 不会出问题。

MyISAM 引擎注定是要被时代抛弃的，不安全、不能并发插入（一个例外是 Concurrent Inserts）、表级锁等等，另外 InnoDB 的读性能早就超过了 MyISAM，引用2张官方性能对比的图来看吧：

InnoDB 比 MyISAM 快了 3-6 倍！

快点抛弃 MyISAM 吧 ^_^

Percona XtraBackup 介绍

Sat, 14 Nov 2015 00:00:00 +0800

前言

Percona XtraBackup 是 Percona 公司开发的一个用于 MySQL 数据库物理热备的备份工具，支持 MySQl（Oracle）、Percona Server 和 MariaDB，并且全部开源，真可谓是业界良心。

项目的 blueprint 和 bug 讨论放在 Launchpad，之前代码也放在 Launchpad 用 Bazzar 管理，现在已经迁移到 Github 啦，项目更新发布非常快，感兴趣的可以关注 :-)

真是一脸傲骄的 Lion。。。

功能支持

Percona XtraBackup 可以说是业内最成熟流行的、开源的 MySQL 物理热备工具，提供了一套完备的备份方案。

对引擎的支持

首先明确下热备的概念，最基本的要求就是不需要 shutdown mysqld 进程，再进一步的是不能影响数据库的正常使用。

InnoDB/XtraDB 引擎，完全的热备，不影响用户对引擎的使用，备份过程中可读写；
非 InnoDB 引擎，如 MyISAM、Merge、Archive 和 CSV等，不完全的热备，虽然备份不需要关闭 mysqld 进程，但是会加全局读锁，备份过程中用户连接只能读不能写；
TokuDB 引擎，相对于 MyISAM 和 InnoDB，这个引擎可以说是后起之秀，数据文件高压缩，节省空间，并且支持事务，目前 XtraBackup 并不支持对 TokuDB 表的备份。在今年4月份的时候，Percona 收购了 Tokutex 公司，现在 TokuDB 已归 Percona 所有，最近 Percona 又将 TokuDB 的热备工具开源，再一次称赞下业界良心，相信下一步就是集成进 Percona-XtraBackup，大家可以期待下 :-)

备份类型的支持

XtraBackup 提供了不同的备份方式：

全备，全库全量备份，这种备份相当于对数据库做一个快照，这种方式比较常用；
增量备份，也是全库备份，但备的是增量数据。增量备份不能单独使用，要和全量结合使用，可以有多个增量。增量备份的一个明显优势是节省空间，用户可以制定适合自己的备份策略，如全增增（1天全量、1天增量和1天增量）周期；
部分备份，和全库备份对应，只备部分库或者部分表。如果觉得全库备份代价较大或者没必要，用户可以只备自己比较关心的表。

备份速度

物理备份是直接拷贝文件，相对于逻辑备份已经很快了，XtraBackup 还提供了对备份速度的控制功能。

加速，默认是单线程备份的，可以开并发来加快拷贝速度，并发数由用户指定；
限速，虽然备份不会影响 mysqld 进程，但是备份依然耗系统的资源，如果备份压力太大，会间接影响 mysqld。拷贝文件最耗的资源 IO，XtraBackup 提供了 IOPS 限制功能。

加速和限速只对 InnoDB 表的备份起作用，MyISAM 表备份都是单线程不限速的。

其它功能

还有一些其它比较好用的功能，如压缩、流式输出、加密等，关于 XtraBackup 的详细功能支持，可以参考官方介绍。

工具使用

是不是迫不及待的想试试了，下面看看怎么玩。

安装

XtraBackup 目前只支持 GNU/Linux 平台，所以得先有一个 Linux 机器。

官方发行版提供了 deb 包、rpm 包和全 Linux 平台通用的二进制压缩包，可以直接从官网下载最新的进行安装。

官方还提供了 yum 源和 apt 源，Debian 系和 Red Hat 系可以配置下源，直接用包管理命令安装，参见官方指导;

因为 XtraBackup 是开源的，所以我们可以自己编译，这对于需要自己增加功能的同学来说是必须的，还是看官方指导

我后面会写一篇关于 XtraBackup 开发的文章 :-)

命令说明

安装完后一共有4个二进行文件，如下：

usr
├── bin
│   ├── innobackupex
│   ├── xbcrypt
│   ├── xbstream
│   └── xtrabackup

最主要的是 innobackupex 和 xtrabackup，前者是一个 perl 脚本，后者是 C 编译出的二进制。

xtrabackup 是用来备份 InnoDB 表的，不能备份非 InnoDB 表，和 mysqld server 没有交互；innobackupex 脚本用来备份非 InnoDB 表，同时会调用 xtrabackup 命令来备份 InnoDB 表，还会和 mysqld server 发送命令进行交互，如加读锁（FTWRL）、获取位点（SHOW SLAVE STATUS）等。

一般来说，我们是希望能备份 MyISAM 表的，虽然我们可能自己不用 MyISAM 表，但是 mysql 库下的系统表是 MyISAM 的，因此备份基本都通过 innobackupex 命令进行；另外一个原因是我们可能需要保存位点信息。

另外2个命令相对小众些，xbcrypt 是加解密用的；xbstream 类似于tar，是 Percona 自己实现的一种支持并发写的流文件格式。两都在备份和解压时都会用到（如果备份用了加密和并发）。

常用命令姿势

XtraBackup 的使用，简单来说就是三板斧——备份、还原、恢复，简单好用。

在使用前要注意下权限问题，这里有2个权限，一个是操作系统用户的权限，能写文件就行了；另一个是 mysql 用户的权限，具体需要哪些权限参考官网。

备份默认情况下备份是在指定的 backup-dir 目录下创建一个时间戳目录，然后备份集写入到时间目录下：
```
 innobackupex --host=127.0.0.1 --port=3306 --user=root --password=123456 --defaults-file=/etc/my.cnf backup-dir
```
也可以通过流方式输出到标准输出，然后就可以在 Linux 下通过管道任意发挥了，如：
```
 innobackupex --host=127.0.0.1 --port=3306 --user=root --password=123456 --defaults-file=/etc/my.cnf --stream=tar backup-dir | gzip > backup.tar.gz
```
上面的命令备出来是一个 tar.gz 压缩包，解压时要用 tar izxvf 参数（千万不能少了i）。也可以管道到 nc 命令，将备份通过网络传走。 Imagination is the only boundary!
还原备份集是不能直接用的，要先用工具还原才能使用。如果备份到压缩包的话，要先解压到目录，才能还原。恢复是用 --apply-log 参数，另外恢复时强烈推荐加 --use-memory ，因为恢复会启动一个 innodb 引擎，这个参数指定的就是 innodb_buffer_pool_size 的大小, 默认是100M，如果备份集中 redo log 比较大的话，设置较大的 use-memory 可以显著提高恢复速度。
```
 innobackupex --defaults-file=/etc/my.cnf --use-memory=4G --apply-log backup-dir
```
恢复恢复就是把还原好的备份集拷贝到对应 mysqld 的数据目录，首先要用一个空的 mysqld 目标目录，并且提供相应的 my.cnf。innobackupex 提供了2个好用的参数，可以根据 my.cnf 中的目录配置，把备份集目录里的数据拷贝/移动到对应目标目录。
```
 innobackupex --defaults-file=/etc/my.cnf --copy-back backup-dir
```
或者
```
 innobackupex --defaults-file=/etc/my.cnf --move-back backup-dir
```

OH Mac!!!

Mon, 25 May 2015 00:00:00 +0800

哪个程序猿不想要一台Mac呢。

最近把 Miss Lou 的 Mac Air 霸占了，又回到 *nix 的世界了 ^_^ !!!

上一遍文章还是去年10月份，一年没更新了，真是被自己的懒折服了。。。

现在有了 Mac，再也不能因为环境的原因不去更新了。

折腾了一年的 MySQL，也算小小地入门，后面应该会更新很多 MySQL 相关的文章。

Let’s play!

Hello World, Jekyll!

Sat, 25 Oct 2014 00:00:00 +0800

终于把博客换成 Jekyll 了，新的记录，新的开始。

旧的博客放在老山羊博客，不在更新。

Markdown, Gentoo, Emacs, MySQL, Let’s PLAY!