建站
咨詢
售后
建站咨詢
新聞中心
在MySQL數(shù)據(jù)庫中，binlog是一種用于記錄所有數(shù)據(jù)庫更改的二進制日志文件。它重要的功能之一是用于數(shù)據(jù)庫的備份、恢復(fù)和數(shù)據(jù)遷移。在處理這些任務(wù)時，你可能會遇到需要指定數(shù)據(jù)庫解析binlog的情況。本文將為你介紹如何在不同場景下指定數(shù)據(jù)庫解析binlog。
成都創(chuàng)新互聯(lián)公司是一家專注于做網(wǎng)站、網(wǎng)站建設(shè)與策劃設(shè)計,魚臺網(wǎng)站建設(shè)哪家好?成都創(chuàng)新互聯(lián)公司做網(wǎng)站,專注于網(wǎng)站建設(shè)十多年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:魚臺等地區(qū)。魚臺做網(wǎng)站價格咨詢:028-86922220
1. 使用mysqlbinlog命令解析binlog文件
mysqlbinlog是MySQL自帶的解析binlog的工具，它可以將binlog文件的內(nèi)容還原成原始的SQL語句。你可以用以下命令來使用mysqlbinlog：
“`mysqlbinlog [options] [–] binlog-file…“`
其中，[options]是mysqlbinlog的選項，binlog-file是你要解析的binlog文件。例如，如果你要解析名為mysql-bin.000001的binlog文件，可以運行以下命令：
“`mysqlbinlog mysql-bin.000001“`
如果你的服務(wù)器上有多個binlog文件，你可以指定多個文件，例如：
“`mysqlbinlog mysql-bin.000001 mysql-bin.000002 mysql-bin.000003“`
由于mysqlbinlog能夠解析所有的binlog文件，而不管這些文件來自哪個數(shù)據(jù)庫，因此在解析binlog的時候，你需要指定要解析的數(shù)據(jù)庫。你可以使用”–database”選項指定，例如：
“`mysqlbinlog –database=mydatabase mysql-bin.000001“`
這將只顯示”mydatabase”數(shù)據(jù)庫中的更新。
2. 使用pt-query-digest解析binlog事件
如果你需要對binlog更深入地進行分析，例如統(tǒng)計SQL執(zhí)行次數(shù)、執(zhí)行時間、慢查詢等信息，可以使用Percona Toolkit中的pt-query-digest工具來解析binlog事件。pt-query-digest是一種基于命令行的工具，它可以從多個來源獲取二進制日志，如文件、管道和數(shù)據(jù)庫等。你可以使用以下命令使用pt-query-digest解析binlog事件：
“`pt-query-digest –type=binlog binlog-file“`
其中，binlog-file是你要解析的binlog文件名。使用”–type”選項指定解析類型（默認是general）。
在使用pt-query-digest解析binlog事件時，需要指定一到多個連接到MySQL服務(wù)器的選項，例如MySQL用戶名、密碼、主機名和端口號等等。你可以使用”–user”、”–password”、”–host”、”–port”選項指定相應(yīng)的值。例如：
“`pt-query-digest –type=binlog –user=root –password=password –host=localhost –port=3306 mysql-bin.000001“`
在解析binlog事件時，pt-query-digest會將二進制日志還原成SQL語句，并將其打印到終端中。你可以使用”–output”選項來指定輸出方式，如輸出到文件或數(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)控、報告和警報等。你可以使用它來解析binlog，并查看二進制日志的詳細信息。使用MySQL Enterprise Monitor解析binlog事件需要執(zhí)行以下步驟：
（1）打開MySQL Enterprise Monitor的GUI界面，進入”Event Analysis”菜單，并選擇”Binary Log Events”選項卡。
（2）在”Binary Log Events”選項卡中，你可以瀏覽所有可用的binlog文件，并選擇你要解析的binlog文件。
（3）在選擇了binlog文件之后，你可以選擇要解析的事件類型，并設(shè)置其他篩選條件。
（4）點擊”Analyze”按鈕，MySQL Enterprise Monitor會解析binlog事件并顯示其詳細信息。
MySQL Enterprise Monitor的優(yōu)點在于它能夠?qū)ySQL數(shù)據(jù)庫進行全面監(jiān)控，包括性能、安全和可用性等方面。因此，如果你需要全面了解你的MySQL數(shù)據(jù)庫，它可能是一個不錯的選擇。
結(jié)論
在不同的場景下，你可以使用不同的方式來指定數(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基于圖形界面，綠色免安裝，能對在線binlog與離線binlog進行分析，在選定在線binlog或離線binlog日志后，可對數(shù)據(jù)庫、表、binlog開始時間、binlog結(jié)束時間、誤操作的重做類型進行信息分析。
XtraBackup 備份指定庫
Percona XtraBackup的功能之一“部分備份（partial backups）”，即讓用戶可以備份指定的表或數(shù)據(jù)庫。要注意的是：你希望備份的表必須是在獨立的表空間中，即該表在創(chuàng)建以前，你的MySQL開啟了innodb_file_per_table設(shè)置。
還一點要注意的是：不要將prepared backup備份的東西拷貝回去。部分備份使用的是導(dǎo)入表（importing the tables），而不是全庫備份的–copy-back參數(shù)。盡管有時簡單的拷貝備份文件可以成功，但是這種方法很容易導(dǎo)致數(shù)據(jù)庫的不一致，因此不推薦大家這么做。
創(chuàng)建部分備份（Creating Partial Backups）
部分備份共有三種方式，分別是：1. 用正則表達式表示要備份的庫名及表名（參數(shù)為–include）；2. 將要備份的表名或庫名都寫在一個文本文件中（參數(shù)為–tables-file）以及 3. 將要備份表名或庫名完整的寫在命令行中（參數(shù)為：–databases）。（譯者注：不管你備份哪個庫或是哪張表，強烈推薦把mysql庫也一起備份，恢復(fù)的時候要用。）
方式一：使用–include參數(shù)
這種方式通過正則表達式來匹配數(shù)據(jù)庫名和表名，你需要寫完整的數(shù)據(jù)庫名及表名，如果數(shù)據(jù)庫有用戶名密碼請使用–user和–password指定相關(guān)信息。，格式如下：databasename.tablename。下面是一個例子：
$ innobackupex –include=’^mydatabasemytable’ /path/to/backup –user=backup –password=backup
上面的方式會和其他使用innobackupex命令的備份方式一樣，創(chuàng)建一個時間戳命名的文件夾，不同的是，最終只包括那些正則表達式匹配的表。
要注意的是，這個命令最后會傳給xtrabackup –tables命令執(zhí)行，并且會為每個數(shù)據(jù)庫（包括不需要備份的數(shù)據(jù)庫）創(chuàng)建一個對應(yīng)的文件夾。
方式二：使用–tables-file參數(shù)
這種方式是將所有要顫桐備份的完整表名都寫在一個文本文件中，每行一個完整表名，然后程序讀取這個文本文件進行備份。完整表名即：databasename.tablename。如果數(shù)據(jù)庫有用戶名密碼請使用–user和–password指定相關(guān)信息。下面是一個例子：
$ echo “mydatabase.mytable” > /tmp/tables.txt$ innobackupex –tables-file=/tmp/tables.txt /path/清洞尺to/backup –user=backup –password=backup
上面的方式會和其他使用innobackupex命令的備份方式一樣，創(chuàng)建一個時間戳命名的文件夾，不同的是，最終只包括那些文件中指定的表名。
這個命令最后會傳給xtrabackup –tables-file命令執(zhí)行，而不是–tables，因答高此這個命令只會創(chuàng)建那些需要備份的數(shù)據(jù)庫文件夾。
Xtrabackup 是由 percona 開源的免費數(shù)據(jù)庫熱備份軟件，它能對 InnoDB 和 XtraDB 存儲引擎的數(shù)據(jù)庫非阻塞地備份。
為了方便建立從庫，Xtrabackup 在備份完成后會將 binlog position 與 GTID 的相關(guān)信息保存于 xtrabackup_binlog_info 文件中。但是當(dāng)你使用 Xtrabackup 生成的備份建立一個從庫時，會發(fā)現(xiàn)恢復(fù)后的實例執(zhí)行 show master status，顯示的 Executed_Gtid_Set 與 xtrabackup_binlog_info 文件中記錄的信息并不一致，而且使用 Xtrabackup 2.4 與 8.0（對 MySQL 8.0 進行備份）生成的備份在恢復(fù)后，信息不一致的表現(xiàn)又不相同。本篇文章主要針對該現(xià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ù)至一個新實例并啟動該實例，執(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)
此時會發(fā)現(xiàn)使用備份恢復(fù)的實例顯示已執(zhí)行過的 GTID 是，而備份文件顯示的是，這是否表示兩者相差的 GTID:代表的事務(wù)丟失了？通過對原實例（進行備份的實例）的 binlog 進行解析，來查詢 GTID:這部分事務(wù)所生成的數(shù)據(jù)在新實例（通過備份恢復(fù)的實例）上是否存在?？梢园l(fā)現(xiàn) GTID:這部分事務(wù)的數(shù)據(jù)都存在于新實例上，也就是說數(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é)合備份時的 general log 可知，Xtrabackup 在執(zhí)行 ftwrl 并備份完所有非 InnoDB 表格的文件后通過 show master status 獲取了 binlog position 和 GTID 的信息，將其記錄到 xtrabackup_binlog_info 文件中。
那么 show master status 獲取的是哪些信息？
該命令提供本實例的 binlog 文件的狀態(tài)信息，顯示正在寫入的 binlog 文件，以及當(dāng)前的binlog position，并且 MySQL 5.7 在 MySQL 庫下引入了 gtid_executed 表，該表會記錄當(dāng)前執(zhí)行過的 GTID。
那么目前看來問題可能就出桐檔在 gtid_executed 表格碧輪稿上，通過測試和官方文檔提供的信息可知，該表格雖然是 InnoDB 表，但是其中的數(shù)據(jù)并非是實時更新的，且該表格記錄信息的方式存在以下兩個情況：1. 如果禁用了 log_bin，實例不會在該表格記錄任何信息；若從庫的 log_slave_updates 為 OFF，那么從庫會在應(yīng)用 relay-log 中的每個事務(wù)時執(zhí)行一次 insert mysql.gtid_executed 的操作。2. 如果啟用了 log_bin，則該表格記錄的是在 binlog 發(fā)生切換（rotate）的時候直到上一個 binlog 文件執(zhí)行過的全部 GTID，而此時 show master status 獲取的 Gtid 信息不再由 mysql.gtid_executed 表提供，而是由全局系統(tǒng)變量 gtid_exected 提供；如果服務(wù)器意外停止，則當(dāng)前 binlog 文件中的 Gtid 不會保存在 mysql.gtid_executed 表中，在實例恢復(fù)期間，這些 Gtid 從 binlog 文件中讀取并添加到表中。
小結(jié)
所以當(dāng)備份恢復(fù)時，實際 show master status 可能會出現(xiàn)以下情況：1. 當(dāng) log_bin 禁用或者 log_slave_updates 為 OFF 時，備份恢復(fù)后的實例 show master status 顯示為空。2. 當(dāng)開啟了 log_bin，但是該實例并未發(fā)生過 binlog 的切換時，備份恢復(fù)后的實例 show master status 顯示也為空。3. 當(dāng)開啟了 log_bin，其該實例的 binlog 發(fā)生過切換時，備份恢復(fù)后的實例 show master status 顯示的信息會比 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. 查看備份實例相對應(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 并不對應(yīng)。而 binlog.000033:1459 對應(yīng)的 GTID 是 70ec927f-4c6d-11ea-b88c-02023aba3fb1:提交后的下一個位置：
# 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ù)到一個新實例并啟動后，執(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 文件記錄的信息并不準確，而備份恢復(fù)后顯示的信息卻是準確的。
原因
首先我們來看一下 Xtrabackup 8.0 針對 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 對 MySQL 8.0 的備份與 Xtrabackup 2.4 略有不同，根據(jù) percona 官方文檔的信息，當(dāng) MySQL 8.0 中僅存在 InnoDB 引擎的表格時，不再執(zhí)行ftwrl（當(dāng)存在非 InnoDB 的表格或者使用 –slave-info 選項時會執(zhí)行），而是根據(jù)上述步驟的第 5 步，Xtrabackup 8.0 會通過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 表時，服務(wù)器將阻止日志的記錄和相關(guān)的更改來獲取足夠的時間以填充該表，然后釋放資源。Log_status 表通知在線備份工具應(yīng)記錄主庫的 binlog 的哪個位點和 gtid_executed 的值，還有每個復(fù)制通道的 relay log。它還為各個存儲引擎提供了相關(guān)信息，例如 InnoDB 存儲引擎使用的最后一個日志序列號（LSN）和最后一個檢查點的 LSN。2. 經(jīng)過測試發(fā)現(xiàn)，當(dāng)無數(shù)據(jù)寫入時， performance_schema.log_status 提供的 binlog position 與 GTID 是一致的，但是當(dāng)有大量數(shù)據(jù)持續(xù)寫入時，該表格提供的 binlog position 與 GTID 信息將不再一致，如下圖：
3. 既然 performance_schema.log_status 提供的信息不一致，那么為什么備份恢復(fù)后，GTID 沒有缺失？這是因為 Xtrabackup 8.0 在備份過程中多了兩步操作，F(xiàn)LUSH NO_WRITE_TO_BINLOG BINARY LOGS 和 copy binlog，Xtrabackup 8.0 在備份完非 InnoDB 表格的文件時會先切換 binlog，然后將切換后的 binlog 也進行備份，這樣使用該備份恢復(fù)的新實例在啟動后不僅會讀取 gtid_executed 表，也會讀取 binlog 文件來更新 GTID，就可以保持與備份時 xtrabackup_binlog_info 文件記錄的 binlog position 保持一致（需要注意的是 MySQL 8.0 的 gtid_executed 表格不再是當(dāng) binlog 切換時更新，而是會不斷的實時更新，但需要注意在有大量數(shù)據(jù)寫入時也不能做到和全局變量 gtid_exeuted 保持嚴格一致）。4. 當(dāng) MySQL 8.0 中存在非 InnoDB 的表格，比如 MyISAM 表時，Xtrabackup 8.0 會在執(zhí)行完 FLUSH NO_WRITE_TO_BINLOG BINARY LOGS 后執(zhí)行 ftwrl，此時查詢 performance_schema.log_status 得到的 binlog position 與 GTID 是一致的，且備份恢復(fù)后 show master status 顯示的信息也與 xtrabackup_binlog_info 文件記錄的信息一致。
總結(jié)1. Xtrabackup 2.4 備份后生成的 xtrabackup_binlog_info 文件記錄的 GTID 信息是準確的，但是備份恢復(fù)后 show master status 顯示的 GTID 是不準確的。2. Xtrabackup 8.0 在備份只有 InnoDB 表的實例時，xtrabackup_binlog_info 文件記錄的 GTID 信息不一定是準確的，但是備份恢復(fù)后 show master status 顯示的 GTID 是準確的。3. Xtrabackup 8.0 在備份有非 InnoDB 表格的實例時，xtrabackup_binlog_info 文件記錄的 GTID 信息是準確的，備份恢復(fù)后 show master status 顯示的 GTID 也是準確的。
注意：此處的“準確”主要指 xtrabackup_binlog_info 文件中記錄的 GTID 與備份中實際的 binlog position & 數(shù)據(jù)是否一致。
xtrabackup可以進行遠程備份，答液不過有些麻煩。
解析binlog 指定數(shù)據(jù)庫的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關(guān)于解析binlog 指定數(shù)據(jù)庫,深入剖析：如何指定數(shù)據(jù)庫解析binlog,跪求MySQL Binlog Digger(日志挖掘分析工具) V4.4 綠色版軟件百度云資源,XtraBackup 備份指定庫的信息別忘了在本站進行查找喔。
香港服務(wù)器選創(chuàng)新互聯(lián)，2H2G首月10元開通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）互聯(lián)網(wǎng)服務(wù)提供商,擁有超過10年的服務(wù)器租用、服務(wù)器托管、云服務(wù)器、虛擬主機、網(wǎng)站系統(tǒng)開發(fā)經(jīng)驗。專業(yè)提供云主機、虛擬主機、域名注冊、VPS主機、云服務(wù)器、香港云服務(wù)器、免備案服務(wù)器等。
分享名稱：深入剖析：如何指定數(shù)據(jù)庫解析binlog(解析binlog指定數(shù)據(jù)庫)
URL地址：http://www.5511xx.com/article/dpogsoo.html
