OceanBase 日志盘过小也会导致创建租户失败？-低调大师

OceanBase 日志盘过小也会导致创建租户失败？

2024-08-09 238

强烈建议OB日志盘大小是内存规格的3倍或以上。

> 作者：郑增权，爱可生 DBA 团队成员，OceanBase 和 MySQL 数据库技术爱好者。 > >爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 > >本文约 1300 字，预计阅读需要 5 分钟。

背景

某客户基于节约资源的想法，将日志盘设置的比较小，日志盘大小约为集群内存规格的1.5倍，当创建租户时，CPU和内存都充足的情况下，却存在报错"LOG_DISK resource not enough"，我们尝试复现问题并定位原因。

环境信息

架构：单节点集群
版本：OceanBase：4.2.1.4

MySQL [oceanbase]&gt; select svr_ip,status,build_version from __all_server;
+--------------+--------+-------------------------------------------------------------------------------------------+
| svr_ip       | status | build_version                                                                             |
+--------------+--------+-------------------------------------------------------------------------------------------+
| 10.186.64.61 | ACTIVE | 4.2.1.4_104010012024030714-c4f3400ad2839e337bc9dab5d1bfe1d01134a1d7(Mar  7 2024 14:32:22) |
+--------------+--------+-------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

查看集群可分配的 CPU、内存、日志盘容量。

MEM_CAPACITY：observer 进程可用的内存大小
LOG_DISK_CAPACITY：日志盘空间总大小，41.8GB
LOG_DISK_ASSIGNED：日志盘已分配大小，6GB
剩余可分配 CPU 数量：18-2=16C
剩余可分配内存大小：24-2=22GB

MySQL [oceanbase]&gt; SELECT SVR_IP, SVR_PORT , ZONE , SQL_PORT , CPU_CAPACITY , CPU_CAPACITY_MAX, CPU_ASSIGNED , CPU_ASSIGNED_MAX ,MEMORY_LIMIT/1024/1024/1024 MEMORY_LIMIT_GB , MEM_CAPACITY/1024/1024/1024 MEM_CAPACITY_GB, MEM_ASSIGNED/1024/1024/1024 MEM_ASSIGNED_GB ,LOG_DISK_CAPACITY/1024/1024/1024 LOG_DISK_CAPACITY_GB,LOG_DISK_ASSIGNED/1024/1024/1024 LOG_DISK_ASSIGNED_GB,LOG_DISK_IN_USE/1024/1024/1024 LOG_DISK_IN_USE_GB  FROM GV$OB_SERVERS;
+--------------+----------+-------+----------+--------------+------------------+--------------+------------------+-----------------+-----------------+-----------------+----------------------+----------------------+--------------------+
| SVR_IP       | SVR_PORT | ZONE  | SQL_PORT | CPU_CAPACITY | CPU_CAPACITY_MAX | CPU_ASSIGNED | CPU_ASSIGNED_MAX | MEMORY_LIMIT_GB | MEM_CAPACITY_GB | MEM_ASSIGNED_GB | LOG_DISK_CAPACITY_GB | LOG_DISK_ASSIGNED_GB | LOG_DISK_IN_USE_GB |
+--------------+----------+-------+----------+--------------+------------------+--------------+------------------+-----------------+-----------------+-----------------+----------------------+----------------------+--------------------+
| 10.186.64.61 |     2882 | zone1 |     2881 |           18 |               18 |            2 |                2 | 30.000000000000 | 24.000000000000 |  2.000000000000 |      41.875000000000 |       6.000000000000 |     0.125000000000 |
+--------------+----------+-------+----------+--------------+------------------+--------------+------------------+-----------------+-----------------+-----------------+----------------------+----------------------+--------------------+
1 row in set (0.00 sec)

可以看到当前集群仅 sys 租户占用了 2C2G 的资源。

MySQL [oceanbase]&gt; SELECT a.tenant_name,a.tenant_id,b.name unit_config,c.name pool_name,b.max_cpu,b.min_cpu,MEMORY_SIZE/1024/1024/1024 as MEMORY_SIZE
-&gt; FROM
-&gt; OCEANBASE.DBA_OB_TENANTS a,
-&gt; OCEANBASE.DBA_OB_UNIT_CONFIGS b,
-&gt; OCEANBASE.DBA_OB_RESOURCE_POOLS c
-&gt; WHERE a.tenant_id=c.tenant_id
-&gt; AND b.unit_config_id = c.unit_config_id
-&gt; ORDER BY a.tenant_id desc;
+-------------+-----------+-------------------------------+-----------+---------+---------+----------------+
| tenant_name | tenant_id | unit_config                   | pool_name | max_cpu | min_cpu | MEMORY_SIZE    |
+-------------+-----------+-------------------------------+-----------+---------+---------+----------------+
| sys         |         1 | config_sys_zone1_twoctwog_xio | sys_pool  |       2 |       2 | 2.000000000000 |
+-------------+-----------+-------------------------------+-----------+---------+---------+----------------+
1 row in set (0.01 sec)

报错复现及疑问

创建租户

尝试创建 1 个规格为 4C12G 的租户。

MySQL [oceanbase]&gt; CREATE RESOURCE UNIT mem_test_unit MEMORY_SIZE = '12G',MAX_CPU = 4, MIN_CPU = 4;
Query OK, 0 rows affected (0.02 sec)

创建资源池

存在报错：LOG_DISK resource not enough

MySQL [oceanbase]&gt; CREATE RESOURCE POOL pool_evan UNIT='mem_test_unit', UNIT_NUM=1, ZONE_LIST=('zone1');
ERROR 4733 (HY000): zone 'zone1' resource not enough to hold 1 unit. You can check resource info by views: DBA_OB_UNITS, GV$OB_UNITS, GV$OB_SERVERS.
server '"10.186.64.61:2882"' LOG_DISK resource not enough

问题 1

剩余资源为 16C 22GB，为何创建一个 4C 12GB 的资源池会失败？

问题 2

报错有关 LOG_DISK ，日志盘容量与内存规格存在何种关联？

日志盘大小与租户内存大小的关系

尝试新建规格为 1C1G 的租户，分析租户内存大小与日志盘容量分配的规律。

新建规格为 1C1G 的租户。
LOG_DISK_ASSIGNED_GB 增长至 9G，相较之前增加了 3G。

MySQL [oceanbase]&gt; CREATE RESOURCE UNIT unit_1g MEMORY_SIZE = '1G',MAX_CPU = 1, MIN_CPU = 1;
Query OK, 0 rows affected (0.01 sec)
MySQL [oceanbase]&gt; CREATE RESOURCE POOL pool_1g UNIT='unit_1g', UNIT_NUM=1, ZONE_LIST=('zone1');
Query OK, 0 rows affected (0.02 sec)
MySQL [oceanbase]&gt; CREATE TENANT IF NOT EXISTS tenant_1g
    -&gt;                 PRIMARY_ZONE = 'zone1',
    -&gt;                 RESOURCE_POOL_LIST=('pool_1g')
    -&gt;                 set OB_TCP_INVITED_NODES='%';
Query OK, 0 rows affected (26.05 sec)
MySQL [oceanbase]&gt; 
MySQL [oceanbase]&gt; SELECT SVR_IP, SVR_PORT , ZONE , SQL_PORT , CPU_CAPACITY ,CPU_ASSIGNED ,MEMORY_LIMIT/1024/1024/1024 MEMORY_LIMIT_GB , MEM_CAPACITY/1024/1024/1024 MEM_CAPACITY_GB, MEM_ASSIGNED/1024/1024/1024 MEM_ASSIGNED_GB ,LOG_DISK_CAPACITY/1024/1024/1024 LOG_DISK_CAPACITY_GB,LOG_DISK_ASSIGNED/1024/1024/1024 LOG_DISK_ASSIGNED_GB  FROM GV$OB_SERVERS;
+--------------+----------+-------+----------+--------------+--------------+-----------------+-----------------+-----------------+----------------------+----------------------+
| SVR_IP       | SVR_PORT | ZONE  | SQL_PORT | CPU_CAPACITY | CPU_ASSIGNED | MEMORY_LIMIT_GB | MEM_CAPACITY_GB | MEM_ASSIGNED_GB | LOG_DISK_CAPACITY_GB | LOG_DISK_ASSIGNED_GB |
+--------------+----------+-------+----------+--------------+--------------+-----------------+-----------------+-----------------+----------------------+----------------------+
| 10.186.64.61 |     2882 | zone1 |     2881 |           18 |            3 | 30.000000000000 | 24.000000000000 |  3.000000000000 |      41.875000000000 |       9.000000000000 |
+--------------+----------+-------+----------+--------------+--------------+-----------------+-----------------+-----------------+----------------------+----------------------+
1 row in set (0.00 sec)

小结

每为租户分配 1GB 内存，则对应的分配 3GB 日志盘容量。

代入本文初始环境计算

计算公式

本文初始背景集群剩余内存规格计算：

(LOG_DISK_CAPACITY_GB - LOG_DISK_ASSIGNED_GB) / 3 =（41.875 - 6.00）/ 3 ≈ 11.958 GB

即，集群剩余可用的内存上限为 11.958GB，取整数为 11GB。

验证

释放资源

删掉租户 tenant_1g 和对应的 RESOURCE POOL 释放资源。

MySQL [oceanbase]&gt; DROP TENANT tenant_1g;
Query OK, 0 rows affected (35.04 sec)
MySQL [oceanbase]&gt; DROP RESOURCE POOL pool_1g;
Query OK, 0 rows affected (0.01 sec)
MySQL [oceanbase]&gt; SELECT SVR_IP, SVR_PORT , ZONE , SQL_PORT , CPU_CAPACITY ,CPU_ASSIGNED ,MEMORY_LIMIT/1024/1024/1024 MEMORY_LIMIT_GB , MEM_CAPACITY/1024/1024/1024 MEM_CAPACITY_GB, MEM_ASSIGNED/1024/1024/1024 MEM_ASSIGNED_GB ,LOG_DISK_CAPACITY/1024/1024/1024 LOG_DISK_CAPACITY_GB,LOG_DISK_ASSIGNED/1024/1024/1024 LOG_DISK_ASSIGNED_GB  FROM GV$OB_SERVERS;
+--------------+----------+-------+----------+--------------+--------------+-----------------+-----------------+-----------------+----------------------+----------------------+
| SVR_IP       | SVR_PORT | ZONE  | SQL_PORT | CPU_CAPACITY | CPU_ASSIGNED | MEMORY_LIMIT_GB | MEM_CAPACITY_GB | MEM_ASSIGNED_GB | LOG_DISK_CAPACITY_GB | LOG_DISK_ASSIGNED_GB |
+--------------+----------+-------+----------+--------------+--------------+-----------------+-----------------+-----------------+----------------------+----------------------+
| 10.186.64.61 |     2882 | zone1 |     2881 |           18 |            2 | 30.000000000000 | 24.000000000000 |  2.000000000000 |      41.875000000000 |       6.000000000000 |
+--------------+----------+-------+----------+--------------+--------------+-----------------+-----------------+-----------------+----------------------+----------------------+
1 row in set (0.00 sec)

重新创建

创建一个规格为 16C11G 的租户。

MySQL [oceanbase]&gt; CREATE RESOURCE UNIT unit_11g MEMORY_SIZE = '11G',MAX_CPU = 16, MIN_CPU = 16;
Query OK, 0 rows affected (0.01 sec)
MySQL [oceanbase]&gt;  CREATE RESOURCE POOL pool_11g UNIT='unit_11g', UNIT_NUM=1, ZONE_LIST=('zone1');
Query OK, 0 rows affected (0.02 sec)

MySQL [oceanbase]&gt; CREATE TENANT IF NOT EXISTS tenant_11g
    -&gt;                 PRIMARY_ZONE = 'zone1',
    -&gt;                 RESOURCE_POOL_LIST=('pool_11g')
    -&gt;                 set OB_TCP_INVITED_NODES='%';
Query OK, 0 rows affected (25.99 sec)
MySQL [oceanbase]&gt; SELECT SVR_IP, SVR_PORT , ZONE , SQL_PORT , CPU_CAPACITY ,CPU_ASSIGNED ,MEMORY_LIMIT/1024/1024/1024 MEMORY_LIMIT_GB , MEM_CAPACITY/1024/1024/1024 MEM_CAPACITY_GB, MEM_ASSIGNED/1024/1024/1024 MEM_ASSIGNED_GB ,LOG_DISK_CAPACITY/1024/1024/1024 LOG_DISK_CAPACITY_GB,LOG_DISK_ASSIGNED/1024/1024/1024 LOG_DISK_ASSIGNED_GB  FROM GV$OB_SERVERS;
+--------------+----------+-------+----------+--------------+--------------+-----------------+-----------------+-----------------+----------------------+----------------------+
| SVR_IP       | SVR_PORT | ZONE  | SQL_PORT | CPU_CAPACITY | CPU_ASSIGNED | MEMORY_LIMIT_GB | MEM_CAPACITY_GB | MEM_ASSIGNED_GB | LOG_DISK_CAPACITY_GB | LOG_DISK_ASSIGNED_GB |
+--------------+----------+-------+----------+--------------+--------------+-----------------+-----------------+-----------------+----------------------+----------------------+
| 10.186.64.61 |     2882 | zone1 |     2881 |           18 |           18 | 30.000000000000 | 24.000000000000 | 13.000000000000 |      41.875000000000 |      39.000000000000 |
+--------------+----------+-------+----------+--------------+--------------+-----------------+-----------------+-----------------+----------------------+----------------------+
1 row in set (0.01 sec)

疑问解答

下面我们来解答上面提出的两个疑问。

问题 1

剩余资源为 16C 22GB，为何创建一个 4C 12GB 的资源池会失败？

答：

由于日志盘规格为 41.875GB，且 sys 租户已占用 6GB 日志盘份额，经前文计算可得：集群剩余可用的内存上限为 11GB。
建租户内存规格超过 11GB 会因申请不到对应份额的日志盘容量而引发报错 LOG_DISK resource not enough。

问题 2

报错有关 LOG_DISK ，日志盘容量与内存规格存在何种关联？

答：LOG_DISK_SIZE：默认值为内存规格值的 3 倍，最小值为 2G。

建议

日志盘大小尽量设置为内存上限的 3 或 4 倍（生产环境至少是 3 倍），避免因日志盘不足导致集群已有的内存无法进行分配。

参考资料

《GV$OB_SERVERS》：https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001051773
《ALTER RESOURCE UNIT》：https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000220301

更多技术文章，请访问：https://opensource.actionsky.com/

关于 SQLE

SQLE 是一款全方位的 SQL 质量管理平台，覆盖开发至生产环境的 SQL 审核和管理。支持主流的开源、商业、国产数据库，为开发和运维提供流程自动化能力，提升上线效率，提高数据质量。

✨ Github：https://github.com/actiontech/sqle

📚 文档：https://actiontech.github.io/sqle-docs/

💻 官网：https://opensource.actionsky.com/sqle/

👥 微信群：请添加小助手加入 ActionOpenSource

🔗 商业支持：https://www.actionsky.com/sqle

微信关注我们

原文链接：https://my.oschina.net/actiontechoss/blog/15227405

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

OpenTiny HUICharts开源发布，带你了解一个简单、易上手的图表组件库

摘要：目前 OpenTiny HUICharts 已经成功落地在华为内部100多个产品中，持续提升了用户的可视化体验。本文分享自华为云社区《OpenTiny HUICharts 正式开源发布，一个简单、易上手的图表组件库》，作者： OpenTiny。引言大家好！我们非常高兴地跟大家宣布，今天正式发布我们的新产品——OpenTinyHUICharts。这是一款前端 Web 可视化图表库，其基础图表功能构建于 ECharts 之上，而高阶图表则采用了新的底层技术，以满足更广泛的数据可视化需求。 OpenTinyHUICharts集成了自适应、性能提升、数据状态管理、无障碍能力、刻度优化、刻度均分等特性。这些特性帮助我们解决了许多内部业务场景中的问题。我们追求的目标是让图表的使用变得更加简单、直观且易于上手。为什么要做 OpenTinyHUICharts OpenTinyHUICharts的诞生源于我们的内部业务需求。在处理数据可视化时，我们常常遇到两个主要问题：工具过于复杂和定制性不足。许多现有的图表工具虽然功能强大，但使用起来相对繁琐，需要频繁查询 API 文档。在处理大量复杂...

2024-08-09

305

go-logger 是一个轻量级的日志库，提供了灵活的日志记录功能，方便在应用程序中实现不同级别的日志输出. 特点：简单易用：go-logger提供了一个简单直观的 API，使得开发者能够快速上手并集成到现有项目中。灵活配置：支持代码直接配置日志的输出级别、输出目标（如标准输出、文件等）以及日志格式。性能考虑：设计时考虑了性能因素，尽量减少日志记录操作的开销，通过优化内存等方式，优化日志性能。日志分级：支持常见的日志级别划分，便于根据不同的环境（开发、测试、生产）调整日志的详细程度。功能：日志级别设置：允许动态调整日志级别，以便在不同环境下控制日志的详细程度。格式化输出：支持自定义日志的输出格式，包括时间戳、日志级别、日志位置等元素。文件数回滚：支持按照日志文件数自动文件回滚，并防止文件数过多。文件压缩：支持压缩归档日志文件。支持标准库log/slog日志文件管理：支持标准库文件切割，压缩等功能。外部处理函数：支持自定义外部处理函数。日志追踪：日志记录点可以回溯到程序入口点的所有函数调用序列，包括每一步函数调用的文件名，函数名，行号日志级别独立日志格式输出：...

2024-08-09

297

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。