mysql二進位制日誌格式介紹
Binary Logging Formats
Binary log有三種format：
--binlog-format=STATEMENT：基於statement，顧名思義，不管對資料庫有沒有影響資料的sql statement都會儲存在binary log裡面
--binlog-format=ROW：基於row，是對錶的行資料有影響的sql statement 儲存在binary log裡面
--binlog-format=MIXED：基於mixed，預設情況下使用statement-based logging，但是某些場合下logging mode會自動轉化為 row -based
1. 基於statement的binlog
每一條會修改資料的 SQL 都會記錄到 master 的 bin-log 中。slave 在複製的時候 SQL 程式會解析成和原來 master 端執行過的相同的 SQL 再次執行。
優點：在 statement 模式下，首先就是解決了 row 模式的缺點，不需要記錄每一行資料的變化，減少了 bin-log 日誌量，節省 I/O 以及儲存資源，提高效能。因為他只需要記錄在 master 上所執行的語句的細節，以及執行語句時候的上下文的資訊。
缺點：在 statement 模式下，由於他是記錄的執行語句，所以，為了讓這些語句在 slave 端也能正確執行，那麼他還必須記錄每條語句在執行的時候的一些相關資訊，也就是上下文資訊，以保證所有語句在 slave 端杯執行的時候能夠得到和在 master 端執行時候相同的結果。另外就是，由於 MySQL 現在發展比較快，很多的新功能不斷的加入，使 MySQL 的複製遇到了不小的挑戰，自然複製的時候涉及到越複雜的內容，bug 也就越容易出現。在 statement 中，目前已經發現的就有不少情況會造成 MySQL 的複製出現問題，主要是修改資料的時候使用了某些特定的函式或者功能的時候會出現，比如：sleep() 函式在有些版本中就不能被正確複製，在儲存過程中使用了 last_insert_id() 函式，可能會使 slave 和 master 上得到不一致的 id 等等。由於 row 是基於每一行來記錄的變化，所以不會出現類似的問題。
mysql> show variables like '%binlog%';
+-----------------------------------------+----------------------+
| Variable_name | Value |
+-----------------------------------------+----------------------+
| binlog_cache_size | 32768 |
| binlog_checksum | CRC32 |
| binlog_direct_non_transactional_updates | OFF |
| binlog_error_action | IGNORE_ERROR |
| binlog_format | STATEMENT |
| binlog_gtid_simple_recovery | OFF |
| binlog_max_flush_queue_time | 0 |
| binlog_order_commits | ON |
| binlog_row_image | FULL |
| binlog_rows_query_log_events | OFF |
| binlog_stmt_cache_size | 32768 |
| binlogging_impossible_mode | IGNORE_ERROR |
| innodb_api_enable_binlog | OFF |
| innodb_locks_unsafe_for_binlog | OFF |
| max_binlog_cache_size | 18446744073709547520 |
| max_binlog_size | 1073741824 |
| max_binlog_stmt_cache_size | 18446744073709547520 |
| simplified_binlog_gtid_recovery | OFF |
| sync_binlog | 0 |
+-----------------------------------------+----------------------+
19 rows in set (0.00 sec)
mysql> insert into emp select * from emp;
Query OK, 1048576 rows affected (35.34 sec)
Records: 1048576 Duplicates: 0 Warnings: 0
mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000003 | 167 |
| mysql-bin.000004 | 167 |
| mysql-bin.000005 | 337 |
+------------------+-----------+
3 rows in set (0.00 sec)
[root@mysqldb mysql]# mysqlbinlog mysql-bin.000005>mysql-bin.000005.txt
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#150817 5:46:35 server id 1 end_log_pos 120 CRC32 0x7dbdc343 Start: binlog v 4, server v 5.6.23-enterprise-commercial-advanced-log created 150817 5:46:35
BINLOG '
e63RVQ8BAAAAdAAAAHgAAAAAAAQANS42LjIzLWVudGVycHJpc2UtY29tbWVyY2lhbC1hZHZhbmNl
ZC1sb2cAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAAUPD
vX0=
'/*!*/;
# at 120
#150817 5:46:52 server id 1 end_log_pos 199 CRC32 0x264835a1 Query thread_id=5 exec_time=35 error_code=0
SET TIMESTAMP=1439804812/*!*/;
SET @@session.pseudo_thread_id=5/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1075838976/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 199
#150817 5:46:52 server id 1 end_log_pos 306 CRC32 0xd1e24c8f Query thread_id=5 exec_time=35 error_code=0
use `test`/*!*/;
SET TIMESTAMP=1439804812/*!*/;
insert into emp select * from emp
/*!*/;
# at 306
#150817 5:46:52 server id 1 end_log_pos 337 CRC32 0xb17220e6 Xid = 47
COMMIT/*!*/;
# at 337
#150817 5:47:55 server id 1 end_log_pos 384 CRC32 0x8ad6fdc8 Rotate to mysql-bin.000006 pos: 4
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
2. 基於row的binlog
日誌中會記錄成每一行資料被修改的形式，然後在 slave 端再對相同的資料進行修改。
優點：在 row 模式下，bin-log 中可以不記錄執行的 SQL 語句的上下文相關的資訊，僅僅只需要記錄那一條記錄被修改了，修改成什麼樣了。所以 row 的日誌內容會非常清楚的記錄下每一行資料修改的細節，非常容易理解。而且不會出現某些特定情況下的儲存過程或 function ，以及 trigger 的呼叫和觸發無法被正確複製的問題。
缺點：在 row 模式下，所有的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容
mysql> show variables like '%binlog%';
+-----------------------------------------+----------------------+
| Variable_name | Value |
+-----------------------------------------+----------------------+
| binlog_cache_size | 32768 |
| binlog_checksum | CRC32 |
| binlog_direct_non_transactional_updates | OFF |
| binlog_error_action | IGNORE_ERROR |
| binlog_format | ROW |
| binlog_gtid_simple_recovery | OFF |
| binlog_max_flush_queue_time | 0 |
| binlog_order_commits | ON |
| binlog_row_image | FULL |
| binlog_rows_query_log_events | OFF |
| binlog_stmt_cache_size | 32768 |
| binlogging_impossible_mode | IGNORE_ERROR |
| innodb_api_enable_binlog | OFF |
| innodb_locks_unsafe_for_binlog | OFF |
| max_binlog_cache_size | 18446744073709547520 |
| max_binlog_size | 1073741824 |
| max_binlog_stmt_cache_size | 18446744073709547520 |
| simplified_binlog_gtid_recovery | OFF |
| sync_binlog | 0 |
+-----------------------------------------+----------------------+
19 rows in set (0.01 sec)
mysql> flush logs;
Query OK, 0 rows affected (0.08 sec)
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000008 | 120 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
mysql> insert into emp values(100,'aaa');
Query OK, 1 row affected (0.06 sec)
[root@mysqldb mysql]# mysqlbinlog mysql-bin.000008
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#150817 6:16:37 server id 1 end_log_pos 120 CRC32 0x0b48cd47 Start: binlog v 4, server v 5.6.23-enterprise-commercial-advanced-log created 150817 6:16:37
# Warning: this binlog is either in use or was not closed properly.
BINLOG '
hbTRVQ8BAAAAdAAAAHgAAAABAAQANS42LjIzLWVudGVycHJpc2UtY29tbWVyY2lhbC1hZHZhbmNl
ZC1sb2cAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAAUfN
SAs=
'/*!*/;
# at 120
#150817 6:16:58 server id 1 end_log_pos 192 CRC32 0x905d8c11 Query thread_id=7 exec_time=0 error_code=0
SET TIMESTAMP=1439806618/*!*/;
SET @@session.pseudo_thread_id=7/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1075838976/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 192
#150817 6:16:58 server id 1 end_log_pos 241 CRC32 0xc70e6a66 Table_map: `test`.`emp` mapped to number 70
# at 241
#150817 6:16:58 server id 1 end_log_pos 285 CRC32 0xd9fea6a2 Write_rows: table id 70 flags: STMT_END_F
BINLOG '
mrTRVRMBAAAAMQAAAPEAAAAAAEYAAAAAAAEABHRlc3QAA2VtcAACAw8CFAADZmoOxw==
mrTRVR4BAAAALAAAAB0BAAAAAEYAAAAAAAEAAgAC//xkAAAAA2FhYaKm/tk=
'/*!*/;
# at 285
#150817 6:16:58 server id 1 end_log_pos 316 CRC32 0x1a216142 Xid = 89
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
Binary log有三種format：
--binlog-format=STATEMENT：基於statement，顧名思義，不管對資料庫有沒有影響資料的sql statement都會儲存在binary log裡面
--binlog-format=ROW：基於row，是對錶的行資料有影響的sql statement 儲存在binary log裡面
--binlog-format=MIXED：基於mixed，預設情況下使用statement-based logging，但是某些場合下logging mode會自動轉化為 row -based
1. 基於statement的binlog
每一條會修改資料的 SQL 都會記錄到 master 的 bin-log 中。slave 在複製的時候 SQL 程式會解析成和原來 master 端執行過的相同的 SQL 再次執行。
優點：在 statement 模式下，首先就是解決了 row 模式的缺點，不需要記錄每一行資料的變化，減少了 bin-log 日誌量，節省 I/O 以及儲存資源，提高效能。因為他只需要記錄在 master 上所執行的語句的細節，以及執行語句時候的上下文的資訊。
缺點：在 statement 模式下，由於他是記錄的執行語句，所以，為了讓這些語句在 slave 端也能正確執行，那麼他還必須記錄每條語句在執行的時候的一些相關資訊，也就是上下文資訊，以保證所有語句在 slave 端杯執行的時候能夠得到和在 master 端執行時候相同的結果。另外就是，由於 MySQL 現在發展比較快，很多的新功能不斷的加入，使 MySQL 的複製遇到了不小的挑戰，自然複製的時候涉及到越複雜的內容，bug 也就越容易出現。在 statement 中，目前已經發現的就有不少情況會造成 MySQL 的複製出現問題，主要是修改資料的時候使用了某些特定的函式或者功能的時候會出現，比如：sleep() 函式在有些版本中就不能被正確複製，在儲存過程中使用了 last_insert_id() 函式，可能會使 slave 和 master 上得到不一致的 id 等等。由於 row 是基於每一行來記錄的變化，所以不會出現類似的問題。
mysql> show variables like '%binlog%';
+-----------------------------------------+----------------------+
| Variable_name | Value |
+-----------------------------------------+----------------------+
| binlog_cache_size | 32768 |
| binlog_checksum | CRC32 |
| binlog_direct_non_transactional_updates | OFF |
| binlog_error_action | IGNORE_ERROR |
| binlog_format | STATEMENT |
| binlog_gtid_simple_recovery | OFF |
| binlog_max_flush_queue_time | 0 |
| binlog_order_commits | ON |
| binlog_row_image | FULL |
| binlog_rows_query_log_events | OFF |
| binlog_stmt_cache_size | 32768 |
| binlogging_impossible_mode | IGNORE_ERROR |
| innodb_api_enable_binlog | OFF |
| innodb_locks_unsafe_for_binlog | OFF |
| max_binlog_cache_size | 18446744073709547520 |
| max_binlog_size | 1073741824 |
| max_binlog_stmt_cache_size | 18446744073709547520 |
| simplified_binlog_gtid_recovery | OFF |
| sync_binlog | 0 |
+-----------------------------------------+----------------------+
19 rows in set (0.00 sec)
mysql> insert into emp select * from emp;
Query OK, 1048576 rows affected (35.34 sec)
Records: 1048576 Duplicates: 0 Warnings: 0
mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000003 | 167 |
| mysql-bin.000004 | 167 |
| mysql-bin.000005 | 337 |
+------------------+-----------+
3 rows in set (0.00 sec)
[root@mysqldb mysql]# mysqlbinlog mysql-bin.000005>mysql-bin.000005.txt
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#150817 5:46:35 server id 1 end_log_pos 120 CRC32 0x7dbdc343 Start: binlog v 4, server v 5.6.23-enterprise-commercial-advanced-log created 150817 5:46:35
BINLOG '
e63RVQ8BAAAAdAAAAHgAAAAAAAQANS42LjIzLWVudGVycHJpc2UtY29tbWVyY2lhbC1hZHZhbmNl
ZC1sb2cAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAAUPD
vX0=
'/*!*/;
# at 120
#150817 5:46:52 server id 1 end_log_pos 199 CRC32 0x264835a1 Query thread_id=5 exec_time=35 error_code=0
SET TIMESTAMP=1439804812/*!*/;
SET @@session.pseudo_thread_id=5/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1075838976/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 199
#150817 5:46:52 server id 1 end_log_pos 306 CRC32 0xd1e24c8f Query thread_id=5 exec_time=35 error_code=0
use `test`/*!*/;
SET TIMESTAMP=1439804812/*!*/;
insert into emp select * from emp
/*!*/;
# at 306
#150817 5:46:52 server id 1 end_log_pos 337 CRC32 0xb17220e6 Xid = 47
COMMIT/*!*/;
# at 337
#150817 5:47:55 server id 1 end_log_pos 384 CRC32 0x8ad6fdc8 Rotate to mysql-bin.000006 pos: 4
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
2. 基於row的binlog
日誌中會記錄成每一行資料被修改的形式，然後在 slave 端再對相同的資料進行修改。
優點：在 row 模式下，bin-log 中可以不記錄執行的 SQL 語句的上下文相關的資訊，僅僅只需要記錄那一條記錄被修改了，修改成什麼樣了。所以 row 的日誌內容會非常清楚的記錄下每一行資料修改的細節，非常容易理解。而且不會出現某些特定情況下的儲存過程或 function ，以及 trigger 的呼叫和觸發無法被正確複製的問題。
缺點：在 row 模式下，所有的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容
mysql> show variables like '%binlog%';
+-----------------------------------------+----------------------+
| Variable_name | Value |
+-----------------------------------------+----------------------+
| binlog_cache_size | 32768 |
| binlog_checksum | CRC32 |
| binlog_direct_non_transactional_updates | OFF |
| binlog_error_action | IGNORE_ERROR |
| binlog_format | ROW |
| binlog_gtid_simple_recovery | OFF |
| binlog_max_flush_queue_time | 0 |
| binlog_order_commits | ON |
| binlog_row_image | FULL |
| binlog_rows_query_log_events | OFF |
| binlog_stmt_cache_size | 32768 |
| binlogging_impossible_mode | IGNORE_ERROR |
| innodb_api_enable_binlog | OFF |
| innodb_locks_unsafe_for_binlog | OFF |
| max_binlog_cache_size | 18446744073709547520 |
| max_binlog_size | 1073741824 |
| max_binlog_stmt_cache_size | 18446744073709547520 |
| simplified_binlog_gtid_recovery | OFF |
| sync_binlog | 0 |
+-----------------------------------------+----------------------+
19 rows in set (0.01 sec)
mysql> flush logs;
Query OK, 0 rows affected (0.08 sec)
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000008 | 120 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
mysql> insert into emp values(100,'aaa');
Query OK, 1 row affected (0.06 sec)
[root@mysqldb mysql]# mysqlbinlog mysql-bin.000008
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#150817 6:16:37 server id 1 end_log_pos 120 CRC32 0x0b48cd47 Start: binlog v 4, server v 5.6.23-enterprise-commercial-advanced-log created 150817 6:16:37
# Warning: this binlog is either in use or was not closed properly.
BINLOG '
hbTRVQ8BAAAAdAAAAHgAAAABAAQANS42LjIzLWVudGVycHJpc2UtY29tbWVyY2lhbC1hZHZhbmNl
ZC1sb2cAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAAUfN
SAs=
'/*!*/;
# at 120
#150817 6:16:58 server id 1 end_log_pos 192 CRC32 0x905d8c11 Query thread_id=7 exec_time=0 error_code=0
SET TIMESTAMP=1439806618/*!*/;
SET @@session.pseudo_thread_id=7/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1075838976/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 192
#150817 6:16:58 server id 1 end_log_pos 241 CRC32 0xc70e6a66 Table_map: `test`.`emp` mapped to number 70
# at 241
#150817 6:16:58 server id 1 end_log_pos 285 CRC32 0xd9fea6a2 Write_rows: table id 70 flags: STMT_END_F
BINLOG '
mrTRVRMBAAAAMQAAAPEAAAAAAEYAAAAAAAEABHRlc3QAA2VtcAACAw8CFAADZmoOxw==
mrTRVR4BAAAALAAAAB0BAAAAAEYAAAAAAAEAAgAC//xkAAAAA2FhYaKm/tk=
'/*!*/;
# at 285
#150817 6:16:58 server id 1 end_log_pos 316 CRC32 0x1a216142 Xid = 89
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/10972173/viewspace-1774808/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- mysql二進位制日誌的引數介紹MySql
- MySQL二進位制日誌MySql
- mysql 二進位制日誌MySql
- mysql 日誌之二進位制日誌MySql
- 管理mysql二進位制日誌MySql
- mysql的二進位制日誌MySql
- MySQL 壓縮二進位制日誌MySql
- mysql二進位制日誌詳解MySql
- mysql二進位制日誌是什麼MySql
- MySQL如何傳輸二進位制日誌MySql
- MySQL二進位制日誌的三種格式優缺點比較MySql
- 使用canal偷取MySQL的二進位制日誌MySql
- mysql二進位制日誌相關引數MySql
- Mysql資料庫二進位制日誌的管理MySql資料庫
- MySQL二進位制日誌刪除與恢復MySql
- MySQL二進位制日誌Mixed格式轉化為row格式的六種情況總結MySql
- 如何在MySQL中檢視binlog二進位制日誌？MySql
- MySQL什麼時候輪換二進位制日誌MySql
- mysql之 日誌體系（錯誤日誌、查詢日誌、二進位制日誌、事務日誌、中繼日誌）MySql中繼
- mysql關於二進位制日誌binary log的總結MySql
- mysql5.7無法開啟二進位制日誌問題MySql
- mysqlbinlog二進位制日誌檢視工具MySql
- 03二進位制包安裝與介紹
- 【MySQL解惑筆記】Mysql5.7.x無法開啟二進位制日誌MySql筆記
- Web 前端開發日誌（二）：JavaScript 的二進位制操作Web前端JavaScript
- 重新整理 mysql 基礎篇————— 介紹mysql日誌[二]MySql
- 遠端備份MySQL二進位制日誌--read-from-remote-serverMySqlREMServer
- 解析MYSQL BINLOG二進位制格式(10)--問題解答MySql
- 解析MYSQL BINLOG 二進位制格式(1)--準備工作MySql
- 解析MYSQL BINLOG 二進位制格式(3)--QUERY_EVENTMySql
- mysql關於ib_logfile事務日誌和binary log二進位制日誌的區別MySql
- mysqlbinlog 處理二進位制日誌檔案的工具MySql
- 解析MYSQL BINLOG 二進位制格式(4)--TABLE_MAP_EVENTMySql
- 解析MYSQL BINLOG 二進位制格式(5)--WRITE_ROW_EVENTMySql
- 解析MYSQL BINLOG 二進位制格式(2)--FORMAT_DESCRIPTION_EVENTMySqlORM
- MySQL建立二進位制日誌產生1067錯誤的解決方案MySql
- 二進位制求5個1的格式。。。。
- Java二進位制Class檔案格式解析Java