她喜欢琵琶和古琴，而我喜欢钢琴和铜管；她喜欢中国古代历史，而我喜欢世界现代史；她沉浸于东南偏安的文化气氛，而我生于中原王朝，奉行克己努力。于是我最终决定放弃追求；当然了，本来我也并不讨她喜欢，放弃也是自然而然的，我写这些只不过为了给自己找点理由，挽回一点面子，给观众一些交代而已。
我们相识于2011年6月25日的一次郊游，从第一眼起，我就喜欢上了她。两天的郊游，一起玩耍；半年多的深入相识、一小些约会，我一直在尝试追求。在元旦杭州游之后，终于告一段落。在这次事件中，我学会了关注对方的想法，学会了不要过于自我中心主义，学会了不要过于自负。虽然最终没能追求到心爱的姑娘，但也不能说一点益处都没有。
望bb姑娘幸福。
流水账一把：
12 月底国航积分即将到期作废，于是换了 PEK-SHA 的机票，然后在 12306 网站买了上海虹桥-杭州的高铁票，去杭州玩了一圈。
元旦上午，冒着寒风等机场大巴，然后堵车到首都机场T3，吃了快餐就匆匆进去了。这班 CA1517 居然有四个航班号（深圳、两个外航），爬升转平飞、平飞转下滑的时候都没有失重感、落地时有感而不超重，很优秀。出了虹桥机场，我就顺着指示牌一路走到了虹桥高铁站，等了一会就刷身份证上火车了。杭州站出来去售票窗口打了车票留作纪念。
出了火车站，给 @adoal 打电话问吃什么，他推荐了老头儿油爆虾。用 iPad 搜索了一下，跟着地图走，我想抄近道就走了小路，结果发现这家店原来就在这条小路里，而地图的标注是偏移的⋯⋯但是因为排号太多，又不知道吃什么比较好，还是乘出租车去找 adoal 吃另一家分店了。饭后，乘出租车去了青旅。这店真有意思，十平米的房间，居然还带卫生间，五脏俱全啊！
第二天，早晨坐12路公交车去吃“咬不得 高祖生煎”，然后步行走到湖滨路，办了租自行车的卡。顺着湖边，从六公园开始步行向北，走了断桥、白堤、孤山岛，到岳庙。看了看，岳庙居然还收费，就算了吧，我干嘛花钱去看望那个安阳老乡呢？步行去浙大路小巷子里的知味观，发现没有蟹黄小笼，就点了鲜肉小笼和米饭套餐。江南的米确实比较差，但是小笼包不错。饭后回西湖，顺着苏堤走了好远，到花港观鱼的码头乘船，去看了三潭印月。然后去淘宝公司看望了叔度，攀谈了一下，聊了聊 IT 行业在杭州，和 nginx 相关的话题。从淘宝出来，租自行车一路骑到保俶路，转向断桥，又到孤山岛，去楼外楼吃了西湖醋鱼。饭后步行想偷窥《印象西湖》，失败，于是骑自行车回六公园去了。路上怕车撞我，把手电筒装在自行车篮子里当车灯。路上还围观了一起车祸，在保俶路南口，一辆车撞中央隔离带，隔离带里的交通标志牌柱子嵌入其前机盖；该路段限速 40，估计这辆车的车速是 70 码。在长生路，找到了大韩民国临时政府杭州旧址，打算明天来看。然后坐 12 路区间公交车回了清波门，再换 809 回山上。
第三天，早晨步行参观了青旅隔壁的中国丝绸博物馆，然后顺着西湖上游溪水步行到雷峰塔游玩。雷峰塔的保护罩倒是挺有意思的，上面新建的塔也不错，登高望远，可以俯视整个西湖。下来之后，步行走到长桥公园，饿了，租自行车去吴山广场的知味观吃饭。这家店有三鲜小笼和大闸蟹黄小笼，吃了，觉得还是三鲜的好。然后骑自行车去了西湖博物馆参观、骑自行车+步行去参观了大韩民国临时政府旧址、坐公交车去灵隐。灵隐景区很不好，把灵隐寺单独拿出来售票，且无联票优惠。我先看了永福寺，永福寺在山上，建筑上是一个一个小院，且不知道是净土宗还是禅宗的；参观期间还遇到一个红衣服小 mm 挺乖巧的。然后看了看自己还有体力，就买票去灵隐寺逛了逛，到一半的时候后院就开始逐渐关门了，于是留下了点遗憾。不过遗憾也好，为将来补遗留下原由。出来之后乘公交车到三公园，步行又去吃了高祖生煎，然后一路打听骑到 24 小时退卡点，退了公交卡。终于有钱了！！门口出租车去武林门民航售票处乘机场巴士，到了机场。机场的人很少，十分钟进入候机区，然后找地方充电。充电过程中听到 last call 广播，就进去了。CZ6164 的高端经济舱挺好玩的，我感觉在飞机前段，但是排号已经是 30 排了，很宽敞。起飞的时候感觉很爽，一定是直接按F4启动的。在飞机上只吃了点心，吃不下那个面条。填了南航明珠入会申请表。接地时明显感觉有转向，挺稳后掏出 iPad 看了看，侧风五米。出门时空姐说让我拉好拉链，没理之，结果一出门就被五米的风吹凌乱了⋯⋯
这次游玩，对杭州的气候、景观、城市交通、IT 行业在杭州的发展有了一定的认识。我觉得其实将来去杭州也会有个不错的发展。
在 MySQL replica 的 master 上执行备份，完毕后没能正确检测 master binlog 相关信息，因而没能在输出和信息文件中正确记录。已经报告了bug并回退到 1.6.3-292 版本
几个月前的一次郊游，偶遇了一个可爱的小姑娘。传说中的一见钟情居然真的存在：很难形容那种感觉，从第一眼开始就令我心动。我已经多年不曾投入感情了，还有点不习惯这种感觉。于是，开始矛盾，开始自问。
在一次放弃之后，事情似乎又峰回路转。而回想放弃之前的痛苦心情，我知道自己这次是躲不过了。这就是命。
来吧，命运；来吧，缘分！
用过 xtrabackup 工具的 innobackupex 脚本备份数据的人可能会注意到，–apply-log 处理过的备份数据里有两个文件说明该备份数据对应的 binlog 的文件名和位置。但有时这俩文件说明的位置可能会不同。
经过实验和询问 Percona 公司，结论如下：
1 对于纯 InnoDB 操作，备份出来的数据中上述两个文件的内容是一致的
2 对于 InnoDB 和非事务存储引擎混合操作，xtrabackup_binlog_info 中所示的 position 应该会比 xtrabackup_pos_innodb 所示的数值大。此时应以 xtrabackup_binlog_info 为准；而后者和 apply-log 时 InnoDB recovery log 中显示的内容是一致的，只针对 InnoDB 这部分数据
另外，今天发现 InnoBASE/MySQL/Oracle 公司出品的 MySQL Enterprise Backup（原 InnoDB Hot Backup）中 innobackup 脚本备份出来的数据也有类似的问题。这其实是由于热拷贝时 InnoDB 表和非事务表分别复制的时间差引起的。
最近几天在筹备多做一个 slave 数据库，所以就用 InnoDB Hot Backup 工具把原来的 slave 库备份了一份，拷贝过来，执行了一段 binlog 之后卡住了，然后发现上述工具对 ARCHIVE 存储引擎的表没有考虑，没把数据文件复制过来。于是改用 Percona 出品的 xtrabackup 工具，其 innobackupex 脚本考虑的比较周全。这样总算搞到一份相对完整的备份。
搞到备份数据之后，我又想尝鲜，于是装了 Percona Server （即 MySQL 的一个增强 fork）的 5.5 版本，结果发现无法操作上述 ARCHIVE 存储引擎的表。查了查 MySQL 5.1 的文档，说从 5.0 到 5.1 之间，ARCHIVE存储引擎变了存储格式，不可能兼容，要求 dump/restore 操作。服了……
考虑到 RedHat EL 及其克隆版本们的广泛应用，以及这些版本逐渐进入衰老期，MySQL 5.0 到其更新版本的数据迁移也会逐渐到来，所以在这里写一篇博客，提醒自己和同行们注意。
矛盾啊，本来想在网上有一片自留地，可以随便写写什么，但偶尔又有些业界心得想分享，也写在这里，于是自留地变成了公园，很多人都来看。
被关注的多了，有些事就不好写出来了，因为是自己心底的秘密，不想被围观者看到。
患得患失，投鼠忌器，不敢写了。算了，那就不写吧，虽然很不健康，但我已经能忍受寂寞，就写在自己心底吧。
3月初我跳槽了，然后一直很忙。不过还是来发一条消息，让大家知道我没有废弃这个博客。
欢迎关注我的新浪微博 http://weibo.com/julyclyde
最近发现我们的 postmaster@$myorigin 经常收到垃圾邮件，而该垃圾邮件的来源是早在几个月前就列入 anti-spam.org.cn 的 RBL 中的。查了一下日志，发现对方发来的邮件被“部分拒收”，发给 postmaster@$myorigin 的那个投递成功了，发给一般地址的被服务器拒收。在 check_client_access 策略里，我把一个内网 IP 列入黑名单，然后 telnet 发信测试，这个问题竟然能稳定重现！我是不是发现 bug 了？
gdb 了半个下午，发现 postfix 中 smtpd_check.c 文件里有这么一段：
/*
* XXX Always say OK when we're probed with our own address verification
* sender address. Otherwise, some timeout or some UCE block may result
* in mutual negative caching, making it painful to get the mail through.
*/
#ifndef TEST
if (*recipient) {
if (canon_verify_sender == 0) {
canon_verify_sender = vstring_alloc(10);
rewrite_clnt_internal(MAIL_ATTR_RWR_LOCAL,
var_verify_sender,
canon_verify_sender);
}
if (strcasecmp(STR(canon_verify_sender), recipient) == 0)
return (0);
}
#endif
其中 canon_verify_sender 是个静态指针，在这一段被初始化之后，其指向的空间里就已经保存了一个字符串 postmaster@$myorigin。然后在第二句 if 之后就直接返回了，不继续进行 if 之后的那些反垃圾策略判断了。
然后看了一下 ADDRESS_VERIFICATION_README 文档，里面是这么说的：
By default, Postfix probe messages have a sender address “double-bounce@$myorigin” (with Postfix versions before 2.5, the default is “postmaster@$myorigin”). This is SAFE because the Postfix SMTP server does not reject mail for this address.
也就是说我活该收到垃圾邮件！好吧，那我改改 address_verify_sender 参数得了。
最近收到好几封垃圾邮件，根据 Received 头来看，是中国电信湖南省网的一个网段中的多个 IP 地址破解了别人的邮件密码之后，盗用别人的邮件账户发信的。跟中国电信 NMC 沟通了一下，他们说“已经通知客户杀毒”了。电信的这种态度，也不知道是懒得管，还是保护客户；反正他们通知客户之后还继续有类似的垃圾邮件发出来，源端也依然是那个网段。
被盗的账户有 hr@ 的，也有 sales@ 的，基本上都是文科职务名邮箱。只能感叹一下中国的高校教育啊，虽然把 Office 作为大学基础课程，让大家都学会打字和基本的文字处理工具了，但还没用把网络安全纳入基础教学范围，文科专业在这方面尤其欠缺。唉！
此事之后，我也查了一下自己公司的邮件服务器，竟然发现我们的服务器上也有一个账户被盗用。因为这个账户平时就是用于向网站注册用户发通知的，收件人不集中，我也就没太注意。今天偶尔用 postcat 看了一下邮件内容，发现竟然是垃圾邮件！！赶快改掉密码、通知发信人所在IDC（郑州景安、香港 HKCIX 交换中心）。不过这些垃圾 IDC 还不如中国电信，根本不给回复。随后我设置了 header_checks ，检测湖南来的垃圾邮件；又设置了 cron，把 SASL 日志里，非公司所属的 IP 地址找出来，定时发给 postmaster。
