[ERROR] Can’t open shared library ‘udf.dll’ (errno: 0 )
有3个多月没写博客了，现在似乎越来越懒了:( 今天竟然忘记了登录密码，幸好，输入几次终于想起来了……
如标题，[ERROR] Can’t open shared library ‘udf.dll’ (errno: 0 )
这是MySQL在启动时报的一个错误，在一个朋友的服务器上看到的，这个错误几乎已经持续了很久很久了，虽然报错，但似乎不影响使用，只不过，对于一个很洁癖的人来说，每次看到都很闹心。
之前曾经尝试过查找原因，包括建立plugin目录，以及遍历整个系统来查找udf.dll，都没什么结果。
也在谷歌和度娘上找过，说是什么提权文件，实话说，用了这么多年还真从来没听过这个功能……也按搜索到的文章操作过，但全部都是失败。
最后，考虑到可以尝试升级一下MySQL的版本（之前是5.0很早期的一个版本），由于系统还有很多不太熟悉的程序，所以为了考虑稳定性，所以只是升级到MySQL5.0的最后一个版本。
升级很简单，轻车熟路，一贯是我最懒人的做法：
1.由于想重新使用mysql的配置向导来配置my.ini所以，先将mysql的服务删除掉，命令行执行，mysqld-nt –remove即可。
2.不改变mysql的安装目录，因此，只需要将原来的安装目录改个名就行（权当备份了）
3.执行mysql安装程序，安装到之前的目录下。
4.执行mysql的配置向导，进行my.ini的配置。
5.手动打开my.ini，修改数据库文件储存目录变量“datadir”，修改为之前的数据库储存位置
6.重启mysql
升级操作就算完毕了，原来的帐号都可以继续使用，其他无须做什么改变。
回头再来看系统日志，发现一个很奇怪的现象，就是刚升级完启动mysql的时候那个错误是没有的，但改完数据库储存目录后再重启那个错误又出现了。
看来，这个错误本身应该还是来自于mysql数据库，而且只能是mysql自身的数据库（数据库名：mysql），
于是，关闭mysql。
尝试将旧的mysql系统数据库（数据库名为mysql），改成其他名字，将新的mysql默认的系统数据库copy过来。
同时将旧系统数据库内的user表文件（三个）都覆盖到新系统数据库内。
这时候再启动mysql就不会有错误提示了。
查看了一下旧系统数据库表，发现其中一个数据表（mysql\func）里存在一条记录：
mysql> select * from func; +-------+-----+---------+----------+ | name | ret | dl | type | +-------+-----+---------+----------+ | baker | 0 | udf.dll | function | +-------+-----+---------+----------+ 1 row in set (0.00 sec)
挺有意思的，真的不知道这是干什么用的，似乎没有它也一样正常运行。
结论：如果有类似这样错误的，可以尝试找一下系统数据库（mysql）的func表，把dl=udf.dll的这条记录删除掉，然后再重启mysql应该就可以了，如果怕出问题可以提前进行一下备份。
PS：网上其他的解决方案真的不知道是否可行，反正我是没成功。我的这个方案只是清除掉错误（功能），可能未必是一个完美的解决方案。但就个人而言，utf.dll似乎真的没什么用，删了也无所谓。
Foxmail无法发送邮件的解决办法
一直以来在客户端收发邮件都是使用Foxmail，用着比较舒服。目前还在使用6.5版的，虽然也装了7.0但还未使用，准备换操作系统后用。
最近用foxmail发邮件总失败，开始是用sohu的邮箱有问题，以为是连接SMTP服务器的问题或者foxmail设置有问题，搞了很久也不行，于是试图尝试给sohu邮箱客服发了纸条，结果，TMD，很久也没回复。
原本想放弃了的。
但今天试图用使用gmail发送邮件，竟然也不行，于是考虑，应该还是foxmail自身的问题。
想起来收邮件时有问题可以对收件箱进行一致性检查或者进行压缩。
于是尝试，对foxmail的发件箱->右键->属性，选择“压缩”，然后再检查“一致性”，一般这样做就可以正常发邮件了，如果还不行的话，再重复一遍这个操作，然后选择“工具”选项卡，点击“开始修复”，应该可以解决问题。
这个办法，仅针对你的foxmail的发信SMTP确定设置正确的情况下，才有效的，假如你的smtp本身设置就有问题那打死也发不了的，呵呵。
最明显的表征就是，明明昨天还可以发邮件，然后今天多次尝试怎么都发不了，那么估计就是你的发件箱出了问题，用我上面的办法就可以解决^_^
PHP在Windows下的安装
很久没在IIS6配置PHP了。因为服务器重装系统，今天配置了PHP。
我不习惯将PHP文件copy到系统目录内（system32），会导致日后升级比较麻烦。
PHP在IIS6下安装很简单，主要是读取指定的php.ini文件路径的设置问题。
我是通过注册表的IniFilePath来定义的，可以将下面的代码另存一个.reg文件，然后导入到注册表内。记得将C:\\PHP5改为实际的PHP存放目录。
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\php] "IniFilePath"="C:\\php5"
另外，一定要将PHP存放路径加入到系统环境变量Path里面去。否则会导致无法加载dll扩展的情况发生。这一步我就给忘了，结果启动iis的时候总会弹出一个类似如下的警告：
弹出应用程序: Warning: PHP Startup: Unable to load dynamic library '*****\php_curl.dll' - 找不到指定的模块。
Windows2003计划任务实现服务器自动重启
最近服务器刚刚更换了一块新硬盘，同时也将PHP升级了一下，然后不知道什么原因（因为这两个维护导致的或是其他的）IIS运行PHP的站点每隔一阵就会无法访问，而静态页面的站点是可以访问的，最为奇怪的是，貌似每次发生这样的故障的间隔期间基本是差不多的，尝试检查了一下，没发现什么意外情况，连系统的日志以及IIS自身的日志都没有什么异常记录。同时也是比较懒得详细检查，所以干脆直接搞了定时重启服务器。
这绝对是一个非常非常非常懒惰的行为，可确实是没什么更好的办法了，如果有朋友能知道这是怎么个原因的话不妨告诉一下，千恩万谢！！！ 更多 »
关于WinXP/Win2003系统时间同步间隔的设置
有时候会发现Win2003系统日志内有一些来源为：W32Time，事件ID为：36，事件描述为：
时间服务有 86400 秒没有与系统时间同步，因为没有一个时间服务提供程序 提供可用的时间戳。时间服务将不再是同步的，也不能为其它客户端提供 时间或者更新系统时钟。请查看事件查看器中显示的系统事件，以确认没 有发生更严重的问题。
这是一个警告事件。 更多 »
关于“找不到附属汇编 Microsoft.VC90.CRT，上一个错误是 参照的汇编没有安装在系统上。”的解决
一个项目需要在Win系统用计划任务执行PHP，写了个批处理bat利用php-cgi.exe进行执行PHP文件，由于在服务器运行为了不影响服务器既有的PHP配置信息，同时也是考虑未来的移植性还有性能问题，自己弄了个精简了的PHP运行环境。
可在Win下死活也是执行不了，运行批处理直接闪一下就啥都木有咧，于是为了看具体的状态，使用cmd命令行模式去运行批处理文件，结果提示“系统无法执行指定的程序。”，悲催了，难道朋友将服务器给阉割导致不能执行.bat文件？
正咬牙切齿的时候决定再尝试一下确定到底是什么问题。这一次直接在cmd中执行php，运行php.exe -c php.ini -i（指定同php.exe相同目录下的php.ini作为php的配置文件，并且显示phpinfo信息），回车后，竟然还是那句该死的“系统无法执行指定的程序。”，看来不是系统运行不了bat批处理，是干脆不能执行php.exe，咋回事捏？
更多 »
由服务器想到的……
昨天夜里到今天上午，服务器由于第二块硬盘无法找到而停止运行。搞得心神不宁的……
服务器已经3年多了，头一两年基本比较稳定，自从去年来，频繁死机，先是更换过内存条，然后春节前有更换了主板，虽然最近一个多月温度稍微高一些（CPU温度一般在55到59度之间），但也算比较稳定的运行了40天，前天正庆幸机器争气，结果昨天就出现了意外——第二块硬盘偶尔就找不到了:(由于数据库以及一些系统日志文件都写到了第二块硬盘，因此非常害怕出问题，经过检查发现，似乎硬盘没什么问题，很有可能是数据线或者接口的问题。凌晨的时候机房没人，所以到今天早上给机房打电话帮忙查看一下，因为机房也没有备用的数据线，所以只是更换了一个插口，恢复开机后，发现运行稳定，暂时处于观察期，但也不敢大意，先把数据库进行了备份，然后将系统日志都转移到主硬盘上了，数据库还是留在那块上，期望减少对这块硬盘的请求降低它的负载，期望不会再有问题了。唉，每次服务器有问题都会搞得头痛，类似那种偏头痛的感觉，睡觉也不踏实，神经衰弱……
经过这个事情，目前考虑了一个新的架构。主要是针对投入有限的情况而且有期望性能有所提高的。
之前架构服务器的时候，为了节省资金获得最高的性价比，因此只用一台服务器进行架构，web+database，从数据库读写性能角度考虑，把数据库放到了第二块硬盘上，web服务和文件放在第一块硬盘（主硬盘） ，系统运行日志也放到第二块上了。其实这种架构应该说是最节省也是相对获得最大的性价比的方式，毕竟再花万把块钱实在是捉襟见肘了。不过，这次感觉这样的架构还是有点麻烦，数据库和系统日志都是频繁进行读写的，增加了系统的不稳定性，现在硬盘价格已经很便宜了，因此，考虑如果只用一台服务器架构web的话：
可以考虑将主硬盘只做操作系统、软件环境、然后单独划出一个分区作为整个系统的日志区，
第二块硬盘，作为web程序文件存放区，除此之外不再放其他文件。
第三块硬盘，作为数据库储存区，只放数据库文件。数据库日志不在此处，单独放到主硬盘的日志区内。
如果，还有可能的话，可以再加一块硬盘，单独作为备份盘使用，平时不做任何读写操作，纯粹做为数据库备份之用。
这样的架构，可以最大的降低磁盘磁头的读写频率，提高I/O性能，从而保护磁盘寿命。
PS：纯粹只是一台机器用的，如果有很多money，基本不太考虑这个了……穷啊……而且，这个服务器上的网站纯粹只是个人爱好而已，没有获得什么收入， 每年运行的费用虽然不多，可也不是个小数了……
百度和Google到底区别在哪里？
自打刚回到家里就感冒，这两天终于好了一些，现在已经不难受了，呆在家里整天看电视、看电影，要么就是研究一些无聊的东西。
最近一个实验站流量不错，自打服务器稳定后、域名更换为.com后，流量在慢慢的上升，甚至已经超过了另外的运行接近4年的小论坛。觉得很有意思，因为是实验目的比较大的，所以这几天也在琢磨原因。
有几个小发现：
１。服务器稳定性对于搜索引擎有影响，但未必是绝对的，当然前提是服务器不能长久（比如１个星期，呵呵）无法访问。这个影响最少应该不在收录，可能对于排名有点干扰。但只要网站内容独特，那么稳定后也一般可以恢复正常；
２。实验证明，.com效果要好于.cn。这个之前已经在很多运营交流站内被讨论过。无论Google还是百度，似乎都更偏好于.com（当然，我是指同等条件下的）。
３。百度更倾向实用性，Google更倾向技术性。这个无关谁强大或者谁更人性化。
看流量统计发现一个有趣的现象。
我的博客来自Google的占到接近95%的流量，百度仅仅为不到3%，甚至可能还不如Bing高。而我的另外一个站（生活内容为主）来自百度的接近 70%，Google约为20%。也许真的印证了一些做SEO的人的话：使用Google的多为做技术的，使用百度的多为非技术的……
只是一个无聊想想而已，我自己觉得，如果想做网站运营，那么就要脚踏实地的做好基础性的东西，比如结构、性能等等，慢慢的去积累内容，终究会有好看的流量的……
题外话，草根现在做网站运营真的越来越难了，难道ZF故意的……
回家啦
之前预计近期事情不多，加之与老妈一同回家，也为了错开春运高峰，所以提早买票回家。车票倒也还算比较顺利买到（早上4点就去车站排队）。可服务器突然罢工，主板和风扇都无法继续坚持，临走的前两天服务器疯狂死机，最后没办法重新更换主板和风扇，虽然买的时候颇费一番折腾，但快递到机房速度很快，机房更换的速度也挺快也很顺利，悬着得心终于放松下来。安心的上火车回家。
29号到家，30号恢复宽带，回来后就观察网站流量，发现服务器死机对于网站的流量和搜索引擎的影响都不大（至少目前为止） 。
昨天早上发现服务器流量异常，比平时正常的流量高出很多，但CPU无明显的攀高，查询日志发现某个来自台湾的IP段（根据IP来源显示是台湾）频繁访问服务器的静态文件，发出的协议是“Java/1.4.2_07” ，判断肯定不是搜索引擎也不是正常的访客，因此果断屏蔽整个该IP段，服务器流量一下恢复正常。
也许是前一阵折腾的上火，加上旅途的折腾，回来就开始不舒服，今天开始咳嗽、流鼻涕了，喝了水吃了药，今天早点睡，希望感冒尽快好，还有很多事要做:(
回家真好，虽然外面很冷，但屋里非常温暖。听老爸说家附近一个地方被列为文物保护点 ，等感冒好利索，让老爸导游”游览“一番，呵呵。
热炕头、冻梨、冰激凌、最爱吃的炖豆腐……该死的感冒……等好了通通补回来^_^
HTTP协议的那些事儿
什么是http连接？一张页面加载过程中，又是图片又是样式、脚本，对于这些东西的请求，是共用一个连接还是多个连接？
网上有人说，为了节省连接数，应该尽量将外部CSS，js合并，或者内联；甚至图片也合成一张，再用CSS定位。显然，在这里，一个请求就用一个连接，请求完成连接即被关掉。
但IIS里，有选项“保持HTTP连接”，且有超时时间可供设置。如果每请求一样东西，就开启一个连接，并且这个连接迟迟不死，保持激活，那么要多少连接才够用？这里的意思，应该是一个连接可以供多次使用。
常用HTTP状态代码和解释说明
来自 Google 的一篇帮助内容，略有修改。
如果向您的服务器发出了某项请求要求显示您网站上的某个网页，那么，您的服务器会返回 HTTP 状态代码以响应该请求。此状态代码提供了有关请求状态的信息，且为请求方提供了有关您网站和请求的网页的信息。
一些常见的状态代码为：
- 200 – 服务器成功返回网页
- 404 – 请求的网页不存在
- 503 – 服务器暂时不可用
以下提供了 HTTP 状态代码的完整列表。点击链接可了解详细信息。您也可以访问有关 HTTP 状态代码的 W3C 页来了解详细信息。 更多 »
