SQL SERVER数据库碰到823错误不能启动的解决方法

由于机器意外断电重启，发现SQL Server 服务不能启动。查看系统的事件日志，发现有错误提示:
———————————-
服务器: 消息 823，级别 24，状态 5
———————————-
对数据库启动错误信息进行细节排查，发现其中有ErrorDB出错，不能附加这个数据库，从而整个SQL Server 服务不能启动。

修复方法：
1. 将已破坏的ErrorDB数据库文件更名，如ErrorDB_Data.Mdf ==>ErrorDB_Data1.Mdf, ErrorDB_Log.Ldf==>ErrorDB_Log1.Ldf

2. 再次启动SQL Server服务，发现可以正常启动服务，但是会看到ErrorDB显示为置疑状态，将其分离，重新建立一个同名的ErrorDB数据库。

3. 选中新建的数据库，将其脱机, 然后到数据库数据目录下将新数据库更名(ErrorDB_Data.Mdf ==> ErrorDB_Data2.Mdf), 将待修复老数据库更名为原先名称ErrorDB_Data1.Mdf ==> ErrorDB_Data.Mdf

4. 在SQL查询分析器中, 执行如下命令:
use master
sp_configure ‘allow’, 1
reconfigure with override
update sysdatabases set status = 32768 where name = ‘ErrorDB’

5. 将LDF文件改名，然后将ErrorDB联机，再在查询分析器中执行
DBCC REBUILD_LOG (‘ErrorDB’, ‘E:\Data\ErrorDB_Log.LDF’ )

6. 恢复数据库紧急模式
update sysdatabases set status = 0 where name = ‘ErrorDB’

7. 在查询分析器中执行
restore database ErrorDB with recovery
sp_configure ‘allow’, 0
reconfigure with override

8. 检查数据库看看还有没有错误,
DBCC CHECKDB (‘ErrorDB’)

————-
如以上还是不行，可以尝试使用
DBCC CHECKDB(‘ErrorDB’, Repair_Allow_Loss_Data)
命令修复数据库，不过这样会丢失一些数据，但是话说回来，貌似不这样那些坏掉的数据也回不来的。
————-
在做以上处理时，要注意关闭使用ErrorDB的程序。要不然某些步骤会提示不能获得数据库的排他性操作权限，不能对命令进行执行处理。

Popularity: 9% [?]

Related

Tags：, .
August 4, 2009 | Filed Under MySQL | Comments Off 

MySQL中Group_Concat函数妙用

Group_Concat 是 MySQL 中用户Group By 的一个函数，函数语法如下:

  1. GROUP_CONCAT([DISTINCT] expr [,expr …]
  2.     [ORDER BY {unsigned_integer | col_name | formula} [ASC | DESC] [,col …]]
  3.     [SEPARATOR str_val])

这个函数在 MySQL 4.1 中被加入。函数返回一个字符串结果，该结果由分组中的值连接组合而成。

充分利用此函数，可以简化我们程序中的一些写法。
比如我们现在有一个学生成绩表，为了方便不同班级科目的设置，对学生的成绩没有采用一条记录多个字段的方式，而是采用多条记录一个成绩字段方式存储。

  1.   CREATE TABLE stu_grade(
  2.     `id` smallint(5) UNSIGNED NOT NULL DEFAULT '0',
  3.     stuname varchar(20), #学生姓名
  4.     course   varchar(20), #科目名称
  5.     score    int, #本科目成绩
  6.     KEY `id` (`id`)
  7.   ) TYPE=MyISAM;

现在要求获得一个班级中学生各科成绩列表。
通过Group_Concat 函数，我们只要简单执行如下的SQL语句，

  1.   SELECT `stuname`,
  2.       GROUP_CONCAT(concat(`course`, ':', score)
  3.                    ORDER BY `course` DESC SEPARATOR ",") AS Result
  4.       FROM `stu_grade`
  5.       GROUP BY `stuname`;

然后在程序中通过一个循环，将选出的结果输出来就可以了。如果不使用，我们通常需要将选出来的数据做再次整理，(多增加一些变量做一些循环判断，没有采用Group_Concat后的逻辑简单)

Popularity: 8% [?]

Related

Tags：.
January 6, 2009 | Filed Under MySQL | Comments Off 

MySQL主从服务器的一些技巧(转)

原作者: 老王
原文地址

红色字为sunnyu加的批注
———–

问题：主从服务器表类型的选择
一般的共识是主服务器使用innodb，事务，行锁等功能是myisam所没有的，对修改操作而言，它更高效；从服务器使用myisam，全文检索功能是innodb所没有的，对查询操作而言，它更高效。这样就可以各尽其能。
呵呵，主从库各司其职，主库：最快的速度做添加删除修改操作，从库，最快的速度做查询操作

问题：主从服务器字段类型的选择
字段类型对于分页等操作有很大影响。主服务器一般是innodb，因为不涉及查询，所以可以使用varchar等来存储字符串来节省空间，从服务器一般是 myisam，因为涉及查询，所以必须在char和varchar之间仔细权衡，没有varchar, text, blob字段的表是静态表，反之是动态表，静态表的检索效率要比动态表好若干倍，一般来说，所有涉及大结果集的查询都应该尽可能保证在静态表上完成，这里 说一个例子：比如说常见的articles表有title(varchar), body(text)等字段，在做文章列表的时候，因为不是静态表，所以查询不会很快，下面开始重构解决方案：把原来的articles表拆分成 subjects表和contents表，title字段设置为一个足够的char类型放在subjects表里，body字段还保持是text类型放到 contents表里，subjects和contents表之间的关系是一对多，这样，顺带着也方便的实现了多页文章的功能，而且更重要的是在查询文章 列表的时候，操作都是在subjects静态表里完成，效率肯定会比前一种方案提升很多。

强调：MyISAM里静态表和动态表的区别对性能影响极大，但我敢说很大一部分使用者并没有注意过这一点！如果你就是其中之一，那么我强烈建议你再次体会 一下前面说的articles分解为subjects/contents的过程，相信你熟悉了以后，下一个应用的速度会有质的提升。
唉，我就是那不知道的当中一人，受教了

问题：主从服务器NOW()函数造成数据不一致
假设在主服务器上执行一条INSERT …. VALUES ( …, NOW())，那么在从服务器上也会同样执行一条的SQL语句，但是主从服务器各自的时间设置可能不一致（比如说时区不同），NOW()在两台服务器上的 结果就可能不一致。在MySQL5.1里，将支持行复制，那时候就不存在这个问题了。不过不管怎么说，都不应该在程序里使用NOW()，时间的计算在应用 程序里完成。这里介绍一个额外的小技巧：获得时间戳，和time()相比，$_SERVER[‘REQUEST_TIME’] 少做了一次系统调用，不过是否合适要视客观情况而定。
这点不敢苟同，binlog上有时间戳信息，所以应该可以放心大胆的使用NOW函数，使用$_SERVER[‘REQUEST_TIME’]并不能得到实际操作数据库的时间

问题：主从服务器读写分离时读操作失败
先重现一下问题：比如说添加一条新数据，添加成功后根据last_insert_id跳转到新添加数据的浏览页面。在此过程中添加新数据的操作是在主服务 器上完成的，浏览新数据的操作实在从服务器上完成的，不过由于主从服务器间SQL同步存在延迟，所以当使用last_insert_id在从服务器上查询 的时候，从服务器很可能还没有还没来得及同步到此记录，所以读操作失败。解决思路也不复杂，在代码里加入一个缓存层（可以使用memcached），新添 加的数据都顺手放到缓存层里一份，新数据的读操作也先查询缓存层，这样就不会再有读操作失败的问题了，当然删除或者更新数据的时候也要顺带着处理好缓存数 据，可以使用观察者模式来搞定。不过这样缓存方案只限于读取单一的记录，对于读取列表的记录的情况，则是无效的。
也可以直接从主库获取数据啊，毕竟这种操作量是少的，而且是根据主键来的，稍微牺牲一下主库应该关系不大

问题：主从服务器索引是否有必要保持一致
一般都是利用主从服务器完成读写分离，从服务器上进行读操作，主服务器进行写操作，这样的话，主服务器上仅保留主键，外键，唯一索引等必要的索引即可，以 便保持数据合法性，而对于那些原本用于优化SELECT操作的索引，可以全部删除，如此的话主服务器的写操作效率会提升很多。
主库上保留的索引还应该考虑实际逻辑中相关删除修改操作的sql，要不然盲目删除一些索引可能会造成性能的直线下降，当然如果删除修改操作的条件都只是针对主键等的，那没有问题。
———–

Popularity: 8% [?]

Related

Tags：.
December 5, 2008 | Filed Under MySQL | Comments Off 

随机读取数据库记录的方法

为了一些抽奖等目的，有时候需要随机的从一些符合的条件的数据中获取几条做为中奖的记录。
这儿列出了一些常见数据库中用来获取随机记录数据的方法。

http://www.carlj.ca/2007/12/16/selecting-random-records-with-sql/

Popularity: 7% [?]

Related

Tags：.
November 1, 2008 | Filed Under MySQL | Comments Off 

MySQL定时增量备份的恢复处理脚本(mysqlbinlog)

在通过 MySQL定时增量备份处理脚本备份了数据后，我们还需要做恢复操作的脚本。
恢复起来相对简单，找到最近一天的数据或指定某天的数据，然后使用 mysqllogbin 根据日志做恢复处理。

步骤1：复制基准的全量数据

从备份目录下将最近备份的全量数据复制到工作目录下

  1. #!/bin/bash
  2.  
  3. PATH=/usr/local/sbin:/usr/bin:/bin
  4.  
  5. #get cur date str 2008-10-12
  6. DATE=`date -I`
  7. TIME=' 01:0:0'
  8. DAYSTARTTIME=" $DATE $TIME"
  9.  
  10. #set backup path info
  11. DATADIR="/var/lib/mysql"
  12. BAK_DIR="/backup/$DATE"
  13.  
  14. #set mysql user name and password
  15. MYSQL_USER="root"
  16. MYSQL_PWD="rootpwd"
  17. MYACC=" -u'$MYSQL_USER' -p'$MYSQL_PWD' "
  18.  
  19. cp -r $BAK_DIR $DATA_DIR

步骤2：根据日志文件对基准数据做恢复

对使用使用mysqlbinlog做数据的恢复。

  1.   HOST=`hostname -s`
  2.  
  3.   for binfile in `ls $DATA_DIR/$HOST-bin.0* |sort`; do
  4.      CMD="mysqlbinlog –start-datetime='$DAYSTARTTIME' $binfile  | mysql $MYACC "
  5.      eval $CMD
  6.   done

完整恢复脚本:

  1. #!/bin/bash
  2.  
  3. PATH=/usr/local/sbin:/usr/bin:/bin
  4.  
  5. #get cur date str 2008-10-12
  6. DATE=`date -I`
  7. TIME=' 01:0:0'
  8. DAYSTARTTIME=" $DATE $TIME"
  9.  
  10. #set backup path info
  11. DATADIR="/var/lib/mysql"
  12. BAK_DIR="/backup/$DATE"
  13.  
  14. #set mysql user name and password
  15. MYSQL_USER="root"
  16. MYSQL_PWD="rootpwd"
  17. MYACC=" -u'$MYSQL_USER' -p'$MYSQL_PWD' "
  18.  
  19. cp -r $BAK_DIR $DATA_DIR
  20.  
  21. HOST=`hostname -s`
  22.  
  23. for binfile in `ls $DATA_DIR/$HOST-bin.0* |sort`; do
  24.    RESTORECMD="mysqlbinlog –start-datetime='$DAYSTARTTIME' $binfile  | mysql $MYACC "
  25.    eval $RESTORECMD
  26. done

Popularity: 7% [?]

Related

Tags：, .
October 21, 2008 | Filed Under MySQL | Comments Off 

MySQL定时增量备份处理脚本

在提出 MySQL主从结构灾难恢复策略机制设想 后尝试编写用于以上目的的备份脚本。

增量日志备份

每日一个全量备份，同时做binlog 的删减(只保留一个小时的日志，根据需要可以做延时)，然后每小时对日志文件做增量部分的备份。

  1. #!/bin/bash
  2.  
  3. PATH=/usr/local/sbin:/usr/bin:/bin
  4.  
  5. #get cur date str 2008-10-12
  6. DATE=`date -I`
  7.  
  8. #set backup path info
  9. DATADIR="/var/lib/mysql"
  10. BASE_BAK_DIR="/backup"
  11. CUR_BAK_DIR="$BASE_BAK_DIR/current"
  12.  
  13. #set mysql user name and password
  14. MYSQL_USER="root"
  15. MYSQL_PWD="rootpwd"
  16. MYACC=" -u'$MYSQL_USER' -p'$MYSQL_PWD' "
  17.  
  18. #set backup type info
  19. INTERVAL="$1"
  20.  
  21. # days, files in base_bak_path
  22. # before this days will be deleted
  23. RETENTION=21
  24. #get host name (a part of bin log file names,
  25. #  if change set master bin file manual, need change this)
  26. HOST=`hostname -s`
  27.  
  28. #set mysql version
  29. MYVERSION="4.1"
  30.  
  31. if [ "$MYVERSION" = '4.1' ] || [ "$MYVERSION" = '5.0' ] ; then
  32.   #purge master logs to latest backup time (remain one hour bin log for slave replication delay)
  33.   PURGELOGS="mysql $MYACC -e \"PURGE MASTER LOGS BEFORE DATE_SUB( NOW(), INTERVAL 1 HOUR )\""
  34. else    
  35. echo "not support MYSql Ver $MYVERSION"
  36. exit 1
  37. fi
  38.        
  39. #check param input (daily or hourly)
  40. if [ ! $1 ];
  41. then    
  42.   read -p "Backup Interval? (Hourly|Daily) : " INTERVAL
  43. fi    
  44.  
  45. case $INTERVAL in
  46.   hourly | HOURLY | Hourly | H | h | 1 )
  47.   echo "Performing hourly level backup — `date`"
  48.   MYCMD="mysql $MYACC -e \"FLUSH LOGS\""
  49.   eval $MYCMD
  50.  
  51.   if [ -d $BASE_BAK_DIR/$DATE ] && [ "$MYVERSION" = '4.1' -o "$MYVERSION" = '5.0' ] ; then
  52.      rsync -aub $DATADIR/$HOST-bin.?????? $BASE_BAK_DIR/$DATE
  53.   else    
  54.      echo "dest dir not exists! please run daily backup first." 1>&2
  55.      exit 1
  56.   fi
  57.   exit 0
  58.   ;;
  59.  
  60.   daily | DAILY | Daily | D | d | 2 )
  61.   echo "Performing daily level backup — `date`"
  62.   # check dest path
  63.   if [ ! -d $CUR_BAK_DIR ]; then    
  64.      echo "Creating $CUR_BAK_DIR"
  65.      mkdir -p $CUR_BAK_DIR
  66.   fi
  67.  
  68.   MYCMD="mysqlhotcopy $MYACC –regexp=.* $CUR_BAK_DIR"
  69.   eval $MYCMD
  70.   chown -R mysql: $CUR_BAK_DIR/
  71.   mv $CUR_BAK_DIR $BASE_BAK_DIR/$DATE
  72.   eval $PURGELOGS
  73.  
  74.   #delete files that outdate
  75.   find $BASE_BAK_DIR -ctime +$RETENTION -exec rm -rf '{}' \;
  76.   exit 0
  77.   ;;
  78.  
  79.   * )
  80.   echo "Invalid Selection" 1>&2
  81.   exit 1
  82. esac

可以在脚本的前面指定好备份目录参数

DATADIR="/var/lib/mysql"
BASE_BAK_DIR="/backup"
CUR_BAK_DIR="$BASE_BAK_DIR/current"

以及用来连接数据库的账号的参数

#set mysql user name and password
MYSQL_USER="root"
MYSQL_PWD="rootpwd"

通过参数 RETENTION=21 来指定备份文件保留的天数，要视具体用来做备份的磁盘大小和数据库大小做综合衡量处理。

最后将脚本添加到crontab中定时运行
首先设定每天备份一次的，然后再设定每小时的备份，其中第一次的每小时备份应该是在每天备份执行之后。
数据库发生失败时的恢复在每日全量备份基础上通过日志文件快速恢复到最近时间的变化。

Popularity: 7% [?]

Related

Tags：, .
October 20, 2008 | Filed Under MySQL | 2 Comments 

MySQL主从结构灾难恢复策略机制设想

当数据库服务器建立好以后，我们一般为了安全以及性能考虑，对数据库建立一个主从结构配置。但是这样做了以后查询性能是得到了提高，但是数据库的安全性真的像我们想的那样，主库坏掉了可以使用从库顶上使用吗？
考虑如下一种情况：
数据库服务器不是发生故障，而是被黑客黑了，黑客将其中一个数据表删除了，只时候我们建立的从库还有作用吗？
答案是：
没有用，因为从库上也会执行主库上所执行的操作，将这个表删除了，这个表的数据在主库和从库上都不存在了，里面的数据再也回不来了。

由此我们在建立了主从服务器后还要做好数据库的备份策略，保障在数据库遭到破坏后(物理损坏或黑客破坏)，可以迅速恢复到最后一次正常的状态，使得数据的损失达到最小，同时要考虑做恢复操作所需要花费的时间（1分钟，10分钟，1小时，1天?)。

备份策略考虑

恢复策略考虑

1. 主服务器数据被黑客篡改破坏

这个时候从库备份的数据无效，因为从库的数据也被破坏，需要重备份的数据中恢复。
情况一: 主库的机器未被黑，只是数据库被黑，数据破坏
处理方法: 停止主库服务，修改主库的my.cnf 文件使其数据库文件目录指向到备份的数据库目录，根据备份的数据重做从库数据库。
情况二: 主库的机器被黑，整个机器失去控制，同时数据被破坏。
处理方法: 启动利用其他机器上最近备份的全量数据，建立新的数据库服务。

2. 主库数据由于意外原因丢失，但是未发生数据篡改

比如主数据库机器虽未被黑客攻击，但是只是停了相关服务，未对数据做篡改破坏。
或机器由于意外原因发生物理损坏不可用，但是未有发生数据被篡改。
处理方法1: 直接使用从库切换
将从库中的一台变更为主库，更改其他从库的主库连接设置，使他们从这台新设的主库机器上复制数据。
处理方法2: 安装数据被篡改的方式处理。

策略原则
鸡蛋不能放在一个篮子中，当一个篮子坏掉了，还有其他篮子可用。
所以数据要在多处以及多种方式做备份恢复处理。

参考:
1. Mysql Slave群切换Master (from alidba)
2. 数据库的自动备份与数据库被破坏后的恢复（mysqlhotcopy）

Popularity: 7% [?]

Related

Tags：, , .
October 20, 2008 | Filed Under MySQL | 1 Comment 

MySQL从库配置维护回顾

因前两天的MySQL从库运行出现问题见 MySQL从库损坏后重建，顺便将MySQL的从库配置维护温习了一下。


MySQL从库建立配置方法(针对MyISAM数据库)

1.主库上的设置

a.my.cnf中的mysqld节主要设置 server-id 和 log-bin 参数 

log-bin
server-id=1
log-bin=my-binlog

b.数据库中创建 从库复制 用的账号。

  1. GRANT replication slave,reload,super ON *.* TO 'myslave'@'192.168.0.200' IDENTIFIED BY 'myslavepwd'

2.从库上的设置

my.cnf中的 mysqld 节主要设置 server-id ,从库的server-id 不能和主库或其他从库相同 

master-host=192.168.10.100
master-user=myslave
master-password=myslavepwd
master-port=3306
server-id=2
master-connect-retry=60

3. 给从库准备初始的主库数据

先在主库中执行

  1. FLUSH TABLES WITH READ LOCK;
  2. SHOW master STATUS;

记录下日志位置信息,

a. 冷备份

将数据库停掉,然后做数据库物理数据文件的拷贝。

b. 热备份

不停止数据库，直接在线做数据文件拷贝，拷贝完后在执行 unlock tables; 命令将数据表的锁释放

c. 热备份

使用 mysqldump 命令，导出数据库的数据。导出完成后使用 unlock tables;命令将数据表的锁释放

4. 将从库和主库连接前来

a. 停止从库运行
b. 给从库的my.cnf文件中添加 skip-slave-start 参数
b. 将从主库备份的文件拷贝到数据目录下
c. 开启从库服务器
d. 用账号登陆到从库数据库，使用 change master to 命令修改主库服务器的连接信息。其中日志位置信息为
e. 使用 slave start; 开启从库进程的运行，在 show slave status\G;查看从库状态
f. 修改 my.cnf 文件，将 skip-slave-start 参数注释掉，以便在下一次运行数据库服务时自动开启从库复制


也可以在从库上执行 LOAD DATA FROM MASTER; 来导入主库中的数据（一般不建议这种方法）

5.关于维护一些问题

1.主库的日志清理

日志文件要定期清理，要不然如果频繁做更新插入操作时会很占磁盘空间。使用 purge 命令处理,不过要小心，如果和从库接不上，从库就要重做了。

  1. purge master logs TO ‘binlog.000004’;
  2. purge master logs before '2008-10-12 22:10:00';

可以在主库的 mysqld 节设置 expire_logs_days 参数，自动将 一些天前的日志清除。

expire_logs_days=21

2.从库的relaytime监测

在从库上使用 show slave status\G; 查看从库的运行状态，及时做故障修复处理。

3.定期的全库备份

为了安全考虑，定期做数据库的全量复制备份。
可以使用 www.innodb.com 公司的 ibbackup 程序和 innobackup 脚本做自动话的备份处理.
————–
对MySQL的备份还可以参见: 常见MySQL数据库备份工具和备份方式比较
还可以参见
MySQL性能优化工作小结

Popularity: 7% [?]

Related

Tags：.
October 17, 2008 | Filed Under MySQL | Comments Off 

MySQL从库损坏后重建

MySQL的从库由于意外原因导致和主库不能同步，需要重新建立从库。

因为发生了异常，从库目录下生成了 几十万 个的 localhost-relay-bin.xxxx 文件, 到了从库的mysql目录下，一个不小心 ls 或 tab 键 机器就假死，失去反应。

首先清除从库数据库目录下的 几十万 个的 localhost-relay-bin.xxxx 文件。
在目录下执行

  1. rm *relay-bin.*

命令执行失败。
通过一番尝试，使用如下命令删除，删除了很久(快一个小时)

  1. find . -name "*relay-bin.*" -exec rm {} \;

因为已经有原先同步过的许多数据，很多表的数据没有变化。准备采用rsync/scp方式将主库的文件拷贝过去。

步骤:
1.首先在主库上执行

  1. FLUSH TABLES WITH READ LOCK;
  2. SHOW MASTER STATUS;

记录下信息。
注： 如果文件比较多，要拷贝很长时间，最好是在SHOW MASTER STATUS 后另开一个ssh窗口，将mysqld服务停止，等拷贝完以后再开启。

2.在从库机器上，停止从库，执行rsync拷贝文件命令

  1. #同一台机器上做拷贝备份
  2. #cp -rpv /var/lib/mysql/  /backup/20080512/
  3. #scp -rpv masterip:/var/lib/mysql/*  /var/lib/mysql/
  4.  
  5. #不同机器做压缩拷贝同步更新，
  6. rsync -avuzr -e ssh mainserverip:/var/lib/mysql/ /var/lib/mysql/

3. 在主库上执行

  1. UNLOCK TABLES;

释放对主库的全局锁，恢复主库的正常使用。

4.修改从库中连接主库的信息
首先修改参数，设置为启动服务时不启动slave进程。修改my.cnf配置,在 [mysqld] 段添加开关

skip-slave-start

运行从库数据库，使用账号登陆到mysql，使用前面步骤 1 记录下来的信息修改从库连接主库的设置。

  1. CHANGE MASTER TO MASTER_HOST='hostip', MASTER_PORT=3309,MASTER_USER='slave', MASTER_PASSWORD='slave',MASTER_LOG_FILE='local-bin.00012',MASTER_LOG_POS=32432

SQL命令中不要忘记对地址，账号，密码和文件名参数的值加引号。
开始从库进程

  1. START SLAVE;

使用

  1. SHOW SLAVE STATUS\G;

查看slave进程的状态。如果在做库文件拷贝的时候没有锁好库，会看到slave sql thread 有执行错。
碰到 

Error: Got error 134 from storage engine

的可以通过

  1. REPAIR TABLE tbName

来修复，还有一些可以通过

  1. SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
  2. SLAVE START;

可以简单跳过错误处理。如果错误厉害一点的，这么处理不行，那就重新来过吧。

修改配置文件 my.cnf 将前面的开关复位 skip-slave-start 注释掉,在下次机器重新启动时自动开始 slave 进程。

对于inodb数据库需要使用sqldump的方式做数据的导出和再导入
可以在这个地址申请下载 ibbackup 的30天试用版，并配合 innobackup-1.5.0 备份脚本 来做热备份。

Popularity: 6% [?]

Related

Tags：.
October 15, 2008 | Filed Under MySQL | 1 Comment 

安装配置Nginx 0.6.32 +php 5.2.6(fastcgi) + Mysql 5.0.51

安装过程参考: http://blog.s135.com/read.php/314.htm

安装 mysql 5.0.51

安装 php 5.2.6

安装 nginx

nginx的中文Wiki站点 http://wiki.codemongers.com/NginxChs
niginx的英文站点 http://nginx.net

配置开机启动Mysql+Phpcgi+Nginx

因为没有安装服务，需要添加一些命令到 /etc/rc.local 中用来开机启动

  1. ulimit -SHn 51200
  2. /bin/sh /usr/local/mysql5051/bin/mysqld_safe –defaults-file=/usr/local/mysql5051/my.cnf &
  3. /usr/local/php526/spawn-fcgi -a 127.0.0.1 -p 10080 -C 30 -u www -f /usr/local/php526/bin/php-cgi
  4. /usr/local/nginx632/sbin/nginx

设置iptables

在防火墙中放开相关服务端口。

  1. #web port
  2. -A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
  3. #fastcgi port
  4. -A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 10080 -s 127.0.0.1 -j ACCEPT
  5. #mysql 本地通过unix socket访问, 不用设置
  6. -A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp -s 127.0.0.1 –dport 3306 -j ACCEPT

使用 /sbin/service iptables restart 重新应用防火墙规则

验证服务状态

验证 nginx + php 运行是否正常。
在 /var/www/xxt.igrow.cn 目录下建一个test.php,里面存放内容

  1. <?
  2.      echo phpinfo();
  3. ?>

通过 curl http://127.0.0.1/test.php 可以看到输出的php信息,表示 nginx + php 运行正常。

Popularity: 6% [?]

Related

Tags：, , , , , , , .
July 11, 2008 | Filed Under LAMP, MySQL, WebServer | 4 Comments 

← Previous Page — Next Page →