趁機房搬遷的機會，打算做一次業務整合。現有的架構是在2010年規劃并運營起來的，隨著時間的推移，項目也越來越多。打開Nginx配置文件，有四十多行Include包含存在，每一個包含就是一個項目（有些是Web，有些是APP）。一整個機柜，老舊的設備，負載均衡高可用架構。

為保證業務一致性和降低成本，業務數據（包括開發的應用程序及用戶上傳數據）共享一套NFS；各業務共享同一套物理數據庫（一臺物理服務器MySQL創建多個庫）。隨著業務和訪問量的增長，這種隱患越來越令人擔憂，主要表現在安全問題及性能問題這兩個方面。

1、安全問題

數十個站點共享目錄，以NFS方式共享給各物理服務器，這幾十個項目，只要任何一個有安全漏洞存在，有心人都能進來為所欲為，讓站點全部淪陷。時不時的被人注入惡意代碼，針對性地進行清除，但沒多久又被注入篡改。

大家心里都有數，存在漏洞的地方，不一定是被篡改的那個。但站點太多，又沒有隔離，根本無法用安全工具掃描（一個站點進行掃描，平均花費一天）。

[root@web57 ~]# more /usr/local/nginx/conf/nginx.confuser www www;worker_processes 6;worker_rlimit_nofile 51200;events {use epoll;#use kqueue; #FreeBSD systemworker_connections 51200;}http {include mime.types;default_type application/octet-stream;#charset gb2312;server_names_hash_bucket_size 256;client_header_buffer_size 256k;large_client_header_buffers 4 256k;client_max_body_size 500m;…………………………………………省略若干…………………………………include vhosts/faxian.quanzhen.com.conf;include vhosts/www.quanzhen.com.conf;include vhosts/news.quanzhen.com.conf;include vhosts/s.quanzhen.com.conf;include vhosts/down.quanzhen.com.conf;include vhosts/static.quanzhen.com.conf;include vhosts/image.quanzhen.com.conf;include vhosts/3g.quanzhen.com.conf;include vhosts/mini.quanzhen.com.conf;include vhosts/xml.quanzhen.com.conf;include vhosts/mayiapi.quanzhen.com.conf;include vhosts/www.android77.com.conf;include vhosts/fahongbao.android77.com.conf;include vhosts/update.android77.com.conf;include vhosts/dev.quanzhen.com.conf;include vhosts/qr.110.cc.conf;include vhosts/110.cc.conf;include vhosts/eggserver.quanzhen.com.conf;include vhosts/apkegg.quanzhen.com.conf;include vhosts/eggserver.yidong7.cn.conf;include vhosts/www.yidong7.cn.conf;include vhosts/down.yidong7.cn.conf;include vhosts/wan.quanzhen.com.conf;include vhosts/open.quanzhen.com.conf;include vhosts/bakdown.yidong7.cn.conf ;include vhosts/hanhua.quanzhen.com.conf;include vhosts/mpk.quanzhen.com.conf;include vhosts/android.quanzhen.com.conf;include vhosts/pay.quanzhen.com.conf;include vhosts/cmstop.quanzhen.cn.conf;include vhosts/news.quanzhen.cn.conf;include vhosts/pingce.quanzhen.cn.conf;include vhosts/gonglue.quanzhen.cn.conf;include vhosts/hao.quanzhen.cn.conf;include vhosts/all.quanzhen.cn.conf;include vhosts/s.quanzhen.cn.conf;include vhosts/apkz.quanzhen.com.conf;include vhosts/ajax.quanzhen.com.conf;include vhosts/union.quanzhen.com.conf;include vhosts/mai.quanzhen.com.conf;include vhosts/blog.quanzhen.com.conf;include vhosts/guazi.quanzhen.com.conf;include vhosts/lockscreen.yidong7.cn.conf;include vhosts/dsp.pujia8.com.conf;include vhosts/3svx4haii9.quanzhen.com.conf;include vhosts/u.quanzhen.com.conf;include vhosts/bianji.quanzhen.com.conf;include vhosts/default.conf;}

2、性能問題

性能問題主要集中在數據庫上邊，只要有一個庫出現問題，引起鎖表或者其它競爭，全部相關業務都會掛起，大伙兒都是煩不勝煩。

遷移過程

想進行拆分，決策人認為，本來就滿機柜了，如果再新家機器，得另租機柜，考慮到成本等其它問題，只求不出事即可。

整合的計劃是，遷移部分業務到公有云上，騰出服務器后，對現有的設備進行擴充配置（拼內存、硬盤等，古舊的機器直接下架）。留下配置高的，進行虛擬化，既能減少設備數量（托管費降低），又有利于日常維護。

前邊說了這么多，似乎與技術關系不大，但對于一些有遺留問題的項目，還是具有參考意義。接下來，我們就進入正題，看看我們要遷移的項目狀況。要往云上遷移的數據包括網站數據及數據庫數據，網站數據比較好辦，rsync同步到對應的目錄，而數據庫相對而言要麻煩不少。

兩個數據庫，一個容量38G，另一個29G，不算太大，但公用的IBData1文件卻有123G，最初是嘗試把這兩個庫，直接導入到阿里云的RDS，在進行數次操作失敗后，咨詢客服得到的答復是RDS暫時不支持分表的數據庫。為節省成本，購買一個配置高一點的云主機（cpu 8core，內存32G，1T高效云盤），部署上MySQL5.6，供兩個數據庫使用。

1、第一次嘗試

預估了一下，200G的數據，貪心一把，看一次性能不能遷移完。提前幾天，把云上的環境全部準備妥當（能出來測試頁），運營部門把通知發下去，然后某天夜里0:30分，一些人在辦公室，一些人在家里，瞇著眼，莊重地在鍵盤敲入“screen”這幾個字符。在qq群里得到一致許可，可以進行數據庫導出操作以后，小弟小心翼翼地發來一條指令：

[root@db-209 ~]# innobackupex --user=root --passwor='i%=KGb76' \--defaults-file=/etc/my.cnf \--databases=“quanzhen_mobile7lockscreen quanzhen_equipment” /data/bakmysql/InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oyand Percona Ireland Ltd 2009-2012. All Rights Reserved.This software is published underthe GNU GENERAL PUBLIC LICENSE Version 2, June 1991.180618 00:30:31 innobackupex: Starting mysql with options: --defaults-file='/etc/my.cnf' --password=xxxxxxxx --user='root' --unbuffered --180618 00:30:31 innobackupex: Connected to database with mysql child process (pid=20090)180618 00:30:37 innobackupex: Connection to database server closedIMPORTANT: Please check that the backup run completes successfully.At the end of a successful backup run innobackupexprints "completed OK!".innobackupex: Using mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1innobackupex: Using mysql server version Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.innobackupex: Created backup directory /data/bakmysql/2018-06-18_00-30-37180618 00:30:37 innobackupex: Starting mysql with options: --defaults-file='/etc/my.cnf' --password=xxxxxxxx --user='root' --unbuffered --180618 00:30:37 innobackupex: Connected to database with mysql child process (pid=20123)180618 00:30:39 innobackupex: Connection to database server closed180618 00:30:39 innobackupex: Starting ibbackup with command: xtrabackup_55 --defaults-file="/etc/my.cnf" --defaults-group="mysqld" --backup --suspend-at-end --target-dir=/data/bakmysql/2018-06-18_00-30-37 --tmpdir=/tmpinnobackupex: Waiting for ibbackup (pid=20132) to suspendinnobackupex: Suspend file '/data/bakmysql/2018-06-18_00-30-37/xtrabackup_suspended'xtrabackup_55 version 2.0.7 for Percona Server 5.5.16 Linux (x86_64) (revision id: 552)xtrabackup: uses posix_fadvise().xtrabackup: cd to /data/mysql_dbxtrabackup: Target instance is assumed as followings.xtrabackup: innodb_data_home_dir = ./xtrabackup: innodb_data_file_path = ibdata1:10M:autoextendxtrabackup: innodb_log_group_home_dir = ./xtrabackup: innodb_log_files_in_group = 2xtrabackup: innodb_log_file_size = 5242880>> log scanned up to (601191481892)[01] Copying ./ibdata1 to /data/bakmysql/2018-06-18_00-30-37/ibdata1>> log scanned up to (601191481892)>> log scanned up to (601191481892)>> log scanned up to (601191481892)>> log scanned up to (601191481892)>> log scanned up to (601191481892)>> log scanned up to (601191481892)>> log scanned up to (601191481892)…………………………………省略……………………………………………

樂觀估計，上午7點前，能完成整個遷移，幾個人商量輪流監看進展程度，等進行完一步后叫醒休息的人，以便進行下一步。結果，到凌晨六點多，才執行完這個innobackupex，還差好幾步呢，每一步都同樣耗時，只能宣告遷移暫時失敗，選個黃道吉日，分兩次進行遷移。

2、第二次分拆遷移

萬年歷排除近期諸事不宜的日子，再搖卦選利用用神的地支，選定日志，約上相關人等，繼續進行遷移。有了上一次的教訓，在遷移前又對要遷移的庫做了清理，刪掉了一些無用的數據，省出來好幾個G的空間。在源數據庫，執行指令：

[root@db-209 ~]#innobackupex --user=root --passwor='i%=KGb76' \--defaults-file=/etc/my.cnf --databases=“quanzhen_equipment” /data/bakmysql/

我交代好以后，就躺下睡覺，到凌晨三點電話響了，告知第一步完成。

[root@db-209 ~]#innobackupex --apply-log /data/bakmysql/2018-06-18_00-30-37

日志應用倒是執行的很快，回車即完。然后進行tar打包和復制文件到目標服務器，由于租賃的出口帶寬太小（總帶寬30M，現在讀者知道為什么要夜間訪問低谷進行遷移了吧？），復制文件到目標服務花了一些時間。

目標服務器，僅僅需要安裝好MySQL軟件，創建好目錄/data/mysql_db，不需要執行數據庫初始化操作，因為Innobackupex導入時，要求數據目錄必須為空。阿里云的配置比源服務器配置高，解壓文件很快就完成。

檢查一下MySQL選項文件/etc/my.cnf，注意是選項文件。

設定“—datadir=/data/mysql_db”，就可執行導入操作，指令如下：

[root@msyql mysql_db]# innobackupex --defaults-file=/etc/my.cnf \--copy-back /data/db_bk/2018-06-18_00-30-37

源數據導出時，沒有把庫MySQL一并導出，這倒不是什么要緊的事情，反正只有一個賬戶需要創建。接下來，初始化數據庫并創建應用帳號，具體操做如下：

[root@msyql mysql_db]#cd /usr/local/mysql/[root@msyql ~]#scripts/mysql_install_db --user=mysql --datadir=/data/mysql_db[root@msyql ~]#mysqlmysql>grant all on quanzhen_equipment.* to ……

還要記得給MySQL空密碼消除掉。

源庫與目標庫，比對一下表的數量，以及隨機抽取一些大表，對記錄數進行比較。確認數據完整以后，一幫去調試應用，后續工作就沒我什么事。

3、第三次分拆遷移

有了上一次的成功經驗，這次信心滿滿了，不過擔心還是有的，就是那個目標庫導入時，要求數據目錄為空。小弟在未開始時，就來征求我的意見，我擔心可能會有障礙，就對他說，你只要把源站數據導出準備好，放到目標數據庫，余下的我親自搞定。

自己的選擇有兩個，一個是使用選項“--force-non-empty-directories”，如果不行，就再弄一個MySQL實例，啟用3307端口，雙實例運行。先嘗試第一個選項，看能不能進行下去，具體指令為：

[root@msyql db_bk]# pwd/data/db_bk[root@msyql db_bk]#innobackupex --defaults-file=/etc/my.cnf --copy-back \--force-non-empty-directories 2018-06-22_00-24-52180623 23:31:57 innobackupex: Starting the copy-back operationIMPORTANT: Please check that the copy-back run completes successfully.At the end of a successful copy-back run innobackupexprints "completed OK!".innobackupex version 2.4.11 based on MySQL server 5.7.19 Linux (x86_64) (revision id: b4e0db5)innobackupex: Can't create/write to file '/data/mysql_db/ib_logfile0' (Errcode: 17 - File exists)[01] error: cannot open the destination stream for ib_logfile0[01] Error: copy_file() failed.

悲催了，有同名文件存在，不行！直接終止運行。好吧，我把文件“ib_logfile0、ib_logfile1”挪走，再執行，還是不行，提示文件“ibdata1”存在，這可是個大家伙。雖然擔心新導入的ibdata1可能不包含現有數據庫相關信息，但忍不住想試一把。可能有讀者會問，這樣搞可能把數據庫原有的數據破壞掉了，其實我想到這一層了，老早我就把整個庫做了備份，買了保險的。

正全神貫注盯著屏幕查看輸出，希望進展順利，突然，qq群有消息傳來，問進展如何，啥時能完成。一看時間，六點了，北方大地已經一片光明。時間來不及了，停掉進程，試試直接復制文件，不使用Innobuckupex。心中沒底，就去仔細比較了數據庫目錄與導出數據目錄中的三個文件“ibdata1、ib_logfile0、ib_logfile1”，發現其大小完全相同。不管了，把現有數據庫里的這幾個文件搬走，從導出目錄cp來著三個文件。復制完，執行mysqld_safe啟動服務，失敗，提示ib_logfile0無寫入權限；這好辦，一條chown指令而已。再執行啟動MySQL服務，正常。

那么數據對不對呢？我不能確定，萬一不對，就再配一個MySQL，導入數據，以雙實例啟動，后邊再想法整合；阿里云購買的服務器，相互通信是內網，不會在傳輸上浪費太多時間。

既然服務正常，就對一下數據吧，萬一運氣爆棚（前幾天夜里夢到自己能飛，抓住一只巨型天鵝，我美美地摟著天鵝的脖子…），數據完整可用呢？

我自己悄悄對比了一陣，沒發現差異，又到qq群呼叫其它人，說導入有障礙，數次不成功，后邊采取了一些不確定的手段，MySQL服務是起來了，請大家核實一下數據，看是否完整可用。幾個程序員一陣忙碌，得到答復，數據是完整可用的。到此，我的工作完成了。

有人可能要鄙視我一番，為什么不先測試？不制定完善的流程？這個問題問得好！我數次建議決策人，準備點資源，說白了就是準備1臺空閑服務器，再內網演練，就算白天也能能進行（復制數據走內網，不在用戶訪問的帶寬），但是，沒有資源給我啊，事情又不得不做。雖然累點，折騰一番，反過來想，咱玩懸的也獲得經驗，不然也沒有這個文章問世，你們覺得呢？

原文發布時間為：2018-07-02
本文作者：sery
本文來自云棲社區合作伙伴“DBAplus社群”，了解相關信息可以關注“DBAplus社群”。

總結

以上是生活随笔為你收集整理的一段三次分拆的蚂蚁搬家式MySQL迁移经历的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。