diff --git a/0f6c98a943e746bfa8191c08574d4a6b.jpg b/0f6c98a943e746bfa8191c08574d4a6b.jpg
new file mode 100644
index 0000000..2a2e173
Binary files /dev/null and b/0f6c98a943e746bfa8191c08574d4a6b.jpg differ
diff --git a/ba70219da48fd40a78729c0caa74752e.jpg b/ba70219da48fd40a78729c0caa74752e.jpg
new file mode 100644
index 0000000..4d8ea48
Binary files /dev/null and b/ba70219da48fd40a78729c0caa74752e.jpg differ
diff --git a/bb013685c11c79aafd42182d71941204.jpg b/bb013685c11c79aafd42182d71941204.jpg
new file mode 100644
index 0000000..5fbdab5
Binary files /dev/null and b/bb013685c11c79aafd42182d71941204.jpg differ
diff --git a/fdc681c6a4a31bdd046a2479b385b7ec.jpg b/fdc681c6a4a31bdd046a2479b385b7ec.jpg
new file mode 100644
index 0000000..0d84c8a
Binary files /dev/null and b/fdc681c6a4a31bdd046a2479b385b7ec.jpg differ
diff --git a/问题排查/doris/StreamLoad 超时.md b/问题排查/doris/StreamLoad 超时.md
index 98444e4..0ee1d7b 100644
--- a/问题排查/doris/StreamLoad 超时.md	
+++ b/问题排查/doris/StreamLoad 超时.md	
@@ -27,3 +27,48 @@
 
 **结论：主键模型对数据倾斜和高频更新场景极其敏感**
 
+## 解决办法
+
+在无法优化导入的前提下：
+1. streamload 发起端增加 group_commit 参数
+```
+# 导入时在 header 中增加"group_commit:async_mode"配置  
+  
+curl --location-trusted -u {user}:{passwd} -T data.csv -H "group_commit:async_mode" -H "column_separator:," http://{fe_host}:{http_port}/api/db/dt/_stream_load  
+{  
+"TxnId": 7009,  
+"Label": "group_commit_c84d2099208436ab_96e33fda01eddba8",  
+"Comment": "",  
+"GroupCommit": true,  
+"Status": "Success",  
+"Message": "OK",  
+"NumberTotalRows": 2,  
+"NumberLoadedRows": 2,  
+"NumberFilteredRows": 0,  
+"NumberUnselectedRows": 0,  
+"LoadBytes": 19,  
+"LoadTimeMs": 35,  
+"StreamLoadPutTimeMs": 5,  
+"ReadDataTimeMs": 0,  
+"WriteDataTimeMs": 26  
+}  
+  
+# 返回的 GroupCommit 为 true，说明进入了 group commit 的流程  
+# 返回的 Label 是 group_commit 开头的，是真正消费数据的导入关联的 label
+```
+
+group_commit 可以实现在服务端赞批的功能，当size达到表设置的 group_commit_data_bytes 大小时，提交一次，可以节省事务和compaction开销
+
+Group Commit 的默认提交数据量为 64 MB，用户可以通过修改表的配置调整：
+```text
+# 修改提交数据量为 128MB  
+ALTER TABLE dt SET ("group_commit_data_bytes" = "134217728");
+```
+
+ *如果设置太大，数据会缓存到内存中，导致内存占用率高，这里需要注意*
+
+如果设置了group_commit还是出现磁盘占用高的问题，可以尝试临时关闭表压缩功能
+```text
+ALTER TABLE dt SET ("disable_auto_compaction" = "true");
+```
+设置完成后，这张表的tablet不会压缩，但是会占用大量磁盘空间，非紧急情况不要使用。
\ No newline at end of file
diff --git a/问题排查/doris/修复tablet 版本不一致问题.md b/问题排查/doris/修复tablet 版本不一致问题.md
new file mode 100644
index 0000000..ad3a28c
--- /dev/null
+++ b/问题排查/doris/修复tablet 版本不一致问题.md	
@@ -0,0 +1,29 @@
+问题如图所示，显示版本号不一致
+![[fdc681c6a4a31bdd046a2479b385b7ec.jpg]]
+
+修复过程如下：
+### 1.查询副本明细
+```sql
+-- 13403365 是日志中显示的tablet_id
+show tablet 13403365
+```
+
+执行SQL后，查看DetailCmd 字段
+![[0f6c98a943e746bfa8191c08574d4a6b.jpg]]
+在执行其中的语句
+```sql
+show proc '/dbs/116719/13403319/partitions/13403318/13403320/13403365'
+```
+
+查看LstFailedVersion 字段，如果全是 -1 表示副本状态正常
+查看LstSuccessVersion 字段，如果一致，表示副本状态正常
+
+如图所示，第一行就是坏副本
+![[bb013685c11c79aafd42182d71941204.jpg]]
+### 2.手动修复副本
+
+doris 可以将某个坏副本状态设置成bad,之后doris会自动将正常副本的数据同步一份到坏副本
+
+```sql
+admin set replica status properties ("tablet_id"="13403365","backend_id"="116686","status"="bad")
+```