9、运维管理

9.1 租户扩容

参考文档：
1

2

9.1.1 通过修改 unit_config 实现租户扩缩容

给OB-MYSQL 扩容，由原来的2c3G到3C6G，会有资源不足，自己想办法，涉及到Unit 的迁移命令。

资源不足的话可以在OCP界面上把sys租户拖动到另一台服务器上。

参考文档：
3

-- 检查集群可分配资源
SELECT 
a.zone, 
CONCAT(a.svr_ip, ':', a.svr_port) observer, 
cpu_total, 
cpu_assigned, 
(cpu_total - cpu_assigned) cpu_free, 
mem_total / 1024 / 1024 / 1024 mem_total_gb, 
mem_assigned / 1024 / 1024 / 1024 mem_assign_gb, 
(mem_total - mem_assigned) / 1024 / 1024 / 1024 mem_free_gb 
FROM __all_virtual_server_stat a 
JOIN __all_server b ON (a.svr_ip = b.svr_ip AND a.svr_port = b.svr_port) 
ORDER BY a.zone, a.svr_ip;

-- 检查占用资源池未释放，排查tenant_id为NULL的记录，删除对应的资源池
SELECT tenant_id,resource_pool_id,name FROM oceanbase.__all_resource_pool limit 20;

-- 删除资源池
DROP RESOURCE POOL mq_pool_02;

unit参考：5

在发起 Unit 迁移前，请您进行如下检查，满足下述条件时，才可以进行迁移操作：

• 目标集群的节点分布为 2-2-2 及以上。
• 目标集群为运行中状态。
• 目标集群下存在租户。
• 目标租户为运行中状态。

注意：迁移目的端需要在同一个 Zone 中，且有足够的资源，否则无法选择。

9.1.2 给OB-ORACLE 扩容

资源单元由一个变为两个
（没有要求黑屏还是白屏，最好白屏操作）

9.2 ObProxy管理

调整只读事务参数，贴出调整命令，ob_proxy_readonly_transaction_routing_policy 为 True和 False的配置。

obclient [oceanbase]> show parameters like 'ob_proxy_readonly_transaction_routing_policy'\G
*************************** 1. row ***************************
      zone: zone1
  svr_type: observer
    svr_ip: 10.186.65.12
  svr_port: 2882
      name: ob_proxy_readonly_transaction_routing_policy
 data_type: NULL
     value: True
      info: Proxy route policy for readonly sql
   section: OBSERVER
     scope: TENANT
    source: DEFAULT
edit_level: DYNAMIC_EFFECTIVE
1 row in set (0.004 sec)

obclient [oceanbase]> ALTER SYSTEM SET ob_proxy_readonly_transaction_routing_policy = false;
Query OK, 0 rows affected (0.061 sec)

参数配置示例（租户级）：

• MySQL 模式

obclient> ALTER SYSTEM SET ob_proxy_readonly_transaction_routing_policy = true;

• Oracle 模式

obclient> ALTER SYSTEM SET ob_proxy_readonly_transaction_routing_policy = 'true';

9.3 sysbench 压测

1 .模拟复现

--创建数据库
create database sbtest;

# 初始化测试表
sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-user=root@gska#hwc_test:14 --mysql-password='OceanBase_123#' --mysql-host=10.186.62.54 --mysql-port=2883 --mysql-db=sbtest --tables=500 --table_size=100000000 --threads=400 --time=360 --report-interval=10 cleanup

# 准备测试数据
sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-user=root@gska#hwc_test:14 --mysql-password='OceanBase_123#' --mysql-host=10.186.62.54 --mysql-port=2883 --mysql-db=sbtest --tables=50 --table_size=10000000 --threads=400 --time=360 --report-interval=10 prepare

# 运行测试，如果上个步骤已经看到错误，可以忽略此步骤
sysbench /usr/share/sysbench/oltp_read_write.lua --tables=50 --table-size=10000000 --mysql-host=10.186.62.54 --mysql-port=2883 --mysql-user=root@gska#hwc_test:14 --threads=400 --report-interval=10 --time=360 --db-driver=mysql --db-ps-mode=disable run 

记录截图报错。

2. 排查内存模块

sysbench 压测，截图保存内存瓶颈，和实验手册一样的。
sysbench 压测，调整参数 writing_throttling_trigger_percentage 的值为90%，进行内存限流。

参考文档：
6

7

-- 展示租户级别的内存统计信息 MySQL 
[oceanbase]> select context,count,used,alloc_count,free_count from gv$memory where  TENANT_ID=1003 order by used desc limit 10;
+-------------------+-------+------------+-------------+------------+
| context           | count | used       | alloc_count | free_count |
+-------------------+-------+------------+-------------+------------+
| OB_MEMSTORE       |   827 | 1733557400 |           0 |          0 |
| MysqlRequesReco   |   147 |  384988160 |           0 |          0 |
| OB_SQL_PHY_PLAN   |  3771 |  143191201 |           0 |          0 |
| OB_SQL_PLAN_CACHE |  6836 |   64514542 |           0 |          0 |
| MemtableCallbac   |  2433 |   19931136 |           0 |          0 |
| OB_KVSTORE_CACHE  |     4 |    8384512 |           0 |          0 |
| PRE_CALC_EXPR     |   927 |    7593984 |           0 |          0 |
| LogAggreBuffer    |   100 |    6553600 |           0 |          0 |
| Election          |     3 |    6288384 |           0 |          0 |
| ElectionGroup     |     1 |    2096128 |           0 |          0 |
+-------------------+-------+------------+-------------+------------+
10 rows in set (0.05 sec)

结论：可以看到,MEMSTORE模块占用的内存最高，与短时间大量写入数据有关。

-- OBServer 内存标签的统计信息。
SELECT * FROM __all_virtual_memory_info  ORDER BY used desc limit 10;

-- 查看 gv$sql_audit 中此 SQL 语句的执行情况，记录 trace_id
MySQL [oceanbase]> select svr_ip,left(query_sql,50),sql_id,plan_id,trace_id,rpc_count,ret_code,plan_type,elapsed_time,get_plan_time from gv$sql_audit where ret_code= '-4030' and query_sql like '%sbtest20%' order by elapsed_time limit 5;
+--------------+----------------------------------------------------+----------------------------------+---------+-----------------------------------+-----------+----------+-----------+--------------+---------------+
| svr_ip       | left(query_sql,50)                                 | sql_id                           | plan_id | trace_id                          | rpc_count | ret_code | plan_type | elapsed_time | get_plan_time |
+--------------+----------------------------------------------------+----------------------------------+---------+-----------------------------------+-----------+----------+-----------+--------------+---------------+
| 10.186.62.46 | INSERT INTO sbtest20(k, c, pad) VALUES(500517, '00 | E1141CCF28AD7E8CCAE735B2B8E059CE |     757 | YB420ABA3E2E-00065081A94BFB0A-0-0 |         0 |    -4030 |         1 |        29987 |          3745 |
+--------------+----------------------------------------------------+----------------------------------+---------+-----------------------------------+-----------+----------+-----------+--------------+---------------+
1 row in set (0.08 sec)

3. 日志分析

去10.186.62.46节点查看，若无结果则搜索前一个 observer 日志文件。

grep YB420ABA3E2E-00065081A94BFB0A-0-0 /home/admin/oceanbase/log/observer.log

结论：
1003租户已经达到内存上限；

批量insert导致的4030的报错，租户内存达到上限。

4. 实验手册相关

打开日志文件查询相关详细信息，发现日志文件报告 memstore 内存到达上限的错误。确认是memstore 的内容总容量不够引起应用报错。

改成压测5张表，测试成功。

结论：
在租户总内存为 2GB 的场景中，模拟多用户应用并发，由于内存不够引起应用报错，查询数据字典获取各个内存的消耗情况。判断某个内存模块不够时的处理方法，本例中由于 memstore 内存不够时，可能需要扩容租户总量。

5. 限流参数

当 MemStore 已使用的内存达到该阈值时，触发写入限速。在3.x的默认值为 100，表示关闭写入限速机制。
参考文档：7

-- 查看限流参数
obclient [oceanbase]> show parameters like 'writing_throttling_trigger_percentage'\G
*************************** 1. row ***************************
      zone: zone1
  svr_type: observer
    svr_ip: 10.186.65.12
  svr_port: 2882
      name: writing_throttling_trigger_percentage
 data_type: NULL
     value: 100
      info: the threshold of the size of the mem store when writing_limit will be triggered. Rang:(0，100]. setting 100 means turn off writing limit
   section: TRANS
     scope: TENANT
    source: DEFAULT
edit_level: DYNAMIC_EFFECTIVE
1 row in set (0.007 sec)

-- 修改租户级限流参数为90%
obclient [oceanbase]> alter system set writing_throttling_trigger_percentage=90 tenant='obce_o';
Query OK, 0 rows affected (0.048 sec)

修改说明：
修改后的值，只能在对应租户里查看90%，全局还是为100%；不加租户则做全局设置。
sys租户下修改参数，业务租户下查看参数生效值。

清理数据，重新压测，未出现报错；若有超时报错，修改ob_query_timeout参数；若限流后还是内存报错，可手工发起一次合并，或者将sysbench的并发降低。

# 过滤日志检查是否存在IO限流
grep "current io status"  /home/admin/oceanbase/log/observer.log

# 查看写入限速日志
grep "report write throttle info"  /home/admin/oceanbase/log/observer.log

参考：8

结论：
出现 MemStore 限流的日志提示，限流原因取决于参数 write_throttling_trigger_percentage；
日志打印 report write throttle info 代表发生了写入限速。

9.4 运维命令

alter system major freeze;
select * from __all_zone;