解决 MySQL 的 Table is marked as crashed and should be repaired 问题

昨天一位 VPS 客户说他的 WordPress 博客没了,网站可以打开,但是文章都没了,怀疑被黑。我们登陆客户 VPS 后没发现被黑迹象,然后进入 MySQL 数据库发现 Table ‘./wordpress/wp_posts’ is marked as crashed and should be repaired 错误,因为 wp_posts 表被损坏了,所以 WordPress 的文章都显示不出来:

# mysql -u root -p
Enter password:

mysql> use wordpress;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select * from wp_posts;
ERROR 145 (HY000): Table './wordpress/wp_posts' is marked as crashed and should be repaired
mysql> Bye

修复 MySQL 数据库数据表问题可以由 mysqlcheck 来解决,先用 mysqlcheck 查看一下:

# mysqlcheck -u root -p wordpress
Enter password:

然后添加 –auto-repair 参数自动修复,最好修复前备份一下数据库:

# mysqldump -u root -p wordpress > wordpress.sql
Enter password:

# mysqlcheck -u root -p wordpress --auto-repair
Enter password:
wordpress.wp_commentmeta
error    : Table upgrade required. Please do "REPAIR TABLE `wp_commentmeta`" or dump/reload to fix it!
wordpress.wp_comments
error    : Table upgrade required. Please do "REPAIR TABLE `wp_comments`" or dump/reload to fix it!
wordpress.wp_links
error    : Table upgrade required. Please do "REPAIR TABLE `wp_links`" or dump/reload to fix it!
wordpress.wp_options
error    : Table upgrade required. Please do "REPAIR TABLE `wp_options`" or dump/reload to fix it!
wordpress.wp_postmeta
error    : Table upgrade required. Please do "REPAIR TABLE `wp_postmeta`" or dump/reload to fix it!
wordpress.wp_posts
error    : Table upgrade required. Please do "REPAIR TABLE `wp_posts`" or dump/reload to fix it!
wordpress.wp_term_relationships                OK
wordpress.wp_term_taxonomy
error    : Table upgrade required. Please do "REPAIR TABLE `wp_term_taxonomy`" or dump/reload to fix it!
wordpress.wp_terms
error    : Table upgrade required. Please do "REPAIR TABLE `wp_terms`" or dump/reload to fix it!
wordpress.wp_usermeta
error    : Table upgrade required. Please do "REPAIR TABLE `wp_usermeta`" or dump/reload to fix it!
wordpress.wp_users
error    : Table upgrade required. Please do "REPAIR TABLE `wp_users`" or dump/reload to fix it!

Repairing tables
wordpress.wp_commentmeta                       OK
wordpress.wp_comments                          OK
wordpress.wp_links                             OK
wordpress.wp_options                           OK
wordpress.wp_postmeta                          OK
wordpress.wp_posts                             OK
wordpress.wp_term_taxonomy                     OK
wordpress.wp_terms                             OK
wordpress.wp_usermeta                          OK
wordpress.wp_users                             OK

vpsee.com 改版(失败)了!

(7月12日更新:改版失败,差评比好评多得多,不得不恢复到原状,不过时间没有白费,折腾一下还是学到不少东西~)

四年都没有改版,不知道大家看这个博客有没有审美疲劳,反正俺是有点看不下去了,特别是现在看多了扁平化设计后再回头看有点 “不适”。现在不是扁平化(flat)都不敢拿出去 show,好吧,俺被感染了,上周末花了点时间重新设计了 vpsee.com,加上一些陆陆续续的补补丁丁,改版已经基本完成。

根据 2013 Web Design Trends Infographic 的图示和理解,今年网站设计的趋势包括以下几点:responsive, metro or “flat”, minimalism, typography, parallax, infinite scrolling, content first, fixed header, single page websites, and large image backgrounds. 我们的改版选择了 responsive, flat, minimalism, content first 这几个关键字。

现代社会的特点是东东极为丰富,给用户和消费者的选择太多,选择多是好事,坏事是不知道选哪个,害怕自己把持不住眼花缭乱的世界,所以定了两条原则:“内容优先” 和 “简单”。不管 flat or not flat,不管是否大图片背景,不管响应设计还是不响应,都要遵循 content first 和 simplicity (and minimalism).

有了基本指导思想,做事的速度就快多了。唯一纠结的问题是导航条是选择放在上面(fixed header)还是放在左边(vertical navigation),vertical navigation 也是今年的流行趋势之一。貌似大部分网站都在用 fixed header,决定尝试一下 vertical navigation.

工具方面,Twitter 的 Bootstrap 觉得有点笨重,不符合我们的最简原则,所以选用了另一个小巧的 CSS 库:Pure. 中文的排版方面参考了 TYPO.CSS.

有了神器 Pure 相助,重写 WordPress 模版花了不到一小时。欢迎大家测试和意见,如果这个新版设计太糟糕,请留言告知你所使用的浏览器和分辨率以便调试,谢谢。

新版
vpsee.com 2.0

旧版
vpsee.com 1.0

使用 HHVM 运行 WordPress

Facebook 在以前的 HPHPc, HPHPi 和 HPHPd 的基础上开发了一套全新的 HipHop VM for PHP (HHVM),使用 JIT(Just-In-Time)编译技术可以快速生成代码和即时编译。据 Facebook 称,HHVM 的性能是 Zend PHP 5.2 的5倍多,更重要的是 HHVM 是开源的~

现在运行 WordPress/Drupal 等流行 PHP 应用程序的流行环境搭配是 Nginx/Apache + MySQL + PHP,我们来看看 HHVM 这个神器能不能搞定 WordPress. HHVM 可以当作一个独立服务器使用,不需要搭配其他的 web 服务器。

首先更新系统(这里采用 Ubuntu Server 12.04 LTS 版本)和升级,然后后安装 php, mysql(hhvm 可以单独运行,不需要安装 apache):

$ sudo apt-get update && apt-get upgrade

$ sudo apt-get install mysql-client mysql-common mysql-server php5 php5-cli php5-common php5-cgi php5-mysql

加入 hiphop 源,更新后安装 hiphop-php:

$ sudo echo "deb http://dl.hiphop-php.com/ubuntu precise main" >> /etc/apt/sources.list
$ sudo apt-get update
$ sudo apt-get install hiphop-php

创建 wordpress 所需要的数据库:

$ mysql -uroot -proot
mysql> create database wordpress;
mysql> Bye

下载 wordpress 后解压、修改配置文件连上数据库:

$ cd /var/www
$ sudo wget http://wordpress.org/latest.tar.gz
$ sudo tar -zxf latest.tar.gz
$ sudo chown -R www-data:www-data wordpress

$ cd wordpress
$ sudo cp wp-config-sample.php wp-config.php
$ sudo vi wp-config.php
...
/** The name of the database for WordPress */
define('DB_NAME', 'wordpress');

/** MySQL database username */
define('DB_USER', 'root');

/** MySQL database password */
define('DB_PASSWORD', 'root');
...

修改 wp-db.php:

$ sudo vi wp-includes/wp-db.php
...
/**
 * @since 0.71
 */
//define( 'OBJECT', 'OBJECT', true );
define( 'OBJECT', 'OBJECT' );
define( 'Object', 'OBJECT' );
define( 'object', 'OBJECT' );
...

配置 hhvm(只需要加一个配置文件就行):

$ sudo vi /etc/hhvm.hdf
Server {
  Port = 80
  SourceRoot = /var/www/
}
 
Eval {
  Jit = true
}
Log {
  Level = Error
  UseLogFile = true
  File = /var/log/hhvm/error.log
  Access {
    * {
      File = /var/log/hhvm/access.log
      Format = %h %l %u %t \"%r\" %>s %b
    }
  }
}
 
VirtualHost {
  * {
    Pattern = .*
    RewriteRules {
      dirindex {
        pattern = ^/(.*)/$
        to = $1/index.php
        qsa = true
      }
    }
  }
}
 
StaticFile {
  FilesMatch {
    * {
      pattern = .*\.(dll|exe)
      headers {
        * = Content-Disposition: attachment
      }
    }
  }
  Extensions {
    css = text/css
    gif = image/gif
    html = text/html
    jpe = image/jpeg
    jpeg = image/jpeg
    jpg = image/jpeg
    png = image/png
    tif = image/tiff
    tiff = image/tiff
    txt = text/plain
  }
}

创建运行 hhvm 所需的 log 目录,运行 hhvm:

$ sudo mkdir /var/log/hhvm/
$ sudo /usr/bin/hhvm --mode daemon --user www-data --config /etc/hhvm.hdf

用浏览器访问 http://IP address/wordpress/ 就应该可以看到 wordpress 安装界面了,按提示安装完后使用一下,看看有啥问题。同时检查一下 hhvm 日志,看看是否有访问纪录:

$ sudo tail /var/log/hhvm/access.log

WordPress 和 APC 的小问题

昨天晚上给一位付费客户安装 APC PHP 加速器 的时候发现一个小问题,访问 WordPress 页面没问题也可以看到 WordPress 管理后台页面,但是无法登录,报错如下:

Fatal error: Call to undefined function wp_dashboard_setup() in /home/vpsee/wordpress/wp-admin/index.php on line 15

关闭 APC 后这个问题就消失了,只要一打开 APC 就报错,进一步调查把问题缩小到一个 APC 配置参数上 apc.include_once_override=1,如果设置成 apc.include_once_override=0 就没有问题。根据 APC 参考手册的说明,apc.include_once_override 参数是用来 Optimize include_once() and require_once() calls and avoid the expensive system calls used. 一般的建议是设置成0(关闭这个选项)。现在解决办法有两个,一个是设置 apc.include_once_override 为 0(这样会影响到所有网站,所有 PHP 站都不能用到 apc.include_once_override 这个优化了):

# vi /etc/php.d/apc.ini

...
apc.include_once_override = 0
...

另一个办法是修改 WordPress 文件(这样只会影响到一个 WordPress 网站),打开 wp-admin/index.php 文件找到 require_once(ABSPATH . ‘wp-admin/includes/dashboard.php’); 这行注释掉后修改成如下:

# vi /home/vpsee/wordpress/wp-admin/index.php

...
/* require_once(ABSPATH . 'wp-admin/includes/dashboard.php'); */
require_once('./includes/dashboard.php');
...

备份 WordPress 博客到 Dropbox

有很多用户在我们的 VPS 上搭建了 WordPress 博客,出于成本的考虑,我们不对 VPS 做任何备份,数据中心里额外的最普通的 FTP 存储每 10GB 至少10美元每月,备份一个 256MB 10GB 的 VPS 就要10美元每月,这个价格可以再买一个 VPS 呢,我相信我们和我们的用户都无法承受这个价格。但是备份又是一件非常重要的事情,所以一个折衷的办法就是采用第三方某种形式的免费网络存储来做选择性的备份,比如用 Gmail 备份数据库文件、用 Dropbox 备份小博客或者购买其他服务商那种只要4美元的 OpenVZ VPS 来做备份等。

WordPress 有个 wp Time Machine 插件可以将 wp-content 下的所有内容和数据库整体打包,然后备份到 Dropbox, Amazon S3 或者 FTP 服务器上。本来想这个 wp Time Machine 插件肯定有很多人在用了,再写一篇博客有点浪费,让人惊讶的是 VPSee 在 Google 上搜索 ”wp Time Machine 插件“ 却没有发现一篇相关的中文介绍。使用和设置 wp Time Machine 非常容易,对于 vpsee.com 的读者群和玩 VPS 的用户来说完全不用详细介绍:D

在 WordPress->Settings->wp Time Machine 里设置 wp Time Machine:

backup wordpress blog to dropbox

上传到 Dropbox 后:

backup wordpress blog to dropbox

谢谢 “我就是 Dianso” 博主的提示,这个插件有安全问题,会在 wp-content 中保留备份的包,任何人都可以根据 wp-content/wpTimeMachine-archive.tar.gz 下载这个包并得到 wordpress 的数据库文件,所以上传到 DropBox 后不要忘了在 wp-content 里删除这个文件。

给 WordPress 加上简单的 Gtalk 状态显示

大家可能注意到博客右边的 “用服通知” 增加了我们 Gmail/Gtalk 的状态信息,方便我们的 VPS 用户随时了解我们的在线状态以便提供及时的服务响应。本来想找个 WordPress 插件完成这个简单功能,在网上搜到一个 “GTalk Status to WordPress” 插件,解开一看有点夸张,3个文件加起来1200多行程序,有点 overkill 了,VPSee 只想显示 Gtalk 的基本状态信息,在线还是离线,就一句话的功能。

首先到 http://www.google.com/talk/service/badge/New 页面定制一个 Gtalk chatback badge,如果想偷懒直接用 Google 生成的 HTML 代码嵌到自己的 WordPress 就可以了,就有了一个可显示状态的插件,问题是这个 Gtalk 插件还能聊天,我们只是想显示在线的状态而已,不需要聊天功能。

gtalk chatback badge

把 Google 生成的那段 HTML 代码取出来,只取一部分:

iframe src="需要截取的部分&w=300&h=18" frameborder="0" allowtransparency="true"

然后在 WordPress 的主题文件的适当位置加入下面的 PHP 代码:

// written by vpsee.com
$url = 'http://www.google.com/talk/service/badge/Show?tk=需要截取的部分';
$from_google = file_get_contents($url);
$status = array();
if (preg_match('|img id=\"b\" src=\"/talk/service/resources/([\w]*)|', 
$from_google, $status)) {
    echo $status[1]=='offline'?'离线':'在线';
} else {
    echo 'gtalk error';
}   

嗯,8行代码就搞定,就这么简单。

64MB 的 VPS 能支持多少访问量?

有个学生在 WebHostingTalk 上发帖请教 VPSLink 的 64MB VPS 是否撑得住18个静态网站的托管,后面有很多所谓的 ”专家“ 跟帖:

I do not believe you can host 18 websites on 64MB of RAM. I’d bump that up to at least 128 or 256.

I’d suggest 256 MB minimum. 128 MB might suffice if you really know what your doing (for memory optimization) but you may encounter problems getting things installed without burst memory or swap.

I really wouldn’t advise anything lower than 265MB RAM for website hosting. Seriously, even if you do use LXAdmin with Lighttpd and any other optimization, it’ll still not be enough.

所谓的 ”专家“ 都不相信 64MB 的 VPS 能应付那个学生的要求。那到底 64MB VPS 能不能用来托管18个静态网站呢?18个网站听上去好像很多,其实可以看作是一个网站只不过多了一些 HTML 页面而已。那个学生的问题要看具体网站访问量来定,不过就一般的静态网站来说,64MB 的 VPS 绰绰有余。lowendbox.com 写了一篇文章 “Yes, You can Run 18 Static Sites on a 64MB Link-1 VPS” 来反驳 “专家”。VPSee 完全站在 lowendbox 这一边,并且 VPSee.com 可以证明 64MB VPS 足够支持一个每天 700PV 左右的 WordPress 博客,VPSee 估计每天 1000PV 左右也是可以扛得住的。

为了证明 64MB 的 VPS 可以干很多事,VPSee 注册了一个 VPSLink 的 64MB VPS,详细看这里:VPSLink 试用),然后把自己另外一个 PV 在700左右的博客搬了过去,经过下面一番优化之后:

继续阅读 »

Nginx+FastCGI 运行 WordPress 和 WP Super Cache

wordpress

有了一个自己的 VPS 主机以后就自由多了,拥有 root 访问权限,几乎可以做任何事情,VPS 一开通我就迫不及待的想要用 nginx 换掉笨重的 apache,share hosting 就没那么幸运了,只能给什么用什么了。

WP Super Cache 是一个 WordPress 插件,用来给 WordPress 提供缓存,也就是说用户请求一个 WordPress PHP 页面后,WP Super Cache 会把结果转化成 HTML 文件保存下来,这样下次用户访问同一个页面的时候就会优先访问那个已保存的 HTML 文件,这样中间就没有 PHP 解析的过程,所以速度非常快,是高流量博客的必备插件。

说明一下为什么需要 FastCGI?Nginx 体积很小,本身不带 CGI 模块,所以需要和第三方配合以支持各种动态脚本的解析。这些解析脚本是如何和 web server 交流的呢?这时需要一个叫做 FastCGI 的支持。那么什么是 FastCGI 呢?FastCGI 是一个外部程序和 web server 之间打交道的协议/接口,有点像应用程序 API 和操作系统之间的关系。与老的 CGI 比起来,FastCGI 可以同时启动多个进程,而 CGI 程序只能运行在一个进程里,这意味着 FastCGI 的性能比 CGI 好得多;FastCGI 的运行完全和 web server 独立,就是说即使 FastCGI down 掉了也不会影响到 web server。

目前较普遍的有两种方法支持 FastCGI,一种是用 lighttpd 的 spawn-fcgi 程序;另外一种是直接用内嵌在 PHP 里面的 php-cgi。这里以第一种方法(spawn-fcgi)为例。

CentOS 上安装 nginx+spawn-fcgi

安装 nginx 和 spawn-fcgi

# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/
epel-release-5-3.noarch.rpm

# yum install nginx
# yum install spawn-fcgi


继续阅读 »