月度归档:2013年08月

[MySQL FAQ]系列 — slow log中出现大量的binlog dump记录

线上有个数据库,在slow log中,存在大量类似下面的记录:

# Time: 130823 13:56:08
# User@Host: repl[repl] @ slave [10.x.x.x]
# Query_time: 9.000833 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 1
SET timestamp=1377237368;
# administrator command: Binlog Dump;

每完成一次binlog dump都会被记录下来,看着非常不爽(我有强迫症,O(∩_∩)O哈哈~),得想着法子搞掉。
经过排查,最后确认是特定版本存在这个现象,目前发现官方 5.1.49 存在,估计整个官方 5.1.x 都会有这个现象。

解决方法:
修改 my.cnf 配置文件,增加或修改下面这个选项:

log-slow-admin-statements = 0

比较坑人的是,这个选项在5.1无法在线修改,需要重启mysqld。
手册上关于这个选项的解释如下:

Include slow administrative statements in the statements written to the slow query log. Administrative statements include ALTER TABLE, ANALYZE TABLE, CHECK TABLE, CREATE INDEX, DROP INDEX, OPTIMIZE TABLE, and REPAIR TABLE.

手册也有不靠谱的时候啊,还是实践出真知。

InnoDB memcached插件vs原生memcached对比性能测试

MySQL 5.6开始支持InnoDB memcached插件,也就是可以通过SQL高效读写memcached里的缓存内容,也支持用原生的memcache协议读写,并且可以实现缓存数据持久化,以及crash recovery、mysql replication、触发器、存储过程等众多特性,详细介绍可以查看:Benefits of the InnoDB / memcached Combination。看起来非常诱人,那就测试下看看吧,是驴子是马拉出来溜溜便知。

  • 环境准备
测试机 DELL PE R710
CPU E5620  @ 2.40GHz(4 core, 8 threads, L3 Cache 12 MB) * 2
内存 48G(8G * 6)
RAID卡 PERC H700 Integrated, 512MB, BBU, 12.10.1-0001
系统 Red Hat Enterprise Linux Server release 6.4 (Santiago)
内核 2.6.32-358.el6.x86_64 #1 SMP
raid级别 raid 5(10K RPM SAS 300G * 6)
文件系统 xfs
硬盘 10K RPM SAS 300G * 6, 1 hotspare
  • 测试方案
方案一 server端运行InnoDB MC,本地/远程调用memslap执行benchmark
方案二 server端运行Native MC,本地/远程调用memslap执行benchmark
  • 测试脚本
cat memslap_run.sh
#!/bin/sh

. ~/.bash_profile > /dev/null 2>&1

cd /home/mc-bench

exec 3>&1 4>&2 1>> memcache_memslap_${RANDOM}.log 2>&1

#不断循环
while [ 1 ]
do
#并发线程数 4 ~ 256
for THREAD in 4 8 16 32 64 128 256
do

#每种并发测试5次
count=1
max=5
while [ $count -le ${max} ]
do
#取样
echo "memstat"
memstat

# --flush 每次测试完毕钱,都先清空数据
# --binary 采用binary模式
# 初始化数据: 5000000, 每个并发线程存取数据量: 100000
# 并发256线程时, 总数据量可达 30,600,000
# 未指定 --test 选项,默认是进行 set 测试
memslap --server=mc_server:11211 --concurrency=${THREAD} --execute-number=100000 --initial-load=5000000 --flush --binary

count=`expr ${count} + 1`

#每次测试完毕后,都休息2分钟,等待服务器恢复空负载
if [ ${count} -lt ${max} ] ; then
 sleep 120
fi
echo ""
echo ""
done
done
done
  • 测试结果

1. 写MC

               线程数
耗时
256 128 64 32 16 8 4
NativeMC(单位:1秒) 104.315 47.646 24.486 12.162 6.351 5.525 5.078
InnoDBMC(单位:100秒) 339.1431 68.11128 27.67265 11.26917 4.968556 2.24988 1.104334

直接以曲线图方式对比:

 

nativemc-vs-innodbmc-benchmark-02-set-result-20130828

nativemc-vs-innodbmc-benchmark-02-set-result-20130828

2. 读MC

        线程数
耗时
4线程并发,2千万记录
本地Native MC 198.5016
本地InnoDB MC 327.239
远程Native MC 846.286
远程InnoDB MC 912.467

曲线图方式对比:

nativemc-vs-innodbmc-benchmark-03-get-result-20130828

nativemc-vs-innodbmc-benchmark-03-get-result-20130828

  • 结论

InnoDB MC看起来很美好,现实很骨感,其并发4线程写数据需呀的耗时,和原生memcached的256线程相当,差的不是一丁半点啊,还有很大优化空间。

而如果是缓存只读,InnoDB MC本地读取的效率大概是原生memcached的2/3,如果是远程读取,则相当于是本地读取效率的1/4 ~ 1/3。

  • 建议应用场景

鉴于上面的测试结果,建议将InnoDB MC这么来用:

1. 数据写入通过触发器(trigger)或者调度器(event scheduler)将待缓存数据同步到InnoDB MC缓存表中;

2. 以memcache API方式,通过本地/远程读取InnoDB MC中的缓存记录;

3. 尽可能减少通过远程方式往InnoDB MC写缓存数据;

从国内向海外转移域名经验谈

本站的域名imysql.com最早是从一位网友手里买来的,当时我还是国内”注明”的域名注册商X资源的代理商(历史原因,别人注册的代理权转给我),因此就将该域名从海外转回国内托管。

随着手头域名的减少,我这个代理商的注册/续费价格也水涨船高,于是打算转入我在moniker.com的账号里。

  • 步骤一:申请转出

在X资源代理商管理后台,选择”客户服务” => “有问必答”,提交相应的域名转出申请,例如:

主题:xxx.com 域名申请转出
问题分类:业务问题
问题描述:xxx.com 域名申请转出,域名相关资料已发往6651@114.com.cn邮箱。

之后如果没问题,国内托管商就会把域名转出码发到你的注册邮箱中,就可以继续后面的流程了。

这里需要注意几点,在X资源想要申请域名转出,有几个所谓的限制条件:

①必须是在厦门X资源网络服务有限公司申请的国际域名。
②域名转出时距离域名到期日不能小于15天。
③域名必须在注册生效后60天才可以提出申请转出。

除此外,他们还给客户挖坑,如果你的域名资料修改过,按照他们所谓的协议,在3年内不得转出,为了这个事情,我和X资源田姓客服代表吵了几次,也打400电话投诉她。我特么的花了钱,虽然不多吧,但让我每次接电话都感觉像是在挨训,说话口气特别横,就这种服务态度和破限制条件,没几个人愿意把域名放在它们上面的。

  • 步骤二:申请转入

以moniker.com(不好意思,我不是托,只是我在海外的域名注册商是它,它们的客服代表服务非常好,而且有可以说汉语的马来西亚华裔哦,挺方便的)为例,它们的官网上也有操作说明,下面中文的操作说明案例:Moniker教程:将域名转入注册商Moniker.com的方法(图文),非常详细。

步骤三:授权转出

在提交转入申请后,moniker.com后台有个功能,点击”Dashboard” => “Domains pending transfer”,这时候可以看到待转入域名的状态时”WAITING CUSTOMER APPROVED”,选择所有域名,点击按钮”Send Customer Approval Email (FOA)”,即可向你注册邮箱发送一个邮件,邮件主题类似”Bulk Domain Transfer Request Authorization”,邮件中附加批准域名转入链接,只需点击打开,即可授权。之后域名转入状态变成了”TRANSFER-PENDING”。

步骤四:批准转出

授权转出后,过1-2天,就会收到域名顶级注册商发出的批准转出邮件,邮件主题类似 “Transfer of xxx.COM – Confirmation of Registrar Transfer Request”,邮件正文有个链接,点击打开,输入转出授权码,即可批准转出。

然后…就没有然后了,等着你的域名转出被受理并自动成功转入到新托管商吧。

最难的是第一步,和国内那些流氓的注册商打交道太需要耐心和手腕了。我的经验是:死缠烂打,抓住他们流程漏洞挑刺。以我为例,X资源的转出条件上并没有写明”域名资料修改后,3年内不得转出”条款,而且在做域名资料修改时,也确实没任何提醒,就这点他们就足以哑口。最后希望国内这家注册商想方设法做好服务,并且培训你们的客服代表,客户花了钱,即便再少,也是客户,是希望得到服务、帮助的,不是来手气的,长此以往,这种企业必然无法长存。

新站第一篇,迁移drupal到wordpress

终于抛弃drupal投入到wordpress阵营了,哈哈。WP确实比DP好用,此处省去五百字…

以前一直在纠结怎么迁移,迁移后旧数据怎么办,有无平滑方案,想破脑袋都没主意,数次动过迁移念头,数次又被消灭。前几天DP通知可以从7.22升级到7.23,可无论如何都升级不成功,预计痛下决心进行迁移。

我现在后台用的是nginx+php-fpm模式,在同事的帮助下经过一番尝试后,终于搞定平滑升级方案:

1. 启用新站直接对外提供服务
2. 将原来的虚拟主机改名,比如把 imysql.com 改成现在的 dp.imysql.com:8080(由于我的server_name采用泛域名,因此这里需要使用非80端口)
3. 将所有对旧站的请求转发到 dp.imysql.com:8080 上

这样,就可以对外提供新站服务的同时,原有被搜索引擎收录的旧链接也能被正常打开。在nginx中,可参考如下配置:

#
# /sites/.* 、 /files/.* ... /image_captcha/.* 是drupal相关请求目录,在wordpress中不会出现,放心转发
# .*\.html 是我以前使用drupal时,url path的规则,以 .html 结尾,启用wordpress后,我的url path结尾改成 .shtml 了,所以也可以放心转发
# 上面规则设定完后,通过proxy_pass将符合特征的请求直接转发给 8080 端口了,也就是 dp.imysql.com:8080
#
location ~ ^/(sites\/.*|file\/.*|scripts\/.*|admin\/.*|node\/.*|user\/.*|image_captcha\/.*|.*\.html) {
    proxy_set_header        Host dp.imysql.com:8080;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass              http://127.0.0.1:8080$request_uri;
}

nginx我也不是非常熟悉,所以上面的正则表达看起来比较土,有什么比较好的麻烦大家告知,谢谢。