友情提示：”严重剧透”已经无法形容本文的剧透的程度了。端午四天假，让我最终有空看完了Lost全六季。回想起，06、07年看Lost时的抓狂，不得不写点什么。最开始的草稿本来是从oceanic 815上的Benjamin Linus开始写起的，写着写着，发现不写清楚故事的“起源”，根本无发写下去。
想想，……，佩服导演和编剧啊。 (more…)
orczhou
-
起源–Lost
·
-
使用rpm包，或者apt-get、yum等方式安装MySQL已经很方便了，不过我还是更喜欢编译安装。编译安装的好处：平台无关、安装的MySQL目录独立（方便清楚），据说有更好的性能和平台耦合。缺点，编译安装较慢（不过现在8核CPU编译起来也很快了）。
1. MySQL编译参数
常用的参数有：
CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors \ -fno-exceptions -fno-rtti" ./configure \ --prefix=/data/mysql --with-extra-charsets=latin1,gbk,utf8 \ --with-plugins=partition,heap,innobase,myisam,myisammrg,csv \ --enable-assembler make make install“If you are using a version of gcc recent enough to understand the -fno-exceptions option, it is very important that you use this option. Otherwise, you may compile a binary that crashes randomly. Also use -felide-constructors and -fno-rtti along with -fno-exceptions.” (more…)
-
无论是工作还是生活中，我都尝试保持简单的自我：说想说的话，做想做的事。
这是很难的，有很多的羁绊都很难克服。一般的时候，我所做的事情都是能够获得多数人支持和认可的，但也有时候，会做一些有悖常理的“傻事”，这时会感到种种压力，有内在怯弱，有社会的鄙夷，有亲人的苦口婆心，有朋友的谆谆教诲…….。面对这些，有时候我会坚持，有时候我会放弃。因为未来的不确定性，最终我也很难确定，孰对孰错。
有悖这个理念的一个想法就是“善意的谎言”。我是不赞成的。一般善意的谎言，出发点都是为了保护亲近的人。一旦开始，后续不得不再编一系列谎言来圆前面谎言，自己很累，而且稍有不慎，反而会更加伤害原本想保护的人。事情既然已经这样了，何不帮助他们慢慢接受呢？
我仍然追求内心的呼喊，用我的言语表达我的想法，用我的方式做我想做的事。
-
押宝的人生
·
有一个关于时间的“祖父悖论”，同理，谁也无法判断未来：反证法，如果你能够判断未来，那你去干扰，导致未来没有按照你的判断发生，那你的判断就是错误的。这大概也是人生另一个有趣的地方吧，你永远也不知道未来会怎样。你不知道你的未来会怎样，你不知道你工作的未来会怎样，你不知道你十年之后会怎样，你也不知道你所公司的未来会怎样…… 对于未来，我们甚至没有一点是可以确定的。
很有意思的是，我们在做很多决定的时候，却都是基于我们对于未来的判断
(例如，天气预报)。事实上，很多时候这是不靠谱的。当然，预测对的时候也有。所以我一直觉得，当我们每次基于此去预测未来的时候，我们都在押宝而已，有时候押的准，有时候会运气不好。我们不必因为之前对于未来判断失败而责备自己。人的一生是短暂和孤单的，未来是不可以预测的，勇敢的追求内心的理想吧。
-
当管理的MySQL主机越来越多的时候，遇到Bug的可能性也就越来越大了。基本上，每隔一段时间，我们都会遇到一个Bug或者版本兼容问题。有些Bug已经修复（Bug #44571），有些Bug无法重现或者修复（Bug #39168）。即使Bug能够重现，我们也不能期待MySQL/Innobase能够多快的给出Patch，他们没有这个义务，我们也没有权利要求。
如何处理Bug？
尝试到找Bug重现的场景，确定他是一个Bug，而不是一个Mistake。一般遇到Bug，都能在MySQL Bug找到线索，如果能够确定是Bug，可以看看新的版本是不是已经修复，如果修复则可以考虑升级小版本号。对于更高的小版本号，我们有如下假设（或者认为）
- 更高的小版本号解决了更多Bug；
- 如果更高的小版本有新特性，那么意味着新特性可能带来更多的Bug；
- 更高的小版本，仍然会有和老版本不兼容的地方；
- 更高的小版本，有很cool的新特性；
- 一般，小版本的升级不会影响应用。
所以，一般遇到Bug，新的小版本如果有修复，我们将优先考虑升级小版本号。
另外，找到Bug重现的场景，还可以考虑绕过Bug（workaround），让自己的应用或者DDL尽量避免Bug出现。有时候，新版本新特性会带来一些Bug，不得以我们还可以考虑降级版本，虽然这是不推荐的做法，因为这样的可能陷入死循环。
Bug？Debug！
纵然，Innobase/MySQL AB已经被Oracle收购，MySQL的源代码仍然受到GPL的保护，所以我们仍然能够获得源代码，这就意味着我们自己Debug也成为可能。很多做开源方案的团队、公司已经发布了很多Patch，一般是做性能提升或者功能增强，他们也在MySQL Bug上提交了很多Patch建议。
这里的另一个问题是，自己的团队是否可能去Debug、打补丁？一般地，如果能够找到源代码的Bug，将其提交到MySQL Bug上，等待更加理解整个架构的人去将代码Merge到源码树中，一般是比较靠谱的办法。这大概也是为什么，目前开源社区、团队产生的一般是性能提升或者功能增强补丁，而很少Debug补丁。
-
起因
昨天，在给一个数据表DDL操作时，InnoDB报了如下错误：
100602 13:48:39 [ERROR] Index uk_usplugin_plugid of test/test_user_plugin_0002 has 2 columns unique inside InnoDB, but MySQL is asking statistics for 3 columns. Have you mixed up .frm files from different installations? See http://dev.mysql.com/doc/refman/5.1/en/innodb-troubleshooting.html
MySQL版本：MySQL5.1.45+InnoDB Plugin1.0.6
当时的DDL：
alter table test_user_plugin_0002 drop index USER_ID,add unique index uk_pluser_userid(USER_ID,PLUGIN_ID);追踪
在MySQL Bug System中看到，问题类似于Bug #44571中的Case2（Bug #47622）。问题的大概原因是，InnoDB的system table中的表信息和MySQL字典中的表信息不同步导致的。尝试了几次，无法重现错误。
如何避开（workaround）
可以通过下面的SQL来重建InnoDB的索引：
alter table test_user_plugin_0002 engine=innodb在Bug #47622看到5.1.46中貌似已经解决了这个问题，还可以尝试升级到5.1.46。
另外，应该还可以尝试在DDL时打开old_alter_table来避免：（未验证）
SET [GLOBAL] old_alter_table=ON