二、案例分享二
2.1 問題描述
主庫執行insert select 批量寫入操作，主從複制通過row模式下轉換為批量的insert大事務操作，導緻隻讀執行個體CPU資源以及延遲上漲
16:55～17:07
2.2 處理流程
1、接收到隻讀執行個體備庫延遲告警後，我們觀察到隻讀執行個體的CPU資源有有明顯上漲，同時資料庫有大量資料寫入操作
2、延遲期間，隻讀執行個體的tps的趨勢是先下降後上漲，binlog日志量達到12.54G，可以推斷出主執行個體傳輸過來的批量的寫入操作是同一事務中，再加上隻讀執行個體配置相對于主執行個體較低，是以導緻這麼大的延遲
2、檢視主從延遲期間主執行個體的情況，可以看到主執行個體确實執行了大量的資料寫入操作，以及主執行個體審計日志中，我們找到了批量寫入操作
3、隻讀執行個體延遲趨勢17:05後，隻讀執行個體tps上漲，同時同步延遲開始下降
4、延遲流程描述
- 16:43 主執行個體執行insert select批量寫入操作，主庫執行完畢後，binlog以row的模式将所有的insert操作放在一個事務中傳輸到隻讀執行個體
- 16:55 隻讀執行個體開始應用該大事務中的insert操作，tps跌落，資料庫緩存寫/日志寫上漲
- 17:05 大事務應用完畢，開始同步延遲期間的binlog操作，正常業務下多個小事務操作，tps上漲明顯，延遲開始回落
- 10:07 主從追平延遲期間的binlog，主從延遲恢複為0