【 使用环境 】测试环境
【 OB or 其他组件 】oblogproxy 二进制日志突然停止生成，oblogproxy.log未报错。
【 使用版本 】4.2.3
【问题描述】oblogproxy 二进制日志突然于上周五（7月19日 05:00）停止生成，oblogproxy.log未报错
【复现路径】配置oblogproxy，开启MySQL Binlog模式后，正常运行了一段时间，突然于7月19日 09:40不继续生成，日志方面未见明显报错。
烦请协助定位，另外，是否只能重新初始化binlog日志。
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
能发下 conf/conf.json 文件的配置吗？这个配置错可能报这个错，检查下配置是否正确
感谢大佬，麻烦看看。
{
“service_port”: 2983,
“encode_threadpool_size”: 8,
“encode_queue_size”: 20000,
“max_packet_bytes”: 67108864,
“record_queue_size”: 20000,
“read_timeout_us”: 2000000,
“read_fail_interval_us”: 1000000,
“read_wait_num”: 20000,
“send_timeout_us”: 2000000,
“send_fail_interval_us”: 1000000,
“check_quota_enable”: false,
“check_clog_enable”: true,
“command_timeout_s”: 10,
“log_quota_size_mb”: 5120,
“log_quota_day”: 7,
“log_gc_interval_s”: 43200,
“log_level”: 2,
“log_flush_strategy”: 1,
“log_flush_level”: 2,
“log_flush_period_s”: 1,
“log_max_file_size_mb”: 1024,
“log_retention_h”: 360,
“oblogreader_path_retain_hour”: 168,
“oblogreader_lease_s”: 300,
“oblogreader_path”: “/usr/local/oblogproxy/run”,
“bin_path”: “/usr/local/oblogproxy/bin”,
“oblogreader_obcdc_ce_path_template”: “/usr/local/oblogproxy/obcdc/obcdc-ce-%s.x-access/libobcdc.so”,
“allow_all_tenant”: true,
“auth_user”: true,
“auth_use_rs”: false,
“auth_allow_sys_user”: true,
“ob_sys_username”: “CFBF5360D0D8B09534FB1C26AE2D7BD7”,
“ob_sys_password”: “CC3D964C879ED5D0D44B94437799D4413603ADDBA98AFE3716D1989A165EE9A7”,
“counter_interval_s”: 2,
“metric_enable”: true,
“metric_interval_s”: 10,
“debug”: false,
“verbose”: false,
“verbose_packet”: false,
“verbose_record_read”: false,
“readonly”: false,
“count_record”: false,
“channel_type”: “plain”,
“tls_ca_cert_file”: “”,
“tls_cert_file”: “”,
“tls_key_file”: “”,
“tls_verify_peer”: true,
“liboblog_tls”: false,
“liboblog_tls_cert_path”: “”,
“binlog_log_bin_basename”: “/data/oceanbase/pre_degp_ob_cluster/oblogproxy/run”,
“binlog_obcdc_ce_path_template”: “/usr/local/oblogproxy/obcdc/obcdc-ce-%s.x-access/libobcdc.so”,
“binlog_ignore_unsupported_event”: true,
“binlog_max_event_buffer_bytes”: 67108864,
“binlog_mode”: true,
“table_whitelist”: “”,
“binlog_nof_work_threads”: 16,
“binlog_bc_work_threads”: 2,
“binlog_max_file_size_bytes”: 524288000,
“binlog_convert_timeout_us”: 10000,
“binlog_checksum”: true,
“binlog_heartbeat_interval_us”: 1000000,
“binlog_gtid_display”: true,
“binlog_ddl_convert”: true,
“binlog_memory_limit”: “3G”,
“binlog_working_mode”: “storage”,
“binlog_recover_backup”: true,
“wait_rotate_ready_max_try”: 1000,
“telemetry_url”: “https://openwebapi.oceanbase.com”,
“telemetry_enabled”: true
}
默认安装用默认路径，自定义安装的，配置文件中有默认路径的改成自定义安装的路径
噢噢，谢谢，因为是这样的，binlog日志比较大，我就选择来独立的目录，原来是全部都需要改吗？
确认下您的oblogproxy是默认安装的还是自定义安装的？
通过 rpm 默认安装的。
默认安装那不需要全部修改，默认安装的那前缀路径就是/usr/local/oblogproxy，上面那个binlog_log_bin_basename它的前缀路径也应是/usr/local/oblogproxy，您这里是想换到其它路径下，推荐rpm安装时指定下oblogproxy安装目录，binlog_log_bin_basename的绝对路径换成不是oblogproxy的安装路径下，看是会有问题的
您好，通过“rpm --prefix=/data/oceanbase/pre_degp_ob_cluster/oblogproxy -i oblogproxy-2.0.2-100000012024060321.el8.x86_64.rpm”好像还是不太行~
重新安装，全部都没进行调整，仍然不行。、
安装有啥报错信息吗？
安装目录换成/data/oceanbase/pre_degp_ob_cluster/oblogproxy
下面这些参数的/usr/local/oblogproxy也改成/data/oceanbase/pre_degp_ob_cluster/oblogproxy了吗？
“oblogreader_path”: “/usr/local/oblogproxy/run”
“bin_path”: “/usr/local/oblogproxy/bin”
“oblogreader_obcdc_ce_path_template”: “/usr/local/oblogproxy/obcdc/obcdc-ce-%d.x-access/libobcdc.so”
“binlog_log_bin_basename”: “/usr/local/oblogproxy/run”
“binlog_obcdc_ce_path_template”: “/usr/local/oblogproxy/obcdc/obcdc-ce-%d.x-access/libobcdc.so”
我已经尝试使用默认的安装目录了。
操作如下：
1、删除binlog服务
DROP BINLOG FOR TENANT pre_degp_ob_cluster.bap_etl;
2、卸载oblogproxy程序
3、默认安装目录下安装oblogproxy
oblogproxy重新安装怎么样？还有报错吗？
大佬，目前还是报错，但是，这让我思考一个问题。
如果后续我们基于oblogproxy替换目前生产的binlog，oblogproxy是应该通过ob的clog生成binlog的，如果clog被覆盖，oblogproxy挂了，那日志是不是就丢失了呢~
如果 clog 在转为 binlog 之前就被清理掉了，这部分日志确实就不能再通过 oblogproxy 拉取到了，所以增量数据的消费时延不能太大。只有在增量同步链路的时延不大的情况下，保证 oblogproxy 服务的可用性才可以做到不丢数据。
我们有计划在后续版本放出 binlog 服务的集群高可用能力，在此之前，用户可能需要部署多套环境实现。
大多数情况下 Failed to open locked file 相关的报错事可以忽略的，logproxy binlog 模式下会有多个进程对 binlog 文件进行更新，我们通过一个文件锁来实现进程同步，过程中有进程获取锁失败就会报这个错。这部分日志我们会在后续版本优化一下，筛掉这些可能不需要关注的问题点。
