mysql如何備份數(shù)據(jù)庫(kù)

MySQL數(shù)據(jù)庫(kù)可以使用mysqldump命令來(lái)實(shí)現(xiàn)備份，步驟如下：

創(chuàng)新互聯(lián)公司2013年成立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目網(wǎng)站制作、做網(wǎng)站網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元濮陽(yáng)縣做網(wǎng)站,已為上家服務(wù),為濮陽(yáng)縣各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:028-86922220

1. 首先，你需要確保MySQL服務(wù)器中已存在要備份的數(shù)據(jù)庫(kù)。

2. 然后，使用mysqldump命令來(lái)備份數(shù)據(jù)庫(kù)：

mysqldump -u [username] -p[password] --all-databases [backup_file].sql

其中，-u參數(shù)表示MySQL的用戶名，-p參數(shù)表示MySQL的密碼，[database_name]表示要備份的數(shù)據(jù)庫(kù)名，[backup_file].sql即為生成的備份文件。

3. 你還可以使用--all-databases參數(shù)來(lái)備份MySQL服務(wù)器中的所有數(shù)據(jù)庫(kù)：

mysqldump -u [username] -p[password] --all-databases [backup_file].sql

4. 如果要定時(shí)備份MySQL數(shù)據(jù)庫(kù)，可以使用crontab來(lái)指定備份的時(shí)間和頻率。例如：

目前，比較好用的MySQL客戶端工具推薦，根據(jù)從OS兼容性、收費(fèi)模式、產(chǎn)品體驗(yàn)、云適配、功能完整度等角度，這里推薦的MySQL 圖形化客戶端工具 NineData。

NineData是一款非常有特色的數(shù)據(jù)庫(kù)SQL開(kāi)發(fā)產(chǎn)品，對(duì)MySQL常用功能支持非常完整，包括智能的SQL補(bǔ)全、SQL執(zhí)行歷史、結(jié)果集編輯、數(shù)據(jù)對(duì)比、結(jié)構(gòu)對(duì)比、數(shù)據(jù)遷移與復(fù)制等。它采用SaaS架構(gòu)模式，用戶不僅可以免費(fèi)使用，而且無(wú)需下載安裝，上手比較簡(jiǎn)單。NineData產(chǎn)品更新迭代比較敏捷，對(duì)于開(kāi)發(fā)者的新需求響應(yīng)比較迅速。另外，該產(chǎn)品在多云適配上是其重要的強(qiáng)項(xiàng)，支持多種連接和訪問(wèn)云數(shù)據(jù)庫(kù)的方式，對(duì)阿里云、騰訊云、華為云、AWS等都有比較好的支持。另外，也適配國(guó)內(nèi)比較流行的PolarDB、GaussDB、TDSQL等數(shù)據(jù)庫(kù)。

如何備份整個(gè)mysql數(shù)據(jù)庫(kù)

1、首先打開(kāi)mysql數(shù)據(jù)庫(kù)軟件進(jìn)入軟件主界面。

2、然后再左側(cè)樹(shù)里打開(kāi)自己的的數(shù)據(jù)庫(kù)。

3、然后需要點(diǎn)擊需要備份的數(shù)據(jù)庫(kù)名。

4、如圖所示為打開(kāi)數(shù)據(jù)庫(kù)后界面。

5、然后需要點(diǎn)擊轉(zhuǎn)儲(chǔ)sql文件選項(xiàng)。

6、然后需要打開(kāi)選擇存儲(chǔ)文件路徑并選擇保存。

7、點(diǎn)擊保存即可在路徑備份好格式為sql的數(shù)據(jù)庫(kù)文件。

MySQL 常用備份工具流程解析

下面我們就看一下常見(jiàn)的備份工具，以及目前最流行的 Percona XtraBackup 的備份流程。

MySQL 常見(jiàn)的備份工具主要分為三種：

這里先說(shuō)一下 binlog 備份，它只是把 binlog 又復(fù)制了一份，并且需要在邏輯備份或者物理備份的基礎(chǔ)上才能進(jìn)行數(shù)據(jù)恢復(fù)，無(wú)法單獨(dú)進(jìn)行數(shù)據(jù)恢復(fù)。

mysqldump 備份出的文件就是 sql 文件，其核心就是對(duì)每個(gè)表執(zhí)行 select ，然后轉(zhuǎn)化成相應(yīng)的 insert 語(yǔ)句。mysqldump 的備份流程大致如下：

從上面可以看出在 mysqldump 備份期間，備份到某個(gè)數(shù)據(jù)庫(kù)時(shí)，該數(shù)據(jù)庫(kù)下的表都會(huì)處于只讀狀態(tài)，無(wú)法對(duì)表進(jìn)行任何變更，直到該庫(kù)下的表備份完畢，這對(duì)于線上環(huán)境一般是無(wú)法接受的。若是指定了--master-data或者 --dump-slave 則會(huì)在備份開(kāi)始時(shí)加全局讀鎖（FLUSH TABLES WITH READ LOCK），直到備份結(jié)束。當(dāng)然我們可以選一個(gè)從庫(kù)進(jìn)行備份，這樣就不會(huì)影響線上業(yè)務(wù)。另外使用 mysqldump 備份還有一個(gè)最大的好處，因?yàn)閭浞莩鰜?lái)的是 sql 語(yǔ)句，所以它支持跨平臺(tái)和跨版本的數(shù)據(jù)遷移或者恢復(fù)，這是物理備份無(wú)法做到的。

但是也正是因?yàn)?mysqldump 備份出來(lái)的是 sql 語(yǔ)句，在使用時(shí)要更加注意，否則可能會(huì)釀成大禍。例如，使用 mysqldump 常見(jiàn)的問(wèn)題有：

所以使用 mysqldump 時(shí)一定要了解各個(gè)選項(xiàng)的作用，以及確認(rèn)備份出來(lái)的 sql 文件里會(huì)有什么操作，會(huì)對(duì)現(xiàn)有數(shù)據(jù)造成什么影響。

Mydumper 原理與 Mysqldump 原理類似，最大的區(qū)別是引入了多線程備份，每個(gè)備份線程備份一部分表，當(dāng)然并發(fā)粒度可以到行級(jí)，達(dá)到多線程備份的目的。這里不再單獨(dú)介紹。

Percona XtraBackup 是 Percona 公司開(kāi)發(fā)的一個(gè)用于 MySQL 數(shù)據(jù)庫(kù)物理熱備的備份工具，是基于 InnoDB 的崩潰恢復(fù)功能來(lái)實(shí)現(xiàn)的。它的基本工作原理如下：

Percona XtraBackup 在進(jìn)行恢復(fù)時(shí)會(huì)應(yīng)用拷貝的 redo log ，應(yīng)用已提交的事務(wù)，回滾未提交的事物，將數(shù)據(jù)庫(kù)恢復(fù)到一致性狀態(tài)。因?yàn)?Percona XtraBackup 備份出來(lái)的是物理文件，所以在使用備份出的文件進(jìn)行恢復(fù)或者遷移時(shí)，不會(huì)像 mysqldump 那樣會(huì)存在很多問(wèn)題。

使用 XtraBackup 備份時(shí)根據(jù)備份參數(shù)設(shè)置不同，對(duì)數(shù)據(jù)庫(kù)的變更會(huì)造成不同程度的影響，具體影響會(huì)在下文分析。

通過(guò)對(duì)比發(fā)現(xiàn)，XtraBackup 具有對(duì)數(shù)據(jù)庫(kù)影響小，且能快速恢復(fù)的優(yōu)點(diǎn)，在日常備份中是首選；mysqldump 使用相對(duì)更加靈活，但是使用是要注意對(duì)數(shù)據(jù)庫(kù)原有數(shù)據(jù)的影響。

備份策略主要有：全量備份和增量備份，再加上 binlog 備份。

目前去哪兒網(wǎng)數(shù)據(jù)庫(kù)備份主要采用 XtraBackup 全量備份 +binlog 備份。數(shù)據(jù)庫(kù)的重要級(jí)別不同，全量備份的頻率不同。備份程序主要架構(gòu)如下：

說(shuō)明：

Percona XtraBackup 是目前備份 MySQL 使用最廣泛的工具。在備份過(guò)程中，數(shù)據(jù)庫(kù)可以進(jìn)行正常的讀寫(xiě)或者其他變更操作，但是偶爾也會(huì)遇見(jiàn)備份引起的元數(shù)據(jù)鎖，或提交事務(wù)時(shí)發(fā)現(xiàn)被 binlog lock 阻塞等情況。下面我們就看一下 Percona XtraBackup 的備份流程和加鎖時(shí)機(jī)。

說(shuō)明：以下對(duì) Percona XtraBackup 的分析都是基于 2.4.23 的版本，其他版本會(huì)略有差別，但是關(guān)鍵步驟基本相同。

XtraBackup 在備份開(kāi)始時(shí)，會(huì)創(chuàng)建一個(gè)后臺(tái)線程，專門(mén)用于拷貝數(shù)據(jù)庫(kù)的 redo log 。首先 XtraBackup 會(huì)掃描每組 redo log 的頭部，找出當(dāng)前的 checkpoint lsn ，然后從該 lsn 后順序拷貝所有的 redo log ，包括后續(xù)新產(chǎn)生的 redo log 。該線程會(huì)一直持續(xù)到將非事務(wù)表完全拷貝完成，才會(huì)安全退出。備份日志輸出中會(huì)記錄拷貝開(kāi)始時(shí)的 checkpoint lsn 。日志輸出如下：

在拷貝ibd文件之前，會(huì)先掃描數(shù)據(jù)庫(kù)的數(shù)據(jù)文件目錄，獲取ibdata1，undo tablespaces及所有的ibd文件列表，并會(huì)記錄相應(yīng)的 space id，因?yàn)樵诨謴?fù)時(shí)需要這些 space id來(lái)找到對(duì)應(yīng) doublewrite buffer里頁(yè)面的內(nèi)容，以及對(duì)應(yīng)的redo log條目。然后開(kāi)始循環(huán)拷貝ibdata1，undo tablespaces及所有的ibd文件。

這里可通過(guò)設(shè)置--parallel進(jìn)行多線程備份，提高物理文件的拷貝效率。不設(shè)置則默認(rèn)為1。

在所有ibd文件拷貝完成后，XtraBackup開(kāi)始備份非ibd文件。這一部分的邏輯比較復(fù)雜，因?yàn)閭浞莘莍bd文件前需要加鎖，具體是否會(huì)加鎖主要受到--no-lock 參數(shù)設(shè)置的影響。

若是設(shè)置了--no-lock為T(mén)RUE，則不會(huì)使用"FLUSH TABLES WITH READ LOCK"去加全局讀鎖，但是若備份過(guò)程中對(duì)non-InnoDB表執(zhí)行了DDL或者DML操作， 這會(huì)導(dǎo)致備份的不一致，恢復(fù)出來(lái)的數(shù)據(jù)就會(huì)有問(wèn)題。所以是不建議將--no-lock為T(mén)RUE，默認(rèn)值是FALSE，也就是在不指定該選項(xiàng)的情況下會(huì)在備份非ibd文件前加全局讀鎖。

下面我們結(jié)合源碼來(lái)看看判斷是否加全局鎖這部分的具體流程邏輯：

流程圖如下：

總結(jié)來(lái)看：

1）若--no-lock為FALSE（默認(rèn)值），則先施加全局讀鎖，然后再進(jìn)行拷貝文件，另外若 --safe-slave-backup 設(shè)置為T(mén)RUE ，則會(huì)在加全局鎖之前關(guān)閉SQL_THREAD線程；

2）若--no-lock為T(mén)RUE，則不會(huì)施加鎖，直接進(jìn)行拷貝文件。

加鎖的邏輯主要由lock_tables_maybe實(shí)現(xiàn),先看一下lock_tables_maybe源代碼，如下：

lock_tables_maybe 函數(shù)簡(jiǎn)化處理流程如下：

1）若備份實(shí)例上已經(jīng)加鎖（ LOCK TABLES FOR BACKUP / FLUSH TABLES WITH READ LOCK）或者設(shè)置lock-ddl-per-table 則直接返回；

2）若支持備份鎖，則執(zhí)行LOCK TABLES FOR BACKUP；

3）若不支持備份鎖，則執(zhí)行 FLUSH TABLES WITH READ LOCK。根據(jù)相應(yīng)選項(xiàng)設(shè)置，在執(zhí)行該操作前會(huì)判斷是否有執(zhí)行中的DDL/DML，以及等待超時(shí)時(shí)間，是否kill 對(duì)應(yīng)的未結(jié)束的事務(wù)等。

從上文中我們還看到一個(gè)參數(shù)--safe-slave-backup ，該參數(shù)的主要作用是：

若是在從庫(kù)執(zhí)行的備份操作時(shí)設(shè)置了該參數(shù)，可以防止因從庫(kù)同步主庫(kù)操作，而導(dǎo)致XtraBackup長(zhǎng)時(shí)間請(qǐng)求不到鎖而造成備份失敗。

若是設(shè)置了 --safe-slave-backup 為T(mén)RUE，那么會(huì)執(zhí)行"STOP SLAVE SQL_THREAD"，并等待Slave_open_temp_tables 為零才開(kāi)始拷貝非 ibd 文件，Slave_open_temp_tables 為零說(shuō)明SQL thread執(zhí)行的事務(wù)都已經(jīng)完成，這樣就能保證備份的一致性。并且此時(shí)也不會(huì)有在執(zhí)行的事務(wù)阻塞 XtraBackup 施加全局鎖。

備份完非 ibd 文件后，將會(huì)備份 slave 和 binlog 信息。

mysql-bin.000004 2004 6b7bda9f-15f0-11ec-ba14-fa163ea367a4:1-83,9841546e-15f0-11ec-9557-fa163e736db4:1

需要注意，在支持備份鎖的實(shí)例上備份，指定了 --slave-info 或--binlog-info 均會(huì)先施加 binlog 備份鎖（ LOCK BINLOG FOR BACKUP），這會(huì)阻塞任何會(huì)更改 binlog 位點(diǎn)的操作。

備份完數(shù)據(jù)庫(kù)的所有文件和binlog等相關(guān)信息，備份工作就基本完成了，之后主要執(zhí)行的操作如下：

1）執(zhí)行"FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS",將所有的redo log刷盤(pán)；

2）停止redo log復(fù)制線程；

3）釋放全局讀鎖（備份鎖），binlog鎖；

4）開(kāi)啟SQL_THREAD；

5）拷貝ib_buffer_pool和ib_lru_dump文件；

6）生成配置文件backup-my點(diǎn)吸煙 f；

7）打印備份信息到xtrabackup_info文件，這些信息主要包含備份時(shí)使用的參數(shù)信息，備份起止時(shí)間，binlog位點(diǎn)信息，以及將會(huì)回到的lsn點(diǎn)。

下面是xtrabackup_info記錄的部分內(nèi)容：

加鎖對(duì)應(yīng)的函數(shù)是 mdl_lock_tables ，釋放鎖對(duì)應(yīng)的函數(shù)是 mdl_unlock_all，主要是執(zhí)行COMMIT，結(jié)束 mdl_lock_tables 中開(kāi)啟的顯式事務(wù)，來(lái)釋放MDL鎖。mdl_lock_tables 流程如下：

上面參數(shù)--lock-ddl和--lock-ddl-per-table是在 Percona XtraBackup 2.4.8 之后添加的，因?yàn)?MySQL 5.7 新增了一個(gè)叫做 Sorted Index Builds 的功能，這會(huì)導(dǎo)致某些 DDL 操作不記錄重做日志而導(dǎo)致備份失敗。使用--lock-ddl或--lock-ddl-per-table 就會(huì)在備份開(kāi)始時(shí)施加鎖，阻止 DDL 操作。

另外，若備份時(shí)指定了--lock-ddl或--lock-ddl-per-table，則在備份非 ibd 文件時(shí)就不是再有加鎖操作。

注意：LOCK TABLES FOR BACKUP和LOCK BINLOG FOR BACKUP 語(yǔ)句只有在支持備份鎖的實(shí)例上才會(huì)執(zhí)行，Percona Server for MySQL已經(jīng)在 5.6.16-64.0 版本開(kāi)始支持這種更加輕量的備份鎖。

Q1: 使用 XtraBackup 備份的文件進(jìn)行恢復(fù)時(shí)，恢復(fù)到哪個(gè)時(shí)間點(diǎn)？ A1：恢復(fù)到執(zhí)行 LOCK BINLOG FOR BACKUP 或 FLUSH TABLES WITH READ LOCK 的時(shí)間點(diǎn)，因?yàn)檫@時(shí)任何改變 binlog 位點(diǎn)的操作都會(huì)被阻塞，redo log和binlog 是一致的。

Q2: 在開(kāi)啟 binlog 的情況下，MySQL 的奔潰恢復(fù)是同時(shí)依賴 binlog 和 redo log 這兩種日志的，為什么XtraBackup 不用備份binlog？

A2：因?yàn)樵趥浞葜杏袌?zhí)行LOCK BINLOG FOR BACKUP/FLUSH TABLES WITH READ LOCK，阻止了任何改變binlog位點(diǎn)的操作，這樣只需要根據(jù)redo log將有commit log 的事務(wù)提交，沒(méi)有commit log的事務(wù)進(jìn)行回滾即可。

Q3: 使用Percona XtraBackup備份完成后redo的位點(diǎn)是和binlog是一樣還是比binlog多一些？

A3：通過(guò)分析備份流程可以發(fā)現(xiàn)備份 binlog 位點(diǎn)信息（加binlog鎖）是發(fā)生在停止 redo 拷貝線程前，而釋放鎖是在停止 redo 拷貝線之后，所以 redo log 會(huì)多一些。鎖住了 binlog 保證了在該 binlog 位點(diǎn)前已經(jīng)提交的事務(wù)的 redo log 都有 commit log 的信息，未提交的事物也就沒(méi)有對(duì)應(yīng)的 commit log 的信息，即便在鎖住 binlog 后有 Innodb 表新的 DML 產(chǎn)生的 redo log ，但是事務(wù)無(wú)法提交，也就沒(méi)有 commit log 的信息的，最后在回放的過(guò)程中對(duì)沒(méi)有 commit log 的事務(wù)進(jìn)行回滾就可以了。

Q4：Percona XtraBackup什么時(shí)候會(huì)加鎖，以及影響加鎖時(shí)間長(zhǎng)度的因素有哪些？

A4：上面進(jìn)行了分析，加鎖操作只在備份非 ibd 文件時(shí)執(zhí)行，加鎖時(shí)長(zhǎng)主要和非事務(wù)表的數(shù)量和大小有關(guān)，非事務(wù)表的數(shù)量越多，體積越大，拷貝文件所用的時(shí)間越長(zhǎng)，那么加鎖時(shí)間也就越長(zhǎng)。也會(huì)和 redo log 生成的速度有關(guān)，只是 redo log 刷盤(pán)受到多個(gè)因素的影響，未及時(shí)刷盤(pán)的 redo log 一般很小。

Q5：Percona XtraBackup 和mysqldump選擇哪個(gè)更好？

A5：通過(guò)上面的的解析，若是整個(gè)實(shí)例備份，首先選擇 Percona XtraBackup ，因?yàn)閷?duì)數(shù)據(jù)庫(kù)的影響最小。若只是備份某個(gè)庫(kù)表，這個(gè)就要視數(shù)據(jù)量而定，若數(shù)據(jù)量不大可以使用 mysqldump 。注意，對(duì)數(shù)據(jù)庫(kù)做備份時(shí)最好選擇業(yè)務(wù)連接最少的從庫(kù)，因?yàn)閭浞菀矔?huì)消耗一定的資源，避免影響業(yè)務(wù)。

MySQL的備份與還原，非常規(guī)備份，全量備份，增量備份

1：官方百萬(wàn)級(jí)別的測(cè)試數(shù)據(jù)庫(kù)：

官方測(cè)試數(shù)據(jù)庫(kù)github網(wǎng)址：

下載到目錄，解壓即可，運(yùn)行命令：

2：自己創(chuàng)建簡(jiǎn)單測(cè)試數(shù)據(jù)庫(kù)：

快速隨機(jī)生成測(cè)試語(yǔ)言的網(wǎng)站：

選擇sql和想生成的字段，點(diǎn)擊生成Generate!生成即可。

在MySQL輸入生成的語(yǔ)句即可。

3：測(cè)試備份還原時(shí)用到的命令

刪庫(kù)跑路測(cè)試（先備份好）

還原后查詢庫(kù)的表數(shù)據(jù)是否完整。

采用復(fù)制整個(gè)數(shù)據(jù)存放目錄

1：查看數(shù)據(jù)庫(kù)數(shù)據(jù)存放位置

有兩種方法：

1)：在數(shù)據(jù)庫(kù)中用命令 show variables like 'datadir'; 查看

2)：在配置文件中查看，配置了 datadir 目錄的可查看。沒(méi)有配置的默認(rèn)為 /var/lib/mysql/ 位置

Linux中查看配置文件

2：復(fù)制目錄或者目錄下某個(gè)數(shù)據(jù)庫(kù)名

3：還原時(shí)直接復(fù)制文件夾到數(shù)據(jù)庫(kù)目錄即可

mysqldump又可叫做全量備份。

參數(shù) --databases 同 -B ，單獨(dú)一個(gè)庫(kù)，也可省略。

1、備份命令mysqldump格式

格式：mysqldump -h主機(jī)名 -P端口 -u用戶名 -p密碼 database 數(shù)據(jù)庫(kù)名 文件名.sql

備份testDatabase數(shù)據(jù)庫(kù)

2、備份MySQL數(shù)據(jù)庫(kù)為帶刪除表的格式

備份MySQL數(shù)據(jù)庫(kù)為帶刪除表的格式，能夠讓該備份覆蓋已有數(shù)據(jù)庫(kù)而不需要手動(dòng)刪除原有數(shù)據(jù)庫(kù)。

3、直接將MySQL數(shù)據(jù)庫(kù)壓縮備份

備份并壓縮

4、備份MySQL數(shù)據(jù)庫(kù)某個(gè)(些)表

備份testDatabase中的myTable表，不需要用參數(shù) --databases 或者 -B

5、同時(shí)備份多個(gè)MySQL數(shù)據(jù)庫(kù)

同時(shí)備份testDatabase和 employees兩個(gè)庫(kù)

6、備份服務(wù)器上所有數(shù)據(jù)庫(kù)

參數(shù) --all-databases 同 -A

7、還原MySQL數(shù)據(jù)庫(kù)的命令

1) 不指定數(shù)據(jù)名還原，默認(rèn)生成原數(shù)據(jù)庫(kù)名稱，還原所有數(shù)據(jù)庫(kù)。

2) 指定數(shù)據(jù)名還原，還原指定單個(gè)數(shù)據(jù)庫(kù)，需在數(shù)據(jù)庫(kù)種預(yù)先創(chuàng)建一個(gè)testDatabase名稱。

3) 還原壓縮的MySQL數(shù)據(jù)庫(kù)

4) 進(jìn)入數(shù)據(jù)庫(kù)用source導(dǎo)入

增量備份是針對(duì)于數(shù)據(jù)庫(kù)的bin-log日志進(jìn)行備份的，增量備份是在全量的基礎(chǔ)上進(jìn)行操作的。增量備份主要是靠mysql記錄的bin-log日志。

1：查看是否開(kāi)啟bin-log日志

進(jìn)入mysql輸入命令可查看。

顯示如下為開(kāi)啟狀態(tài)，日志文件在/var/lib/mysql/以binlog.00001的格式保存。

如未開(kāi)啟，需要在配置文件種配置

2：查看目前使用的bin-log日志文件

進(jìn)入mysql查看命令。

顯示如下，目前使用的是binlog.000022文件，所有操作都記錄在此文件。

查看當(dāng)前testDatabase的表myTable數(shù)據(jù)如下，

3：刷新日志，使用新的日志文件（備份）

在命令端執(zhí)行命令

日志文件從 binlog.000022 變?yōu)?binlog.000023

這時(shí)相當(dāng)與已經(jīng)備份成功，備份文件即為上次的binlog.000022日志文件。

4：刪除數(shù)量，從日志還原數(shù)據(jù)

1) 刪除ABC行

查詢以及沒(méi)有ABC行列。

2) 恢復(fù)數(shù)據(jù)ABC行

退出mysql，在命令端用mysqlbinlog命令恢復(fù)到binlog.000022日志狀態(tài)。

進(jìn)入數(shù)據(jù)庫(kù)再次查看數(shù)據(jù)，ABC已經(jīng)恢復(fù)。

增量備份完成。

名稱欄目：mysql怎么全量備份 mysql全備份命令
網(wǎng)站鏈接：http://www.rwnh.cn/article20/ddgosco.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供建站公司、網(wǎng)站維護(hù)、企業(yè)建站、域名注冊(cè)、云服務(wù)器、網(wǎng)頁(yè)設(shè)計(jì)公司

廣告

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