obproxy4.3.3发生多次自动重启问题

[jiaxin666]

社区版本

obbinlog 4.2.3

obproxy 4.3.3.0-5

observer 4.2.5.1

业务测试环境，QPS TPS较高 3K左右

4号发生自动重启

201 obproxy

ll -h /home/admin/obproxy/ | grep 'Mar  4'
-rw------- 1 admin admin 1.5G Mar  4 07:46 core.35194

204 obproxy

ll -h /home/admin/obproxy/ | grep 'Mar  4'
-rw------- 1 admin admin 1.6G Mar  4 04:55 core.29368

215 obproxy

ll -h /home/admin/obproxy/ | grep 'Mar  4'
-rw------- 1 admin admin 1.3G Mar  4 09:22 core.450082
-rw------- 1 admin admin 1.3G Mar  4 01:22 core.454216

3号发生自动重启

201 obproxy

ll -h /home/admin/obproxy/ | grep 'Mar  3'
-rw------- 1 admin admin 1.4G Mar  3 04:54 core.14723
-rw------- 1 admin admin 1.3G Mar  3 12:55 core.24189

204 obproxy

ll -h /home/admin/obproxy/ | grep 'Mar  3'
-rw------- 1 admin admin 1.5G Mar  3 04:54 core.178091

215 obproxy

ll -h /home/admin/obproxy/ | grep 'Mar  3'
-rw------- 1 admin admin 1.4G Mar  3 17:22 core.414236
-rw------- 1 admin admin 1.2G Mar  3 04:55 core.418686

mysql->OB drc同步中断

目标端 执行sql出现错误!io.ReadFull(header) failed. err EOF: connection was bad,Table [biz_trace_log -> biz_trace_log]

生产环境低版本没自动重启过

obproxy 4.2.3

observer 4.2.2

测试环境有obbinlog，日志里有同步obbinlog连接失败，是否和这连接失败有关？

obproxy日志

obproxy.log 日志看不出异常

less obproxy_error.log 有大量同步binlog连接失败

2025-03-03 12:55:55.769488,myproxy2,,,,obtest42:mysql:,OB_MYSQL,,,OB_MYSQL_COM_LOGIN,,failed,1045,,1763us,452us,0us,1247us,Y0-00007F99F0CD5390,,xxxxx.131.130:27904,,0,xxxxx.183.204:2881,Access denied for us
er '这是同步binlog账号'@'xxx.xxx.xxx.xxx' (using password: YES),
2025-03-03 12:55:55.869378,myproxy2,,,,obtest42:mysql:,OB_MYSQL,,,OB_MYSQL_COM_LOGIN,,failed,1045,,1941us,463us,0us,1419us,Y0-00007F99F0ED51D0,,xxxxx.131.130:27908,,0,xxxxx.183.204:2881,Access denied for us
er '这是同步binlog账号'@'xxx.xxx.xxx.xxx' (using password: YES),
2025-03-03 12:55:55.969409,myproxy2,,,,obtest42:mysql:,OB_MYSQL,,,OB_MYSQL_COM_LOGIN,,failed,1045,,1749us,435us,0us,1258us,Y0-00007F99F0CD5390,,xxxxx.131.130:27912,,0,xxxxx.183.204:2881,Access denied for us
er '这是同步binlog账号'@'xxx.xxx.xxx.xxx' (using password: YES),
2025-03-03 12:55:56.045737,myproxy2,,,,obtest42:mysql:,OB_MYSQL,,,OB_MYSQL_COM_LOGIN,,failed,1045,,1777us,388us,0us,1320us,Y0-00007F99F0ED51D0,,xxxxx.131.130:27930,,0,xxxxx.183.201:2881,Access denied for us
er '这是同步binlog账号'@'xxx.xxx.xxx.xxx' (using password: YES),
2025-03-03 12:55:56.046422,myproxy2,,,,obtest42:mysql:,OB_MYSQL,,,OB_MYSQL_COM_LOGIN,,failed,1045,,1551us,243us,0us,1244us,Y0-00007F99F0CD5390,,xxxxx.131.130:27920,,0,xxxxx.183.201:2881,Access denied for us
er '这是同步binlog账号'@'xxx.xxx.xxx.xxx' (using password: YES),
2025-03-03 12:55:56.129619,myproxy2,,,,obtest42:mysql:,OB_MYSQL,,,OB_MYSQL_COM_LOGIN,,failed,1045,,1868us,395us,0us,1400us,Y0-00007F99F0ED51D0,,xxxxx.131.130:27932,,0,xxxxx.183.201:2881,Access denied for us
er '这是同步binlog账号'@'xxx.xxx.xxx.xxx' (using password: YES),
2025-03-03 12:55:56.245444,myproxy2,,,,obtest42:mysql:,OB_MYSQL,,,OB_MYSQL_COM_LOGIN,,failed,1045,,1783us,470us,0us,1254us,Y0-00007F99F0CD5390,,xxxxx.131.130:27940,,0,xxxxx.183.204:2881,Access denied for us
er '这是同步binlog账号'@'xxx.xxx.xxx.xxx' (using password: YES),
2025-03-03 12:55:56.326802,myproxy2,,,,obtest42:mysql:,OB_MYSQL,,,OB_MYSQL_COM_LOGIN,,failed,1045,,1949us,457us,0us,1435us,Y0-00007F99F0ED51D0,,xxxxx.131.130:27944,,0,xxxxx.183.215:2881,Access denied for us
er '这是同步binlog账号'@'xxx.xxx.xxx.xxx' (using password: YES),
2025-03-03 12:55:56.393855,myproxy2,,,,obtest42:mysql:,OB_MYSQL,,,OB_MYSQL_COM_LOGIN,,failed,1045,,1761us,474us,0us,1220us,Y0-00007F99F0CD5390,,xxxxx.131.130:27952,,0,xxxxx.183.204:2881,Access denied for us
er '这是同步binlog账号'@'xxx.xxx.xxx.xxx' (using password: YES),
2025-03-03 12:55:56.393855,myproxy2,,,,obtest42:mysql:,OB_MYSQL,,,OB_MYSQL_COM_LOGIN,,failed,1045,,1707us,411us,0us,1220us,Y0-00007F99F0ED51D0,,xxxxx.131.130:27948,,0,xxxxx.183.204:2881,Access denied for us
:

obbinlog日志

cd /data/binlogservice/log
[root@xxxx-0005 log]# ll -h
total 1.5G
-rw-r--r-- 1 root root 2.2K Feb 27 11:13 deploy.log
-rw-r--r-- 1 root root 3.0K Feb 27 11:13 logproxy.20250227.111312104.log.gz
-rw-r--r-- 1 root root 993M Mar  4 12:13 logproxy.log
-rw-r--r-- 1 root root 4.4K Feb 27 11:13 out.log
[root@xxxx-0005 log]# 
[root@xxxx-0005 log]# grep -i 'error|ediag'  ./*.log

该mysql2租户 binlog实例里有warning日志，没有error|ediag级别日志

cd /data/binlogservice/run/sx8day4gzh/log

[root@xxxxx-0005 log]# grep -i 'error|ediag'  ./*.log
[root@xxxxx-0005 log]# 
[root@xxxxx-0005 log]# 

grep -v 'info'  binlog_instance.log | less
[2025-03-04 12:15:35.033612] [warning] binlog_dumper.cpp(855): [f67e3dea607b623dda281311b7d1c5bf][OBI][ddw_replica@mysql2#obtest42,obtest42,mysql2]xxxxx.131.151:8100-xxxxx.183.204:40322/118: The content of the current binlog event is incomplete, and the expected file length is 208556047
[2025-03-04 12:15:35.034474] [warning] binlog_dumper.cpp(855): [8948c154b6ea51cd54ceff9214766f1c][OBI][ddw_replica@mysql2#obtest42,obtest42,mysql2]xxxxx.131.151:8100-xxxxx.183.204:49428/103: The content of the current binlog event is incomplete, and the expected file length is 208567980
[2025-03-04 12:15:35.034900] [warning] binlog_dumper.cpp(837): [a5c06657d1105d1a8b17175aa322ec][OBI][ddw_replica@mysql2#obtest42,obtest42,mysql2]xxxxx.131.151:8100-xxxxx.183.201:63690/87: The content of the current binlog event header is incomplete, and the expected file length is 208580617,the actual value is 208580608
[2025-03-04 12:16:54.914687] [warning] binlog_dumper.cpp(855): [9d2ade96f2a27c73db10b44357e58213][OBI][ddw_replica@mysql2#obtest42,obtest42,mysql2]xxxxx.131.151:8100-xxxxx.183.204:40318/109: The content of the current binlog event is incomplete, and the expected file length is 208621576
[2025-03-04 12:18:00.272953] [warning] binlog_dumper.cpp(837): [90fd18283623a1f6c45479a42ec5c5a][OBI][ddw_replica@mysql2#obtest42,obtest42,mysql2]xxxxx.131.151:8100-xxxxx.183.201:62078/102: The content of the current binlog event header is incomplete, and the expected file length is 208629771,the actual value is 208629760

binlog_instance_libobcdc.tar.gz (11.5 MB)

201_obproxy_crash.log (19.6 MB)
core.23577.tar.gz (38.3 MB)

gdb分析的03,04号重启时的core文件结果

gdb-output03_23_46.log (6.8 KB)
gdb-output04_15_47.log (6.8 KB)

obinlog服务器信息
cat /etc/issue
\S
Kernel \r on an \m

uname -r
5.4.210-4.ve1.x86_64

cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)

---

obproxy服务器信息
uname -r
3.10.0-957.el7.x86_64

cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)

cat /etc/issue
\S
Kernel \r on an \m

[论坛小助手]

根据文档库中的信息，您的 OBProxy 自动重启问题可能与以下几种情况有关：

1. 内存不足导致 OBProxy 进程频繁 OOM 退出：

   • 根据片段标题: ODP 端故障 → 应急处理步骤 的描述，如果 OBProxy 内存使用超过 proxy_mem_limited 参数设定的限制（默认为800MB），OBProxy 进程会主动退出。您可以检查 OBProxy 日志中是否有类似 obproxy's memory is out of limit's 90% 的报错信息。
   • 解决方案：可以尝试调整 proxy_mem_limited 参数值到更高的数值，例如2GB或8GB，具体命令如下：

     ALTER proxyconfig SET proxy_mem_limited = 2G;
     

     或者对于云平台部署的 OBProxy，可以调整到8GB。

2. 守护进程异常，OBProxy 无法自动重启：

   • 如果是守护进程的问题，您需要手动重启 OBProxy。请确认守护进程是否正常工作，或者是否存在其他外部因素影响了 OBProxy 的正常运行。

3. 高 QPS/TPS 下的性能瓶颈：

   • 您提到业务测试环境的 QPS 和 TPS 较高（约3K），这可能导致 OBProxy 在处理大量请求时出现性能瓶颈，进而触发自动重启。建议监控 OBProxy 的资源使用情况（如 CPU、内存、网络等），以确定是否存在性能瓶颈。

4. 同步 binlog 连接失败：

   • 您提供的日志显示有大量的同步 binlog 连接失败记录，错误信息为 Access denied for user 'ddw_replica'@'xxx.xxx.xxx.xxx' (using password: YES)。这表明 OBProxy 尝试连接 MySQL 实例时遇到了权限问题，可能是由于用户名或密码配置不正确，或者是 MySQL 实例对 OBProxy 的访问进行了限制。
   • 解决方案：请检查并确保 OBProxy 和 MySQL 实例之间的连接配置正确无误，特别是用户名和密码的设置。同时，确认 MySQL 实例允许来自 OBProxy IP 地址的连接。

5. 核心文件分析：

   • 您提供了多个日期的核心文件（core dump），这些文件可以帮助进一步诊断 OBProxy 崩溃的原因。建议使用调试工具（如 GDB）对这些核心文件进行分析，以获取更多崩溃原因的信息。

综上所述，建议您首先检查 OBProxy 的内存使用情况，并适当调整 proxy_mem_limited 参数。其次，确保 OBProxy 和 MySQL 实例之间的连接配置正确。最后，利用核心文件进行更深入的崩溃原因分析。如果问题仍然存在，建议联系 OceanBase 技术支持团队获取进一步的帮助。

检索到的文档如下:

1. ODP 端故障
2. 重启 OBProxy 集群下全部 OBProxy
3. 容灾架构及容灾级别
4. 4000 ~ 4499
5. 4500 ~ 4999
6. fast_recovery_concurrency
7. 日志同步问题
8. 9000 ~ 9499

[淇铭]

在生成core文件的那台机器上 收集一下堆栈
安装步骤：

1. 如果有gdb，并且版本比较低，需要先卸载
2. 安装依赖
   yum install gcc-c++ -y
   yum install texinfo -y
3. 下载 gdb
   wget https://ftp.gnu.org/gnu/gdb/gdb-9.1.tar.gz
4. 解压安装
   tar -zxvf gdb-9.1.tar.gz
   cd gdb-9.1.tar.gz
   mkdir build
   cd build
   …/configure
   make
   make install
   cp gdb/gdb /usr/bin
5. 确认安装完成
   gdb --version
   收集堆栈
   gdb $observer $core_file
   举例：gdb bin/observer core.28031
   –在进入交互界面之后
   set logging file /home/admin/oceanbase/gdb-output
   set logging on
   set pagination off
   set print pretty on
   set print elements 0
   bt
   bt full
   info r
   info thread
   set logging off
   quit

gdb 调试文件会被记录到 /home/admin/oceanbase/gdb-output中

[try_again]

你好，从描述来看，结合会话说有突降，可能是OB高负载下，撑爆了obporxy服务的内存，导致重启，可以看下obporxy日志
grep ‘obproxy’s memroy is out of limit’s’ /home/admin/obporxy/log/obproxy.log.20250304*
看下有无信息

[jiaxin666]

已上传在帖子

[辞霜]

收到，这边先找下内核同学帮忙看下

[jiaxin666]

不是引起问题

[论坛小助手]

根据您提供的信息和上传的图片，特别是核心文件（core dump）分析结果以及 OBProxy 日志，我们可以进一步深入分析 OBProxy 自动重启的问题。以下是详细的分析和建议：

1. 核心文件分析

从您提供的 gdb 分析日志 (gdb-output03_23_46.log 和 gdb-output04_15_47.log) 中，我们需要查看具体的崩溃堆栈信息以确定 OBProxy 崩溃的原因。请提供这些日志的具体内容或关键部分，以便我们能够更准确地定位问题。

2. OBProxy 日志分析

从您提供的 OBProxy 日志片段中，可以看到以下关键信息：

• OBProxy 在处理大量连接时出现了错误，例如 bad_request 和 kill_this 的日志记录。
• 连接 MySQL 实例时频繁出现 Access denied for user 'ddw_replica'@'xxx.xxx.xxx.xxx' (using password: YES) 错误。

具体日志片段：

[2025-03-03 12:54:00.035004] INFO  [PROXY.TXN] bad_request (ob_mysql_transact.cpp:159) [24216][Y0-00007F2F6D186590] [lt=0] [dc=0] [ObMysqlTransact::bad_request] parser marked request bad
[2025-03-03 12:54:00.035007] INFO  [PROXY.SM] setup_error_transfer (ob_mysql_sm.cpp:9790) [24216][Y0-00007F2F6D186590] [lt=0] [dc=0] setup_error_transfer, transfer internal buffer and try to disconnect(sql_cmd=242, internal_state=0)
[2025-03-03 12:54:00.035037] INFO  [PROXY.SM] kill_this (ob_mysql_sm.cpp:10463) [24216][Y0-00007F2F6D186590] [lt=0] [dc=0] will deallocate sm(sm_id=359131, pending_action=NULL, api_.callout_state=0, trans_state_.trace_log= | dropped=0)

这些日志表明 OBProxy 在处理某些请求时遇到了解析错误，并尝试断开连接。这可能是由于客户端发送了不合法的 SQL 请求或其他协议违规行为。

3. 同步 binlog 连接失败

您提到的 obproxy_error.log 中有大量的 Access denied 错误，这表明 OBProxy 尝试连接 MySQL 实例时遇到了权限问题。具体错误如下：

Access denied for user '这是同步binlog账号'@'xxx.xxx.xxx.xxx' (using password: YES)

解决方案：

1. 检查用户名和密码：确保 OBProxy 配置文件中的用户名和密码与 MySQL 实例中的配置一致。
2. 确认 MySQL 用户权限：确保 MySQL 实例中的用户具有足够的权限来执行所需的 binlog 同步操作。可以使用以下命令检查并授予权限：

   GRANT REPLICATION SLAVE ON *.* TO 'ddw_replica'@'xxx.xxx.xxx.xxx' IDENTIFIED BY 'your_password';
   FLUSH PRIVILEGES;
   

3. 网络防火墙设置：确保 MySQL 实例允许来自 OBProxy IP 地址的连接，检查防火墙规则是否正确配置。

4. 内存和性能瓶颈

考虑到您的业务测试环境 QPS 达到约 3K，OBProxy 可能存在内存和性能瓶颈。您可以采取以下措施：

• 调整 proxy_mem_limited 参数：如前所述，适当增加 proxy_mem_limited 参数值，以避免因内存不足导致的 OOM 退出。
• 监控资源使用情况：使用工具（如 top、htop 或 vmstat）监控 OBProxy 的 CPU、内存和网络使用情况，确保其在高负载下仍能正常运行。

5. 进一步诊断

如果上述措施未能解决问题，建议进行更深入的诊断：

• 启用调试日志：将 OBProxy 的日志级别调整为 DEBUG，以便捕获更多详细信息。
• 分析核心文件：使用 GDB 对核心文件进行详细分析，查找崩溃的具体原因。您可以使用以下命令加载核心文件并分析堆栈：

  gdb /path/to/obproxy /path/to/corefile
  (gdb) bt full
  

总结

综上所述，OBProxy 自动重启问题可能由多个因素引起，包括内存不足、权限配置错误、性能瓶颈等。建议您首先检查并解决同步 binlog 连接失败的问题，确保 OBProxy 和 MySQL 实例之间的连接配置正确。同时，监控 OBProxy 的资源使用情况，并根据需要调整相关参数。如果问题仍然存在，请继续分析核心文件并联系 OceanBase 技术支持团队获取进一步帮助。

如果您有更多日志或核心文件分析结果，请提供详细信息，以便我们能够更准确地定位问题。

更多信息请查看:

1. OceanBase 数据库代理社区版 V4.2.0
2. OceanBase 数据库代理社区版 V4.0.0
3. 使用 OceanBase 导数工具在 OceanBase 集群 MySQL 租户间迁移数据
4. 问题排查思路
5. Alert 日志
6. OceanBase 数据库代理社区版 V4.2.1
7. 遇到问题如何向技术支持同学提问
8. 使用 OceanBase 导数工具从 OceanBase 集群 Oracle 租户迁移数据到 MySQL 租户
9. 内存诊断
10. 使用 OCP 部署 ODP

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

[AntTech_J7SO4J]

麻烦再 ./obproxy -V 查看下 obproxy 版本

cat /etc/issue

[try_again]

ok，那得分析core文件看原因了

[jiaxin666]

cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)

cat /etc/issue
\S
Kernel \r on an \m

/home/admin/obproxy/bin/obproxy -V
obproxy (OceanBase 4.3.3.0 5)
REVISION: 1-local-60ff90081edf7829e4f6458adb6d1184c3344b80
BUILD_TIME: Jan 21 2025 17:32:47
BUILD_FLAGS: -g -O2 -D_OB_VERSION=1000 -D_NO_EXCEPTION -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -D__USE_LARGEFILE64 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Wformat -Wno-deprecated -Wno-invalid-offsetof -finline-functions -fno-strict-aliasing -mtune=core2 -Wno-psabi -Wno-address-of-packed-member -fno-omit-frame-pointer -Wl,-z,noexecstack,-z,relro,-z,now,-z,notext -fPIC -isystem /home/jenkins/agent/workspace/ob_artifacte_local_artifact/ob_source_code_dir/obproxy-tmp.140/BUILD/obproxy-ce-4.3.3.0/deps/3rd/usr/local/oceanbase/deps/devel/include -isystem /home/jenkins/agent/workspace/ob_artifacte_local_artifact/ob_source_code_dir/obproxy-tmp.140/BUILD/obproxy-ce-4.3.3.0/deps/3rd/usr/include -L/home/jenkins/agent/workspace/ob_artifacte_local_artifact/ob_source_code_dir/obproxy-tmp.140/BUILD/obproxy-ce-4.3.3.0/deps/3rd/usr/local/oceanbase/deps/devel/lib -D_GLIBCXX_USE_CXX11_ABI=0 -DBUILD_OPENSOURCE -DSUPPORT_SSE4_2 -DHAVE_SCHED_GETCPU -DHAVE_REALTIME_COARSE -DOB_HAVE_EVENTFD -DHAVE_FALLOCATE -fuse-ld=lld -Wall -Wextra -Wno-ignored-qualifiers -Wno-deprecated-copy -Wno-sign-compare -Wno-varargs -Wno-overloaded-virtual -Wno-sign-conversion -Wno-string-plus-int -Wno-shorten-64-to-32 -Wno-delete-non-abstract-non-virtual-dtor -Wno-overloaded-virtual -Wno-unused-command-line-argument -Wno-inconsistent-missing-override -Wno-mismatched-tags -Wno-dynamic-class-memaccess -Wno-format-security -Wno-reinterpret-base-class -Wl,–allow-multiple-definition --gcc-toolchain=/home/jenkins/agent/workspace/ob_artifacte_local_artifact/ob_source_code_dir/obproxy-tmp.140/BUILD/obproxy-ce-4.3.3.0/deps/3rd/usr/local/oceanbase/devtools

[淇铭]

确定是obproxy的bug，在某些异常场景缺乏防御导致core的问题

[mittens]

来学一下故障诊断与排查