【OceanBase】OBPROXY的管理

1.生产环境运行OBProxy - 守护进程

◼ OBProxy无状态，即使宕机重启也不会影响数据一致性，所以OBProxy在部署时都带有一个守护进程，周期性检
查OBProxy的健康程度，一旦发现宕机就立即重启OBProxy
◼ OBProxy手动启动和检查过程如下：
⚫ 登录 OBProxy 所在的宿主机，使用admin用户在命令行工具中运行/opt/taobao/install/<obproxy
目录>/bin/obproxyd.sh -c start -e private -n <obproxy名称>以启动守护进程，守护进程会
自动拉起 OBProxy 进程
⚫ 检查OBProxy进程状态：ps -ef | grep obproxy | grep '^admin'
⚫ 在 OceanBase 数据库支持的客户端工具中使用 root 用户登录集群的 sys 租户。
然后运行obclient -uroot@sys#[集群名称] -P2883 -h127.0.0.1 -p[密码] -Doceanbase -c
以验证是否能连到OceanBase 集群

2.OBProxy配置项

◼ 系统租户，通过OBProxy连接OceanBase集群
◼ 涉及配置项的内部命令有两种，如下：（2883 obproxy; 2881 observer）
⚫ show proxyconfig，展示proxy内部各配置项属性以及config server的配置信息
⚫ alter proxyconfig set key=value，更新指定config配置项值
◼ 更新命令只对除config server配置信息之外的其他配置项有效，config server配置信息只能通过config 
server来更新
◼ 部分配置需要重启Proxy才生效（参考 need_reboot 这列的值）

配置项可以分为3种类型况来说明：

◼ 第一种是proxy写到本地etc文件夹中配置文件的配置项，这些配置项可供用户根据使用场景进行配置和更新
◼ 第二种是proxy内部自己使用，对一般用户不可见的配置项，不会注册到内部表中
◼ 第三种是proxy从config server中获取到的配置信息(包括版本号、meta table信息、cluster信息、bin url
和更新时间)，这些信息只用来展示config server的配置，不会注册到内部表或者dump到本地配置文件中，
并且它们全部以字符串“json_config”开头，查询时可以使用like进行过滤

3.常用OBProxy配置

◼ xflush_log_level：监控用的xflush的日志级别
◼ syslog_level：OBProxy自己的应用日志的日志级别
◼ observer_query_timeout_delta：关系到网络断开连接，到认为Observer不可用的delta时间
◼ log_cleanup_interval：清理OBProxy自身应用日志的间隔时间
◼ log_dir_size_threshold：proxy日志大小阈值，超过阀值即可进行日志清理
◼ internal_cmd_mem_limited：会话较多，导致buffer内存不足时需要调大

4.常见问题

启动失败
◼ 机器是否存在 hostname ：输入hostname -i, 确认host ip是否存在
◼ 目录是否存在，权限是否正确：确保当前目录下有读、写、执行的权限
◼ 端口是否被占用：使用obproxyd.sh启动OBProxy, 使用的端口为2883
◼ 启动环境是否指定正确：如果通过obproxyd.sh启动， 需要使用-e参数指定OBProxy运行环境

5.成功启动但无法建立连接

常见问题/报错/解决思路
--IP PORT错误 
ERROR 2003 (HY000): Can''t connect to MySQL server on '127.1' (111)
检查所需建立连接的obproxy, obproxy是否存在

--权限错误
ERROR 1045 (42000): Access denied for user ‘XXXXXXXXX’ 
直接连接observer确认该信息是否正确

--租户名错误 
ERROR 5160 (HY000): invalid tenant name specified in connection string
本机mysql版本是否过低，MySQL 5.7.8之前版本，
用户名长度超过16字节会被截断。5.7.8版本之后版本用户长度超过32字节会被截


--认证错误
ERROR 2013 (HY000): Lost connection to MySQL server at ‘reading authorization packet’, 
system error: 0
本地json配置集群是否和远程json文件一致，该配置文件主要用于确认你需要连接的OB集群是否存在

6.慢查询配置项及其修改方式

OBProxy 有自己的慢查询日志打印功能，通过 OBProxy 的以下两个配置项可控制打印到日志中的 SQL 或事务的处理
时间阈值。

配置项/说明
--slow_transaction_time_threshold 
指慢查询或事务的整个生命周期的时间阈值，超过了该时间，就会打印相关日志。
--slow_proxy_process_time_threshold 
在发往 Server 前 Proxy 本身的处理时间，包括获取集群信息、路由信息、黑名单信息等。

--slow_query_time_threshold
指从 OBProxy 获取 SQL 直到返回给客户端之前的这段时间的阈值，超过了该时间，也会打印相关日志。

一般修改配置项slow_transaction_time_threshold即可，配置项 slow_proxy_process_time_threshold默认值为 2 
ms，该值适用于绝大多数场景
obclient> ALTER PROXYCONFIG SET slow_transaction_time_threshold='100ms';
obclient> ALTER PROXYCONFIG SET slow_proxy_process_time_threshold='5ms';

7.慢查询举例

[2023-05-24 22:39:00.824392] WARN [PROXY.SM] update_cmd_stats (ob_mysql_sm.cpp:4357) [28044][Y0-7F70BE3853F0] [14] 
Slow query: 
client_ip=127.0.0.1:17403 // 执行SQL client IP
server_ip=10.1.1.109:45785 // SQL被路由到的observer
conn_id=2147549270
cs_id=1
sm_id=8
cmd_size_stats=
client_request_bytes:26 // 客户端请求 SQL大小
server_request_bytes:26 // 路由到observer SQL大小
server_response_bytes:1998889110 // observer转发给obproxy数据大小
client_response_bytes:1998889110 // obproxy转发给client数据大小
cmd_time_stats=
client_transaction_idle_time_us=0 // 在事务中该条SQL与上一条SQL执行结束之间的间隔时间, 即客户端事务中SQL间隔时间
client_request_read_time_us=0 // obproxy读取客户端SQL耗时
server_request_write_time_us=0 // obproxy将客户端SQL转发给observer耗时
client_request_analyze_time_us=15 // obproxy 解析本条SQL消耗时间
cluster_resource_create_time_us=0 // 如果执行该条SQL, 需要收集OB cluster相关信息(一般发生在第一次连接到该集群的时候), 
建立集群相关信息耗时
pl_lookup_time_us=3158 // 查询partition location耗时
prepare_send_request_to_server_time_us=3196 // 从obproxy接受到客户端请求，到转发到observer执行前总计时间，正常应该是前
面所有时间之和
server_process_request_time_us=955 // observer处理请求的时间，对于流式请求就是从observer处理数据，到第一次转发数据的时间
server_response_read_time_us=26067801 // observer转发数据到obproxy耗时，对于流式请求observer是一边处理请求，一边转发数
据(包含网络上的等待时间)
client_response_write_time_us=716825 // obproxy将数据写到客户端耗时
request_total_time_us=26788969 // 处理该请求总时间
sql=select * from sbtest1 // 请求SQL

8.SQL相关timeout设置

默认配置：
◼ 查询超时：ob_query_timeout(默认10s)
◼ 事务未提交超时ob_trx_timeout 默认100s）
◼ 事务空闲超时 ob_trx_idle_timeout（默认120s）
常见超时原因：
◼ 连接闲置时间超时
◼ 客户端SQL执行耗时长
问题解决：
◼ Ping to keep alive.
◼ 调优SQL or 调整timeout value

9.小结

◼ OBProxy作为OceanBase的高性能且易于运维的反向代理服务器，具有防连接闪断、OBServer宕机
或升级不影响客户端正常请求、兼容所有MySQL客户端、支持热升级和多集群功能
◼ OBProxy核心功能包括路由、连接管理以及运维&&监控
◼ OBProxy的部署方式可以分为集中部署和客户端部署
◼ OBproxy可以通过RSList启动，也可以通过config_url启动，前者只可以管理特定的OB集群，后者可
以管理多个集群
◼ OBProxy弱一致性读策略可以分为主备均衡的路由策略（默认）、备优先读策略、读写分离策略
◼ OBProxy慢查询日志除了SQL本身之行的时间，还包括发送和接收数据消耗的网络延时