Blog

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.confhttp { 下面添加一行 client_max_body_size 4M; 之后问题解决。这个值默认是 1M,而我的 WordPress 导出文件大小是 2.6M,明显超出了这个限制。

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

WordPress Import Error

我用 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 上的内容了。

2 comments

  1. 变更 blog 样式 | 我的空想特摄 - pingback on 2011/07/02/ 07:09
    沙发

Leave a Reply