本文目錄一覽:
- 1、dump mysql導出數據庫時,怎麼執行
- 2、如何將xshell中的mysql導出查詢 dump
- 3、如何在兩台服務器之間安全遷移MySQL數據庫
- 4、如何將mysql中的數據導出成文件 mysqldump
- 5、mysql數據庫運用mysqldump命令過後沒有反應是什麼情況。如圖。
dump mysql導出數據庫時,怎麼執行
比方說你要把一個名為luciatest2的庫導出到文件:
mysqldump -uroot -p123456 luciatest2 luciatest2.sql
如何將xshell中的mysql導出查詢 dump
如何將xshell中的mysql導出查詢 dump
開始—運行—輸入“CMD”回車,然後直接寫入以下命令
導出的命令:
exp 用戶名/密碼@數據庫名 file=D:\database.dmp log=data.log
file後是寫得你導出的文件存放的路徑,database.dmp是你導出的文件,log是你導出日誌,便於查詢錯誤,不要也可以。例如 exp user/password@orcl file=d:\aaa.dmp
如何在兩台服務器之間安全遷移MySQL數據庫
遷移MySQL數據庫通常只需要幾個簡單的步驟,但是由於您要轉移的數據量可能比較龐大,因此一般耗時也會比較長。
下面的步驟將指導您如何從舊的服務器上導出MySQL數據庫,對它進行安全加固;然後將其複製並導入到新的服務器上,以保證數據的完整。
將MySQL數據庫導出至轉儲文件(dump file)
Oracle提供了一個名為mysqldump的工具,允許您輕鬆地將數據庫結構和其數據導出到一個SQL的轉儲文件。您可以使用如下的命令:
1.mysqldump -u root -p –opt [database name] [database name].sql
不過,請注意如下幾點:
我們可以使用–single-transaction的標誌,以避免數據庫在導出數據的過程中被鎖死。這樣能夠在將數據導出到轉儲文件的同時,您仍可繼續在舊的數據庫上更新數據。不過請注意,那些在導出進程已經開始之後被更新的數據,是不會被導入轉儲文件之中的。
在運行該命令之前,請務必將[database name]替換成您的實際數據庫名稱。
請輸入您自己的用戶名和相對應的密碼,並確保該用戶具有備份數據庫所需的權限。
安全加固備份文件
在大多數情況下,數據是一家企業的最重要的資產。因此,我們不希望數據庫的各種備份被暴露在不受保護的服務器上,因為這樣有可能會造成錯誤地泄露,甚至會出現被黑客竊取等更為糟糕的狀況。
因此,通常您可以嘗試的做法是:壓縮、加密文件,然後刪除原文件。在Linux操作系統上,請使用以下的命令對已壓縮文件進行加密:
1.zip –encrypt dump.zip db.sql
在壓縮開始之前,系統將提示您輸入密碼。
傳輸備份文件
至此,我們已經獲得了一個加密的轉儲文件。下面讓我們通過網絡使用SCP命令,將其傳輸到新的服務器上:
1.scp /path/to/source-file user@host:/path/to/destination-folder/
將MySQL轉儲導入新服務器
通過上面一步,我們已將備份文件傳到了新的服務器上,下面讓我們來進行解密和提取:
1.unzip -P your-password dump.zip
為了存儲空間和安全方面的原因,一旦文件導入成功,請記得刪除其對應的轉儲文件。
您可以使用以下的命令來導入文件:
1.mysql -u root -p newdatabase /path/to/newdatabase.sql
在新服務器上驗證導入的數據
現在我們在新服務器上已經導入了數據庫,那麼我們就需要一種方法來驗證數據的真實存在,並確保沒有任何遺漏。
我建議您同時在舊的和新的數據庫上運行如下查詢,並將獲得的結果進行對比。
該查詢會在所有的表裡計算行數,以顯示出新、舊數據庫中的數據量。
1.SELECT
2.TABLE_NAME,
3.TABLE_ROWS
4.FROM
`
5.information_schema`.`tables`
6.WHERE
`
7.table_schema` = ‘YOUR_DB_NAME’;
此外,我建議您檢查各個表中數字列的MIN和MAX記錄,以確保數據本身是有效的,而不僅僅是看數據的總量(雖然這是查詢所唯一能夠讀出的值)。另一種可供測試的選擇是將數據庫從新的服務器導出為SQL轉儲文件,並將其與舊服務器的SQL轉儲文件做比較。
此外,在應用程序被遷移之前,我建議您先將一個應用程序的實例重定向到新的數據庫上,以確認一切運行正常。
另一種導出和導入的選項
我們之所以把該選項放在最後,是因為我們的確不建議您去使用它。
該方法實現起來非常的容易,因為它僅使用一個命令,便能一次性將轉儲文件導出、傳輸、並將其數據導入到新的數據庫之中。
而它的不足之處在於,一旦其網絡鏈接斷掉,您就需要重新啟動它了。
因此,我們認為它並不值得被推薦,尤其是在大型數據庫中,可能會非常不適用。
當然,如果您非要嘗試一下的話,可以使用如下的命令:
1.mysqldump -u root -pPassword –all-databases | ssh user@new_host.host.com ‘cat – | mysql -u root -pPassword’
重要提示
請確保在新舊兩處,安裝有相同官方發行版本的MySQL服務器。否則,你需要按照MySQL網站上的升級說明來進行統一(請參見(https://dev.mysql.com/doc/refman/5.7/en/upgrading.html)。
請確保您在舊的服務器上擁有足夠的空間來保存轉儲文件和壓縮文件(應該有db_size×2的空間)。
請確保您在新的服務器上擁有足夠的空間來保存加密的和解密的轉儲文件、並能導入數據庫(應該有db_size×3的空間)。
如果您曾經考慮過只是將datadir從一個數據庫轉移到另一個的話,我建議您最好不要這樣做。否則,您會搞亂數據庫的內部結構,而且會給將來可能的問題埋下隱患。
在新的服務器配置中,請不要忘了配置諸如innodb_log_file_size這樣的重要標誌。因為如果忘記了根據新服務器的規格而更新配置的話,很可能會導致嚴重的性能問題。
在許多情況下,一般升級到新的數據庫服務器的初衷是為了提高查詢性能。而如果此類升級沒有達到預期的改善,那麼您就應該考慮去優化SQL查詢,而不僅僅是升級硬件那麼簡單了
如何將mysql中的數據導出成文件 mysqldump
mysqldump: 最早,也是最成熟的邏輯備份工具,是 MySQL 原生的用來備份整個數據庫實例、單個數據庫、單張表的邏輯備份工具, 上手簡單,學習成本幾乎為 0。備份簡單,恢復也簡單。
比如導出單個數據庫 ytt: mysqldump ytt /tmp/ytt.sql;
恢復也非常簡單:mysql /tmp/ytt.sql
缺點是備份速度慢。在整個備份過程中,是單線程運行;備份出來的數據集要恢復的話同樣也是單線程運行,恢復速度也慢。除非對同一時刻的所有表單獨備份出來,自己寫額外腳本進行多線程恢復。
mysql數據庫運用mysqldump命令過後沒有反應是什麼情況。如圖。
通用規律只有使用 –all-databases (-A) 會 ERROR 1356,那就看看他到底備份了什麼東西。於是喊上同事一起 less 看了下,上下掃了兩眼。突然發現:1. 備份 SQL 文件里 DROP 掉了 mysql.proc;2. 後CREATE了一個新的 mysql.proc;3. LOCK TABLES 和 UNLOCK TABLES 中間居然沒有備份 CREATE ROUTINE 任何數據?這不就是相當於每次導入全備都給我一個沒有任何 sys schema routines 的全新 mysql.proc 表?那這不就異常的尷尬?
—- Table structure for table `proc`–
—- Dumping data for table `proc`-
真相大白在官方文檔【sys-schema-usage】官方文檔明確的告訴我們不會備份 sys 庫。但在使用 mysqldump 在執行 –all-databases 會清空 mysql.proc 導致 sys 無法正常使用;這是一個 BUG,並且只存在於 MySQL 5.7.x !
1、mysql_upgrade install or upgrade sys schema
這個方案適用於 sys 庫已經因為 mysqldump 導入而損壞的情況下使用。
注意:mysql_upgrade 在修理 sys 庫的同時,還修理 mysql 庫和用戶庫表(期間加鎖且速度一般),有極小可能會誤傷;使用 mysql_upgrade 的時候要加上 –upgrade-system-tables,不然會掃描用戶庫表。
2、全備時同時備份 sys 庫
這個方案適用於需要還原的數據庫,sys 庫也不太正常的情況下使用;在全備後額外再備份一份 sys 庫用於修復。
注意:不適用於做主從時使用它。
3、使用 databases 全備
這個方案適用於所有場景的全備需求,100% 安全。
4、使用 mysql-sys 開源代碼
如果你的數據庫 sys 全部中招了,又是生產庫。那你只能用這個方法;
mysql-sys:
中記錄了 sys 庫的創建語句將文件下載到本地,然後根據數據庫版本,執行以下命令即可。
原創文章,作者:I7NSQ,如若轉載,請註明出處:https://www.506064.com/zh-hant/n/130142.html