doris版本1.1.1 内存持续增长，版本升级到1.1.5稳定版本的记录

2022年12月下载了doris1.1.1之后出现了各种问题，其中最重大的是内存持续缓慢增长，直至超过最大mem_limit限制后仍旧增长
更改前：

期间为了解决这个问题更改了：

------------------主要调控内存现象
trash_file_expire_time_sec=86400   		#清理文件的时间间隔(秒)
total_permits_for_compaction_score=1000 #合并文件的同时进行数  默认10000   是消耗内存的大客户  
max_segment_num_per_rowset=200			#用于限制导入 新产生的 rowset中的segment数量
描述: 用于限制导入时，新产生的rowset中的segment数量。如果超过阈值，导入会失败并报错 -238。
过多的 segment 会导致compaction占用大量内存引发 OOM 错误。
segment_cache_capacity=100000			#Segment Cache 缓存的 Segment 最大数量
默认值目前只是一个经验值，可能需要根据实际场景修改。
增大该值可以缓存更多的segment从而避免一些IO。减少该值则会降低内存使用。
write_buffer_size=104857600				#默认值：104857600
刷写前缓冲区的大小
导入数据在 BE 上会先写入到一个内存块，当这个内存块达到阈值后才会写回磁盘。
默认大小是 100MB。过小的阈值可能导致 BE 上存在大量的小文件。
可以适当提高这个阈值减少文件数量。但过大的阈值可能导致 RPC 超时。
load_process_max_memory_limit_percent=48318382080 #最大写入单节点上所有的导入线程占据的内存上限
将这些默认值设置得很大，因为我们不想在用户升级 Doris 时影响负载性能。 如有必要，用户应正确设置这些配置。
mem_limit=30%

只是减缓了内存的增长速度并没有解决内存缓慢增长的问题，官网浏览版本更新介绍在1.1.3版本中有介绍说1.1.0-1.1.2版本都是没有解决内存缓慢增长的问题，只能检索版本查看稳定版，最新的1.2.X性能强大，但是刚出现并不能确定版本是否稳定，能确定较稳定的版本只有0.15和1.1.5,但是0.15 相对性能较差，因而选定了1.1.5。
下面来说更新版本的操作：
sql 执行

admin set frontend config("disable_balance" = "true");
admin set frontend config("disable_colocate_balance" = "true");
admin set frontend config("disable_tablet_scheduler" = "true");

停止文件的交换和写入。
下载apache-doris-fe-1.1.5-bin.tar.gz 和 apache-doris-be-1.1.5-bin-x86_64.tar.gz分发到对应的fe、be节点,解压。
1、停止FE，重命名fe数据存储目录为fe-two,作为备份
在fe的fe.conf中有：
meta_dir=/datassd03/doris/doris-meta

sh stop_fe.sh
cp -r /datassd03/doris/doris-meta /datassd03/doris/doris-meta_two

2、停止BE，重命名be数据存储目录be为be-two,作为备份
在be的be.conf中有：
storage_root_path = /datassd03/doris/disk1/data

sh stop_be.sh
cp -r /datassd03/doris/disk1/data /datassd03/doris/disk1/data_two

3、fe 主节点fe.conf 添加 metadata_failure_recovery=true 多个fe节点先只启动一个作为master节点。

sh  start_fe.sh --daemon

4、启动BE

sh start_be.sh --daemon

5、查看log日志检测是否成功
6、成功后，可选择删除two后缀文件夹
7、其他fe节点 ，删除本地的存储文件，删除后重新添加
删除除了已经启动的master节点外的所有fe节点
要注意的是先前保存的fe.conf中meta_dir对应的目录要删掉后重新创建新的，用来加载元数据。

ALTER SYSTEM drop FOLLOWER "follower_host:edit_log_port";

启动：

./bin/start_fe.sh --helper master_fe_host:edit_log_port --daemon

添加

ALTER SYSTEM add FOLLOWER "follower_host:edit_log_port";

一天后运行所有已有程序内存展现：

成功解决。
题外话：
源数据同步理论上是没啥问题了，但是我这里查询一些表报编号-230错误，最后sql尝试删除后从回收站恢复：

drop table database_name.table_name;
RECOVER TABLE database_name.table_name;

并且设置了参数：
ignore_rowset_stale_unconsistent_delete=true

–文件修复 报错 detailMessage = Failed to get scan range, no queryable replica found in tablet: 9719453
show tablet 9719453;
----将字段DetailCmd 值粘出执行
SHOW PROC ‘/dbs/10018/7901884/partitions/7901883/7901885/7901898’;
----可以查到backend_id 给文件的状态付给bad值 ，有副本的话 会自动恢复副本文件
ADMIN SET REPLICA STATUS PROPERTIES(“tablet_id” = “7901898”, “backend_id” = “10110”, “status” = “bad”);

如果没有副本，

当确认数据已经无法恢复后，可以通过执行以下命令，生成空白副本
ADMIN SET FRONTEND CONFIG (“recover_with_empty_tablet” = “true”);
五分钟后执行
查询 报错的表，正常展示
ADMIN SET FRONTEND CONFIG (“recover_with_empty_tablet” = “false”);

以上如果无法解决就得清空表重新运行

SHOW PROC ‘/cluster_health/tablet_health’; —查看整个文件系统的健康状态 会显示各种文件状态