[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似乎真的没什么用,删了也无所谓。

MySQL5.0升级到5.5

服务器又出故障了,这次比较彻底——系统文件丢失:(

不得已重做了系统。

趁着这个重做系统,决定将MySQL自5.0升级到5.5。 更多 »

由服务器想到的……

昨天夜里到今天上午,服务器由于第二块硬盘无法找到而停止运行。搞得心神不宁的……

服务器已经3年多了,头一两年基本比较稳定,自从去年来,频繁死机,先是更换过内存条,然后春节前有更换了主板,虽然最近一个多月温度稍微高一些(CPU温度一般在55到59度之间),但也算比较稳定的运行了40天,前天正庆幸机器争气,结果昨天就出现了意外——第二块硬盘偶尔就找不到了:(由于数据库以及一些系统日志文件都写到了第二块硬盘,因此非常害怕出问题,经过检查发现,似乎硬盘没什么问题,很有可能是数据线或者接口的问题。凌晨的时候机房没人,所以到今天早上给机房打电话帮忙查看一下,因为机房也没有备用的数据线,所以只是更换了一个插口,恢复开机后,发现运行稳定,暂时处于观察期,但也不敢大意,先把数据库进行了备份,然后将系统日志都转移到主硬盘上了,数据库还是留在那块上,期望减少对这块硬盘的请求降低它的负载,期望不会再有问题了。唉,每次服务器有问题都会搞得头痛,类似那种偏头痛的感觉,睡觉也不踏实,神经衰弱……

经过这个事情,目前考虑了一个新的架构。主要是针对投入有限的情况而且有期望性能有所提高的。

之前架构服务器的时候,为了节省资金获得最高的性价比,因此只用一台服务器进行架构,web+database,从数据库读写性能角度考虑,把数据库放到了第二块硬盘上,web服务和文件放在第一块硬盘(主硬盘) ,系统运行日志也放到第二块上了。其实这种架构应该说是最节省也是相对获得最大的性价比的方式,毕竟再花万把块钱实在是捉襟见肘了。不过,这次感觉这样的架构还是有点麻烦,数据库和系统日志都是频繁进行读写的,增加了系统的不稳定性,现在硬盘价格已经很便宜了,因此,考虑如果只用一台服务器架构web的话:

可以考虑将主硬盘只做操作系统、软件环境、然后单独划出一个分区作为整个系统的日志区,

第二块硬盘,作为web程序文件存放区,除此之外不再放其他文件。

第三块硬盘,作为数据库储存区,只放数据库文件。数据库日志不在此处,单独放到主硬盘的日志区内。

如果,还有可能的话,可以再加一块硬盘,单独作为备份盘使用,平时不做任何读写操作,纯粹做为数据库备份之用。

这样的架构,可以最大的降低磁盘磁头的读写频率,提高I/O性能,从而保护磁盘寿命。

PS:纯粹只是一台机器用的,如果有很多money,基本不太考虑这个了……穷啊……而且,这个服务器上的网站纯粹只是个人爱好而已,没有获得什么收入, 每年运行的费用虽然不多,可也不是个小数了……

建议所有的程序开发者一起来保护MySQL——《拯救MySQL》

对于其他程序不甚了解,但就PHP开发来说,估计99%的人都选择MySQL作为数据库,因为MySQL给大家的印象是轻巧、易用并且最重要的是它有一个免费的社区版本,这个版本同它收费版本是完全一样的区别仅在于它的商业版本提供技术服务而已。

作为一个PHPer来说,我自2000年接触PHP,因为没有任何程序语言基础,所以学习起来挺费劲,一直使用文本储存数据,但真的觉得既麻烦又不安全,然后2001年年初的时候第一次开始接触MySQL,对于我无任何数据库语言概念的人来说上手的确有一点点困难,但我清晰的记得,看完了几个例子以后,我便轻松的了解了MySQL知道了它的强大、易用,而且最主要的是它不像Orlce和SQL Server,它是免费的!!

自那个时候起,我慢慢开始了解了这世上还有一些人,在维护着PHP、维护着MySQL、维护着Apache,我知道了一个名词“开源社区”,知道了还有一个免费的操作系统Linux ,知道这世界上还有一群具有创新、共享精神的人……

到现在,熟练使用并在自己项目上应用部署MySQL已经有接近8年的时间了,从MySQL4.0用到MySQL5.1,这个过程是很奇妙的,我从未担心过什么,因为我知道MySQL精神会继续着 ……

突然有一天,我知道了那个卖得很贵的数据库Orcal的东家甲骨文开始“惦记”着MySQL了 ,就我个人的感觉来说,这不是什么好事,如果这个公司或者其他别有用心的公司去收购MySQL,那么可能会带来的两种情况就是:1.为了维护其自身收费的数据库产品,势必会打压MySQL的开发,致使MySQL慢慢落后于其他数据库,导致它的淘汰;2.将MySQL也变成一个完全收费的产品。我个人可能更容易想到第一种情况,如果是那样,那真的是一个灾难……

为此,包括MySQL的创始人Michael Widenius在内的一些人组织了一个《拯救MySQL》的活动,请求所有MySQL的支持者支持和保护MySQL。

刚刚也在上面签名了,做为能力有限的支持者来说,我也许只能做到这些了。

希望支持MySQL的朋友们,一起来救救MySQL,点击进入这个链接填写表单就可以了:http://www.helpmysql.org/cn/petition

不要害怕E文,呵呵,是多语言的,我给的连接是中文版的^_^

拯救MySQL

拯救MySQL

MySQL字段的取值范围

设计数据库的时候会为表中涉及到的字段设定一个范围,如果不考虑这个取值范围可能会对未来的运营产生或者性能问题或者数据问题。如果实际的取值大于设计的取值则会造成数据无效或丢失导致程序出错,如果实际的取值小于设计的取值虽然不会对程序产生什么错误,但会白白的浪费储存空间导致性能问题。 更多 »

Deepseath Modified from Green Hope Theme · Proudly powered by WordPress · 津ICP备09005418号-1  津公网安备 12010302001005号