存算分离集群 对象存储数据无法删除

💬 StarRocks 用户问答 日常运维
#1

为了更快的定位您的问题，请提供以下信息，谢谢
【详述】问题详细描述
对象存储（COS）的数据无法删除的问题，删除表的分区，SR能够逻辑删除，但是对象存储的数据文件一直在，可以排除是保留机制的问题，是国庆节前删除的
经过排查发现是SR调用这个接口语法的问题，starrocks存算分离集群，使用COS作为对象存储 底层删除是调用这个接口 DELETE Multiple Objects ，
SR发出的删除请求是，在这种情况下COS会返回200，但是没有删除，因为根据key找不到文件
POST https://COSID.cos.ap-guangzhou.myqcloud.com/starrocks?delete
请求体

<Delete xmlns=""http://s3.amazonaws.com/doc/2006-03-01/"">
    <Object>
        <Key>shared/0f2e43f6-d928-4841-9f9a-69720d985cc0/db13007/13122/13124/data/0000000000000006_ab37348b-c7d4-403d-b101-7ff65f95f273.dat</Key>
    </Object>
    <Quiet>true</Quiet>
</Delete>

按照腾讯云文档 https://cloud.tencent.com/document/product/436/8289 的说明
正确的应该是
POST https://COSID.cos.ap-guangzhou.myqcloud.com/?delete
请求体

<Delete xmlns=""http://s3.amazonaws.com/doc/2006-03-01/"">
    <Object>
        <Key>starrocks/shared/0f2e43f6-d928-4841-9f9a-69720d985cc0/db13007/13122/13124/data/0000000000000006_ab37348b-c7d4-403d-b101-7ff65f95f273.dat</Key>
    </Object>
    <Quiet>true</Quiet>
</Delete>

starrocks作为存储桶根目录，不应该在url中出现，应该在请求体中完整的显示要删除文件的key；
【背景】做过哪些操作？
【业务影响】对象存储数据无法删除,存储量只增不减
【是否存算分离】是
【StarRocks版本】例如：3.3.17
【集群规模】例如：5fe（3 follower+2observer）+4cn
【机器信息】CPU虚拟核/内存/网卡，例如：48C/64G/万兆
【联系方式】联系方式，社区群28-无痕
【附件】

#2

应该是一直把提供的endpoint当作path style的endpoint使用, 所以会在URL上拼上一个bucket name. 你用的sr版本是哪个版本?

#3

image
image2002×322 66.3 KB

应该是COS这种URL的拼接方式是非aws标准的, 正常是<bucketname>.<serviceName>.<region>.<domain>

COS弄出了个<bucketName>-appid这种不兼容的方式, 会导致域名检查拼接有问题.

#4

是3.3.17版本

#5

目前还有这个 Key必须是完整的路径,这样COS才能成功删除。

能够成功删除的
<Key>starrocks/shared/0f2e43f6-d928-4841-9f9a-69720d985cc0/db13007/13122/13124/data/0000000000000006_ab37348b-c7d4-403d-b101-7ff65f95f273.dat</Key>

而 shared/… 开头的，会找不到文件，无法删除，但是也会返回200的响应

不能成功删除的
<Key>shared/0f2e43f6-d928-4841-9f9a-69720d985cc0/db13007/13122/13124/data/0000000000000006_ab37348b-c7d4-403d-b101-7ff65f95f273.dat</Key>
#6

因为域名不规范, 整个bucket当作path style处理了. 所以路径里都带上了starrocks/前缀. delete时, 带上的starrocks是bucket的意思, 但这个endpoint是virtual host style, 所以是个错误的API请求, 被拦截了.

#7

你这种情况, SR里的bucketName应该直接配置成<bucketName>-appid, 这样就能匹配上, 正常工作了.

可以重新创建一个storage volume, 用<bucketName>-appid 做为bucketName, 把原先库表里的数据导入到用这个storage volume创建的新的库表, 然后原先的数据全部手动清理掉.

京ICP备2022026421号-1