Ghost博客数据库迁移至MySQL

为何要迁移数据库？

刚刚开始，这个博客是由Ghost + CentOS7 + sqlite3 搭建的。然而本身对于sqlite3不是特别的熟悉，因此决定，将其迁移至MySQL来。可是在迁移的过程当中，还不是那么的顺利，就用笔记记录下来吧。

升级阿里云的配置

以前购买的虚拟云主机是最低配置的，1核 + 512M内存。这个配置基本也就能恰好跑跑一个Ghost。由于当时的内存使用率基本就到了90%左右，因此在安装mysql的时候，直接就报错，内存不够，因此，就把当前的云主机升级为了1核 + 1GB内存。费用由原来的每月30RMB多到了50RMB多，其余厂家的云主机的价格都感受差很少，阿里的技术我比较信赖，毕竟在11.11这么大并发的状况下，可能抗住。是一个伟大的公司，值得全部人的敬佩。

升级完后，须要在控制台重启机器，配置才会获得更新，其余的方式，介绍说不能够。

安装mysql

按照之前的方式安装mysql居然不行了，缘由是由于系统是CentOS7的。

如何查看系统的相关信息呢？

[cyblogs@iZ94tq694y3Z ~]$ cat /etc/redhat-release 
CentOS Linux release 7.0.1406 (Core)

系统原来是当时买云主机的时候选择的。

回顾一下原来是如何安装mysql on CentOS的

yum install mysql mysql-server mysql-devel

可是运行下来，发现报错，说mysql-server没有找到，因此这里就安装失败了。经过查阅资料，找到了正确的安装操做说明。

一、- We use Yum to Remove MySQL, like so: yum remove mysql mysql-server

二、- With MySQL removed, we can safely backup the configuration: mv /var/lib/mysql /var/lib/mysql_old_backup If you'd rather remove it, issue: rm -vR /var/lib/mysql

三、- Now we can safely reinstall MySQL, using the default configuration that is included in the package from the Official MySQL repository (we need wget to fetch the rpm that will update your repos):

四、- yum install wget

• Now download and install the repository: wget http://repo.mysql.com/mysql-community-release-el7-5.noarch.rpm && rpm -ivh mysql-community-release-el7-5.noarch.rpm

五、- Verify the repositories are installed: ls -1 /etc/yum.repos.d/mysql-community*

• Issue the actual install command (This will replace the mysql-server in the CentOS repository with the official package from upstream MySQL):
• yum install mysql-server

六、- Use the script provided to set the root password, now that we have a fresh install again: mysql_secure_installation

七、- If you ever need to set the password after using the script, use: mysql -u root

八、- Now you can use the standard commands from systemctl, part of systemd to Start and Stop the daemon like so:

• systemctl start mysqld

按照上面的步骤一步步的操做，应该没有什么太大的问题。由于，我已经安装成功了。

给用户设置密码以及赋予权限

mysqladmin -u root password root (本身的密码)

grant replication slave on *.* to 'root'@'%' identified by 'root';

此时，基本在mysql这一步就OK了。本身能够尝试着登陆，操做sql语句查看一些一些表的信息。

备份以前sqlite3的数据，方便后面的从新导入。

输入 http://hostname/ghost/settings/labs/ 能够看到这个页面。 点击Export就能够导出数据了，文件名字是这样子的mr-chen.ghost.2015-11-21.json数据JSON格式的数据。

修改Ghost的配置文件

以前用sqlite3的配置 config.js 中的production模块

database: {
   	client: 'sqlite3',
            connection: {
                filename: path.join(__dirname, '/content/data/ghost.db')
            },
            debug: false
        },

修改为mysql的配置

database: {
            client: 'mysql',
            connection: {
                host: 'localhost',
                user: 'root',
                password: 'root',
                database: 'cyblogs',
                charset: 'utf8'
            },
            debug: false
        },

而后将文件替换掉，重启服务。

若是重启服务后，不能访问，有可能你的iptatles没有开放80端口，须要设置一些防火墙。

/sbin/iptables -I INPUT -p tcp --dport 80 -j ACCEPT
/sbin/iptables -I INPUT -p tcp --dport 22 -j ACCEPT

而后访问本身的网站，就能够正常的工做了。最后再将输入导入进去，可是发现背景图片与用户本身的头像都丢失了，须要用户本身从新上传。

可是在上传用户头像的时候，ghost报错了。错误提示：

ERROR: ER_TRUNCATED_WRONG_VALUE: Incorrect datetime value: '2015-03-18T02:14:41.000Z' for column 'created_at' at row 1

以后在，gitbub上找到了答案，须要在mysql的配置文件中，从新设置一下。

Hi @keesun, sorry to hear you're having trouble.

Although I've seen this problem before with other software, I've never seen it reported with Ghost before, and I can't find anyone reporting it to >bookshelf or knex either.

Not sure specifically why this is happening to you, but it may be to do with your specific version of MySQL.

The fix is to first locate your my.cnf file (often somewhere like /usr/local/my.cnf /etc/my.cnf /etc/mysql/my.cnf /usr/local/etc/my.cnf ~/.my.cnf).

Then, inside of that file remove STRICT_TRANS_TABLES from the sql-mode line, and restart MySQL. All should then be fine.

I don't think there's an issue here for us to fix. Perhaps we ought to be using timestamp rather than datetime fields, however as it should be easily >fixable with a config change, unless we get lots of people running into this I don't think it needs looking into at this stage. Therefore, I'm going to >close this for now - and if we get more reports we can reopen.

删除掉 STRICT_TRANS_TABLES，而后再从新启动mysql服务就行了。