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服務就行了。