IT评测·应用市场-qidao123.com

标题: 【OceanBase诊断调优】—— 断连接题目根因分析 [打印本页]
作者: 大连全瓷种植牙齿制作中心    时间: 2024-9-25 01:10
标题: 【OceanBase诊断调优】—— 断连接题目根因分析
配景

当前用户请求实行的链路主要如下，请求从客户端发送到ObProxy，ObProxy将请求路由到对应的ObServer节点，ObServer处理请求发送回包给ObProxy，ObProxy回给客户端。目前整条链路上都大概发生断连接的场景，好比请求处理时间较长客户端长时间没有收到回包断开连接、用户登录填写错误的集群租户等导致无法登录、ObProxy以及ObServer的内部错误导致断开连接等等。
当断连接发生的时候，用户最直接得到的信息是ObServer返回的错误包提示，用户可以根据错误包的提示作开端的排查，这里提供的信息往往比较少，用户很难确定题目，而且一部门场景下用户无法得到错误包提示，需要排查整条链路上的题目。ObProxy针对断连接题目，提供断连接的诊断信息纪录。


断连接诊断方法说明

诊断流程



诊断日志

当发生断连接之后ObProxy会纪录一段断连接日志，纪录到obproxy_diagnosis.log中，这里会具体纪录断连接相干的信息。
以租户名错误为例：
  1. [2023-08-23 20:11:08.567425] [109316][Y0-00007F285BADB4E0] [CONNECTION](trace_type="LOGIN_TRACE", connection_diagnosis={cs_id:1031798792, ss_id:0, proxy_session_id:0, server_session_id:0, client_addr:"xxx.xxx.xxx.xxx:58218", server_addr:"*Not IP address [0]*:0", cluster_name:"undefined", tenant_name:"test", user_name:"root", error_code:-4043, error_msg:"dummy entry is empty, please check if the tenant exists", request_cmd:"COM_SLEEP", sql_cmd:"COM_LOGIN"}{internal_sql:""})
复制代码
这里的错误码遵循以下的格式：

常见断连接场景

登录断连接

对应trace_type：LOGIN_TRACE
租户名错误诊断日志示例：
  1. [2023-09-08 10:37:21.028960] [90663][Y0-00007F8EB76544E0] [CONNECTION](trace_type="LOGIN_TRACE", connection_diagnosis={cs_id:1031798785, ss_id:0, proxy_session_id:0, server_session_id:0, client_addr:"xxx.xxx.xxx.xxx:xxxx", server_addr:"*Not IP address [0]*:0", cluster_name:"undefined", tenant_name:"sys", user_name:"root", error_code:-10018, error_msg:"fail to check observer version, empty result", request_cmd:"COM_SLEEP", sql_cmd:"COM_LOGIN"}{internal_sql:"SELECT ob_version() AS cluster_version"})
复制代码
额外诊断信息
internal_sql：obproxy当前实行的内部请求
用户侧使用题目

场景诊断错误码诊断信息办理手段集群名错误4669cluster xxx does not exist确保对应集群存在，可以通过直连ObServer的方式举行确认租户名错误4043dummy entry is empty, please check if the tenant exists确保对应的租户存在，可以通过直连ObServer的方式确认ObProxy白名单校验失败8205user xxx@xxx can not pass white list通过OCP确认ObProxy白名单是否配置正确ObServer白名单校验失败1227Access denied确认ObServer白名单是否配置正确客户端连接数达上限client_max_connections5059too many sessions可以调整ObProxy的全局配置client_max_connections做暂时的规避ObProxy配置要求使用SSL协议，但是用户发起平凡协议请求8004obproxy is configured to use ssl connection修改SSL协议配置enable_client_ssl，或者使用SSL协议访问直接访问proxyro@sys10021user proxyro is rejected while proxyro_check on不应直接使用proxyro@sys访问数据库云上用户在关闭enable_cloud_full_user_name的场景下使用三段式访问10021connection with cluster name and tenant name is rejected while cloud_full_user_name_check off云上用户关闭enable_cloud_full_user_name时，ObProxy会限制三段式的访问非云用户开启enable_full_user_name的场景下，没有使用三段式访问10021cluster name and tenant name is required while full_username_check on非云用户关闭enable_full_user_name时，ObProxy会限制非三段式的访问 部署错误

trace_type场景诊断错误码诊断信息办理手段LOGIN_TRACEproxyro暗码配置错误10018fail to check observer version, proxyro@sys access denied, error resp { code:1045, msg:Access denied for user xxx }默认情况下的部署proxyro的暗码是不会存在题目标，如果手动更改proxyro用户的暗码，请确保ObProxy的启动参数配置正确LOGIN_TRACE启动obproxy时配置的rootservice_list 不可用10018fail to check observer version, empty result这里可以通过直连ObServer确认ObProxy启动时配置的server ip是否可用 OB侧错误

trace_type场景诊断错误码诊断信息办理手段LOGIN_TRACE集群信息查询为空4669cluster info is empty直连ObServer实行internal_sql字段的sql语句确认ObServer返回的集群信息是否为空LOGIN_TRACE集群信息查询失败10018fail to check observer version
fail to check cluster info
fail to init server state直连ObServer实行internal_sql字段的sql语句确认ObServer返回的集群信息是否为空LOGIN_TRACEconfig_server信息查询失败10301fail to fetch root server list from config server   fail to fetch root server list from local可以手动拉去启动时配置的config_server的url确认这里config server返回的信息是否正常 超时断连接

对应trace_type：TIMEOUT_TRACE
集群过期发起断连接诊断日志示例：
  1. [2023-08-17 17:10:46.834897] [119826][Y0-00007FBF120324E0] [CONNECTION](trace_type="TIMEOUT_TRACE", connection_diagnosis={cs_id:1031798785, ss_id:7, proxy_session_id:7230691830869983235, server_session_id:3221504994, client_addr:"xxx.xxx.xxx.xxx:42468", server_addr:"xxx.xxx.xxx.xxx:xxxx", cluster_name:"undefined", tenant_name:"sys", user_name:"root", error_code:-10022, error_msg:"OBProxy inactivity timeout", request_cmd:"COM_SLEEP", sql_cmd:"COM_END"}{timeout:1, timeout_event:"CLIENT_DELETE_CLUSTER_RESOURCE", total_time(us):21736})
复制代码
额外诊断信息：
timeout_event：超局面件
total_time：请求实行时间
trace_type超局面件场景诊断错误码相干配置默认值办理手段TIMEOUT_TRACECLIENT_DELETE_CLUSTER_RESOURCE集群信息发生变化10022obproxy配置cluster_expire_time1天可以通过调整obproxy cluster_expire_time 配置暂时规避，默认过期时间为一天，新的请求会重置过期时间TIMEOUT_TRACECLIENT_INTERNAL_CMD_TIMEOUT内部请求实行超时10022固定时间30s30s非预期超时，需要客户情况配合诊断TIMEOUT_TRACECLIENT_CONNECT_TIMEOUT客户端与ObProxy建连超时10022固定时间10s30s非预期超时，需要客户情况配合诊断TIMEOUT_TRACECLIENT_NET_READ_TIMEOUTObProxy等待用户请求数据超时10022net_read_timeout(observer变量)30s修改observer net_read_timeout变量，需要主要修改global级别的配置对已有连接不会生效TIMEOUT_TRACECLIENT_NET_WRITE_TIMEOUTObProxy等待回包数据超时10022net_write_timeout(observer变量)60s修改observer net_read_timeout变量，需要主要修改global级别的配置对已有连接不会生效TIMEOUT_TRACECLIENT_WAIT_TIMEOUT用户请求过程中，客户端连接长时间没有发生交互导致超时10022wait_timeout(observer变量)28800s修改observer wait_timeout变量暂时规避TIMEOUT_TRACESERVER_QUERY_TIMEOUT用户请求查询超时10022ob_query_timeout(observer变量)
hint指定的query_timeout
observer_query_timeout_delta(obproxy配置，控制obproxy额外超时时间)30s [ob_query_timeout(10s) + observer_query_timeout_delta(20s)]修改observer ob_query_timeout变量暂时规避   修改obproxy observer_query_timeout_delta 配置规避TIMEOUT_TRACESERVER_TRX_TIMEOUT用户事务实行超时10022ob_trx_timeout(observer变量)86400000000us修改ob_trx_timeout变量暂时规避TIMEOUT_TRACESERVER_WAIT_TIMEOUT用户请求过程中，ObServer连接长时间没有发生交互导致超时10022wait_timeout(observer变量)28800s修改observer wait_timeout变量暂时规避 ObServer主动断开连接

应trace_type: SERVER_VC_TRACE
ObProxy与ObServer建连失败诊断日志示例：
  1. [2023-08-10 23:35:00.132805] [32339][Y0-00007F74C9A244E0] [CONNECTION](trace_type="SERVER_VC_TRACE", connection_diagnosis={cs_id:838860809, ss_id:0, proxy_session_id:7230691830869983240, server_session_id:0, client_addr:"xxx.xxx.xxx.xxx:45765", server_addr:"", cluster_name:"undefined", tenant_name:"sys", user_name:"root", error_code:-10013, error_msg:"Fail to build connection to observer", request_cmd:"COM_QUERY", sql_cmd:"COM_HANDSHAKE"}{vc_event:"unknown event", total_time(us):2952626, user_sql:"select 1 from dual"})
复制代码
外诊断信息：
vc_event：断连接相干的事件，用户不需要太关注
total_time：请求实行时间
user_sql：用户请求
trace_type场景诊断错误码诊断信息办理手段SERVER_VC_TRACEObProxy 与 ObServer 节点建连失败10013Fail to build connection to observer需要observer配合诊断SERVER_VC_TRACEObProxy 传输请求给ObServer时连接断开10016An EOS event eceived while proxy transferring request需要observer配合诊断SERVER_VC_TRACEObProxy 传输 ObServer回包时连接断开10014An EOS event received while proxy reading response需要observer配合诊断   ObServer主动断连接的场景ObProxy没有办法网络更为具体的信息，如果ObProxy配置的ObServer节点状态正常则需要配合ObServer的日志举行诊断。  客户端主动断连接

客户端主动断连接日志纪录

对应trace_type: CLIENT_VC_TRACE
ObProxy读请求时断开客户端连接诊断日志示例：
  1. [2023-08-10 23:28:24.699168] [32339][Y0-00007F74C9A244E0] [CONNECTION](trace_type="CLIENT_VC_TRACE", connection_diagnosis={cs_id:838860807, ss_id:26, proxy_session_id:7230691830869983239, server_session_id:3221698209, client_addr:"xxx.xxx.xxx.xxx:44701", server_addr:"xxx.xxx.xxx.xxx:xxxx", cluster_name:"undefined", tenant_name:"sys", user_name:"root", error_code:-10010, error_msg:"An EOS event received from client while obproxy reading request", request_cmd:"COM_SLEEP", sql_cmd:"COM_END"}{vc_event:"VC_EVENT_EOS", total_time(us):57637, user_sql:""})
复制代码
额外诊断信息：
vc_event：断连接相干的事件，用户不需要太关注
total_time：请求实行时间
user_sql：用户请求
trace_type场景诊断错误码诊断信息办理手段CLIENT_VC_TRACEObProxy收发包时客户端发生断连接10010An EOS event received from client while obproxy reading request需要客户端配合诊断CLIENT_VC_TRACEObProxy处理请求时客户端断连接10011An EOS event received from client while obproxy handling response需要客户端配合诊断CLIENT_VC_TRACEObProxy回包时客户端发送断连接10012An EOS event received from client while obproxy transferring response需要客户端配合诊断   客户端断连接的场景ObProxy没有办法网络更为具体的信息，只能指出客户端方面主动断开连接的操纵，比较常见的断连接题目有驱动超时主动断开连接、Druid/Hikaricp/Nginx等中间件主动断连接、网络抖动等题目  ObProxy/ObServer内部错误

一样平常内部错误

对应trace_type：PROXY_INTERNAL_TRACE / SERVER_INTERNAL_TRACE
诊断日志示例：
  1. [2023-08-10 23:26:12.558201] [32339][Y0-00007F74C9A244E0] [CONNECTION](trace_type="PROXY_INTERNAL_TRACE", connection_diagnosis={cs_id:838860805, ss_id:0, proxy_session_id:7230691830869983237, server_session_id:0, client_addr:"xxx.xxx.xxx.xxx:44379", server_addr:"", cluster_name:"undefined", tenant_name:"sys", user_name:"root", error_code:-10019, error_msg:"OBProxy reached the maximum number of retrying request", request_cmd:"COM_QUERY", sql_cmd:"COM_QUERY"}{user_sql:"USE `ý<8f>ý<91>ý<92>`"})
复制代码
额外诊断信息：
user_sql：用户请求sql
trace_type场景诊断错误码诊断信息办理手段PROXY_INTERNAL_TRACE租户分区信息查询失败4664dummy entry is empty, disconnect未预期错误场景PROXY_INTERNAL_TRACEObProxy部门内部请求实行失败10018proxy execute internal request failed, received error resp, error_type: xxx未预期错误场景PROXY_INTERNAL_TRACEObProxy重试请求达上限10019OBProxy reached the maximum number of retrying request未预期错误场景PROXY_INTERNAL_TRACEObProxy目标Session被关闭10001target session is closed, disconnect未预期错误场景PROXY_INTERNAL_TRACE其他未预期的错误场景10001诊断信息为空未预期错误场景SERVER_INTERNAL_TRACECheckSum 校验出错10001ora fatal error未预期错误场景SERVER_INTERNAL_TRACE主备库切换场景10001primary cluster switchover to standby, disconnect主备库切换过程中大概存在的断连接题目，符合预期的场景 其他场景

对应trace_type：PROXY_INTERNAL_TRACE
诊断日志示例：
  1. [2023-08-10 23:27:15.107427] [32339][Y0-00007F74CAAE84E0] [CONNECTION](trace_type="PROXY_INTERNAL_TRACE", connection_diagnosis={cs_id:838860806, ss_id:21, proxy_session_id:7230691830869983238, server_session_id:3221695443, client_addr:"xxx.xxx.xxx.xxx:44536", server_addr:"xxx.xxx.xxx.xxx:xxxx", cluster_name:"undefined", tenant_name:"sys", user_name:"", error_code:-5065, error_msg:"connection was killed by user self, cs_id: 838860806", request_cmd:"COM_QUERY", sql_cmd:"COM_QUERY"}{user_sql:"kill 838860806"})
复制代码
额外诊断信息：
user_sql：用户请求sql
trace_type场景诊断错误码诊断信息排查手段PROXY_INTERNAL_TRACEkil 当前session5065connection was killed by user self, cs_id: xxx符合预期的场景，诊断日志作纪录PROXY_INTERNAL_TRACEkill 其他session5065connection was killed by user session xxx符合预期的场景，诊断日志作纪录 断连接诊断示例

确定断连接方

客户请求到OB的链路比较常见的有以下两种：

客户端的请求到ObServer之间的链路大概需要颠末多个节点，中间任意一个节点出现题目时候都会导致客户端的连接断开。所以当发生断连接且客户端没有收到明确的错误包提示断连接原因时，如果从整条链路上开始排查断连接题目标话首先需要确定断连接方。
如果使用的ObProxy具备连接诊断的本领，可以通过诊断日志obproxy_diagnosis.log快速判断发起断连接的一方。
用户可以根据用户名、租户名、集群名、从驱动拿到的thread_id（对应日志cs_id)等、断连接时间等信息从日志中快速筛选出对应的断连接日志，根据trace_type字段判断断连接方

排查断连接原因

客户端断连接

socketTimeout场景
JDBC默认的socketTimeout配置为0，即不会产生socketTimeout超时，但是部门客户端好比Druid/MyBatis自身有控制socketTimeout的参数，如果发生请求实行时间过长导致的断连接，可以优先确认socketTimeout的配置。
  1. [2023-09-07 15:59:52.308553] [122701][Y0-00007F7071D194E0] [CONNECTION](trace_type="CLIENT_VC_TRACE", connection_diagnosis={cs_id:524328, ss_id:0, proxy_session_id:7230691833961840700, server_session_id:0, client_addr:"xxx.xxx.xxx.xxx:38877", server_addr:"xxx.xxx.xxx.xxx:50110", cluster_name:"ob1.changluo.cc.xxx.xxx.xxx.xxx", tenant_name:"mysql", user_name:"root", error_code:-10011, error_msg:"An unexpected connection event received from client while obproxy handling request", request_cmd:"COM_QUERY", sql_cmd:"COM_QUERY"}{vc_event:"VC_EVENT_EOS", total_time(us):5016353, user_sql:"select sleep(20) from dual"})
复制代码
主要诊断信息：
trace_type: CLIENT_VC_TRACE， 判断出是客户端主动断开的连接
error_msg: An unexpected connection event received from client while obproxy handling request，说明客户端在obproxy处理请求时断开连接
total_time: 5016353，请求总的实行时间为5s左右，可以通过total_time去匹配客户端的超时参数
根据诊断信息能确定是客户端主动断开了连接，需要排查客户端相干的题目。
查看JDBC堆栈：
  1. The last packet successfully received from the server was 5,016 milliseconds ago.  The last packet sent successfully to the server was 5,011 milliseconds ago.
  2.         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
  3.         at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
  4.         at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  5.         at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
  6.         at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
  7.         at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1129)
  8.         at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3720)
  9.         at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3609)
  10.         at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4160)
  11.         at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2617)
  12.         at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2778)
  13.         at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2819)
  14.         at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2768)
  15.         at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:949)
  16.         at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:795)
  17.         at odp.Main.main(Main.java:12)
  18. Caused by: java.net.SocketTimeoutException: Read timed out
  19.         at java.net.SocketInputStream.socketRead0(Native Method)
  20.         at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
  21.         at java.net.SocketInputStream.read(SocketInputStream.java:170)
  22.         at java.net.SocketInputStream.read(SocketInputStream.java:141)
  23.         at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
  24.         at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
  25.         at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
  26.         at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3163)
  27.         at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3620)
  28.      9 more
复制代码
The last packet successfully received from the server was 5,013 milliseconds ago. The last packet sent successfully to the server was 5,012 milliseconds ago.Caused by: java.net.SocketTimeoutException: Read timed out 可以从堆栈以及收发包时间中大致判断这里是socketTimeout触发的题目。
ObProxy断连接

net_write_timeout超时场景（非常见场景）
obproxy会读取observer设置的net_write_timeout配置，控制收包和发包时传包的超时时间，该配置默认时间为60s，当网络情况比较极端或者observer回包处理较慢时大概会出现obproxy net_write_timeout超时断连接的题目
  1. [2023-09-08 01:22:17.229436] [81506][Y0-00007F455197E4E0] [CONNECTION](trace_type="TIMEOUT_TRACE", connection_diagnosis={cs_id:1031798827, ss_id:342, proxy_session_id:7230691830869983244, server_session_id:3221753829, client_addr:"xxx.xxx.xxx.xxx:34901", server_addr:"xxx.xxx.xxx.xxx:21102", cluster_name:"undefined", tenant_name:"mysql", user_name:"root", error_code:-10022, error_msg:"OBProxy inactivity timeout", request_cmd:"COM_QUERY", sql_cmd:"COM_QUERY"}{timeout(us):6000000, timeout_event:"CLIENT_NET_WRITE_TIMEOUT", total_time(us):31165295})
复制代码
主要诊断信息：
trace_type: TIMEOUT_TRACE， 判断出ObProxy由于超时主动断开连接
timeout_event: CLIENT_NET_WRITE_TIMEOUT，判断出obproxy由于net_write_timeout超时断连接
根据诊断信息就能确定这里触发了net_write_timeout，客户端连接等待数据高出6s（非默认值），导致连接断开，通过修改体系变量延伸超时限制可以暂时规避。
登录失败

rootservice_list指定的observer不可用
  1. [2023-09-08 10:37:21.028960] [90663][Y0-00007F8EB76544E0] [CONNECTION](trace_type="LOGIN_TRACE", connection_diagnosis={cs_id:1031798785, ss_id:0, proxy_session_id:0, server_session_id:0, client_addr:"xxx.xxx.xxx.xxx:44018", server_addr:"*Not IP address [0]*:0", cluster_name:"undefined", tenant_name:"sys", user_name:"root", error_code:-10018, error_msg:"fail to check observer version, empty result", request_cmd:"COM_SLEEP", sql_cmd:"COM_LOGIN"}{internal_sql:"SELECT ob_version() AS cluster_version"})
复制代码
主要诊断信息：
trace_typeOGIN_TRACE，确定这里登录失败的题目
internal_sql:SELECT ob_version() AS cluster_version，确定登录过程中obproxy实行该内部请求失败
error_msg:fail to check observer version, empty result，确定这里内部请求失败的原由于结果集为空
这里看到proxy实行内部请求 "SELECT ob_version() AS cluster_version" 失败，结果集为空，这条sql是obproxy查询集群版本的请求，用户初次登录时obproxy会实行这条请求校验集群信息，当obproxy启动时配置的rootservice_list错误或者observer宕机时，obproxy查询失败，即导致登录失败。
客户端连接数达obproxy上限
  1. [2023-09-08 11:19:26.617385] [110562][Y0-00007FE1F06AC4E0] [CONNECTION](trace_type="LOGIN_TRACE", connection_diagnosis={cs_id:1031798805, ss_id:0, proxy_session_id:0, server_session_id:0, client_addr:"xxx.xxx.xxx.xxx:40004", server_addr:"*Not IP address [0]*:0", cluster_name:"undefined", tenant_name:"sys", user_name:"root", error_code:-5059, error_msg:"Too many sessions", request_cmd:"COM_SLEEP", sql_cmd:"COM_LOGIN"}{internal_sql:""})
复制代码
主要诊断信息：
trace_typeOGIN_TRACE，确定这里登录失败的题目
error_msg:Too many session，确定这里由于连接数达到上限导致登录失败
  1. $ obclient -hxxx.xxx.xxx.xxx -P2899 -uroot@sys -Dtest -A -c
  2. ERROR 1203 (42000): Too many sessions
复制代码
如何借助obdiag来快速分析断连题目

使用示例

目前obdiag支持了断连题目标场景，目前支持obproxy 4.2.2.0及之后的版本。
  1. obdiag rca run --scene=disconnection --input_parameters='{"since":"1d"}'
复制代码
input_patameters是一个用于输入差别根因分析场景下需要引入的变量赋值，输入对象的应该为一个json格式的字符串用于解析。
  1. since代表需要往回追溯的时间，默认为30分钟
复制代码
record示例：
如图为一次断联的排查，确认了事件范例为CLIENT_VC_TRACE，判断出是客户端主动断开的连接，需要客户端配合去举行诊断。


后续场景升级

目前基于obproxy已有日志举行排查，后续将逐步举行深入的根因分析
有爱好的DBA和开发者可以参加obdiag SIG举行共建开发。
技能支持

排查思路及流程感谢 怀有（潘锐鸿） 提供。
附录

•obdiag 下载地点： https://www.oceanbase.com/softwarecenter
•obdiag 官方文档： https://www.oceanbase.com/docs/obdiag-cn
•obdiag github地点： GitHub - oceanbase/obdiag: obdiag (OceanBase Diagnostic Tool) is designed to help OceanBase users quickly gather necessary information and analyze the root cause of the problem.
•obdiag SIG 营地： [obdiag SIG] 诊断工具组 · OceanBase 技能交换

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 IT评测·应用市场-qidao123.com (https://dis.qidao123.com/) Powered by Discuz! X3.4