建站
咨詢
售后
建站咨詢
新聞中心
在MySQL數(shù)據(jù)庫中，binlog是一種用于記錄所有數(shù)據(jù)庫更改的二進(jìn)制日志文件。它重要的功能之一是用于數(shù)據(jù)庫的備份、恢復(fù)和數(shù)據(jù)遷移。在處理這些任務(wù)時(shí)，你可能會(huì)遇到需要指定數(shù)據(jù)庫解析binlog的情況。本文將為你介紹如何在不同場(chǎng)景下指定數(shù)據(jù)庫解析binlog。
成都創(chuàng)新互聯(lián)公司是一家專注于做網(wǎng)站、網(wǎng)站建設(shè)與策劃設(shè)計(jì),魚臺(tái)網(wǎng)站建設(shè)哪家好?成都創(chuàng)新互聯(lián)公司做網(wǎng)站,專注于網(wǎng)站建設(shè)十多年,網(wǎng)設(shè)計(jì)領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:魚臺(tái)等地區(qū)。魚臺(tái)做網(wǎng)站價(jià)格咨詢:028-86922220
1. 使用mysqlbinlog命令解析binlog文件
mysqlbinlog是MySQL自帶的解析binlog的工具，它可以將binlog文件的內(nèi)容還原成原始的SQL語句。你可以用以下命令來使用mysqlbinlog：
“`mysqlbinlog [options] [–] binlog-file…“`
其中，[options]是mysqlbinlog的選項(xiàng)，binlog-file是你要解析的binlog文件。例如，如果你要解析名為mysql-bin.000001的binlog文件，可以運(yùn)行以下命令：
“`mysqlbinlog mysql-bin.000001“`
如果你的服務(wù)器上有多個(gè)binlog文件，你可以指定多個(gè)文件，例如：
“`mysqlbinlog mysql-bin.000001 mysql-bin.000002 mysql-bin.000003“`
由于mysqlbinlog能夠解析所有的binlog文件，而不管這些文件來自哪個(gè)數(shù)據(jù)庫，因此在解析binlog的時(shí)候，你需要指定要解析的數(shù)據(jù)庫。你可以使用”–database”選項(xiàng)指定，例如：
“`mysqlbinlog –database=mydatabase mysql-bin.000001“`
這將只顯示”mydatabase”數(shù)據(jù)庫中的更新。
2. 使用pt-query-digest解析binlog事件
如果你需要對(duì)binlog更深入地進(jìn)行分析，例如統(tǒng)計(jì)SQL執(zhí)行次數(shù)、執(zhí)行時(shí)間、慢查詢等信息，可以使用Percona Toolkit中的pt-query-digest工具來解析binlog事件。pt-query-digest是一種基于命令行的工具，它可以從多個(gè)來源獲取二進(jìn)制日志，如文件、管道和數(shù)據(jù)庫等。你可以使用以下命令使用pt-query-digest解析binlog事件：
“`pt-query-digest –type=binlog binlog-file“`
其中，binlog-file是你要解析的binlog文件名。使用”–type”選項(xiàng)指定解析類型（默認(rèn)是general）。
在使用pt-query-digest解析binlog事件時(shí)，需要指定一到多個(gè)連接到MySQL服務(wù)器的選項(xiàng)，例如MySQL用戶名、密碼、主機(jī)名和端口號(hào)等等。你可以使用”–user”、”–password”、”–host”、”–port”選項(xiàng)指定相應(yīng)的值。例如：
“`pt-query-digest –type=binlog –user=root –password=password –host=localhost –port=3306 mysql-bin.000001“`
在解析binlog事件時(shí)，pt-query-digest會(huì)將二進(jìn)制日志還原成SQL語句，并將其打印到終端中。你可以使用”–output”選項(xiàng)來指定輸出方式，如輸出到文件或數(shù)據(jù)庫等。例如：
“`pt-query-digest –type=binlog –user=root –password=password –host=localhost –port=3306 mysql-bin.000001 –output=/path/to/output“`
這將將pt-query-digest的輸出保存到指定的文件中。
3. 使用MySQL Enterprise Monitor解析binlog事件
如果你使用的是MySQL Enterprise數(shù)據(jù)庫，你可以使用MySQL Enterprise Monitor來解析binlog事件。MySQL Enterprise Monitor是一款商業(yè)軟件，它提供了豐富的功能，包括性能管理、監(jiān)控、報(bào)告和警報(bào)等。你可以使用它來解析binlog，并查看二進(jìn)制日志的詳細(xì)信息。使用MySQL Enterprise Monitor解析binlog事件需要執(zhí)行以下步驟：
（1）打開MySQL Enterprise Monitor的GUI界面，進(jìn)入”Event Analysis”菜單，并選擇”Binary Log Events”選項(xiàng)卡。
（2）在”Binary Log Events”選項(xiàng)卡中，你可以瀏覽所有可用的binlog文件，并選擇你要解析的binlog文件。
（3）在選擇了binlog文件之后，你可以選擇要解析的事件類型，并設(shè)置其他篩選條件。
（4）點(diǎn)擊”Analyze”按鈕，MySQL Enterprise Monitor會(huì)解析binlog事件并顯示其詳細(xì)信息。
MySQL Enterprise Monitor的優(yōu)點(diǎn)在于它能夠?qū)ySQL數(shù)據(jù)庫進(jìn)行全面監(jiān)控，包括性能、安全和可用性等方面。因此，如果你需要全面了解你的MySQL數(shù)據(jù)庫，它可能是一個(gè)不錯(cuò)的選擇。
結(jié)論
在不同的場(chǎng)景下，你可以使用不同的方式來指定數(shù)據(jù)庫解析binlog。如果你只需要還原SQL語句，可以使用mysqlbinlog；如果你需要更深入地分析binlog事件，可以使用pt-query-digest；如果你使用MySQL Enterprise數(shù)據(jù)庫并需要全面監(jiān)控，可以使用MySQL Enterprise Monitor。但無論你使用哪種方法，你都需要指定要解析的binlog文件和要解析的數(shù)據(jù)庫。
相關(guān)問題拓展閱讀：
- 跪求MySQL Binlog Digger(日志挖掘分析工具) V4.4 綠色版軟件百度云資源
- XtraBackup 備份指定庫
跪求MySQL Binlog Digger(日志挖掘分析工具) V4.4 綠色版軟件百度云資源
鏈接:
提取碼:a2vh
軟件名稱:MySQLBinlogDigger(日志挖掘分析工具)V4.4綠色版
語言:英文軟件
大小:13.14MB
類別:系統(tǒng)工具
介紹:MySQLBinlogDigger基于圖形界面，綠色免安裝，能對(duì)在線binlog與離線binlog進(jìn)行分析，在選定在線binlog或離線binlog日志后，可對(duì)數(shù)據(jù)庫、表、binlog開始時(shí)間、binlog結(jié)束時(shí)間、誤操作的重做類型進(jìn)行信息分析。
XtraBackup 備份指定庫
Percona XtraBackup的功能之一“部分備份（partial backups）”，即讓用戶可以備份指定的表或數(shù)據(jù)庫。要注意的是：你希望備份的表必須是在獨(dú)立的表空間中，即該表在創(chuàng)建以前，你的MySQL開啟了innodb_file_per_table設(shè)置。
還一點(diǎn)要注意的是：不要將prepared backup備份的東西拷貝回去。部分備份使用的是導(dǎo)入表（importing the tables），而不是全庫備份的–copy-back參數(shù)。盡管有時(shí)簡(jiǎn)單的拷貝備份文件可以成功，但是這種方法很容易導(dǎo)致數(shù)據(jù)庫的不一致，因此不推薦大家這么做。
創(chuàng)建部分備份（Creating Partial Backups）
部分備份共有三種方式，分別是：1. 用正則表達(dá)式表示要備份的庫名及表名（參數(shù)為–include）；2. 將要備份的表名或庫名都寫在一個(gè)文本文件中（參數(shù)為–tables-file）以及 3. 將要備份表名或庫名完整的寫在命令行中（參數(shù)為：–databases）。（譯者注：不管你備份哪個(gè)庫或是哪張表，強(qiáng)烈推薦把mysql庫也一起備份，恢復(fù)的時(shí)候要用。）
方式一：使用–include參數(shù)
這種方式通過正則表達(dá)式來匹配數(shù)據(jù)庫名和表名，你需要寫完整的數(shù)據(jù)庫名及表名，如果數(shù)據(jù)庫有用戶名密碼請(qǐng)使用–user和–password指定相關(guān)信息。，格式如下：databasename.tablename。下面是一個(gè)例子：
$ innobackupex –include=’^mydatabasemytable’ /path/to/backup –user=backup –password=backup
上面的方式會(huì)和其他使用innobackupex命令的備份方式一樣，創(chuàng)建一個(gè)時(shí)間戳命名的文件夾，不同的是，最終只包括那些正則表達(dá)式匹配的表。
要注意的是，這個(gè)命令最后會(huì)傳給xtrabackup –tables命令執(zhí)行，并且會(huì)為每個(gè)數(shù)據(jù)庫（包括不需要備份的數(shù)據(jù)庫）創(chuàng)建一個(gè)對(duì)應(yīng)的文件夾。
方式二：使用–tables-file參數(shù)
這種方式是將所有要顫桐備份的完整表名都寫在一個(gè)文本文件中，每行一個(gè)完整表名，然后程序讀取這個(gè)文本文件進(jìn)行備份。完整表名即：databasename.tablename。如果數(shù)據(jù)庫有用戶名密碼請(qǐng)使用–user和–password指定相關(guān)信息。下面是一個(gè)例子：
$ echo “mydatabase.mytable” > /tmp/tables.txt$ innobackupex –tables-file=/tmp/tables.txt /path/清洞尺to/backup –user=backup –password=backup
上面的方式會(huì)和其他使用innobackupex命令的備份方式一樣，創(chuàng)建一個(gè)時(shí)間戳命名的文件夾，不同的是，最終只包括那些文件中指定的表名。
這個(gè)命令最后會(huì)傳給xtrabackup –tables-file命令執(zhí)行，而不是–tables，因答高此這個(gè)命令只會(huì)創(chuàng)建那些需要備份的數(shù)據(jù)庫文件夾。
Xtrabackup 是由 percona 開源的免費(fèi)數(shù)據(jù)庫熱備份軟件，它能對(duì) InnoDB 和 XtraDB 存儲(chǔ)引擎的數(shù)據(jù)庫非阻塞地備份。
為了方便建立從庫，Xtrabackup 在備份完成后會(huì)將 binlog position 與 GTID 的相關(guān)信息保存于 xtrabackup_binlog_info 文件中。但是當(dāng)你使用 Xtrabackup 生成的備份建立一個(gè)從庫時(shí)，會(huì)發(fā)現(xiàn)恢復(fù)后的實(shí)例執(zhí)行 show master status，顯示的 Executed_Gtid_Set 與 xtrabackup_binlog_info 文件中記錄的信息并不一致，而且使用 Xtrabackup 2.4 與 8.0（對(duì) MySQL 8.0 進(jìn)行備份）生成的備份在恢復(fù)后，信息不一致的表現(xiàn)又不相同。本篇文章主要針對(duì)該現(xiàn)象進(jìn)行簡(jiǎn)單的分析。
一、Xtrabackup 2.4.18 for MySQL 5.7.26
現(xiàn)象
1. 使用 Xtrabackup 工具備份后，xtrabackup_binlog_info 文件記錄的信息如下：\# cat xtrabackup_binlog_infomysql-bin.d3d9b9-4d49-11ea-932c-02023aba3fa6:
2. 將該備份恢復(fù)至一個(gè)新實(shí)例并啟動(dòng)該實(shí)例，執(zhí)行 show master status; 查看信息：mysql> show master status\G*************************** 1. row ***************************File: mysql-bin. Position:Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 55d3d9b9-4d49-11ea-932c-02023aba3fa6:row in set (0.00 sec)
此時(shí)會(huì)發(fā)現(xiàn)使用備份恢復(fù)的實(shí)例顯示已執(zhí)行過的 GTID 是，而備份文件顯示的是，這是否表示兩者相差的 GTID:代表的事務(wù)丟失了？通過對(duì)原實(shí)例（進(jìn)行備份的實(shí)例）的 binlog 進(jìn)行解析，來查詢 GTID:這部分事務(wù)所生成的數(shù)據(jù)在新實(shí)例（通過備份恢復(fù)的實(shí)例）上是否存在?？梢园l(fā)現(xiàn) GTID:這部分事務(wù)的數(shù)據(jù)都存在于新實(shí)例上，也就是說數(shù)據(jù)與 xtrabackup_binlog_info 文件記錄的是一致的，只不過與 show master status 命令獲取的信息的不一致。
原因分析
首先我們要清楚 Xtrabackup 2.4 的備份流程悔孝，大致如下：
1. start backup
2. copy ibdata1 / copy .ibd file
3. Excuted ftwrl
4. backup non-InnoDB tables and files
5. Writing xtrabackup_binlog_info
6. Executed FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS
7. Executed UNLOCK TABLES
8. Copying ib_buffer_pool
9. completed OK!
結(jié)合備份時(shí)的 general log 可知，Xtrabackup 在執(zhí)行 ftwrl 并備份完所有非 InnoDB 表格的文件后通過 show master status 獲取了 binlog position 和 GTID 的信息，將其記錄到 xtrabackup_binlog_info 文件中。
那么 show master status 獲取的是哪些信息？
該命令提供本實(shí)例的 binlog 文件的狀態(tài)信息，顯示正在寫入的 binlog 文件，以及當(dāng)前的binlog position，并且 MySQL 5.7 在 MySQL 庫下引入了 gtid_executed 表，該表會(huì)記錄當(dāng)前執(zhí)行過的 GTID。
那么目前看來問題可能就出桐檔在 gtid_executed 表格碧輪稿上，通過測(cè)試和官方文檔提供的信息可知，該表格雖然是 InnoDB 表，但是其中的數(shù)據(jù)并非是實(shí)時(shí)更新的，且該表格記錄信息的方式存在以下兩個(gè)情況：1. 如果禁用了 log_bin，實(shí)例不會(huì)在該表格記錄任何信息；若從庫的 log_slave_updates 為 OFF，那么從庫會(huì)在應(yīng)用 relay-log 中的每個(gè)事務(wù)時(shí)執(zhí)行一次 insert mysql.gtid_executed 的操作。2. 如果啟用了 log_bin，則該表格記錄的是在 binlog 發(fā)生切換（rotate）的時(shí)候直到上一個(gè) binlog 文件執(zhí)行過的全部 GTID，而此時(shí) show master status 獲取的 Gtid 信息不再由 mysql.gtid_executed 表提供，而是由全局系統(tǒng)變量 gtid_exected 提供；如果服務(wù)器意外停止，則當(dāng)前 binlog 文件中的 Gtid 不會(huì)保存在 mysql.gtid_executed 表中，在實(shí)例恢復(fù)期間，這些 Gtid 從 binlog 文件中讀取并添加到表中。
小結(jié)
所以當(dāng)備份恢復(fù)時(shí)，實(shí)際 show master status 可能會(huì)出現(xiàn)以下情況：1. 當(dāng) log_bin 禁用或者 log_slave_updates 為 OFF 時(shí)，備份恢復(fù)后的實(shí)例 show master status 顯示為空。2. 當(dāng)開啟了 log_bin，但是該實(shí)例并未發(fā)生過 binlog 的切換時(shí)，備份恢復(fù)后的實(shí)例 show master status 顯示也為空。3. 當(dāng)開啟了 log_bin，其該實(shí)例的 binlog 發(fā)生過切換時(shí)，備份恢復(fù)后的實(shí)例 show master status 顯示的信息會(huì)比 xtrabackup_binlog_info 文件中記錄的 GTID 缺失一部分，這一部分就是 mysql.gtid_executed 表格未記錄的部分。
二、Xtrabackup 8.0.8 for MySQL 8.0.18現(xiàn)象1. 使用 Xtrabackup 工具備份后，xtrabackup_binlog_info 文件記錄的信息如下：# # cat xtrabackup_binlog_infobinlog. 70ec927f-4c6d-11ea-b88c-02023aba3fb1:
2. 查看備份實(shí)例相對(duì)應(yīng)的 binlog 解析后的內(nèi)容：
# mysqlbinlog -vv binlog.| less
定位至 70ec927f-4c6d-11ea-b88c-02023aba3fb1:621683
# at 508
#:46:47 server idend_log_posGTID last_committed=sequence_number=rbr_only=yes original_committed_timestamp=07 immediate_commit_timestamp=
transaction_length=317
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=07 (:46:47.CST)
# immediate_commit_timestamp=07 (:46:47.CST)
/*!80001 SET @@session.original_commit_timestamp=07*//*!*/;
/*!80014 SET @@session.original_server_version=80018*//*!*/;
/*!80014 SET @@session.immediate_server_version=80018*//*!*/;
SET @@SESSION.GTID_NEXT= ’70ec927f-4c6d-11ea-b88c-02023aba3fb1:621683’/*!*/;
# at 583
#:46:47 server idend_log_posQuery thread_id=214 exec_time=0 error_code=0
SET TIMESTAMP=/*!*/;
BEGIN
/*!*/;
# at 659
#:46:47 server idend_log_posRows_query
# insert into t1 values(null,2)
# at 708
#:46:47 server idend_log_posTable_map: `mysqlslap`.`t1` mapped to number 314
# at 758
#:46:47 server idend_log_posWrite_rows: table id 314 flags: STMT_END_F
BINLOG ‘
x+JEXh2wIAoAMQAAAMQCAACAAB1pbnNlcnQgaW50byB0MSB2YWx1ZXMobnVCwyKQ==
x+JEXhOwIAoAMgAAAPYCAAAAADoBAAAAAAEACW15c3Fsc2xhcAACdDEAAgMDAAIBAQA=
x+JEXh6wIAoAKAAAAB4DAAAAADoBAAAAAAEAAgAC/wCKAAEAAgAAAA==
‘/*!*/;
### INSERT INTO `mysqlslap`.`t1`
### SET
### @1=65674 /* INT meta=0 nullable=0 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
# at 798
#:46:47 server idend_log_posXid =
COMMIT/*!*/;
可以發(fā)現(xiàn)該文件提供的 binlog position 與 GTID 并不對(duì)應(yīng)。而 binlog.000033:1459 對(duì)應(yīng)的 GTID 是 70ec927f-4c6d-11ea-b88c-02023aba3fb1:提交后的下一個(gè)位置：
# at 1142
#:46:47 server idend_log_posGTID last_committed=sequence_number=rbr_only=yes original_committed_timestamp=46 immediate_commit_timestamp=
transaction_length=317
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=46 (:46:47.CST)
# immediate_commit_timestamp=46 (:46:47.CST)
/*!80001 SET @@session.original_commit_timestamp=46*//*!*/;
/*!80014 SET @@session.original_server_version=80018*//*!*/;
/*!80014 SET @@session.immediate_server_version=80018*//*!*/;
SET @@SESSION.GTID_NEXT= ’70ec927f-4c6d-11ea-b88c-02023aba3fb1:621685’/*!*/;
# at 1217
#:46:47 server idend_log_posQuery thread_id=215 exec_time=0 error_code=0
SET TIMESTAMP=/*!*/;
BEGIN
/*!*/;
# at 1293
#:46:47 server idend_log_posRows_query
# insert into t1 values(null,2)
# at 1342
#:46:47 server idend_log_posTable_map: `mysqlslap`.`t1` mapped to number 314
# at 1392
#:46:47 server idend_log_posWrite_rows: table id 314 flags: STMT_END_F
BINLOG ‘
x+JEXh2wIAoAMQAAAD4FAACAAB1pbnNlcnQgaW50byB0MSB2YWx1ZXMobnVCwyKQ==
x+JEXhOwIAoAMgAAAHAFAAAAADoBAAAAAAEACW15c3Fsc2xhcAACdDEAAgMDAAIBAQA=
x+JEXh6wIAoAKAAAAJgFAAAAADoBAAAAAAEAAgAC/wCMAAEAAgAAAA==
‘/*!*/;
### INSERT INTO `mysqlslap`.`t1`
### SET
### @1=65676 /* INT meta=0 nullable=0 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
# at 1432
#:46:47 server idend_log_posXid =
COMMIT/*!*/;
# at 1459
3. 再看將備份恢復(fù)到一個(gè)新實(shí)例并啟動(dòng)后，執(zhí)行 show master status 顯示的信息：mysql> show master status\G*************************** 1. row ***************************File: binlog. Position:Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 70ec927f-4c6d-11ea-b88c-02023aba3fb1:row in set (0.00 sec)
可以發(fā)現(xiàn)與 Xtrabackup 2.4 不同的是，該備份的 xtrabackup_binlog_info 文件記錄的信息并不準(zhǔn)確，而備份恢復(fù)后顯示的信息卻是準(zhǔn)確的。
原因
首先我們來看一下 Xtrabackup 8.0 針對(duì) MySQL 8.0 備份的大致過程：1. start backup2. copy .ibd file3. backup non-InnoDB tables and files4. Executed FLUSH NO_WRITE_TO_BINLOG BINARY LOGS5. Selecting LSN and binary log position from p_s.log_status6. copy last binlog file7. Writing /mysql/backup/backup/binlog.index8. Writing xtrabackup_binlog_info9. Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS10. copy ib_buffer_pool11. completed OK!由以上步驟可知，Xtrabackup 8.0 對(duì) MySQL 8.0 的備份與 Xtrabackup 2.4 略有不同，根據(jù) percona 官方文檔的信息，當(dāng) MySQL 8.0 中僅存在 InnoDB 引擎的表格時(shí)，不再執(zhí)行ftwrl（當(dāng)存在非 InnoDB 的表格或者使用 –slave-info 選項(xiàng)時(shí)會(huì)執(zhí)行），而是根據(jù)上述步驟的第 5 步，Xtrabackup 8.0 會(huì)通過SELECT server_uuid, local, replication, storage_engines FROM performance_schema.log_status
來獲取 LSN 、binlog position and Gtid。1. performance_schema.log_status 是 MySQL 8.0 提供給在線備份工具獲取復(fù)制日志文件信息的表格。查詢 log_status 表時(shí)，服務(wù)器將阻止日志的記錄和相關(guān)的更改來獲取足夠的時(shí)間以填充該表，然后釋放資源。Log_status 表通知在線備份工具應(yīng)記錄主庫的 binlog 的哪個(gè)位點(diǎn)和 gtid_executed 的值，還有每個(gè)復(fù)制通道的 relay log。它還為各個(gè)存儲(chǔ)引擎提供了相關(guān)信息，例如 InnoDB 存儲(chǔ)引擎使用的最后一個(gè)日志序列號(hào)（LSN）和最后一個(gè)檢查點(diǎn)的 LSN。2. 經(jīng)過測(cè)試發(fā)現(xiàn)，當(dāng)無數(shù)據(jù)寫入時(shí)， performance_schema.log_status 提供的 binlog position 與 GTID 是一致的，但是當(dāng)有大量數(shù)據(jù)持續(xù)寫入時(shí)，該表格提供的 binlog position 與 GTID 信息將不再一致，如下圖：
3. 既然 performance_schema.log_status 提供的信息不一致，那么為什么備份恢復(fù)后，GTID 沒有缺失？這是因?yàn)?Xtrabackup 8.0 在備份過程中多了兩步操作，F(xiàn)LUSH NO_WRITE_TO_BINLOG BINARY LOGS 和 copy binlog，Xtrabackup 8.0 在備份完非 InnoDB 表格的文件時(shí)會(huì)先切換 binlog，然后將切換后的 binlog 也進(jìn)行備份，這樣使用該備份恢復(fù)的新實(shí)例在啟動(dòng)后不僅會(huì)讀取 gtid_executed 表，也會(huì)讀取 binlog 文件來更新 GTID，就可以保持與備份時(shí) xtrabackup_binlog_info 文件記錄的 binlog position 保持一致（需要注意的是 MySQL 8.0 的 gtid_executed 表格不再是當(dāng) binlog 切換時(shí)更新，而是會(huì)不斷的實(shí)時(shí)更新，但需要注意在有大量數(shù)據(jù)寫入時(shí)也不能做到和全局變量 gtid_exeuted 保持嚴(yán)格一致）。4. 當(dāng) MySQL 8.0 中存在非 InnoDB 的表格，比如 MyISAM 表時(shí)，Xtrabackup 8.0 會(huì)在執(zhí)行完 FLUSH NO_WRITE_TO_BINLOG BINARY LOGS 后執(zhí)行 ftwrl，此時(shí)查詢 performance_schema.log_status 得到的 binlog position 與 GTID 是一致的，且備份恢復(fù)后 show master status 顯示的信息也與 xtrabackup_binlog_info 文件記錄的信息一致。
總結(jié)1. Xtrabackup 2.4 備份后生成的 xtrabackup_binlog_info 文件記錄的 GTID 信息是準(zhǔn)確的，但是備份恢復(fù)后 show master status 顯示的 GTID 是不準(zhǔn)確的。2. Xtrabackup 8.0 在備份只有 InnoDB 表的實(shí)例時(shí)，xtrabackup_binlog_info 文件記錄的 GTID 信息不一定是準(zhǔn)確的，但是備份恢復(fù)后 show master status 顯示的 GTID 是準(zhǔn)確的。3. Xtrabackup 8.0 在備份有非 InnoDB 表格的實(shí)例時(shí)，xtrabackup_binlog_info 文件記錄的 GTID 信息是準(zhǔn)確的，備份恢復(fù)后 show master status 顯示的 GTID 也是準(zhǔn)確的。
注意：此處的“準(zhǔn)確”主要指 xtrabackup_binlog_info 文件中記錄的 GTID 與備份中實(shí)際的 binlog position & 數(shù)據(jù)是否一致。
xtrabackup可以進(jìn)行遠(yuǎn)程備份，答液不過有些麻煩。
解析binlog 指定數(shù)據(jù)庫的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于解析binlog 指定數(shù)據(jù)庫,深入剖析：如何指定數(shù)據(jù)庫解析binlog,跪求MySQL Binlog Digger(日志挖掘分析工具) V4.4 綠色版軟件百度云資源,XtraBackup 備份指定庫的信息別忘了在本站進(jìn)行查找喔。
香港服務(wù)器選創(chuàng)新互聯(lián)，2H2G首月10元開通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）互聯(lián)網(wǎng)服務(wù)提供商,擁有超過10年的服務(wù)器租用、服務(wù)器托管、云服務(wù)器、虛擬主機(jī)、網(wǎng)站系統(tǒng)開發(fā)經(jīng)驗(yàn)。專業(yè)提供云主機(jī)、虛擬主機(jī)、域名注冊(cè)、VPS主機(jī)、云服務(wù)器、香港云服務(wù)器、免備案服務(wù)器等。
當(dāng)前標(biāo)題：深入剖析：如何指定數(shù)據(jù)庫解析binlog(解析binlog指定數(shù)據(jù)庫)
地址分享：http://m.fisionsoft.com.cn/article/dpogsoo.html
