工作近一年来犯过的错误

并不都是灾难，有些错误没什么严重后果，它们值得一提只是因为说明了一个道理：也许你对有些事情有斩钉截铁的把握，但事实上你仍然有可能被击败。原因很简单，你只对你目前所能想到的方面有把握，而没有人知道那件事到底有多少个方面。

1、SQL UPDATE without WHERE

这可能是DBA所能犯的最愚蠢、最彻底的灾难了。我在刚得到MYSQL数据库密码，但还没意识到自己将要负责数据库的管理工作时，曾经做过这种荒唐时，并且是在master db上！

不幸中的万幸是：

（1）我在那条语句执行完之前按Ctrl+C终止了，因此这个操作没有传播到slave上；

（2）那个表很不活跃，从我发现错误到把数据中slave反向恢复到master期间，没有产生新的更改。

这是一次非常恐怖的体验，教训也是非常、非常、非常强烈的。

2、误删文件

具体的情形很多，比如：

（1）开了太多的putty窗口，并且工作目录都相似，忙乱中在错误的主机上执行了rm命令；

（2）我以为我在测试机器上删除的是一个不再需要的目录，却忘了挂载在那个目录上的是来自另一台机器的NFS目录！

3、文本文件的格式

还是有两个案例：

（1）用Windows文本编辑器创建Linux bash脚本，虽然看起来内容没有问题，但是拿到Linux就是不能执行。这种错误是在初接触Linux时犯的，应该是小case了；

（2）这是昨天碰到的情况。在新机器上创建PHP.ini时，粘贴的代码是从WinSCP自带的文件查看器中复制的，也是看起来没问题，但是PHP就是没有加载这个配置，而且郁闷的是也没看到PHP报错；

4、PHP代码文件的编码

我新写了一个PHP程序，断定代码没有任何问题，但是它写到MYSQL里的中文字符串的编码跟现有的PHP程序的不一样，导致前端页面要么把这个程序、要么把其它程序写的数据显示成乱码。如果了解这个现象其实跟MYSQL表的默认字符集以及putty的文字编码无关的话，这个问题应该不是问题，但是在那时候，我确实几乎抓狂。

5、一台机器上有两个PHP！

这是今天碰到的情况。有一台机器很久没用了，不了解它的情况。我修改它的PHP.ini，用以下两个命令查看都发现新的配置死活没有生效：

$ php -i

$ php -r 'phpinfo();'

后来（好像真的是有经验了，不轻易抓狂了）type php一下，发现这个php根本不是我期望的那个php——机器上安装了两份同一版本的PHP，一个在缺省目录下，另一个在自定义的目录下。我配置的其实是自定义目录下的PHP，但是apache用的是缺省的那个。

6、mysql salve 的 server-id 冲突会怎样？

这个错误低级到根本不应该发生，不过我觉得它的症状还有点意思。

我新建了一个 mysql slave，在配置时错误地把 server-id 设成了与另一个 slave 相同的值，于是产生了一个很壮观的灾难：新 slave 启动后，在数据目录下瞬间产生了无数个碎小的relay bin log，并且数量每过一秒都在增加。当我后来停止 mysql 时，发现那些 relay log 文件已经有130万之多，以至于批量删除时，rm 报错说 Argument list too long，因此不得不分批删除。

看起来就像是 slave 每次从 master 取回来一些 bin log 后，都写到新的relay log里，而不是追加到当前的文件。我用 mysqlbinlog 工具查看了其中一个 relay log，里面只有寥寥几条 SQL 语句。

从 mysql> show processlist\G 里看到，IO进程的状态不是 Waiting for master to send event，而是 Queuing ...。没有工作进程，但是 mysql 刚运行时，有个工作进程在不停地执行从 master 取过来的 SQL UPDATE 的。

现在想来，这个结果还不是最坏的，毕竟不正常的是新 slave，如果不正常的是id与之冲突的旧 slave，那后果就很难说了。

PS. 在参加工作之前，我在学校里也是积累了相当的编程经验的，但那时从没介意犯错误，因为那时一直都致力于开发桌面应用程序，在自己的PC上，犯再大的错误又能折腾到哪去？只要手头有几张光盘，简直是天塌下来都不怕。

PS.2 我没记错，我确实是以C/C++程序员的角色进入公司的，但是鲜有写新代码的机会，现在居然阴差阳错地做起了——DBA & WEB MASTER，不补充知识能行吗！所以老车的项目的维护我真的必须下决心终止了，必须。有些知识是随用随查的，但也有些是有储备意义的，会在你甚至还没有意识到的时候暗中助你一臂之力。