Linux 软Raid:mdadm 操作

(此文摘自百度文库)

1.查看RAID的信息
mdadm –detail /dev/md0
这里包含RAID的详细信息

2.删除和恢复某个RAID磁盘(假设使用hda1)
先删除某个磁盘:
mdadm /dev/md0 -f /dev/hda1—–标记错误磁盘
mdadm /dev/md0 -r /dev/hda1—–去除错误磁盘

恢复之前删除的磁盘
mdadm /dev/md0 -a /dev/hda1

此时查看RAID信息可以看到/dev/hda1自动成为了热备盘

3.扩展已有的RAID
这里先创建要添加的RAID分区:/dev/hdd1
添加磁盘
mdadm –add /dev/md0 /dev/hdd1
此时md0中增加了一个spare磁盘,接下来就是扩展了
mdadm –grow /dev/md0 –raid-devices=4
这里在grow模式下增加了设备,也可以增加设备容量
fsck.ext3 /raid
校验文件系统,为扩展作准备
resize2fs /raid
扩展文件系统,更新系统信息

4.创建RAID控制文件
echo DEVICE /dev/hd[a-d]1 >> /etc/mdadm.conf
mdadm -Ds >> /etc/mdadm.conf
此时可以看到配置文件如下:
DEVICE /dev/hda1 /dev/hdb1 /dev/hdc1 /dev/hdd1
ARRAY /dev/md0 level=raid5 num-devices=4
UUID = 9ca85577:25660a81:67152b19:3235d3s6

5.控制RAID起停
mdadm -S /dev/md0—–停止raid
怎么启动RAID呢?
如果已经配置了RAID控制文件,则
mdadm -As /dev/md0
根据配置文件的描述,RAID自动启动
如果没有配置文件
mdadm -As /dev/md0 /dev/hd[a-d]1
此时给出RAID的构成盘,RAID启动成功

linux做实验时创建了软raid. 后来重新创建raid时 提示如下
[root@client ~]# mdadm -C /dev/md0 -l 1 -n 2 /dev/sdb5 /dev/sdb6
mdadm: another array by this name is already running.

[root@client ~]# mdadm -S /dev/md0
mdadm: stopped /dev/md0
[root@client ~]# mdadm -D /dev/md0
mdadm: md device /dev/md0 does not appear to be active.

然后就可以创建raid了.

mdadm -S, –stop
deactivate array, releasing all resources.

有些情况还是不行
mdadm -S /dev/md0
mdadm -D /dev/md0
需要重启后生效.

Blog 搬迁至 Linode

已经是上个月的事情了,先买了一个月试用了一下,速度可以接受。

Linode:http://www.linode.com/
这家美国的 VPS 服务商确实不错,使用 Xen 构建,保证不会超卖。
大家如果有海外 VPS 需求的话,我推荐大家在 Linode 购买 :-)

我使用的是位于 Freemont 数据中心的 Linode 512 套餐:
内存:512MB
硬盘:16GB
流量:200GB/月
价格:$19.95/月

数据中心测速地址:http://www.linode.com/speedtest/

这个月起准备按月支付了,可以打9折。

大家需要购买的话,欢迎从这里点过去:
http://www.linode.com/?r=0afe8e299a0c99fd54f8736b7e40521d62efe149

在你注册使用满3个月后,我就可以得到一笔推介费用啦~

— EOF —

无废话 MongoDB 及 PHP 扩展编译安装

操作系统环境:Gentoo Linux

需要使用 scons 编译安装:

emerge scons

安装 mongodb 依赖库:

emerge boost
emerge libpcre
export CFLAGS=”-DJS_C_STRINGS_ARE_UTF8″ # 编译spidermonkey支持utf8
emerge spidermonkey

安装 mongodb:

# 1.6.5 版本

cd /work/setup
wget http://downloads.mongodb.org/src/mongodb-src-r1.6.5.tar.gz
tar zxf mongodb-src-r1.6.5.tar.gz
cd mongodb-src-r1.6.5
scons all
scons –full install

# 2.0.0 版本(2011-09-13 更新)

cd /work/setup
wget http://downloads.mongodb.org/src/mongodb-src-r2.0.0.tar.gz
tar zxf mongodb-src-r2.0.0.tar.gz
cd mongodb-src-r2.0.0
scons all
scons –full install

启动 mongodb 服务器:
创建默认的数据库目录,创建后启动 mongod:

mkdir -p /data/db
/usr/local/bin/mongod

在系统自动启动队列文件 /etc/conf.d/local.start 中添加:

/usr/local/bin/mongod –fork –logpath /var/log/mongodb.log –logappend

安装 PHP 扩展:

wget http://pecl.php.net/get/mongo-1.1.4.tgz
tar zxf mongo-1.1.4.tgz
cd mongo-1.1.4
/usr/local/php/bin/phpize
./configure –with-php-config=/usr/local/php/bin/php-config
make && make install

# 2011-09-13 更新

wget http://pecl.php.net/get/mongo-1.2.4.tgz
tar zxf mongo-1.2.4.tgz
cd mongo-1.2.4
/usr/local/php/bin/phpize
./configure –with-php-config=/usr/local/php/bin/php-config
make && make install

最后在 php.ini 尾部加上:

extension = mongo.so

— EOF —

NGINX + PHP-FPM 502 相关事

NGINX + PHP-FPM 报 502 错误,我想大部分 SA 都遇到过吧。
根据报错的频率,可以分为两种情况,间歇性的502和连续性的502。
这里只讨论第一种情况——间歇性的502。

502,是后端 PHP-FPM 不可用造成的,间歇性的502一般认为是由于 PHP-FPM 进程重启造成的。

在 PHP-FPM 的配置中存在这么一项:

How much requests each process should execute before respawn.
Useful to work around memory leaks in 3rd party libraries.
For endless request processing please specify 0
Equivalent to PHP_FCGI_MAX_REQUESTS
<value name=”max_requests”>500</value>

这段配置的意思是,当一个 PHP-CGI 进程处理的请求数累积到 500 个后,自动重启该进程。

但是为什么要重启进程呢?

一般在项目中,我们多多少少都会用到一些 PHP 的第三方库,这些第三方库经常存在内存泄漏问题,如果不定期重启 PHP-CGI 进程,势必造成内存使用量不断增长。因此 PHP-FPM 作为 PHP-CGI 的管理器,提供了这么一项监控功能,对请求达到指定次数的 PHP-CGI 进程进行重启,保证内存使用量不增长。

正是因为这个机制,在高并发的站点中,经常导致 502 错误,我猜测原因是 PHP-FPM 对从 NGINX 过来的请求队列没处理好。不过我目前用的还是 PHP 5.3.2,不知道在 PHP 5.3.3 中是否还存在这个问题。

目前我们的解决方法是,把这个值尽量设置大些,尽可能减少 PHP-CGI 重新 SPAWN 的次数,同时也能提高总体性能。在我们自己实际的生产环境中发现,内存泄漏并不明显,因此我们将这个值设置得非常大(204800)。大家要根据自己的实际情况设置这个值,不能盲目地加大。

话说回来,这套机制目的只为保证 PHP-CGI 不过分地占用内存,为何不通过检测内存的方式来处理呢?我非常认同高春辉所说的,通过设置进程的峰值内在占用量来重启 PHP-CGI 进程,会是更好的一个解决方案。

期待他的建议能在今后的 PHP-FPM 版本中实现。

— EOF —

自动检测 PHP-FPM 的错误并重启的 PHP 脚本

公司的 WEB 生产服务器使用 NGINX+PHP-FPM 构建。

近日 NGINX 频报 (110: Connection timed out) 以及 (11: Resource temporarily unavailable) 的错误,出错后后端的 PHP-FPM 几乎全部挂死,重启 PHP-FPM 后又能正常工作。

初步认定是 PHP-FPM 或系统参数配置有问题,优化了系统参数并重启服务器后,目前尚未发现问题。

但是依然比较担心意外情况发生,没人想在春节期间再来照看这些服务器,索性用 PHP 写了个脚本监控错误日志,监测到错误后自动重启 PHP-FPM。

脚本下载:
phpfpm_guarder

配置说明:
$bin_tail_path tail命令路径
$bin_cp_path cp命令路径
$log_path 错误日志文件路径
$error_logs 要检测的错误类型,可以检测多种
$restart_cmd 重启 PHP-FPM 的命令
$guide_period 检测周期,单位为秒
$max_error_cnt 在检测周期里面发现多少次错误后重启服务器

没几天就要过年了,祝各位新快乐,万事如意!

— EOF —