MySQL 服務器設置的 binlog 單文件最大為 1GB，偶然發現會有十幾 GB 大小的 binlog 文件，從產生的時間上看像是某個 cron job 使用了超大的 transaction，為了找出“罪魁禍首”，我需要分析一下 binlog。
在使用 mysqlbinlog 將 binary log 轉換為文本文件時，發現根分區很快就被塞滿了，使用 lsof 發現 mysqlbinlog 在往 /tmp 下寫臨時文件：
# lsof -p 17423
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mysqlbinl 17423 root 1w REG 0,19 791765366 3186036 /mfs/user/xupeng/tmp/bigbinlogs/bigbinlog.sql
mysqlbinl 17423 root 2u CHR 136,7 0t0 10 /dev/pts/7
mysqlbinl 17423 root 3r REG 0,19 13863171331 3172073 /mfs/user/xupeng/tmp/bigbinlogs/log.000323
mysqlbinl 17423 root 4u REG 8,1 612122624 135332782 /tmp/tmp.rWTNda (deleted)
mysqlbinl 17423 root 5u REG 8,1 2490368 135332784 /tmp/tmp.spKjTA (deleted)
看 mysqlbinlog 的 Man page，發現並沒有參數可以指定臨時目錄，翻了一下 mysqlbinlog (client/mysqlbinlog.cc) 的代碼，看到了下面的代碼：
MY_TMPDIR tmpdir;
tmpdir.list= 0;
if (!dirname_for_local_load)
{
if (init_tmpdir(&tmpdir, 0))
exit(1);
dirname_for_local_load= my_strdup(my_tmpdir(&tmpdir), MY_WME);
}
init_tmpdir 定義在 mysys/mf_tempdir.c 中：
my_bool init_tmpdir(MY_TMPDIR *tmpdir, const char *pathlist)
{
char *end, *copy;
char buff[FN_REFLEN];
DBUG_ENTER(“init_tmpdir”);
DBUG_PRINT(“enter”, (“pathlist: %s”, pathlist ? pathlist : “NULL”));
pthread_mutex_init(&tmpdir->mutex, MY_MUTEX_INIT_FAST);
if (my_init_dynamic_array(&tmpdir->full_list, sizeof(char*), 1, 5))
goto err;
if (!pathlist || !pathlist[0])
{
/* Get default temporary directory */
pathlist=getenv(“TMPDIR”); /* Use this if possible */
#if defined( __WIN__) || defined(__NETWARE__)
if (!pathlist)
pathlist=getenv(“TEMP”);
if (!pathlist)
pathlist=getenv(“TMP”);
#endif
if (!pathlist || !pathlist[0])
pathlist=(char*) P_tmpdir;
}
所以在運行 mysqlbinlog 之前設置 TMPDIR 這個環境變量就好了。
MySQL server 和 客戶端工具都使用這個臨時目錄查找策略，怪不得使用 mysqlbinlog tmp directory 作為關鍵詞沒有搜到需要的結果，而使用 mysql tmp directory 作為關鍵詞，第一條搜索結果就是 Where MySQL Stores Temporary Files，選擇正確的關鍵詞很重要啊。
