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

爱可生开源社区 爱可生开源社区 博客等级 墨衍会员 · AI 创作全网分发 墨衍智能分发 本文由作者通过墨衍一键同步至各平台 1分发平台 700+累计阅读 743平均单平台 已同步平台 优快云 微信公众号 微博 知乎 掘金 百家号 博客园 抖音 小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年，写一次发全网 我也要 码龄8年
关注
原创 最新推荐文章于 2026-09-07 21:42:18 发布 743 阅读 AI 写同款· GEO 优化 ›
【OceanBase诊断调优】—— OceanBase 数据库日志解读 OceanBase 数据库日志解读 阅读详情

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

作者：郑增权，爱可生 DBA 团队成员，OceanBase 和 MySQL 数据库技术爱好者。

爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

本文约 1300 字，预计阅读需要 5 分钟。

背景

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

环境信息

  • 架构：单节点集群
  • 版本：OceanBase：4.2.1.4
MySQL [oceanbase]> 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]> 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]> 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
-> FROM
-> OCEANBASE.DBA_OB_TENANTS a,
-> OCEANBASE.DBA_OB_UNIT_CONFIGS b,
-> OCEANBASE.DBA_OB_RESOURCE_POOLS c
-> WHERE a.tenant_id=c.tenant_id
-> AND b.unit_config_id = c.unit_config_id
-> 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]> 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]> 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 的租户，分析租户内存大小与日志盘容量分配的规律。

  1. 新建规格为 1C1G 的租户。
  2. LOG_DISK_ASSIGNED_GB 增长至 9G，相较之前增加了 3G。
MySQL [oceanbase]> CREATE RESOURCE UNIT unit_1g MEMORY_SIZE = '1G',MAX_CPU = 1, MIN_CPU = 1;
Query OK, 0 rows affected (0.01 sec)
MySQL [oceanbase]> CREATE RESOURCE POOL pool_1g UNIT='unit_1g', UNIT_NUM=1, ZONE_LIST=('zone1');
Query OK, 0 rows affected (0.02 sec)
MySQL [oceanbase]> CREATE TENANT IF NOT EXISTS tenant_1g
    ->                 PRIMARY_ZONE = 'zone1',
    ->                 RESOURCE_POOL_LIST=('pool_1g')
    ->                 set OB_TCP_INVITED_NODES='%';
Query OK, 0 rows affected (26.05 sec)
MySQL [oceanbase]> 
MySQL [oceanbase]> 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]> DROP TENANT tenant_1g;
Query OK, 0 rows affected (35.04 sec)
MySQL [oceanbase]> DROP RESOURCE POOL pool_1g;
Query OK, 0 rows affected (0.01 sec)
MySQL [oceanbase]> 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]> CREATE RESOURCE UNIT unit_11g MEMORY_SIZE = '11G',MAX_CPU = 16, MIN_CPU = 16;
Query OK, 0 rows affected (0.01 sec)
MySQL [oceanbase]>  CREATE RESOURCE POOL pool_11g UNIT='unit_11g', UNIT_NUM=1, ZONE_LIST=('zone1');
Query OK, 0 rows affected (0.02 sec)

MySQL [oceanbase]> CREATE TENANT IF NOT EXISTS tenant_11g
    ->                 PRIMARY_ZONE = 'zone1',
    ->                 RESOURCE_POOL_LIST=('pool_11g')
    ->                 set OB_TCP_INVITED_NODES='%';
Query OK, 0 rows affected (25.99 sec)
MySQL [oceanbase]> 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 的资源池会失败？

答：

  1. 由于日志盘规格为 41.875GB，且 sys 租户已占用 6GB 日志盘份额，经前文计算可得：集群剩余可用的内存上限为 11GB。

  2. 建租户内存规格超过 11GB 会因申请不到对应份额的日志盘容量而引发报错 LOG_DISK resource not enough。

问题 2

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

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

建议

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

参考资料

  1. 《GV$OB_SERVERS》：https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001051773
  2. 《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

标签
#mysql #oceanbase #数据库 #ActionDB
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
OceanBase运维避坑指南：从创建租户到参数调优，这些SQL命令你记对了吗？ 本文详细解析了OceanBase数据库运维中的高频易错SQL命令，从租户创建的资源分配到参数调优的认知误区，再到备份恢复的时序陷阱，提供了全面的避坑策略和实战技巧。特别针对OceanBase运维操作中的常见问题，如内存计算、CPU分配、日志磁盘管理等，给出了专业建议和优化方案，帮助DBA提升运维效率。 阅读详情

相关推荐

如何排查断连问题——《OceanBase诊断系列》十三

当断连接发生的时候，用户最直接得到的信息是ObServer返回的错误包提示，用户可以根据错误包的提示作初步的排查，这里提供的信息往往比较少，用户很难确定问题。ObProxy针对断连接问题，提供断连接的诊断信息记录。

OceanBase分布式数据库的博客 1876

实践练习一（必选）：OceanBase Docker 体验

总是听闻ob的大名，今天第一次进行实践，真是令人兴奋。在创建resource pool的时候，报了资源不足的问题，通过报错提示进行了解决，也简单记录了下。第一部分：实践内容第二部分：问题复现及解决。

m0_55146438的博客 1958

OceanBase 4.X-2F1A 仲裁高可用方案初探

作者：郑增权，爱可生 DBA 团队成员，OceanBase 和 MySQL 数据库技术爱好者。背景对于分布式数据库来说，当多个数据副本间发生半数异常时(一半副本故障或与另一半网络隔离)，可以通过集群之外的仲裁服务来参与变更决策(选主/成员组变更)，进而恢复服务。OceanBase 数据库 V4.1.0 版本开始支持 仲裁服...

qq_35485206的博客 1248

手动部署OceanBase集群（单zone）

薅OBCP考试券的社区活动本次实验：手动部署OceanBase。单节点的OBserver+OBProxy虚拟机配置：4C12G。

ka7iu的博客 2490

OceanBase MySQL 租户 4 种连接方式实测：ODC、OBClient、MySQL Client、JDBC 性能与场景对比

本文深入评测了OceanBase MySQL租户的四种连接方式：ODC图形化工具、OBClient命令行工具、MySQL Client和JDBC编程接口。通过实际测试数据，分析了它们在连接效率、查询性能、吞吐能力和资源占用等方面的表现差异，并提供了场景化选型指南和疑难问题解决方案，帮助用户根据实际需求选择最适合的连接工具。

weixin_33901641的博客 398

通过OMS迁移Oracle到OceanBase Oracle租户

摘要 本文详细介绍了通过OMS将Oracle数据库迁移至OceanBase Oracle租户的完整流程和注意事项。

Sebastien23的博客 447

OceanBase Docker 部署&使用

OceanBase Docker 部署&使用

夏洛的克 3644

通过OMS迁移Oracle到OceanBase MySQL租户

本文介绍了通过OMS将Oracle数据库迁移至OceanBase MySQL租户的完整流程及注意事项。

Sebastien23的博客 506

CentOS7.9上OceanBase4.0 Docker容器的快速部署

创建资源单元 U2C4G 配置为 2 个 CPU，4G 内存，128- 个 IOPS，10G 日志盘。一、CentOS7.9上OceanBase4.0 Docker容器的快速部署。一台8C16G100G的虚拟机，系统是CentOS7.9。修改租户的root密码，下次登录后需要输入密码。将U2C4G调小为2G后重新创建资源池成功。登录obmysql租户，默认密码为空。查看oceanbase镜像。创建资源池时报错，内存不足。安装docker-ce。安装所需要的系统工具。启动docker服务。

weixin_42337395的博客 2414

OceanBase数据库：多租户备份策略与租户级备份管理深度解析

摘要 OceanBase多租户架构通过资源池和资源单元实现租户间的资源隔离与共享，提供高效数据库服务交付。其备份策略基于分布式系统可靠性理论，包含物理备份（全量/增量/日志归档）和逻辑备份两种类型，遵循3-2-1规则设计原则。租户级备份采用分布式快照技术和LSN机制保障数据一致性，涉及Root Service协调、分区Leader数据备份等关键流程。 备份配置支持NFS、OSS等多种介质，需合理设置备份参数（如并发度、IO限流等）并管理标准化目录结构。具体操作包括全量备份环境准备、执行命令及验证。增量备份则

本博客聚焦 YOLOv11 全流程落地，涵盖架构优化、数据集处理、训练技巧与多场景部署，兼及国产数据库、Java 开发与 AI 模型应用，内容兼顾理论与工程实践，为开发者提供系统干货，助力高效提升技术能力。 405

从‘眼花缭乱’到‘心中有数’：rs-fMRI统计分析全流程避坑指南（附DPABI操作截图）

本文详细解析了rs-fMRI统计分析的全流程，从质量控制到统计模型选择，再到多重比较校正和结果解读。特别针对DPABI软件操作中的常见陷阱提供实用指南，帮助研究者避免FDR和GRF校正等关键环节的错误，实现从数据混乱到清晰分析的转变。

weixin_33686714的博客 398

日志盘容量小，是导致创建租户失败的因素吗 | OceanBase 案例分析

某客户出于资源节约的考量，将日志盘容量设定得相对较小，约为 OceanBase 集群内存容量的1.5倍。然而，在创建新租户的过程中，尽管CPU和内存资源均显示充足，却遭遇了“LOG_DISK resource not enough”的错误提示。为了查明问题根源，我们进行了问题复盘与深入排查。

OceanBase分布式数据库的博客 772

VerilogEval实战指南：从基准测试到模型微调的全流程解析

本文提供了VerilogEval实战指南，详细解析了从基准测试到模型微调的全流程。VerilogEval是一个自动化、标准化的测试框架，用于客观评估大语言模型生成Verilog硬件代码的能力。文章涵盖了环境搭建、核心机制解析、利用其生成合成数据进行模型微调的策略，以及如何将其工程化集成到自动化评估流程中，为硬件设计领域的AI应用提供了完整的方法论。

yy01234的博客 1005

OceanBase基础概念

OceanBase的“总控服务”核心功能 租户简介租户特性Unit注意：OceanBase可以为不同类型的应用分配不同类型和不同数量的Unit，满足业务不同的需求。资源并不是静态的，可以随着业务的发展不断调整（调高或者调低）创建“资源单元规格”（仅仅是规格定义，不实际分配资源） 创建资源池(会实际创建unit，按规格定义分配资源)：根据资源单元规格的定义创建资源单元，并赋给一个新的资源池 每个resource pool在每个OB Server上只能有一个resource unit；如果unit_num

缘友一世的博客 1891

LMX2594时钟配置实战：TICS PRO从入门到寄存器导出

本文详细介绍了LMX2594时钟芯片的配置实战，重点讲解了如何使用TICS PRO调试软件简化复杂的寄存器设置过程。通过实例演示从基础频率配置到高级参数调优的全流程，并分享SPI写入的嵌入式系统移植技巧，帮助工程师快速掌握高性能时钟芯片的配置方法。

weixin_29189003的博客 552

西门子1500 PLC与巴鲁夫RFID实战：从硬件接线到数据读写的完整流程

本文详细介绍了西门子S7-1500 PLC与巴鲁夫RFID系统集成的完整实战流程。内容涵盖从硬件选型、接线、PROFINET网络配置，到在TIA Portal中安装GSD文件、组态设备、分配地址，再到使用标准功能块（如FB31）进行程序架构设计、实现数据读写以及错误诊断。文章重点分享了硬件连接要点、软件配置步骤、数据块管理技巧以及调试中常见问题的解决方案，为工业自动化工程师实施RFID项目提供了清晰的指导。

weixin_29161785的博客 386

OceanBase Switchover

本文详细介绍了在物理备库的两种部署方式下，主租户与备租户角色交换（Switchover）的操作流程。首先，系统租户（sys）的角色始终为PRIMARY，不支持切换。在切换前，需确保备租户所有日志流副本在线，否则需等待副本永久下线。Switchover操作分为三个阶段：主租户切换为备租户、备租户切换为主租户、为原主租户设置日志恢复源。操作过程中，需通过DBA_OB_LS或CDB_OB_LS视图查询日志流副本状态，并通过DBA_OB_TENANTS视图确认切换结果。此外，基于日志归档的物理备库场景中，备租户需先

Made In SQL 809

用R来做一个临床研究亚组分析的森林图

在编程语言里R语言最强大的功能是做图功能，我们知道在做Meta分析的时候会需要做森林图，实际上我们在很多临床研究中也经常看到森林图，主要是亚组分析的森林图，比如下面这篇文章里的一个森林图： 今天就教教大家怎么用R语言来做上面这种亚组分析的森林图 1. 在Excel里编辑好数据，按照下面的格式整理，保存为csv格式 2. 下载安装R跟Rstudio R软件的下载地址： https://mirrors.tuna.tsinghua.edu.cn/CRAN/ Rstudio下

Mrrunsen的博客 5340

OceanBase仲裁高可用过程

OceanBase数据库最新版本引入了仲裁服务（ArbitrationService），旨在优化两地三中心架构下的故障处理效率和成本控制。仲裁服务通过维护租户日志流的仲裁成员，仅在选举、PaxosPrepare和成员组变更投票中参与，不涉及日志多数派投票，从而减少资源消耗。当半数全功能副本故障导致日志同步失败时，仲裁服务会自动执行日志流降级流程，删除故障副本，确保服务恢复且RPO=0。故障副本恢复后，仲裁服务会执行日志流升级流程，重新加入副本，提升系统可用性。此外，仲裁服务的日志流降级控制时间由租户级配置项

Made In SQL 1309

42页Claude 3技术报告解读（Opus, Sonnet, Haiku）

在Claude 3模型中，增加了一个额外的原则到Claude的宪法中，以鼓励尊重残疾人权利，这一原则源自对集体宪法AI的研究。Claude 3模型的训练基于专有的混合数据集，包括截至2023年8月互联网上公开可用的信息，以及第三方提供的非公开数据、数据标注服务和付费承包商提供的数据，还有内部生成的数据。这些初始响应通常包含有害和有毒的内容。Claude 3模型家族在推理、编码和问答任务上展现出卓越的性能，特别是在行业标准基准测试中取得了显著的提升，证明了其在处理复杂问题和提供准确答案方面的能力。

具身机器人和通用AI 2438

怀旧版电脑GBC模拟器

再现原版GBC掌机的界面，电脑运行连游戏界面都一样大小，很怀旧，很真实，（英文版）强烈推荐，很小的文件，很难才找到的。

OceanBase物理备库容灾

OceanBase数据库的物理备库功能是其高可用解决方案的关键部分，旨在为关键应用提供高可用性、数据保护和灾难恢复能力。物理备库作为主库的准实时热备份，在主库不可用时能够接管服务，提供无损和有损切换，以最小化服务停机时间和数据损失。从V4.1.0版本开始，物理备库的产品形态从集群级主备转变为租户级主备，主租户支持完整的数据库服务，而备租户仅提供容灾和只读服务。物理备库通过日志传输、存储和回放服务确保主备租户数据一致性，并可与多种容灾方案和功能组合使用，满足多样化的数据保护和可用性需求。物理备库的部署方案灵活

Made In SQL 1137

WINCC7.3破解文件

WINCC7.3硬件够破解文件，有需要的下载！WINCC7.3硬件够破解文件，有需要的下载！

OceanBase-租户当前已使用的内存（租户内存使用率）

#参数格式 （IP:用户:租户:集群:密码:端口:操作系统用户） #OB-租户当前已使用的内存（租户内存使用率） #run_shell:#$1格式： IP:user:tenant_usr:colony_name:passwd:port:os_usr #run_shell:OC_CONFS=$1 #run_shell: #run_shell:[ -z "${OC_CONFS}" ] && exit 0 #run_shell:IP=$(echo ${OC_CONFS}|awk -F':' '{

Zeolite_1020的博客 750

IDEA的使用指南

IDEA基于java的使用手册,可以最快速的上手,在使用中不断的丰富自己的使用技巧.

ssm框架搭建

这个是一个在idea上成功跑起来的ssm框架项目，保存在这里方便以后使用直接下载

OceanBase 物理备份恢复

数据备份是指 OceanBase 数据库定期地将存储在磁盘上的数据文件（SSTable）复制并传输到指定的外部存储介质的过程。备份内容：主要包含数据库转储（Minor Freeze）和合并（Major Compaction）后生成的SSTable 宏块数据。与日志归档的区别：数据备份是定期的静态快照，而日志归档是持续的动态 Clog 记录。两者结合可实现指定时间点恢复（PITR）。

985 硕士，高级职称，数据库技术爱好者。持有Oracle/MySQL/ PostgreSQL/OceanBase/OpenGauss/TiDB和达梦中级认证，涉猎OLTP、OLAP 与大数据领域。现专注国产分布式数据库知识分享和实战沉淀。 393
上一篇： 在 MySQL 事务中，什么时候释放锁？
下一篇： 为什么你的 show slave status 会卡住？
点赞 4
评论 0
书签 书签 4
爱可生开源社区
爱可生开源社区
博客等级 码龄8年 1936粉丝 1004原创
+ 关注
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值