作者：马顺华
从事运维管理工作多年，目前就职于某科技有限公司，熟悉运维自动化、OceanBase部署运维、MySQL 运维以及各种云平台技术和产品。并已获得OceanBase认证OBCA、OBCP 证书、OpenGauss社区认证结业证书。OceanBase & 墨天轮第二、三、四、五届技术征文大赛，多次获得 一、二、三 等奖，时常在墨天轮发布原创技术文章，并多次被首页推荐。
前言
分布式数据库，面临五大运维管理挑战
想要解决分布式数据库的运维管理难题，首先就需要了解分布式数据库运维管理目前面临哪些新挑战？据皇甫晓飞介绍，第一面临的是安全问题，只要能访问数据库的，以及数据库的特定操作，特别是一些特权操作，要能够进行审计，保证安全。
第二是可用性问题。当数据库出现故障的时候，要求能够快速恢复，满足行业和监管的要求。
第三是数据库性能问题，最好是要有一套完整的故障处理流程和方法论，运维人员通过我们的知识库、用户手册以及借助我们的数据库运维工具，能够快速分析处理问题。
第四则是能够对性能以及容量进行评估，要保证客户项目的运营。
第五，如何更好的满足，特别是金融行业，能够满足监管的要求和业务的变化。金融行业根据自身的特点，每年或者甚至每个季度都有一些业务的变化，而且要符合监管机构的要求，应对这个复杂多变的金融场景。
一、故障追踪与定位
本篇将继续数据库运维的话题，展开对故障追踪与定位能力的讨论。首先让我们看下这样一个场景:
业务部门：数据库查询请求好慢，可以看看哪里出问题了吗？
DBA 查看数据库节点实时监控
DBA：我在数据库节点的实时监控并未发现很慢的 SQL。
业务部门：那是怎么回事？
DBA：可能是客户端到数据库节点这一链路有问题，我来看一下中间代理服务器的日志。
DBA 开始查询日志，1 hour later……
DBA：从代理服务器日志看耗时也是正常的。可能是客户端到代理服务器的网络问题？
……
上文描述的是分布式数据库下运维遇到慢 SQL 时的场景，如果运维无法及时找出问题原因，就会非常影响使用体验，甚至导致业务服务不可用。因此，如何提供简单、高效的诊断能力，一直是我们思考的问题。相比单机数据库，分布式数据库系统涉及多个节点、多组件协同工作，集群规模可能达到几十、上百台服务器，用户请求链路会更加复杂，要实现快速高效地问题诊断与定位也会更有挑战。
OceanBase 4.0 在诊断能力方面有了显著提升，其中包括首次实现对 SQL 请求的可视化全链路追踪，能够帮助用户快速追踪并定位具体问题发生在哪个执行阶段、哪台机器以及哪个模块，并提供具体的相关执行信息，为用户提供简单、高效的运维体验。本文将分享我们对数据库高效诊断的思考，介绍 OceanBase 全链路追踪能力及设计思路：
在 OceanBase 中，当用户发起一个请求后，首先会被发送给 OBProxy（SQL请求代理），由 OBProxy 路由转发到 OceanBase 集群，进入集群中的某一个 OBServer 节点，随后会经过 SQL 引擎、存储引擎、事务引擎等（不同的请求会涉及不同引擎中的诸多处理模块），该请求也有可能通过 rpc 任务访问多个 OBServer 节点的数据，最终将结果返回给客户端。
图1 OceanBase SQL请求执行过程示意图
当用户请求出现报错或者执行慢的问题时, 可能是请求执行过程中的某个组件问题，也可能是不同组件节点间的网络等问题。在 4.0 之前的版本中，OceanBase 已经为用户提供了较为完善的监控和诊断能力，包括 SysStat、Sql Audit、Trans Stat、Tenant Dump、Slow Trans、Slow Query 等，OceanBase 运维平台（OCP）根据上述监控输出的信息实现了白屏化监控和诊断，包括事务诊断、TopSQL 诊断、SlowSQL 诊断等。但这些诊断能力缺乏请求全链路视角的信息, 导致往往定位问题发生在哪个执行阶段、哪个机器以及哪个模块就花费了很多时间；有时甚至需要各组件专家一起参与排查才能定位，影响运维人员对问题快速诊断和恢复的效率。
为进一步提高分布式场景下用户请求问题诊断效率, OceanBase 实现了全链路追踪机制, 能够追踪用户 SQL 请求在数据库全链路过程中，在不同阶段、不同组件执行的相关信息，并以可视化方式展现给用户，从而帮助用户快速定位问题所在位置。
▋ 事务 + SQL 维度的全链路追踪
OceanBase 提供了面向用户的事务 + SQL 维度的全链路追踪能力。对于业务部门而言，更关心的往往是一笔业务服务总的耗时情况。例如在 OLTP 系统中，一笔业务服务一般由一个或多个事务组成。因此，我们把事务作为追踪单位会更贴合用户的实际业务，一个事务形成一个追踪的 Trace，并对事务中每条 SQL 请求记录 OBClient -> OBProxy -> OBServer 内部全链路过程中相关执行信息，用户可以通过一个 Trace 快速找到该事务执行了哪些语句，以及这些语句从客户端视角看到的执行情况。
在实际业务中，一旦用户发现有慢的 SQL 请求，或者存在某个慢的事务，可以从慢 SQL 的整个执行链路中快速定位是哪个执行阶段慢。又或者在某个事务中，如果发现一个 SQL 结束到另一个 SQL 再发起之间的时间较长，则可请业务同学查看业务逻辑侧可能存在的问题。
▋ 支持分布式环境下的全链路追踪
OceanBase 支持分布式环境下的全链路追踪能力。首先，OceanBase 作为一个分布式系统，当 OBProxy 接收到一个客户端请求后，有可能会将其路由到 OBServer 集群中任意一台 OBServer 上。同时，该请求涉及到的数据可能分布在不同的 OBServer 中。具体到 SQL 执行阶段，执行引擎会向不同的 OBServer 发送执行子任务 task，当 OBServer 数量很多时，这些 SQL 请求和 Task 具体是在哪个 Server上执行？Server 内具体各模块执行的耗时情况是怎样的？都会困扰运维人员。
全链路追踪机制实现了 SQL 请求在分布式场景下，涉及多 Server 时完整执行链路的追踪。用户能够直观地看到是哪个 OBServer 上接收请求，哪个 OBServer 上执行远程 task，每个 task 的调度情况，以及执行耗时等信息。
二、运维管理-日常巡检
日常巡检概述
介绍日常对 OceanBase 集群进行巡检应该检查的事项，包含 OceanBase 集群的核心指标，范围涉及性能、可用性、资源水位和数据备份。为了及时发现和修复 OceanBase 的隐患，建议您重点关注 OceanBase 的日常巡检结果。
1、检查集群状态
OceanBase 数据库支持对集群的运行状态和合并状态检查，集群运行状态检查会全面排查集群的运行情况，针对有异常的地方产生相应的异常报告，您可以根据巡检报告查看异常项，并进行相应处理；合并状态检查会查看合并状态是否健康，异常会导致基线数据和增量数据无法合并，因此需要关注。
通过视图查看集群合并状态，查看所有返回记录中 merge_status 的状态。
obclient [oceanbase]> SELECT status FROM oceanbase.DBA_OB_ZONES;
+--------+
| status |
+--------+
| ACTIVE |
| ACTIVE |
| ACTIVE |
+--------+
3 rows in set (1.917 sec)
obclient [oceanbase]>
2、检查集群参数
OceanBase 数据库支持对集群最佳实践的参数进行检查。在问题分析阶段，您可通过检查集群参数来进行问题排查，您可以修改日志打印级别来获取更多的参数日志信息，待问题确定并修复后，请修改回原来的参数。
通过 SQL 语句修改集群参数
集群参数即配置项，修改配置项的语法如下所示，同时修改多个系统配置项时，请用逗号（,）分隔。
ALTER SYSTEM SET param_name = expr
[COMMENT 'text']
[PARAM_OPTS]
[TENANT = 'test_tenant']
PARAM_OPTS:
[ZONE='zone' | SERVER='server_ip:rpc_port']
参数修改语句说明如下：
PARAM_OPTS 修改配置项时所指定的其它限定条件，例如，指定 Zone、指定 Server 等。
ALTER SYSTEM 语句不能同时指定 Zone 和 Server。并且在指定 Zone 时，仅支持指定一个 Zone；指定 Server 时，仅支持指定一个 Server。
集群级别的配置项（Scope) 不能通过普通租户设置，也不可以通过 sys 租户指定普通租户来设置。例如，ALTER SYSTEM SET memory_limit=‘100G’ TENANT=‘test_tenant’ 将导致报错，因为 memory_limit 是集群级别（Scope）的配置项。
3、检查主机状态
OceanBase 数据库该检查项支持对主机状态进行检查，包括不限于磁盘水位、主机时间和主机负载。
3.1 检查租户资源使用状态
OceanBase 数据库支持对租户资源使用进行检查，包括不限于 CPU 、内存、副本数和磁盘。
通过 SQL 命令查看租户资源的使用情况
obclient [oceanbase]> SELECT t1.tenant_name,concat(svr_ip,":",svr_port) as "unit_server",t3.max_cpu,t3.min_cpu FROM OCEANBASE.DBA_OB_TENANTS t1,OCEANBASE.DBA_OB_UNITS t2,OCEANBASE.DBA_OB_UNIT_CONFIGS t3,OCEANBASE.DBA_OB_RESOURCE_POOLS t4
-> where t1.tenant_id = t4.tenant_id
-> AND t4.resource_pool_id=t2.resource_pool_id
-> AND t4.unit_config_id=t3.unit_config_id
-> ORDER BY t1.tenant_name;
+--------------+-------------------+---------+---------+
| tenant_name | unit_server | max_cpu | min_cpu |
+--------------+-------------------+---------+---------+
| sys | 10.0.0.0:7702 | 1 | 1 |
| sys | 10.0.0.0:7702 | 1 | 1 |
| sys | 10.0.0.0:7702 | 1 | 1 |
| test_tenant | 10.0.0.0:7702 | 2 | 2 |
| test_tenant | 10.0.0.0:7702 | 2 | 2 |
| test_tenant | 10.0.0.0:7702 | 2 | 2 |
| test_tenant2 | 10.0.0.0:7702 | 1 | 1 |
| test_tenant2 | 10.0.0.0:7702 | 1 | 1 |
| test_tenant2 | 10.0.0.0:7702 | 1 | 1 |
+--------------+-------------------+---------+---------+
9 rows in set (0.090 sec)
obclient [oceanbase]>
3.2 检查集群资源使用状态
OceanBase 数据库支持对集群资源使用进行检查，包括不限于 CPU 、内存、副本数和磁盘。
通过 SQL 命令查看集群资源的使用情况
obclient [oceanbase]> SELECT * FROM GV$OB_SERVERS LIMIT 2;
+--------------+----------+-------+----------+--------------+------------------+--------------+------------------+--------------+--------------+-------------------+-------------------+-----------------+--------------------+------------------+-------------------------+--------------+-------------------------+-----------------------+
| SVR_IP | SVR_PORT | ZONE | SQL_PORT | CPU_CAPACITY | CPU_CAPACITY_MAX | CPU_ASSIGNED | CPU_ASSIGNED_MAX | MEM_CAPACITY | MEM_ASSIGNED | LOG_DISK_CAPACITY | LOG_DISK_ASSIGNED | LOG_DISK_IN_USE | DATA_DISK_CAPACITY | DATA_DISK_IN_USE | DATA_DISK_HEALTH_STATUS | MEMORY_LIMIT | DATA_DISK_ABNORMAL_TIME | SSL_CERT_EXPIRED_TIME |
+--------------+----------+-------+----------+--------------+------------------+--------------+------------------+--------------+--------------+-------------------+-------------------+-----------------+--------------------+------------------+-------------------------+--------------+-------------------------+-----------------------+
| 172.20.2.120 | 2882 | zone1 | 2881 | 16 | 16 | 4 | 4 | 8589934592 | 8589934592 | 53687091200 | 6442450944 | 5100273664 | 53687091200 | 14474543104 | NORMAL | 17179869184 | NULL | NULL |
| 172.20.2.121 | 2882 | zone2 | 2881 | 16 | 16 | 4 | 4 | 8589934592 | 8589934592 | 53687091200 | 6442450944 | 5100273664 | 53687091200 | 14480834560 | NORMAL | 17179869184 | NULL | NULL |
+--------------+----------+-------+----------+--------------+------------------+--------------+------------------+--------------+--------------+-------------------+-------------------+-----------------+--------------------+------------------+-------------------------+--------------+-------------------------+-----------------------+
2 rows in set (0.070 sec)
obclient [oceanbase]>
3.3 检查 OBServer 状态
OceanBase 数据库支持对 OBServer 的状态检查，包括进程是否存在、副本数等。
通过宿主机查看 OBServer 状态
登录 OBServer 所在的宿主机。
在命令行工具中运行以下命令查看 observer 进程。
Bye
[root@CAIP131 ~]# ps -ef |grep observer
root 37148 31476 0 16:56 pts/0 00:00:00 grep --color=auto observer
[root@CAIP131 ~]#
通过视图查看 OBServer 状态
obclient [oceanbase]> SELECT status FROM oceanbase.DBA_OB_SERVERS;
+--------+
| status |
+--------+
| ACTIVE |
| ACTIVE |
| ACTIVE |
+--------+
3 rows in set (0.039 sec)
obclient [oceanbase]>
如果返回结果为 active，说明 OBServer 处于正常运行状态。
如果返回结果为 inactive，说明 OBServer 处于下线状态。
如果返回结果为 deleting，说明 OBServer 处于正在被删除状态。
4、检查 NTP 偏移量
OceanBase 数据库支持对主机 NTP 偏移量的检查，OceanBase 集群主机节点的 NTP 偏移量如果相差太大，可能会导致选主异常。
网络时间协议 (Network Time Protocol，NTP )，可通过网络同步计算机系统之间的时钟。NTP 服务器可使组织中的所有服务器的时间保持同步。
OceanBase 数据库是一个分布式数据库，故集群的多个节点以及 OCP 节点的时钟必须配置时钟同步服务 NTP 或者 chrony，保证所有节点的时钟偏差在 100ms 以内。
运行 OBServer 的服务器上，系统时间是通过 NTP 服务进行同步的，但是当时间差过大的情况下，NTP 服务不会更改和矫正系统时间。如果集群时间不同步，则可能影响 OceanBase 集群的选举模块，导致没有主副本或者脑裂。本文主要介绍如何调整 OBServer 的操作系统时间。
通过宿主机查看
您可执行以下命令来检查时钟偏移量。
[root@hostname /]# ntpq -p|grep -E "\*|\=|remote"
remote refid st t when poll reach delay offset jitter
==========================================================================
xxxxxxxxxxx xxxxx 2 u 16 64 377 1.333 0.046 0.033
注意
检查 NTP 同步的 offset，应保证 ntpq 的 offset 值小于 50ms。
5、检查数据备份
OceanBase 数据库支持对备份的检查，包括备份成功与否、备份速度和备份进度。
日志备份开始后，您可以发起数据备份。
前提条件
在执行数据备份前，您需要进行以下事项：
确认当前已发起日志备份，仅当日志备份任务的 STATUS 为 DOING 时，才能开始数据备份。
发起日志备份的相关操作请参见 发起日志备份。
备份准备（可选）
发起数据备份前，您可以为备份后的备份集设置密码。
使用 root 用户登录到数据库的 sys 租户。
（可选）执行以下命令，设置备份的密码。
说明
该密码为备份后的备份集的密码。如果设置了该选项，在使用该备份集进行恢复时，需要输入该密码，且该密码不能被删除。
obclient> SET ENCRYPTION ON IDENTIFIED BY 'password' ONLY;
发起全量备份
完成准备工作后，您可以通过以下方式开启全量数据备份。
假设当前集群中有 3 个租户，分别是 sys、mysql_tenant 和 oracle_tenant，且租户 mysql_tenant 和 oracle_tenant 均已完成发起数据备份前的准备工作。
用户租户发起全量备份
用户租户可以对本租户发起全量数据备份，不会影响其他租户。
租户管理员登录到相应的租户。
本示例中，您可以使用 root 用户登录 mysql_tenant 租户；或者也可以使用 sys 用户登录 oracle_tenant 租户。
执行以下语句，对-uroot@test_tenant发起全量数据备份。
obclient> ALTER SYSTEM BACKUP DATABASE;
系统租户发起全量备份
sys 租户可以对集群中的所有租户或指定租户发起全量数据备份。
使用 root 用户登录到数据库的 sys 租户。
执行以下语句，发起全量数据备份。
对集群中的所有租户发起全量数据备份
该方式会对集群中的所有租户发起全量数据备份。
obclient> ALTER SYSTEM BACKUP DATABASE;
命令执行成功后，在本示例中，系统会对集群中的 mysql_tenant 和 oracle_tenant 租户发起全量数据备份。
对集群中的指定租户发起全量数据备份
该方式仅对指定租户发起全量数据备份，不会影响集群中的其他租户。
对 mysql_tenant 租户发起全量数据备份的示例如下：
obclient> ALTER SYSTEM BACKUP TENANT = mysql_tenant;
说明
同时指定多个租户时，租户名之间使用英文逗号 (,) 分隔。
命令执行成功后，在本示例中，系统会对集群中的 mysql_tenant 租户发起全量数据备份。
6、租户内资源的扩容和缩容
通过修改 unit_config
对租户内资源的扩容和缩容可以通过修改 unit_config 即租户的资源单元配置来实现。
通过 SQL 语句修改租户的资源单元配置
在通过调大和调小租户资源单元的配置进行扩容和缩容时，有以下两种场景：
当前租户配置了独立的资源单元配置，可以直接修改租户的资源单元配置。
多个租户使用了相同的资源单元配置，需要切换租户的资源单元配置。
确认租户是否使用了独立的资源单元配置的操作如下：
使用 root 用户登录数据库的 sys 租户。
执行以下语句，获取待操作的租户所属的资源配置 ID。
obclient [oceanbase]> SELECT a.TENANT_NAME, b.UNIT_CONFIG_ID FROM oceanbase.DBA_OB_TENANTS a,oceanbase.DBA_OB_RESOURCE_POOLS b WHERE b.TENANT_ID=a.TENANT_ID;
+--------------+----------------+
| TENANT_NAME | UNIT_CONFIG_ID |
+--------------+----------------+
| sys | 1 |
| test_tenant | 1003 |
| test_tenant2 | 1004 |
+--------------+----------------+
3 rows in set (0.009 sec)
obclient [oceanbase]>
根据查询结果，如果当前租户对应的 UNIT_CONFIG_ID 与其他租户相同，则表示有多个租户使用了相同的资源单元配置；如果当前租户中对应的 UNIT_CONFIG_ID 与其他租户均不相同，则表示该租户使用了独立的资源单元配置。
以下将通过这两种场景提供租户扩容和缩容的操作指导。
租户配置了独立的资源单元配置的场景
如果待操作的租户配置了独立的资源单元配置，您可以直接通过修改租户的 unit_config 来完成租户的扩容和缩容。
执行以下语句，获取待操作租户的资源配置详细信息。
```language
obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_UNIT_CONFIGS WHERE UNIT_CONFIG_ID='1003';
+----------------+-------+----------------------------+----------------------------+---------+---------+-------------+---------------+----------+----------+-------------+
| UNIT_CONFIG_ID | NAME | CREATE_TIME | MODIFY_TIME | MAX_CPU | MIN_CPU | MEMORY_SIZE | LOG_DISK_SIZE | MAX_IOPS | MIN_IOPS | IOPS_WEIGHT |
+----------------+-------+----------------------------+----------------------------+---------+---------+-------------+---------------+----------+----------+-------------+
| 1003 | unit1 | 2023-03-19 11:35:40.215273 | 2023-03-19 13:03:08.574968 | 2 | 2 | 4294967296 | 2147483648 | 1024 | 1024 | 0 |
+----------------+-------+----------------------------+----------------------------+---------+---------+-------------+---------------+----------+----------+-------------+
1 row in set (0.018 sec)
obclient [oceanbase]>
根据获取的资源单元配置信息，修改 unit1 的配置。
查询结果显示，unit1 资源单元 CPU、内存使用的分别是 1 C，2 G。
调大 unit1 的配置 调整 unit1 资源单元 CPU、内存的使用大小为 2 c，4 G。
obclient [oceanbase]>
obclient [oceanbase]> ALTER resource unit unit1 max_cpu =2,min_cpu =2 ,memory_size ='4G';
Query OK, 0 rows affected (0.015 sec)
obclient [oceanbase]>
调小 unit1 的配置 调整 unit1 资源单元 CPU、内存的使用大小为 2 c，2 G。
obclient> ALTER resource unit unit1 max_cpu =2,min_cpu =2 ,memory_size ='2G';
检查
操作结束后，您可以通过 oceanbase.DBA_OB_UNIT_CONFIGS 视图，确认当前租户的 unit_config 是否修改成功。
obclient> SELECT * FROM oceanbase.DBA_OB_UNIT_CONFIGS;
7、通过调大租户的 UNIT_NUM 来进行租户的扩容。
背景信息
假设当前集群中包含 3 个可用区 z1、z2、z3，每个 Zone 内包含 3 台 OBServer。在集群中创建一个普通租户 MySQL，其资源分配情况如下：
obclient> CREATE RESOURCE UNIT unit1 MAX_CPU 6, MIN_CPU 6, MEMORY_SIZE '36G', MAX_IOPS 1024, MIN_IOPS 1024, IOPS_WEIGHT=0, LOG_DISK_SIZE '2G';
obclient> CREATE RESOURCE POOL pool1 UNIT 'unit1', UNIT_NUM 1, ZONE_LIST ('z1','z2','z3');
obclient> CREATE TENANT MySQL resource_pool_list=('pool1');
调大 UNIT_NUM
随着业务量的不断变大，每个 Zone 上 1 个 Unit 已经无法承载当前的业务量，因此需要考虑调大 UNIT_NUM 来提高租户的服务能力，以满足新的业务需求。
使用 root 用户登录到数据库的 sys 租户。
进入 oceanbase 数据库。
obclient>USE oceanbase;
执行以下语句，获取当前租户的资源配置信息。
obclient> SELECT a.TENANT_NAME, b.RESOURCE_POOL_ID,b.NAME resource_pool_name,b.UNIT_CONFIG_ID,b. UNIT_COUNT FROM oceanbase.DBA_OB_TENANTS a,oceanbase.DBA_OB_RESOURCE_POOLS b WHERE b.TENANT_ID=a.TENANT_ID;
+-------------+------------------+--------------------+----------------+------------+
| TENANT_NAME | RESOURCE_POOL_ID | resource_pool_name | UNIT_CONFIG_ID | UNIT_COUNT |
+-------------+------------------+--------------------+----------------+------------+
| sys | 1 | sys_pool | 1 | 1 |
| MySQL | 1001 | pool1 | 1001 | 1 |
| Oracle | 1002 | pool002 | 1002 | 1 |
+-------------+------------------+--------------------+----------------+------------+
3 rows in set
obclient> SELECT * FROM oceanbase.DBA_OB_UNIT_CONFIGS WHERE UNIT_CONFIG_ID='1003';
+----------------+-------+---------+---------+-------------+---------------+----------+----------+-------------+
| UNIT_CONFIG_ID | NAME | MAX_CPU | MIN_CPU | MEMORY_SIZE | LOG_DISK_SIZE | MAX_IOPS | MIN_IOPS | IOPS_WEIGHT |
+----------------+-------+---------+---------+-------------+---------------+----------+----------+-------------+
| 1001 | unit1 | 6 | 6 | 38654705664 | 2147483648 | 1024 | 1024 | 0 |
+----------------+-------+---------+---------+-------------+---------------+----------+----------+-------------+
1 row in set
执行以下语句，调大 UNIT_NUM 的数量。
说明
不支持通过指定 unit_id 的方式调大 UNIT_NUM 的数量。
obclient>ALTER RESOURCE TENANT MySQL UNIT_NUM = 2;
语句执行后，系统会直接在每个 Zone 内添加一个 Unit。
结语：
OceanBase 4.0 的全链路追踪能力实现了对每个事务、每条 SQL 请求的可观测性，提供了高效的问题诊断和定位能力。我们相信这一新能力将帮助用户更加快速地定位问题并解决问题, 从而带来更简单、更高效地数据库运维体验。作为改善 OceanBase 易用性的重要一环，我们也将在未来的 4.x 中着力提升运维体验，新增包括 ASH（Active Session History）、Realtime SQL Plan Monitor、Logical Plan Manager 等在内的更多功能。最后，欢迎大家在评论区留言，一起探讨对数据库问题诊断的看法。
