为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
TiDB cluster 版本：v5.4.1
TiDB DM cluster 版本：v5.4.0
【概述】 场景 + 问题概述
DM 同步資料到一半，突然發生錯誤，錯誤訊息如下
"RawCause": "Error 1105: message:\"raft entry is too large, region 187275, entry size 9202758\" raft_entry_too_large:\u003cregion_id:187275 entry_size:9202758 \u003e "
錯誤發生前，raftstore.raft-entry-max-size 這個參數沒有調整，使用預設8MB
【背景】 做过哪些操作
之後因為要讓DM的replication先通過，有將 raftstore.raft-entry-max-size 調整到16MB
【现象】 业务和数据库现象
發生錯誤當下去看前面的mysql正在做INSERT INTO ON DUPLICATE KEY UPDATE，大約62筆資料，後來看這62筆資料都是做UPDATE
【问题】 当前遇到的问题
DM的replication通過後，因為參考官方git的回覆說調整raftstore.raft-entry-max-size會造成效能問題(https://github.com/tikv/tikv/issues/3508)，所以有把此參數調整回8MB，結果調整回8MB以後又再次發生相同的問題，目前只好將參數調整到16MB
原本以為是INSERT ON DUPLICATE KEY UPDATE 62筆資料的時候導致raft-entry-max-size過大，但後來測試語法相同INSERT ON DUPLICATE KEY UPDATE 205筆資料的時候，raftstore.raft-entry-max-size: 8MB 卻可以成功寫入
當前遇到的問題：
- 不確定將raftstore.raft-entry-max-size調大( ex: 8MB → 16 MB)，後續會有什麼影響？嚴重程度如何？
(若我們的網路是10G以上，是否效能影響就會降低) - raftstore.raft-entry-max-size 是否跟mysql 每一包transaction大小有直接相關？
- raftstore.raft-entry-max-size 是否跟mysql 表結構的欄位形態有關係？(例如：longtext)
- 基於上述兩個問題，我們不太清楚該如何建議RD要如何調整，可以達到raftstore.raft-entry-max-size 不會超過8MB。
【业务影响】
會導致DM停止replication，造成資料落後
【TiDB 版本】
TiDB cluster 版本：v5.4.1
TiDB DM cluster 版本：v5.4.0
【附件】 相关日志及配置信息
附件附上當前我們tidb cluster 的 config
uat-tidb.cnf (5.6 KB)