有時候，一些數據的錄入可能需要使用表格直接錄入會顯得更加方便快捷，這種情況有時候也是由於客戶使用習慣而提出，本篇隨筆介紹在WPF應用端上使用DataGrid來直接新增、編輯、保存數據的處理。 錄入數據的時候，我們都採用在一個窗體界面中，根據不同內容進行錄入，但是有時候涉及主從表的數據錄入，從表的數據... ...
1.什麼是binlog？
2.binlog可以用來乾什麼？
3.怎麼樣使用binlog?
binlog是記錄所有資料庫表結構變更（例如CREATE、ALTER TABLE…）以及表數據修改（INSERT、
UPDATE、DELETE…）的二進位日誌。實際落庫產生的日誌（事務提交後）。
我們先看一下Mysql數據更新的流程：
binlog可以乾什麼？
• 通過如上所述，我們知道binlog是mysql的已提交日誌，是實際落庫的，那麼如果可以監聽到binlog那麼我們可以用來處理DB主從同步，跨庫同步，數據備份，同步ES，緩存刷新等等
怎麼樣使用binlog？
準備工作
1.檢查binlog是否開啟
SHOW GLOBAL VARIABLES LIKE ‘log_bin%’; 結果返回不等於ON時代表關閉
可以通過my.ini配置文件(linux中為my.cnf) log-bin=mysql-bin //指定binlog日誌文件的名稱，可以根據實際需求進行命名。 binlog-format=ROW //設置binlog的格式，下麵會解釋這三種格式。
2.檢查binlog格式
SHOW GLOBAL VARIABLES like ' binlog_format%’;
mysql binlog 分為三種模式（STATEMENT，ROW，MIXED）
- Statement（Statement-Based Replication,SBR）：每一條會修改數據的 SQL 都會記錄在 binlog 中
- Row（Row-Based Replication,RBR）：不記錄 SQL 語句上下文信息，僅保存哪條記錄被修改
- Mixed（Mixed-Based Replication,MBR）：Statement 和 Row 的混合體
這裡我們設置Row即可
SET GLOBAL binlog_format = 'ROW’;
SET GLOBAL binlog_row_metadata = ‘FULL’;//8.0版本以下不需要設置
現在準備工作完成，可以開始寫代碼訂閱master節點去獲取binlog信息了，再次之前我們先瞭解下 binlog的存儲原理
3.多文件存儲
mysql 將資料庫更新操作對應的event記錄到本地的binlog文件中，顯然在一個文件中記錄所有的 event是不可能的，過大的文件會給我們的運維帶來麻煩，如刪除一個大文件，在I/O調度方面會給我們帶來不可忽視的資源開銷。
因此，目前基本上所有支持本地文件存儲的組件，如MQ、Mysql等，都會控制一個文件的大小。在數據量較多的情況下，就分配到多個文件進行存儲。
在mysql中可以通過
show binlog events;
得到binlog的log_name（文件名）和大小以及pos（偏移量位置）
這兩個會在後面發送dump到master節點去訂閱的時候用到，代表從binlog的哪處位置開始訂閱，master 就會在EventStream中發送此文件節點之後的所有資料庫變更信息
4.Binlog管理事件
所謂binlog管理事件，官方稱之為binlog managent events，你可以認為是一些在任何模式下都有可能會出現的事件，不管你的配置binlog_format是Row、Statement還是Mixed。
每個binlog文件總是以Format Description Event作為開始，以Rotate Event結束作為結束。如果你使用的是很古老的Mysql版本中，開始事件也有可能是START EVENT V3，而結束事件是Stop Event。在開始和結束之間，穿插著其他各種事件。
在Event_Type列中，我們看到了三個事件類型：
- Format_desc：也就是我們所說的Format Description Event，是binlog文件的第一個事件。在Info列，我們可以看到，其標明瞭Mysql Server的版本是8.0，Binlog版本是4。
- Previous_gtids：該事件完整名稱為，PREVIOUS_GTIDS_LOG_EVENT。熟悉Mysql 基於GTID複製的
同學應該知道，這是表示之前的binlog文件中，已經執行過的GTID。需要我們開啟GTID選項，這個事件才會有值，在後文中，將會詳細的進行介紹。
- Rotate：Rotate Event是每個binlog文件的結束事件。在Info列中，我們看到了其指定了下一個 binlog文件的名稱是mysql-bin.000004。
5.開始發送一個dump到master節點
serverId代表此slave節點的id（不要跟master節點重覆），訂閱binlog需要模擬一個slave（從節點）去向master節點發送dump，後續就會接收的訂閱返回的事件流信息 filename和position前面提到過的文件名和偏移量
發送成功後就會接收到master節點返回的event信息
每個binlog事件都以一個事件頭（event header）開始，然後是一個binlog事件類型特定的數據部分，稱為事件體（event body）。
事件體的具體結構與事件類型相關，以QUERY_EVENT類型為例，存儲格式如下：
常見的事件類型有：
- FORMAT_DESCRIPTION_EVENT：該部分位於整個文件的頭部，每個binlog文件都必定會有唯一一個該event
- PREVIOUS_GTIDS_EVENT：包含在每個binlog的開頭，用於描述所有以前binlog所包含的全部*GTID*的一個集合(包括已經刪除的binlog)
- GTID_EVENT/ANONYMOUS_GTID_EVENT：每一個Query事務前都會有這樣的一個GTID_EVENT，如果未開啟則是ANONYMOUS_GTID_EVENT。
事務開始時，執行的BEGIN操作；ROW格式中的DDL操作等
- TABLE_MAP_EVENT：每個DML事務之前，都會有一個TABLE_MAP_EVENT，記錄操作對應的表的信息。
- WRITE_ROW_EVENT：插入操作。
- DELETE_ROW_EVENT：刪除操作。
- UPDATE_ROW_EVENT：更新操作。記載的是一條記錄的完整的變化情況，即從前量變為後量的過程 • XID_EVENT：主要是事務提交的時候回在最後生成一個xid號，有這個便代表事務已經成功提交了
- ROTATE_EVENT：Binlog結束時的事件，與一樣僅有一個
具體的源碼可以通過以下鏈接去下載：
https://github.com/kogel-net/Kogel.Subscribe
尾言
這個輪子是在前兩年時候寫的，那時候想利用mysql的cdc解決緩存刷新的問題，但是找了一圈發現只有 java開源的輪子例如canal，flinkcdc等，c#社區好像並無此類似輪子就想寫一個，完善下c#/.net社區，希望以後.net發展能夠越來越好吧。
