VPS 转移

我在这次购买新的 VPS 的时候之前的一段时间里，由于长时间没有上 VPS 的终端，因此对于 VPS 的一些设定什么的都忘的差不多了。那时我一直对于再次登陆 VPS 的终端有种排斥的感觉。当我的新 VPS 开通后，如何转移数据让我头疼了一阵子。好在现在已经转移成功，我可以写一篇文章把当中出现过的一些问题给记录下来，之后再遇到类似情况可以轻松一些。

其实 Linux 系统的数据转移很简单，反正都是文件，开通 FTP 之后镜像一下就一切搞定。不过我在之前的一篇文章中说过，我这次想要用与过去不同的软件来搭建主机，所以有些东西需要重新配置。对于新软件不熟悉，导致了这次的一些问题的发生。不过这也是一次学习机会，通过这次转移，我又积累了一些服务器方面的经验。

先说一下我过去用的软件吧：Debian 5.0 + Lighttpd + PHP-CGI + MySQL + phpMyAdmin + MemCache + Exim4 + vsftpd。我这次用的软件为：Debian 6.0 + Nginx + PHP-FPM + MySQL + Exim4 + vsftpd。操作系统方面都是 Debian，没什么问题。Web 服务器需要重新配置。我过去用过 Nginx 建网站，不过当时用的也是 PHP-CGI，所以有些参数的位置不同。数据库方面，我过去的所有操作都是通过 phpMyAdmin 来完成的，而对于用 SQL 语句来操纵用户权限，我没有接触过。我的站点规模都很小，因此从之前的经验上看来 MemCache 没有起太大的作用，所以这次就没有再用它。其它的邮件和 FTP 服务器都是一样的。

Web 服务器

Nginx 和 Lighttpd 的配置都挺简单的，看一下例子把内容按照自己的需求修改一下就可以了。不过因为用的软件不同，有些配置都变了位置。比如说 PHP 进程的个数，原来在 Lighttpd 的配置文件里可以设定，现在需要去 /etc/php5/fpm/pool.d/www.conf 里面设定。

我这次使用 WordPress 遇到了几次内存限制的问题。由于缓存方面配置的失误（缓存那部分说），我没有通过转移数据库的方式来转移 blog，而是在新 VPS 上新安装了一个 WordPress，然后从旧的 WordPress 那里选择 export 后再在新 WordPress 那里 import。本来我觉得这么操作不会有任何问题的，结果上传文件的时候我收到了这样的错误信息：

nginx 413 Request Entity Too Large

搜索这句话，我找到了这个页面。有人回复说这是 Nginx 客户端请求的限制，也就是 HTTP header 里 Content-Length 大小的限制。在 /etc/nginx/nginx.conf 中 http { 下面添加一行 client_max_body_size 4M; 之后问题解决。这个值默认是 1M，而我的 WordPress 导出文件大小是 2.6M，明显超出了这个限制。

修改了 Nginx 的限制之后，我成功的上传了文件。之后我看到如下结果：

我用 Google 搜索到了这么个网页，作者遇到了和我一样的问题。我从其中一篇回复中找到了线索。回复中说增加 PHP 的 memory_limit 可以解决问题。他给出的方法是在 /wp-admin/import/wordpress.php 文件中添加 ini_set("memory_limit","24M"); 这么一行。我照做了后页面直接打不开了，不知道是哪里出的问题，于是我干脆直接修改了 php.ini 文件中的 memory_limit 设定。安装好 PHP 后的默认设定为 160M，我的 VPS 内存限制是 256M。最开始我把它设定成 16M，因为我上一个 VPS 就是这样设定的。我这次把它改成 50M，再次导入，结果问题解决。为了防止内存使用超标，我再导入成功之后又把这个值给改成了 16M，结果之后又引起了问题了。

我不大喜欢在 WordPress 的 web 后台上直接写文章，因为在有些浏览器里你不小心按了某个快捷键刷新/前进/后退了页面，就可能导致文本框里的文字消失，非常讨厌。我购买了 MarsEdit 来从本地上写文章，需要的设定很全面，完全可以不用登陆就正常的发表文章。这次把 WordPress 的数据导入之后，我首先要测试一下 MarsEdit，确保可以离线更新 blog。打开 MarsEdit 之后我点刷新，结果又有了错误提示了：

Can’t get recent posts because the server reported an error: unexpected response code 500.

通过搜索，我找到了这个页面。作者遇到了类似的问题，回复的人似乎是 MarsEdit 的开发者，他也提到了内存限制的问题，给出的解决方法是把 MarsEdit 的同步文章的数量降低一下，结果问题解决。虽然我的问题不是文章数量的问题，不过开发者也给了相关思路。我调大了 memory_limit 的值，结果问题解决。看来这个值太低的话会引起许多问题，不过我之前用 Lighttpd + PHP-CGI 的时候没有遇到这样的问题。通过在 MarsEdit 中不断的刷新，我渐渐的找到了一个大概的临界值。我把 memory_limit 设定为 32M 的话就不会出问题。我这个新 VPS 的内存又 256M，比上一个最开始时的 80M 的条件好太多了，内存使用完全不必那么抠了。

数据库

我再使用 VPS 之前，用的是和别人合租的 Site5 虚拟主机。那里的 MySQL 数据库没有修改默认的字符集，结果我从 phpMyAdmin 里看到了一大堆乱码。那时我没有什么兴趣仔细在 phpMyAdmin 里通过 SQL 来调整字符集的设定，而且用的 Movable Type 和 MediaWiki 都支持 Sqlite 3 数据库，因此我就没有使用 MySQL。用了 VPS 之后，我把 blog 软件换成了 WordPress。WordPress 到版本 3 之后 PDO 插件就不兼容了，要安装版本 2 导入数据库后再升级成 3 太麻烦，而且我又有了 MySQL 数据库的完全控制权限，我也对 MySQL 的操作稍微熟悉一点了，所以我就选择了 MySQL 作为 blog 和 wiki 的数据库。虽然比不上 Sqlite 3，但 MySQL 在熟悉了之后一样比较方便。

我在用上一个 VPS 的时候，MySQL 的所有设置都是通过 phpMyAdmin 来完成的。我是通过 Sqlite 3 学习的数据库，因此对用户和权限的操作没有接触过。phpMyAdmin 可以很方便的对数据库做各种设定。不过 Debian 下的 phpMyAdmin 安装包依赖一个 web 服务器，而且它默认只对 Apache 2 和 Lighttpd 提供支持。如果你装了这两个 web 服务器之一的话，再安装的时候告诉系统你用的是哪一个 web 服务器就好了，系统可以自动设定好各种配置，安装结束后直接用浏览器访问 localhost/phpmyadmin 就可以用了。而我没有装这两个服务器，系统会自动把 Apache 2 加到依赖列表里，非常讨厌。我印象里应该有选项可以禁止自动安装 Apache 2 的，但懒得去查，所以干脆不用 phpMyAdmin 了，借着这个机会学习一下 MySQL 的相关操作。

没有了 phpMyAdmin，MySQL 的备份与恢复就需要在命令行上完成了。这其实并不难。我参考了这篇文章，按照里面提供的说明与示例，通过 mysqldump 来导出数据库，这些选项文章里讲的都很清楚。

导出了数据库之后，我发现我还没有修改新 VPS 上的默认字符集编码。搜索一下，找到了这篇文章。按照文章里说的，在 [client] 和 [mysqld] 下面添加 default-character-set=utf8，并在 [mysqld] 下面多添加一行 init_connect='SET NAMES utf8' 就可以了。

导入数据库特别简单，按照上面那篇文章中说的做就行，其实就是用重定向把导出的 SQL 文件中的语句用 MySQL 执行一遍，非常简单。

缓存

过去我主要是因为好奇，所以给 VPS 加装了 MemCache 来用缓存数据库。其实我这么个小网站根本不需要数据库缓存，而且我一共 80M 的内存还用来缓存数据库看上去也有点可笑。所以过了瘾之后，我决定在这个新的 VPS 上不使用 MemCache 了。我本来觉得这挺简单的，只要把 WordPress 和 MediaWiki 里有关 MemCache 的设定注释掉就好了，结果 WordPress 这一关给卡住了，总是提示我系统没有安装 MemCache。我现在不确定我当时有没有在 wp-config.php 里正确的注释掉 MemCache 的设定了，现在回想起来似乎我没有注意最关键的那一行。不过我当时没有发现，所以我重头安装了 WordPress。不过这样也好，让我重新清理了一下 WordPress 的设定，而且这次 WordPress 的 Pingback 又出来了，如果我导入成功了 WordPress 的数据库的话那么 Pingback 未必就能正常工作。

在转移 MediaWiki 的时候，我成功的注释掉了相关的设定，结果一切正常。

邮件和 FTP

我对 VPS 的邮件设定没有什么特殊的要求，只需要可以让系统正常发送 WordPress 给我发送的新评论通知邮件就可以了。FTP 也是如此，只要我可以用 lftp 登陆 VPS 传输文件就可以了。因此我这两个软件选择的是 Exim4 和 vsftpd。Exim4 似乎是现在轻量级 VPS 的通用选择，网上很多教程文章讲的都是 Exim4。而我选择 vsftpd 是因为我过去读过一篇小说《我是一名黑客》，不管文章里的水平怎么样，我至少记住了关于 vsftpd 的描述，就是说它 very secure。反正对 vsftpd 印象挺深刻的，配置起来也不麻烦，体积也小，所以我就一直用它。

我过去配置 Exim4 的时候，从网上找的文章都挺奇怪的。通过一个命令启动图形化设定界面，然后一步一步的设定。我看了设定界面里的解释，又很多术语都让我比较困惑，而教程里文章里的 Exim4 和我用的版本不一致，结果界面的顺序与名称都不统一，我费了好大劲才配置好。这次我看了某一篇文章，只讲了最简单的配置，也不需要图形界面，只要编辑 /etc/exim4/update-exim4.conf.conf 文件，把 dc_eximconfig_configtype 的值设定为 'internet' 就好了。比我上次配置要容易多了。

其它

弄到这里，关键的部分都转移成功了，剩下的就只有局部设置了。我遇到了两个 WordPress 插件的问题和一个 DNS 的 A 地址问题。

1

我过去使用 Google Analyticator 来配置 Google Analytics。它非常方便，不但可以自动添加跟踪代码，而且还可以在 WordPress 的 Dashboard 上显示访问量与访问来源。这次我没有成功的配置它。当我在设定里向 Google 发送认证请求的时候，Google 那边说另一个网站正在请求访问我的 Google 账户，但却发送了异常的请求，详细的错误信息如下：

The site “http://cnliufeng.com” has not been registered.

不明所以。查了插件的 FAQ，发现第一问的第一种情况就是我这样子的，不过看解决方案涉及 AuthSub 之类的东西，太复杂，我就没有再继续深入研究了。问题是我之前在老的 VPS 上设定成功过，为什么转到新 VPS 之后就不行了呢？

2

我最早因为看很多中文 blogger 都用 Spam Karma 2 来防止垃圾评论，于是我也跟着做。到后来 Akismet 后来居上，成为了最流行的防垃圾评论机制，我也从善如流。这次我因为是重头安装的 WordPress，因此过去的设定都要重新设置一遍，其中就包括 Akismet Key。我去 Akismet 的网站上要求重新把 key 再给我发到邮箱中去。结果我等了有一个小时，中间还重复申请了几次，总是不见回音。到后来我干脆扒旧 VPS 的数据库，找到了 key 填上了。结果到了晚上，我却收到了 key 的邮件，已经太迟了啊。

3

最后提一下关于域名 DNS 变更的事情，这次我也因为这个弄的迷糊了几天，耽搁了一段时间。当我的新 VPS 开通后，我立即给 Ramhost 提交 ticket，要求把指向旧 VPS 的域名转到指向新域名上来。然后我就等，等到一天晚上我这里都 11 点多了，收到邮件说是我的请求被处理了。给我的邮件里是这么说的，XX 和 YY 两个域名已经从账号 A 转移到账号 B 了（两个账号都指 RAMCP 的账号）。我在浏览器里刷新了一下域名，发现内容仍然是旧的 VPS 上的内容，我于是猜想变更 DNS 或许要一段时间，于是等到第二天中午，我发现域名依旧指向旧的 VPS。

我无奈去 RAMCP 的 DNS Manager 里查看，结果无语的发现我这个域名的 A 地址仍然是旧的 VPS 的 IP。客服确实转移了账号，但没有完全转移 A 地址，当然不行了。我修改了 A 地址几分钟之后，再 traceroute 就看到最终地址是我的新 VPS 了，在浏览器中刷新页面也显示了新 VPS 上的内容了。