【 使用环境 】生产环境
【 其他组件 】obproxy
【 使用版本 】4.2.4.0社区版
【问题描述】
我是在自己的vCenter虚拟化平台部署的三节点oceanbase 社区版。新建了两个租户。
1、pre租户通过obproxy的2883端口连接数据库时好是坏，坏的时候提示Access denied。
【复现路径】在这个问题之前，我们对oceanbase三台虚拟机做了一次热迁移操作
@论坛小助手
推荐使用 obdiag 工具进行日志采集，这将有助于我们定位和解决问题。
日志采集场景: SQL 执行出错
日志采集命令: obdiag gather scene run --scene=observer.sql_err --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”
请您按照上述命令采集日志，并将生成的日志压缩包提供给我们。同时，为了更准确地定位问题，请您回答以下问题：
这些问题的答案将有助于我们更快地定位并解决您的问题。感谢您的配合。
附上敏捷诊断工具 obdiag 使用帮助链接
1、迁移时间是8月15日。
2、热迁移前后没有对数据库最任何配置修改操作；
3、仅仅只有xj_pre租户存在这个问题，其他租户都是可以正常使用obproxy连接数据库
4、2883和2881使用的账户和密码是一样的仅只有端口不一样；
5、环境中的OBproxy和observer在这段时间没有做过任何操作；
6、可以提供，但是你提供的命令好像不对
7、从2025-08-15 19:11 obproxy日志开始产生Access denied日志
[2025-08-15 19:11:40.797174] WDIAG [PROXY.SM] print_mysql_complete_log (ob_mysql_sm.cpp:5906) [49046][Y0-0000150D7E7D6550] [lt=0] [dc=0] finishing mysql tunnel((sm_id=4017437, cs_id=2091185884, proxy_sessid=744995200467961606, ss_id=8697060, server_sessid=3221640982, cli
ent_ip={*Not IP address [0]*:0}, server_ip={10.86.193.48:2881}, server_trace_id=, proxy_user_name=proxyro@sys#xj-oceanbase, database_name=, is_flow_controlled=false, cpu_flow_control_count=0, memory_flow_control_count=0, sql=, sql_cmd="Login", result={is_trans_completed:
true, is_resp_completed:true, ending_type:2, is_partition_hit:true, has_new_sys_var:false, has_proxy_idc_name_user_var:false, is_server_db_reset:false, reserved_len:0, connection_id:0, scramble_buf:"", is_resultset_resp:false, server_capabilities_lower_.capability:0, ok_
packet_action_type:2, last_ok_pkt_len:12, rewritten_last_ok_pkt_len:0, extra_info:{is_exist_sess_info:false, sess_info_count:0, extra_len:0}, error_pkt:field_count:255, errcode:1045, sqlstate:"42000", message:"Access denied for user 'proxyro'@'xxx.xxx.xxx.xxx' (using pas
sword: NO)"})还没遇到过这种问题，插个眼
是用oms做的迁移么？从mysql迁移到ob么？还是ob迁移到ob obproxy是哪个版本 obproxy.log的日志提供一下 obproxy怎么搭建的 是否修改过proxyro的密码
插眼学习
1、是虚拟机的迁移，和oceanbase没关系，单纯的把虚拟机移动到另外一个物理节点上；
2、没有修改过proxyro的密码；
3、部署使用的obd web，跟着流程部署的；完成后没有对集群做过任何修改；
4、obproxy.log有很多的access denied提示，从8月16开始产生的；
[2025-08-20 11:16:17.364532] WDIAG [PROXY.SM] print_mysql_complete_log (ob_mysql_sm.cpp:5906) [46222][Y0-0000150D7BEAE710] [lt=0] [dc=0] finishing mysql tunnel((sm_id=4722077, cs_id=2091126541, proxy_sessid=744995200467988080, ss_id=9422171, server_sessid=3221905208, client_ip={*Not IP address [0]*:0}, server_ip={10.86.193.49:2881}, server_trace_id=, proxy_user_name=proxyro@sys#xj-oceanbase, database_name=, is_flow_controlled=false, cpu_flow_control_count=0, memory_flow_control_count=0, sql=, sql_cmd="Login", result={is_trans_completed:true, is_resp_completed:true, ending_type:2, is_partition_hit:true, has_new_sys_var:false, has_proxy_idc_name_user_var:false, is_server_db_reset:false, reserved_len:0, connection_id:0, scramble_buf:"", is_resultset_resp:false, server_capabilities_lower_.capability:0, ok_packet_action_type:2, last_ok_pkt_len:12, rewritten_last_ok_pkt_len:0, extra_info:{is_exist_sess_info:false, sess_info_count:0, extra_len:0}, error_pkt:field_count:255, errcode:1045, sqlstate:"42000", message:"Access denied for user 'proxyro'@'xxx.xxx.xxx.xxx' (using password: NO)"})
5、查看的集群的配置文件是存在
skip_proxy_sys_private_check: true
6、使用密码是可以登录，不是用密码无法登录
obproxy也是通过obd web搭建的么？看着是obproxy的proxyro的密码有问题呀
1、obproxy也是通过obd web搭建的。
2、我看着也是密码问题。但是obproxy的配置设置了skip_proxy_sys_private_check: true不应该是可以不用密码登录吗？
3、 我以为是observer的设置了必须要求密码，但是查我了require_secure_transport并没有这个参数。
4、出问题的是生产环境，我测试环境和生产环境是一模一样的部署和参数都是一致的。我测试环境是没问题的。
5、会不会是因为缓存等其他原因导致的呢？
6、我查询过非官方的一些资料，说可能是这个版本的bug
这个是集群配置文件，上面也配置了密码的，且密码我通过直连2881是可以登录的，但是obproxy日志还是提示密码为空
oceanbase-ce:
depends:
- ob-configserver
servers:
- name: server1
# Please don't use hostname, only IP can be supported
ip: 10.x.x.48
- name: server2
ip: 10.x.x.49
- name: server3
ip: 10.x.x.50
global:
appname: xj-oceanbase
cluster_id: 123456
root_password: root_password
ocp_agent_monitor_password: ocp_agent_monitor_password
proxyro_password: proxyro_password
ocp_root_password: ocp_root_password
ocp_meta_password: ocp_meta_password
# 以上密码替换过
obproxy-ce:
# Set dependent components for the component.
# When the associated configurations are not done, OBD will automatically get the these configurations from the dependent components.
depends:
- oceanbase-ce
- ob-configserver
servers:
- 10.x.x.48
global:
listen_port: 2883 # External port. The default value is 2883.
prometheus_listen_port: 2884 # The Prometheus port. The default value is 2884.
home_path: /oceanbase/obproxy
enable_cluster_checkout: false
# observer cluster name, consistent with oceanbase-ce's appname. When a depends exists, OBD gets this value from the oceanbase-ce of the depends.
# cluster_name: obcluster
skip_proxy_sys_private_check: true
enable_strict_kernel_release: false
# obproxy_sys_password: # obproxy sys user password, can be empty. When a depends exists, OBD gets this value from the oceanbase-ce of the depends.
# observer_sys_password: # proxyro user pasword, consistent with oceanbase-ce's proxyro_password, can be empty. When a depends exists, OBD gets this value from the oceanbase-ce of the depends.
obproxy_sys_password: obproxy_sys_password
10.86.193.48:
proxy_id: 7977
client_session_id_version: 2
终于不是我一个人遇到这个问题，很早前遇到过这个问题~
你最后解决了吗？
我记得这个参数 skip_proxy_sys_private_check 用于控制 ODP 是否跳过检查系统私有地址
现在是看着配置都是正常的porxyro账号的密码也要不过是在oceanbase-ce这一层并没有在obproxy-ce这一层。 还是提示access denied 提示没有输入密码。大佬还有其他办法吗？
没遇到过，跟踪一下处理进展
你应该是改过这个密码proxyro_password 你还记得之前的密码么？
从来没有修改过，我也是通过集群配置文件里面proxyro的密码直接2881是可以登录的，也就是说密码没有被修改过
那不应该呀 如果这个密码没有修改的话 obproxy的proxy_config的observer_sys_password是根据这个密码同步的呀 关键是有时候能连上有时候连不上 ob集群是1-1-1的么 obproxy是集群的么？ 你使用的obproxy是哪个版本 登陆成功的 obproxy_diagnosis.log 和不成功的obproxy_diagnosis.log 日志提供一下
1、有一个租户是pre，这个租户就是有时候时好时坏的。
2、如果用proxyro@sys去连接2883就一定失败，不管是输入不输入密码。反之连接2881输入密码就可以连接；
2、oceanbase集群式1-1-1，但是obproxy只有一个节点，在第一个observer上的，obproxy非集群
3、版本4.2.3.0
obproxy_bachup_diagnosis.log (7.6 MB)
学习一下大佬们的经验 
