建站
咨詢
售后
建站咨詢
新聞中心
操作系統(tǒng)掛了，怎么把mysql備份出來
MySQL命令行導(dǎo)出數(shù)據(jù)庫： 1，進(jìn)入MySQL目錄下的bin文件夾：cd MySQL中到bin文件夾的目錄如我輸入的命令行：cd C:\Program Files\MySQL\MySQL Server 4.1\bin (或者直接將windows的環(huán)境變量path中添加該目錄) 2，導(dǎo)出數(shù)據(jù)庫：mysqldump -u 用戶名 -p 數(shù)據(jù)庫名 導(dǎo)出的文件名如我輸入的命令行:mysqldump -u root -p news news.sql (輸入后會讓你輸入進(jìn)入MySQL的密碼) （如果導(dǎo)出單張表的話在數(shù)據(jù)庫名后面輸入表名即可） 3、會看到文件news.sql自動生成到bin文件下命令行導(dǎo)入數(shù)據(jù)庫： 1，將要導(dǎo)入的.sql文件移至bin文件下，這樣的路徑比較方便 2，同上面導(dǎo)出的第1步 3，進(jìn)入MySQL：mysql -u 用戶名 -p 如我輸入的命令行:mysql -u root -p (輸入同樣后會讓你輸入MySQL的密碼) 4，在MySQL-Front中新建你要建的數(shù)據(jù)庫，這時是空數(shù)據(jù)庫，如新建一個名為news的目標(biāo)數(shù)據(jù)庫 5，輸入：mysqluse 目標(biāo)數(shù)據(jù)庫名如我輸入的命令行:mysqluse news; 6，導(dǎo)入文件：mysqlsource 導(dǎo)入的文件名; 如我輸入的命令行：mysqlsource news.sql;
創(chuàng)新互聯(lián)建站自2013年創(chuàng)立以來，先為岱岳等服務(wù)建站，岱岳等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為岱岳企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
mysql到底如何備份
數(shù)據(jù)備份是數(shù)據(jù)容災(zāi)的最后一道防線，即便有著兩地三中心的架構(gòu)，備份也依然重要。如果備份出問題，備份時影響了交易業(yè)務(wù)，備份數(shù)據(jù)無法恢復(fù)，這些也是企業(yè)難以承受的。所以選擇合適的備份工具尤為重要。
每個企業(yè)級數(shù)據(jù)庫都會有配套的備份工具，MEB(MySQL Enterprise Backup)就是MySQL企業(yè)版中非常重要的工具之一，是為企業(yè)級客戶提供的數(shù)據(jù)備份方案。
Xtrabackup一直作為MEB 開源版?zhèn)涮ザ嬖?，從MySQL 8.0開始情況可能會變得有所不同。
在 MySQL 8.0的Backup Lock、Redo Log Archiving、Page Tracking等新特性的加持下，MEB備份/恢復(fù)體驗會更好，目前xtrabackup還不支持這些特性。
MySQL 企業(yè)版還有哪些功能？
特性1：Backup Lock
8.0之前使用xtrabackup或MEB做物理備份，為了保證備份時InnoDB引擎表與其他引擎數(shù)據(jù)文件、及binlog日志的一致性會上全局讀鎖，再拷貝非InnoDB文件，這期間MySQL會變成只讀，數(shù)據(jù)無法寫入。表數(shù)量越多，可能加上時間越長，如果使用的xtrabackup 不小心沒加rsync參數(shù)，逐個拷貝frm文件，鎖定時間會更長，對業(yè)務(wù)影響較大。
我曾遇到過部署在虛擬機(jī)的實例有12000多張表，當(dāng)時使用的xtrabackup，備份腳本中沒加rsync參數(shù)，結(jié)果鎖了十幾分鐘，而MEB就沒有這樣的問題。
MySQL 8.0支持輕量級備份鎖 LOCK INSTANCE FOR BACKUP，數(shù)據(jù)字典也重構(gòu)了由InnoDB存儲。若不創(chuàng)建非InnoDB表，MEB默認(rèn)使用備份鎖獲取binlog日志一致性位置，并阻止DDL操作，但不影響DML操作。
只有InnoDB表，僅上備份鎖
請點擊輸入圖片描述
若有非InnoDB表，上全局鎖
請點擊輸入圖片描述
特性2：Redo Log Archiving
MEB能做到在線熱備，備份時不影響數(shù)據(jù)庫讀寫，這是利用了InnoDB事務(wù)日志，在備份期間持續(xù)監(jiān)視redo log的變化，讀取增量變化，寫入到ibbackup_logfile，也就不需要上鎖來保障備份一致性。(對非InnoDB的文件需要上讀鎖拷貝)
如果備份期間數(shù)據(jù)庫寫入負(fù)載特別大，而寫入ibbackup_logfile速度較慢，redo log size也不大，很可能會出現(xiàn)ibbackup_logfile的寫入速度跟不上redo log記錄生成速度，redo log 空間不夠時需要覆寫日志文件，那么來不及寫入ibbackup_logfile的記錄會丟失，導(dǎo)致備份失敗。
MEB 4.1對此做了優(yōu)化，將redo log處理線程拆分成多線程分工合作，提高處理redo log的效率，降低了redo log覆寫造成備份失敗的概率，但redo log新增速度和ibbackup_logfile寫入速度懸殊太大，問題依然會發(fā)生。
MySQL 8.0.17支持了redo log archiving 徹底解決了此問題，備份前設(shè)置innodb_redo_log_archive_dirs，指定redo log歸檔目錄。MEB備份時自動開啟日志歸檔，當(dāng)checkpoint時會將舊記錄歸檔到此目錄，后續(xù)從歸檔文件中讀取redo日志記錄，避免了覆寫可能導(dǎo)致的redo記錄丟失。
請點擊輸入圖片描述
注意：innodb_redo_log_archive_dirs 不能在數(shù)據(jù)目錄下，目錄權(quán)限要求是700
特性3：Page Tracking
Page Tracking 是為優(yōu)化增量備份效率，減少不必要的數(shù)據(jù)頁掃描。
增量備份當(dāng)前有3種掃描模式：
page-track：利用LSN精確跟蹤上次備份之后被修改頁面，僅復(fù)制這些頁面，效率最快。
optimistic：掃描上次備份之后被修改的InnoDB 數(shù)據(jù)文件中，找出并拷貝修改的頁面。依賴系統(tǒng)時間，使用存在限制。
full-scan：掃描所有InnoDB數(shù)據(jù)文件，找出并拷貝自上次備份之后修改的頁面，效率最慢
1、利用page-track增量備份，需先安裝備份組件
mysql INSTALL COMPONENT "";
2、在全備前開啟page-track
SELECT mysqlbackup_page_track_set(true);
3、全備之后，做增量備份時指定若滿足page tracking條件，默認(rèn)會使用page-track模式，否則會使用full-scan模式，也可以指定--incremental=page-track。
mysqlbackup --incremental-backup-dir=backup_incr --trace=3 --incremental=page-track --incremental-base=history:last_full_backup backup
incremental-base有3種選擇
last_backup：基于前一次備份做增備，前一次備份可能是增備，也可能是全備。這種方式全備之間可能會有多個增備，每次增量可能比較小，但恢復(fù)時需要逐個合并。
last_full_backup：基于前一次全備做增備。這種方式增備會越往后體積可能越大，但恢復(fù)時只需要合并最后一次增量備份。
dir：基于前一次的備份目錄，前一次備份可能是增備，也可能是全備。
測試對比full-scan 和page-track ，在變更頁小于總體50%的情況下 ，備份效率至少能有1倍的速度提升。
page-track 模式 磁盤讀寫均衡，說明讀寫的都是修改頁面。
請點擊輸入圖片描述
full-scan模式 磁盤讀寫差別很大，說明讀了很多未修改的頁面。
請點擊輸入圖片描述
如何使用mysqldump命令備份mysql數(shù)據(jù)庫
通用規(guī)律只有使用 --all-databases (-A) 會 ERROR 1356，那就看看他到底備份了什么東西。于是喊上同事一起 less 看了下，上下掃了兩眼。突然發(fā)現(xiàn)：1. 備份 SQL 文件里 DROP 掉了 mysql.proc；2. 后CREATE了一個新的 mysql.proc；3. LOCK TABLES 和 UNLOCK TABLES 中間居然沒有備份 CREATE ROUTINE 任何數(shù)據(jù)？這不就是相當(dāng)于每次導(dǎo)入全備都給我一個沒有任何 sys schema routines 的全新 mysql.proc 表？那這不就異常的尷尬？
---- Table structure for table `proc`--
---- Dumping data for table `proc`-
真相大白在官方文檔【sys-schema-usage】官方文檔明確的告訴我們不會備份 sys 庫。但在使用 mysqldump 在執(zhí)行 --all-databases 會清空 mysql.proc 導(dǎo)致 sys 無法正常使用；這是一個 BUG，并且只存在于 MySQL 5.7.x ！
1、mysql_upgrade install or upgrade sys schema
這個方案適用于 sys 庫已經(jīng)因為 mysqldump 導(dǎo)入而損壞的情況下使用。
注意：mysql_upgrade 在修理 sys 庫的同時，還修理 mysql 庫和用戶庫表（期間加鎖且速度一般），有極小可能會誤傷；使用 mysql_upgrade 的時候要加上 --upgrade-system-tables，不然會掃描用戶庫表。
2、全備時同時備份 sys 庫
這個方案適用于需要還原的數(shù)據(jù)庫，sys 庫也不太正常的情況下使用；在全備后額外再備份一份 sys 庫用于修復(fù)。
注意：不適用于做主從時使用它。
3、使用 databases 全備
這個方案適用于所有場景的全備需求，100% 安全。
4、使用 mysql-sys 開源代碼
如果你的數(shù)據(jù)庫 sys 全部中招了，又是生產(chǎn)庫。那你只能用這個方法；
mysql-sys：
中記錄了 sys 庫的創(chuàng)建語句將文件下載到本地，然后根據(jù)數(shù)據(jù)庫版本，執(zhí)行以下命令即可。
怎么備份和還原mysql數(shù)據(jù)庫
備份數(shù)據(jù)庫
使用mysqldump命令備份數(shù)據(jù)庫
還原數(shù)據(jù)庫
1、使用mysql命令還原數(shù)據(jù)庫
將game_backup.sql 還原至 game 數(shù)據(jù)庫：
2、使用source命令還原數(shù)據(jù)庫
如果數(shù)據(jù)庫過大，建議可以使用source命令
分享文章：服務(wù)器損壞mysql怎么備份 mysql數(shù)據(jù)備份恢復(fù)
鏈接地址：http://fisionsoft.com.cn/article/dococeh.html
