OB S3备份问题咨询
【测试环境】
【 OB 】
【 4.3.0】
【问题描述】
背景：在4.3.0新版本中希望将日志归档到厂内的存储(s3协议)，在测试的时候遇到如下报错:
命令为(去掉了一些敏感信息)：
ALTER SYSTEM SET LOG_ARCHIVE_DEST='LOCATION=s3://xxx/obbackup/archive?
host=http://s3.xxx.com:8080
&access_id=xxx
&access_key=xxx
&s3_region=xxx
&delete_mode=tagging’ TENANT = tp_tenant;
日志为(也将host和ak/sk隐去了)：
observer.log.zip (239.2 KB)
这个会和host不是amazonaws.com结尾有关系吗
通过开源的s3 cli去查是可以查到路径：
aws --endpoint-url http://s3.xxx.com:8080 s3 ls s3://xxx/obbackup/archive/
2024-04-15 14:24:09 0
有人能看下吗。。。。
有老师能帮忙看下吗
可以将问题再复现一次，然后将rs节点的的最新rootservice.log 日志附件压缩后发一下
select svr_ip from dba_ob_servers where with_rootserver=‘yes’;
老师能看下吗
上传的这个附件信息太少了，请把完整的日志发一下吧。
[2024-04-19 11:16:43.468160] INFO [STORAGE.TRANS] rollback_tx (ob_tx_api.cpp:365) [83266][T1_L0_G0][T1001][YB420A48760C-00061619E7F3B6F7-0-0] [lt=8] rollback tx(ret=0, *this={is_inited_:true, tenant_id_:1001, this:0x7ff1ae004030}, tx={this:0x7ff2527101f0, tx_id:{txid:5155004}, state:7, addr:“10.72.117.251:2882”, tenant_id:1001, session_id:1, assoc_session_id:1, xid:NULL, xa_mode:"", xa_start_addr:“0.0.0.0:0”, access_mode:0, tx_consistency_type:0, isolation:1, snapshot_version:{val:18446744073709551615, v:3}, snapshot_scn:0, active_scn:{branch:0, seq:1}, op_sn:3, alloc_ts:1713496603467557, active_ts:1713496603467557, commit_ts:-1, finish_ts:1713496603467557, timeout_us:9999360, lock_timeout_us:-1, expire_ts:1713496613466917, coord_id:{id:-1}, parts:[], exec_info_reap_ts:0, commit_version:{val:18446744073709551615, v:3}, commit_times:0, commit_cb:null, cluster_id:1713150285, cluster_version:17180065793, seq_base:1713496603467556, flags_.SHADOW:false, flags_.INTERRUPTED:false, flags_.BLOCK:false, flags_.REPLICA:false, can_elr:false, cflict_txs:[], abort_cause:-6002, commit_expire_ts:0, commit_task_.is_registered():false, ref:2})
[2024-04-19 11:16:43.468268] INFO [SHARE] add_event (ob_event_history_table_operator.h:261) [83266][T1_L0_G0][T1][YB420A48760C-00061619E7F3B6F7-0-0] [lt=48] event table add task(ret=0, event_table_name="__all_rootservice_event_history", sql=INSERT INTO _all_rootservice_event_history (gmt_create, module, event, name1, value1, name2, value2, name3, value3, value4, value5, value6, rs_svr_ip, rs_svr_port) VALUES (usec_to_time(1713496603468237), ‘root_service’, ‘admin_set_config’, ‘ret’, -9026, ‘arg’, '{name:“log_archive_dest”, value:"LOCATION=s3://xxx/obbackup/archive?
[2024-04-19 11:16:43.468279] INFO [RS] process (ob_rs_rpc_processor.h:232) [83266][T1_L0_G0][T1][YB420A48760C-00061619E7F3B6F7-0-0] [lt=10] [DDL] execute ddl like stmt(ret=-9026, cost=682, ddl_arg=NULL)
9026 表示的备份的目的端无效，这里提到的s3是自建的吗，只是兼容s3协议，具体是什么，比如minio ?
老师您好，我们是用的兼容s3协议的百度云存储bos服务。上面的问题我现在已经解决了，发现应该是直接从文档copy过来换行的问题。
现在调整之后发现加上delete_mode=tagging时会报no I/O operation permission at the backup destination 的错，去掉这个参数之后之后就可以正常执行
delete_mode 主要有以下两种模式：
delete 模式：表示清理模式为直接删除满足要求的备份文件。该模式下，当您清理备份文件时，对于满足清理要求的备份文件，系统会直接将其删除，如果没有指定delete_mode 默认就是该模式。tagging 模式：表示清理模式为对满足清理要求的备份文件设置 Tag，备份文件将仍然保留。该模式下，当您清理备份文件时，对于满足清理要求的备份文件，系统会给这些文件设置标签，标签的 key 为 "delete_mode"，value 为 "tagging"，以便后续您可以通过设置的标签在 OSS 或 COS 上对这些文件的生命周期进行管理。所以tagging是只针对oss和cos的是吧，普通的就不需要这个了，直接用默认的。我可以这样理解吗？
可以先确认一下 ：兼容s3协议的百度云存储bos服务 是否支持打标签。
好的，如果真的不支持的话，默认的应该也没多大问题吧？
hi 老师 我们这边确认是不支持打标签。