作为一个Oracle DBA,对MySQL很多SQL语法还不是很熟悉,两者之间还是有很多差异的。

这里我将要在MySQL里建一个表,表名为"Test Table", 其中一个列名为"First Name",当我用下列SQL语句来创建此表时,MySQL返回下列错误:

mysql> create table "Test Table2" (id int, "First Name" varchar(200));

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '"Test Table2" (id int, "First Name" varchar(200))' at line 1

这个MySQL数据库是按照默认配置安装的。

那么改如何解决这个问题呢?

方法1:
使用 ` (即数字键1左边那个键)符来代替上面的双引号,就像下面
create table `Test Table2` (id int, `First Name` varchar(200));

方法2:
修改MySQL的配置文件my.cnf文件,在[mysqld]此项中添加下面参数,然后重启MySQL使之生效
sql_mode = ANSI_QUOTES

方法3:
在启动MySQL时添加一个启动选项
mysqld_safe --user=mysql --sql-mode=ANSI_QUOTES &

个人推荐使用方法2。



LPCD带来的震撼

| | Comments (0) | TrackBacks (0)

lpcd45.jpg

记得好像是去年就曾经在CD架上看到雨果唱片公司的LPCD了,当时只知道HDCD、XRCD、SACD这些,所以对LPCD也没怎么在意。直到前两天,在网上下了一张LPCD转成ape格式的《十二钗》雨果女声示范碟,虽然当时只是在笔记本上通过PX200来听,但还是能很明显的感觉到LPCD的威力,初步听感就是声场比普通CD更准确、特别是人声,临场感特别强烈,喜出望外,于是决定一定要买张LPCD来好好听听。

于是今天下午又去了一趟位于上海音乐学院旁边的九龙,那是我常逛的一家专业音像店,这里以古典居多,也可以找到很多国内的作品,最重要的是这里雨果CD很全,本人对雨果唱片一直情有独钟,买的第一张CD就是《雨果发烧碟一》,那时还在念初中,囊中羞涩,买的是D版的,如今当然要支持正版了,好了,废话不多说。

挑了半天,决定还是先买《发烧@港》这张LPCD 45,因为对其中很多作品还算比较熟悉。我买的这张LPCD价格是223/张,价格还是蛮高的,普通的一张雨果CD一般也就90左右,不过我还是相信那句老话:一分钱一分货。

到家后,迫不及待地打开CD、耳放和耳机,这里顺便介绍一下我的设备,CD机是去年买的马兰士CD5001,耳放是云钟的纯甲类,耳机是森海塞尔的HD650,感觉CD机在这套组合中还是显得比较鸡肋,因为买回来不久我就拆开了看过,用料实在令人失望,以后有机会一定要先把他替换掉。

CD盒内共有两张CD,一张是LPCD,另一张就是普通的CD,具体LPCD和普通CD的差异在哪?从附带的说明书来看,传统的CD需要经过:母带---母盘CDR---玻璃模---金属模---压碟---CD这些工序,这个过程中数码格式需要转换5-6次,而LPCD从母带到最终的成品LPCD应该只经过了2次数码转换,而且LPCD直接从母带处理完后直接刻盘,免去了传统玻璃模、金属模、压碟这几道失真损耗非常严重的工序,对音质的提升是肯定的。更多关于LPCD的介绍大家可以到雨果唱片公司的官方网站上查阅

这张LPCD刻录面是紫色的,颇显几分神秘,估计应该也属于CD-R,因为CD盒封面上有提示,要求你的CD播放机能兼容CD-R。另外说一下LPCD 33和LPCD 45的区别,说明书上介绍道:LPCD产品规格分为LPCD 33和LPCD 45,LPCD 33是特殊加工处理的CD产品;LPCD 45是录音水准顶峰代表的产品,也是CDR母盘规格最高的。所以,要想完全领略LPCD的魅力,当然要选择LPCD 45了!

下面来谈谈个人对《发烧@港》这张专辑的听后感,仅供参考。
1 《阳春白雪》--琵琶
这是整张专辑的第一首,刚入耳,第一感觉就是声音更清晰、定位更准确,所演奏的琵琶声清脆有力、毫不含糊,其他配乐的方位感很强烈,可以很清楚地判断出乐器所在的方位,让我们初步领略LPCD的不凡功底。

2 《望春风》--人声:张杏月
这首是现场版,由老易现场录音,开头是短暂的观众鼓掌声,然后便是萨克斯的演奏,可以感觉是从偏右方传来,这时从中央传来了歌手的声音,定位很清晰。接下来便是歌手的深情演绎,其深厚的唱功展露无疑,加上LPCD的助威,使得女声极富感染力,临场感非常强烈,此时此刻,歌手就仿佛就站立在你的面前,而你已经完全融入到了现场。。。一曲演罢,全场发出了热烈的掌声,可以听出掌声是从前台最先发出,继而引致整个全场.

3 《二泉映月》--二胡
个人觉得,我们通过各种方式不断地追求高音质,并不是为了单纯的让某个乐器听得更清楚,或者说能够听出他的前后左右等等,而是为了通过更高的回放效果来更有力的表现作品所要表达的内容和思想,这就有点类似"形"与"神",声音是形,作品的思想是神,没有声音这个载体,作品的神是无法展现出来的,如果"形"能够更生动有效的表达出来,那么更有利于让我们充分体会和了解"神"所要反映的实质。

借助于LPCD的精彩传神的表现,当我听完《二泉音乐》之后,不由得心沉了许多,压抑了许久,那时而阵阵颤抖,时而绵绵无尽的二胡,都极生动地描绘了作者内心的悲苦,难怪CD说明书中提道:此曲在心情低落之际切忌聆听!

一言以蔽之,LPCD给了我很多惊喜。

晚上,又在网上订了两张LPCD 45,分别是《十二金钗》雨果女声示范碟和《新历其声》新加坡发烧盛会,期待着更多。。。


安装Memcached

| | Comments (0) | TrackBacks (0)

Memcached 是一个非常流行且高性能的cache应用程序,目前被广泛应用在很多web2.0网站,比如:LiveJournal, Facebook, Sourceforge 等。下面简单介绍一下memcached的安装和使用,更详细的资料可以从memcached的官方网站获得:http://danga.com/memcached/

下面的测试都是在RedHat Advanced Server Update 6上实现的。

必须的软件

安装:

  • libevent

./configure --prefix=/usr
make && make install

  • memcached

configure的时候有很多参数可供选择,可根据具体需求来选择
./configure --help

./configure --prefix=/home/memcached --with-libevent=/usr
make && make install

运行memcached
/home/memcached/bin/memcached -d -m 100 -l 192.168.1.136 -p 11211 -u nobody

-d: 让memcached以daemon形式运行
-m: 分配给memcached的内存大小,单位是MB
-l: memcached所监听的IP地址
-p: memcached监听的端口
-u: 运行memcached的用户

memcached运行后,我们可以用 'netstat' 来确认端口11211已经打开。
#netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State
tcp        0      0 192.168.1.136:11211         0.0.0.0:*                   LISTEN

几个简单的用来测试memcached的Perl脚本

现在我们已经在192.168.1.136上运行memcached了,下面我们将在另外一台客户端192.168.1.137上来向memcached存储和抓取数据。

由于这两个Perl脚本需要用到 'Cache::Memcached' 模块, 所以在运行之前必须确保其已经在客户端安装好,可以从www.capn.org 上获得,安装完毕后我们就可以开始来做测试了。

1. 将值 '123' 存储到memcached
脚本名称: push_mem.pl

#!/usr/bin/perl
use Cache::Memcached;
my $memd = new Cache::Memcached {
      'servers' => [ "192.168.1.136:11211"],
    };

# Set a value
$memd->set("my_key", "123");

$memd->disconnect_all();
exit;

2. 从memcached抓取数据
脚本名称: print_mem.pl

#!/usr/bin/perl
use Cache::Memcached;
my $memd = new Cache::Memcached {
      'servers' => [ "192.168.1.136:11211"],
    };
my $val = $memd->get( "my_key" );
if ( $val )
{
     print "Value is '$val'\n";
}

$memd->disconnect_all();
exit;

输出结果: Value is '123'

我们可以看到,当我第一次运行push_mem.pl脚本后,值123就被存储到memcached了,然后当我运行第二个测试脚本print_mem.pl的时候,我们就可以从memcached抓取到我们刚刚存储的值123了。

这里,我只是举了个简单的例子来演示memcached,实际情况中要比这个复杂多了。

提示:
我们可以telnet到memcached的端口11211来检查当前memcached的运行情况,这对检查系统运行状况和排查问题会有些帮助。

[root@web1 scripts]# telnet 192.168.1.136 11211
Trying 192.168.1.136...
Connected to web1.isoracle.com (192.168.1.136).
Escape character is '^]'.
input command: stats
STAT pid 23810
STAT uptime 622
STAT time 1209240944
STAT version 1.2.5
STAT pointer_size 32
STAT rusage_user 0.000999
STAT rusage_system 0.061990
STAT curr_items 1
STAT total_items 1
STAT bytes 58
STAT curr_connections 2
STAT total_connections 5
STAT connection_structures 3
STAT cmd_get 1
STAT cmd_set 1
STAT get_hits 1
STAT get_misses 0
STAT evictions 0
STAT bytes_read 43
STAT bytes_written 36
STAT limit_maxbytes 104857600
STAT threads 1
END

而且我们可以计算出cache的命中率, 也就是 get_hits/ cmd_get

在本篇文章中,我不会讨论详细的如何搭建基于Sendmail, Postfix, qmail邮件系统的步骤,这方面的文档网上非常多,大家可以通过Google来搜索查询。

一年多前,本人曾管理过一大型商业用途的邮件系统,每天的发送量超过1亿封,这里只是单纯的site邮件,还不包括广告邮件等。这里很想和大家分享一下我的一些关于高可扩展性、高管理性和高性能邮件系统的经验和心得。

1. 分割
对于soft bounce的邮件,目前大部分MTA都有自己的规则,会在未来的几天内对这些soft bounce的邮件不断的重新发送,以提高发送的成功率,造成soft bounce的原因很多,比如网络延迟等等。对于一般的邮件系统来说,这些soft bounce会在成功发送前一直存在于邮件队列中,随着时间的推移,这样会造成邮件队列越来越大,这样就会导致正常的邮件不能很及时的发送给用户。

那么该如何改进呢?这里就要引入一个概念,即fallback,何为fallback呢?简单的讲,就是如果主邮件服务器第一次无法成功发送的话,那么此邮件就会通过fallback机制,将此邮件转发给另外一台邮件服务器,这个邮件服务器专门用来发送这类第一次无法成功投递的邮件。这样的好处就是主邮件服务器的队列基本上会保持在一个稳定的范围内,而不至于过高,这样正常的邮件就能及时的成功发送给用户,而soft bounce的邮件就专门由fallback的邮件服务器来不断重复尝试发送,大家各司其职。

据我所知,当前Sendmail和Postfix都支持这项功能,大家可以去查阅官方文档了解如何实现此功能。

2. 负载均衡
对于一个大型商业用途的邮件系统来说,每天的发送量是非常庞大的,如果单凭两三台服务器是很难支撑这样的负载的,这时候我们就应该考虑采用负载均衡技术来将这些庞大的邮件量均衡的平摊到多台邮件服务器来发送。

举个例子,假设我现在有50台配置很好的主邮件服务器和40台一般配置的fallback邮件服务器,我们可以将这两种功能的邮件服务器划分为两个pool,每个pool拥有自己单独的域名,这里我给主邮件服务器pool建一个域名:mx.vip.isoracle.com,给fallback邮件服务器pool建: fallback.vip.isoracle.com域名。 由应用程序生成的所有邮件都将发送给mx.vip.isoracle.com,所有fallback的邮件都将发送给fallback.vip.isoracle.com,当然,我们需要在负载均衡服务器(比如F5)上做相关的配置,将发送给mx.vip.isoracle.com的邮件分配给mx1.isoracle.coom, mx2.isoracle.com ... mx50.isoracle.com这50台主邮件服务器,同理,将发送给fallback.vip.isoracle.com的邮件分配给fallback1.isoracle.com ... fallback40.isoracle.com这40台fallback邮件服务器。

这样做的好处就是可以大大的提高系统的可扩展性,如果当前邮件系统的容量无法满足日益增长的邮件数的时候,我们就可以很方便往mx.vip.isoracle.com里添加新机器,如果不采用负载均衡技术的话,那么当碰到瓶颈的时候,那么就可能需要重新设计当前邮件系统的构架等,这将是件非常麻烦的事。

如果你目前没有足够预算来购买硬件负载均衡器,比如F5, NetScaler,可以考虑使用Nginx或DNS轮询来实现简单的负载均衡功能。

3. 操作系统和存储
个人感觉Linux操作系统很适合邮件系统,性能和稳定性方面都挺不错的。 至于新出的FreeBSD 7.0, 本人还没有做过相关测试,据官方说明,性能相比之前的版本有很大的提高。

至于存储,最好使用SCSI硬盘来存储邮件队列中的小文件,SCSI硬盘相比SATA或SAS硬盘,占用CPU资源更少。

4. 监控
对于任何一个规范的邮件系统来说,监控系统是非常重要,必不可少的。

一般来讲,我们需要对以下做重点监控:
a 邮件队列,如果某台邮件服务器的队列过高,那么就必须要检查相关的配置和日志,查出问题的原因。

b CPU,内存和load,尤其CPU和load需要重点监控,往往邮件服务器出问题的时候都会从CPU或Load反映出来。

c 存储邮件队列的硬盘的剩余空间

4. 排查问题和生成相关报告
作为一个邮件工程师来说,经常会碰到各种各样的问题,通常我们都需要检查相关时间段内的邮件系统日志,这对于快速诊断和解决问题是非常有帮助的。但是对于大型邮件系统来说,每小时所产生的日志量都是非常庞大的,针对此状况,我曾经写了一个邮件日志分析系统,大致流程就是通过cronjob每隔一小时将每台邮件服务器上的日志传输到一台专门用来存储邮件日志的服务器上来,然后通过Perl和Shell脚本来处理这些日志,最终将处理完的数据存到Oracle数据库中,然后写了一个cgi的web界面,当需要查询日志的时候,只要输入问题发生时间和相关的邮件地址,那么就可以很快的从数据库中查询到详细的日志信息,通过分析这些日志信息,对快速诊断问题是很有帮助的。

在数据库里有相关的邮件系统日志信息的前提下,我们就可以通过RRDTool这类的绘图软件来生成相关的图形报表来显示邮件投递成功率、soft bounce和hard bounce的数量等重要信息。

当然,邮件系统是非常复杂的,这里我也不可能面面俱到,如果你有相关的经验或建议,非常欢迎交流。