如何在兩臺服務器之間安全遷移MySQL數(shù)據(jù)庫

遷移MySQL數(shù)據(jù)庫通常只需要幾個簡單的步驟，但是由于您要轉(zhuǎn)移的數(shù)據(jù)量可能比較龐大，因此一般耗時也會比較長。

專注于為中小企業(yè)提供成都網(wǎng)站設計、成都網(wǎng)站制作服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)昭平免費做網(wǎng)站提供優(yōu)質(zhì)的服務。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上千家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

下面的步驟將指導您如何從舊的服務器上導出MySQL數(shù)據(jù)庫，對它進行安全加固；然后將其復制并導入到新的服務器上，以保證數(shù)據(jù)的完整。

將MySQL數(shù)據(jù)庫導出至轉(zhuǎn)儲文件（dump file）

Oracle提供了一個名為mysqldump的工具，允許您輕松地將數(shù)據(jù)庫結(jié)構(gòu)和其數(shù)據(jù)導出到一個SQL的轉(zhuǎn)儲文件。您可以使用如下的命令：

1.mysqldump -u root -p --opt [database name] [database name].sql?

不過，請注意如下幾點：

我們可以使用--single-transaction的標志，以避免數(shù)據(jù)庫在導出數(shù)據(jù)的過程中被鎖死。這樣能夠在將數(shù)據(jù)導出到轉(zhuǎn)儲文件的同時，您仍可繼續(xù)在舊的數(shù)據(jù)庫上更新數(shù)據(jù)。不過請注意，那些在導出進程已經(jīng)開始之后被更新的數(shù)據(jù)，是不會被導入轉(zhuǎn)儲文件之中的。

在運行該命令之前，請務必將[database name]替換成您的實際數(shù)據(jù)庫名稱。

請輸入您自己的用戶名和相對應的密碼，并確保該用戶具有備份數(shù)據(jù)庫所需的權(quán)限。

安全加固備份文件

在大多數(shù)情況下，數(shù)據(jù)是一家企業(yè)的最重要的資產(chǎn)。因此，我們不希望數(shù)據(jù)庫的各種備份被暴露在不受保護的服務器上，因為這樣有可能會造成錯誤地泄露，甚至會出現(xiàn)被黑客竊取等更為糟糕的狀況。

因此，通常您可以嘗試的做法是：壓縮、加密文件，然后刪除原文件。在Linux操作系統(tǒng)上，請使用以下的命令對已壓縮文件進行加密：

1.zip --encrypt dump.zip db.sql?

在壓縮開始之前，系統(tǒng)將提示您輸入密碼。

傳輸備份文件

至此，我們已經(jīng)獲得了一個加密的轉(zhuǎn)儲文件。下面讓我們通過網(wǎng)絡使用SCP命令，將其傳輸?shù)叫碌姆掌魃希?/p>

1.scp /path/to/source-file user@host：/path/to/destination-folder/?

將MySQL轉(zhuǎn)儲導入新服務器

通過上面一步，我們已將備份文件傳到了新的服務器上，下面讓我們來進行解密和提取：

1.unzip -P your-password dump.zip?

為了存儲空間和安全方面的原因，一旦文件導入成功，請記得刪除其對應的轉(zhuǎn)儲文件。

您可以使用以下的命令來導入文件：

1.mysql -u root -p newdatabase /path/to/newdatabase.sql?

在新服務器上驗證導入的數(shù)據(jù)

現(xiàn)在我們在新服務器上已經(jīng)導入了數(shù)據(jù)庫，那么我們就需要一種方法來驗證數(shù)據(jù)的真實存在，并確保沒有任何遺漏。

我建議您同時在舊的和新的數(shù)據(jù)庫上運行如下查詢，并將獲得的結(jié)果進行對比。

該查詢會在所有的表里計算行數(shù)，以顯示出新、舊數(shù)據(jù)庫中的數(shù)據(jù)量。

1.SELECT ??

2.TABLE_NAME, ??

3.TABLE_ROWS ?

4.FROM ??

`

5.information_schema`.`tables` ?

6.WHERE ??

`

7.table_schema` = 'YOUR_DB_NAME'；?

此外，我建議您檢查各個表中數(shù)字列的MIN和MAX記錄，以確保數(shù)據(jù)本身是有效的，而不僅僅是看數(shù)據(jù)的總量（雖然這是查詢所唯一能夠讀出的值）。另一種可供測試的選擇是將數(shù)據(jù)庫從新的服務器導出為SQL轉(zhuǎn)儲文件，并將其與舊服務器的SQL轉(zhuǎn)儲文件做比較。

此外，在應用程序被遷移之前，我建議您先將一個應用程序的實例重定向到新的數(shù)據(jù)庫上，以確認一切運行正常。

另一種導出和導入的選項

我們之所以把該選項放在最后，是因為我們的確不建議您去使用它。

該方法實現(xiàn)起來非常的容易，因為它僅使用一個命令，便能一次性將轉(zhuǎn)儲文件導出、傳輸、并將其數(shù)據(jù)導入到新的數(shù)據(jù)庫之中。

而它的不足之處在于，一旦其網(wǎng)絡鏈接斷掉，您就需要重新啟動它了。

因此，我們認為它并不值得被推薦，尤其是在大型數(shù)據(jù)庫中，可能會非常不適用。

當然，如果您非要嘗試一下的話，可以使用如下的命令：

1.mysqldump -u root -pPassword --all-databases | ssh user@new_host.host.com 'cat - | mysql -u root -pPassword'?

重要提示

請確保在新舊兩處，安裝有相同官方發(fā)行版本的MySQL服務器。否則，你需要按照MySQL網(wǎng)站上的升級說明來進行統(tǒng)一（請參見（https：//dev.mysql.com/doc/refman/5.7/en/upgrading.html）。

請確保您在舊的服務器上擁有足夠的空間來保存轉(zhuǎn)儲文件和壓縮文件（應該有db_size×2的空間）。

請確保您在新的服務器上擁有足夠的空間來保存加密的和解密的轉(zhuǎn)儲文件、并能導入數(shù)據(jù)庫（應該有db_size×3的空間）。

如果您曾經(jīng)考慮過只是將datadir從一個數(shù)據(jù)庫轉(zhuǎn)移到另一個的話，我建議您最好不要這樣做。否則，您會搞亂數(shù)據(jù)庫的內(nèi)部結(jié)構(gòu)，而且會給將來可能的問題埋下隱患。

在新的服務器配置中，請不要忘了配置諸如innodb_log_file_size這樣的重要標志。因為如果忘記了根據(jù)新服務器的規(guī)格而更新配置的話，很可能會導致嚴重的性能問題。

在許多情況下，一般升級到新的數(shù)據(jù)庫服務器的初衷是為了提高查詢性能。而如果此類升級沒有達到預期的改善，那么您就應該考慮去優(yōu)化SQL查詢，而不僅僅是升級硬件那么簡單了

如何遷移MySQL數(shù)據(jù)庫

MySQL數(shù)據(jù)庫遷移

MySQL數(shù)據(jù)庫遷移(數(shù)據(jù)文件直接遷移)

在今年10月下旬的時候，公司的服務器需要遷移，其中涉及到了MySQL數(shù)據(jù)庫遷移。查看了一下MySQL數(shù)據(jù)文件的大小，接近60G的大小(實際數(shù)據(jù)并沒用那么多)。由于服務器上業(yè)務需要，要盡量減少服務器遷移時的損失。所以遷移時間選在了晚上零點開始，而且要盡量減少遷移所用的時間。

在遷移之前有三種方案：

數(shù)據(jù)庫直接導出，拷貝文件到新服務器，在新服務器上導入。

使用【MySQL

GUI

Tools】中的

MySQLMigrationTool。

數(shù)據(jù)文件和庫表結(jié)構(gòu)文件直接拷貝到新服務器，掛載到同樣配置的MySQL服務下。

我在我的電腦上用虛擬機測試后，選中了占用時間最少的第三種方案。下面是三種方案的對比：

第一種方案的優(yōu)點:會重建數(shù)據(jù)文件，減少數(shù)據(jù)文件的占用空間。

第一種方案的缺點:時間占用長。(導入導出都需要很長的時間，并且導出后的文件還要經(jīng)過網(wǎng)絡傳輸，也要占用一定的時間。)

第二種方案的優(yōu)點：設置完成后傳輸無人值守

第二種方案的缺點：

設置繁瑣。

傳輸中網(wǎng)絡出現(xiàn)異常，不能及時的被發(fā)現(xiàn)，并且會一直停留在數(shù)據(jù)傳輸?shù)臓顟B(tài)不能被停止，如不仔細觀察不會被發(fā)現(xiàn)異常。

傳輸相對其他fang時間長。

異常后很難從異常的位置繼續(xù)傳輸。

第三種方案的優(yōu)點：時間占用短，文件可斷點傳輸。操作步驟少。（絕大部分時間都是在文件的網(wǎng)絡傳輸）

第三種方案的缺點：可能引起未知問題，暫時未發(fā)現(xiàn)。

下面介紹一下第三種方案d遷移步驟：

保證Mysql版本一致，安裝配置基本一致（注意：這里的數(shù)據(jù)文件和庫表結(jié)構(gòu)文件都指定在同一目錄data下）

停止兩邊的Mysql服務（A服務器--遷移--B服務器)

刪除B服務器Mysql的data目錄下所有文件

拷貝A服務器Mysql的data目錄下除了ib_logfile和.err之外的文件到B服務器data下

啟動B服務器的Mysql服務，檢測是否發(fā)生異常

遷移完成后，服務啟動正常，未發(fā)現(xiàn)其他異常問題。

備注：經(jīng)測試，源mysql的安裝目錄及數(shù)據(jù)文件目錄

可以與

目標Mysql的安裝目錄及數(shù)據(jù)文件目錄

不一致。

此時，只需要拷貝您所需移動的dbname（如上：pa、testdb）及'mysql'和'ibdata1'，即可。

如何把sqlserver數(shù)據(jù)遷移到mysql數(shù)據(jù)庫及需要注意事項

以下有幾款遷移工具的對比，可以參考，比較推薦DB2DB.

軟件易用性主要是指軟件在導入前的配置是否容易。由于很多軟件設計是面向程序員而非一般的數(shù)據(jù)庫管理人員、甚至是普通的應用程序?qū)嵤┤藛T，而這一類人員很多時候并沒有數(shù)據(jù)源配置經(jīng)驗。因為一些使用 ODBC 或者 ADO 進行配置的程序往往會讓這類用戶造成困擾（主要是不知道應該選擇什么類型的數(shù)據(jù)庫驅(qū)動程序）。下面讓我們看看四個工具的設計界面：

1、SQLyog

SQLyog?使用的是古老的 ODBC 連接，但對于新一代的程序來說，這種方式的非常的不熟悉并且不容易使用，并且必須要求本機安裝好相應的數(shù)據(jù)庫的 ODBC 驅(qū)動程序（SQL Server 一般自帶好）。

2、Navicat?Premium

NavicatPremium是四個應用工具中設計最不人性化的一個：從上圖怎么也想像不到要點按那個小按鈕來添加一個新的連接，并且這個連接設置不會保存，每次導入時都必須重新設置。NavicatPremium使用的是比 ODBC 稍先進的 ADO 設置方式（199X年代的產(chǎn)物），但使用上依然是針對老一代的程序員。

3、Mss2sql

Mss2sql?是最容易在百度上搜索出來的工具，原因之一是它出現(xiàn)的時間較早。

Mss2sql由于是很有針對性的從 SQLServer 遷移到 MySQL，因為界面使用了操作向?qū)гO計，使用非常容易。同時在設置的過程中，有非常多的選項進行細節(jié)調(diào)整，可以感覺到軟件經(jīng)過了相當長一段時間的使用漸漸完善出來的。

4、DB2DB

DB2DB?由于是由國人開發(fā)，因此無論是界面還是提示信息，都是全程漢字。另外，由于 DB2DB 在功能上很有針對性，因為界面設計一目了然和易使用。和 mss2sql 一樣， DB2DB 提供了非常多的選項供用戶進行選擇和設置。

三、處理速度和內(nèi)存占用評測

在本評測前，本人的一位資深同事曾經(jīng)從網(wǎng)上下載了某款遷移軟件，把一個大約2500萬記錄數(shù)的數(shù)據(jù)表轉(zhuǎn)送到阿里云 MySQL，結(jié)果經(jīng)過了三天三夜（好在其中兩天是星期六和星期日兩個休息日）都未能遷移過來。因此這一次需要對這四個工具的處理速度作一個詳細的測試。

考慮到從 SQL Server 遷移到 MySQL 會出現(xiàn)兩種不同的場景：

從 SQL Server 遷移到本地 MySQL 進行代碼測試和修改；

從 SQL Server 遷移到云端 MySQL 數(shù)據(jù)庫正式上線使用；

以下為測試過程中的截圖：

1、SQLyog

請點擊輸入圖片描述

2、Navicat Premium

請點擊輸入圖片描述

請點擊輸入圖片描述

注意：我們在測試 Navicat Premium 遷移到 ?MySQL 時發(fā)現(xiàn)，對于 SQL Server 的 Money 類型支持不好（不排除還有其它的數(shù)據(jù)類型支持不好）。Money 類型字段默認的小數(shù)位長度為 255，使得無法創(chuàng)建數(shù)據(jù)表導致整個測試無法成功，需要我們逐張表進行表結(jié)構(gòu)修改才能完成測試過程。

Navicat Premium?的處理速度屬于中等，不算快也不算慢，但 CPU 占用還有內(nèi)存占用都處于高位水平。不過以現(xiàn)在的電腦硬件水平來說，還是可以接受。但 CPU 占用率太高，將使得數(shù)據(jù)在導入的過程中，服務器不能用于其它用途。

3、Mss2sql

Mss2sql?并沒有提供計時器，因此我們使用人工計時的方法，整個過程處理完畢大于是 726 秒。Mss2sql 的 CPU 占用率相對其它工具來說較高，但仍屬于可以接受的范圍之內(nèi)。

4、DB2DB

請點擊輸入圖片描述

DB2DB?同樣遷移 300萬數(shù)據(jù)時，僅僅使用了 2 分 44 秒，這個速度相當驚人。不過最后的結(jié)果出現(xiàn)一個 BUG，就是提示了轉(zhuǎn)換成功，但后面的進度條卻沒有走完（在后面的數(shù)據(jù)完整性評測中，我們驗證了數(shù)據(jù)其實是已經(jīng)全部處理完畢了）。

mysql數(shù)據(jù)遷移

這個估計沒辦法簡單的一條 sql 語句完成了。

你可能創(chuàng)建幾個 新舊id 關(guān)聯(lián)表， 來存儲數(shù)據(jù)。

還不能確定， 你的 id 是不是自動增長的.

例如

信息表a(id,name)

創(chuàng)建一個表 old_to_new_a ( oldid , newid)

以下處理邏輯， 是假設你的 id 是 自增長的情況。

你舊庫 a -- 新庫 a 的時候。

如果 新舊 id 與 name 都一樣， 那么簡單去 old_to_new_a 插入一行關(guān)聯(lián)數(shù)據(jù)。

舊系統(tǒng)的 id 與 新系統(tǒng)的id 是相同的。

如果 name 已存在， 那么去 old_to_new_a 插入一行關(guān)聯(lián)數(shù)據(jù)。

也就是 old_to_new_a ( 舊系統(tǒng)的 id , 新系統(tǒng)的id)

如果 name 不存在

那么先去 a 插入一行新的數(shù)據(jù)。 獲取新的 自增id.

然后再去 old_to_new_a 插入一行關(guān)聯(lián)數(shù)據(jù)。

舊庫 b -- 新庫 b 的 處理， 和 a 差不多一樣。

就是要去折騰個 old_to_new_b ( oldid , newid)

----

最后就是折騰 關(guān)系表e。

一行一行判斷 aid 和 bid

用 aid 去 old_to_new_a 表， 查詢出 新系統(tǒng)的 aid

用 bid 去 old_to_new_b 表， 查詢出 新系統(tǒng)的 bid

然后去新系統(tǒng)的 e 表中查詢。數(shù)據(jù)是否已存在。

不存在就插入一行。

新聞標題：遷移mysql怎么生效,MySQL 遷移
文章源于：http://chinadenli.net/article33/dsehcss.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站設計、品牌網(wǎng)站建設、微信小程序、Google、品牌網(wǎng)站制作、標簽優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)