OceanBase由于合并操作导致事务被杀死的情况。
事务 操作 情况 合并 导致 杀死 由于 OceanBase
2023-09-27 14:27:09 时间
OceanBase是一台内存数据库,兼容MySQL协议以及SQL协议,拥有跟内存数据库一样的属性:所有的数据都需要先写入到内存里面,但是并不会立刻落盘写入到存储里面,需要等一次合并操作,将内存里面所有的改动落盘到存储里面。所以发生这种合并操作的时候,伴随着资源的使用,也会出现问题。我们来看其中一种由于合并操作导致数据库杀死事务的情况如何排查。
机器配置:
2c8g
应用端报错信息:
系统未知错误,请联系管理员: transaction error,need to rollback。
第一次遇到这种问题也是比较懵的,因为平常测试库的压力不大,而且合并时间都在凌晨,一般不会出现这种问题。所以排查也是冲头到尾一步一步梳理的。
排错过程:
首先确认一下所有的observe是否都正常。
可以直接使用observe机器所在的IP直接连接,或者是查看端口是否通等等的。确认无误。
然后查看相关监控信息如下:
监控信息里面能反应出一些事情来,确实那个时间段相对的系统负载要比平时高。
然后,看一下是否由于压力的问题,导致了系统发生了合并操作。
OceanBase (root@oceanbase) show tables like %rootservice%; +-------------------------------------+ | Tables_in_oceanbase (%rootservice%) | +-------------------------------------+ | __all_rootservice_event_history | | __all_rootservice_job | +-------------------------------------+ 2 rows in set (0.02 sec)合并操作记录在__all_rootservice_event_history表中。
select * from __all_rootservice_event_history where gmt_create between 2017-09-25 16:00:00 and 2017-09-25 17:00:00 order by gmt_create;查看发生故障时间段是否发生过合并状态。
发现在故障时间点确实是存在合并操作的。通过之前的操作可以看到75是这次合并操作的序号
select count(*) from __all_rootservice_event_history where gmt_create between 2017-09-25 16:00:00 and 2017-09-25 17:00:00 and value1 = 75 order by gmt_create;
show parameters like %turn%;发现enable_merge_by_turn打开,表示轮转合并是打开的,也就是3个zone不是同时合并,是依次合并。每个zone合并前,会把当前zone的所有leader切到别的不合并的zone,结束后再切回来
这是一次非计划的合并,说明性能测试写操作太猛,租户的memstore增长太快,达到一定阈值后就自动触发了合并操作。
OceanBase 源码解读(四):事务的一生 源码是 OceanBase 的“方向盘”,本系列主要围绕“源码解读”,通过文章阐述,帮助大家理清数据库的内在本质。此前,带你读源码第三篇《戳这里回顾:OceanBase 源码解读(三)分区的一生》为大家介绍了OceanBase 的存储层的相关内容。在第一节讲通信协议 obmp_query 时,跳过了事务控制的细节,本文为 OceanBase 数据库源码解读系列文章的第四篇,将主要为大家介绍事务的外部接口相关知识。
深入剖析数据库内核之事务的本质 | 附下一代分布式数据库 OceanBase 解决方案 在近日 OceanBase 开源技术直播上,OceanBase 分布式数据库事务研发负责人颜然以数据库事务的本质为主题,深入分享了事务的前世今生一季 OceanBase 在分布式事务上的解决方案。本文将从以下三方面进行阐述数据库事务:一、事务的前世,二、事务的挑战,三、分布式事务
初探OceanBase的定期合并&数据分发 定期合并和数据分发都是将UpdateServer中的增量更新分发到ChunkServer中的手段,二者的整体流程比较类似:UpdateServer冻结当前的活跃内存表(Active MemTable),生成冻结内存表,并开启新的活跃内存表,后续的更新操作都写入新的活跃内存表。
赛况激烈!2022 OceanBase数据库大赛50强诞生 数据库作为各行业数据的存储、管理和分析的软件,是承载数据要素、影响数字经济发展的底座。对于数据库从业者而言,对数据库的要求就是对自身能力的要求。据有关数据统计,目前国内从事数据库内核研发的人员稀缺,制定可行且有效的人才培养方案迫在眉睫。 OceanBase 作为国内自研数据库的厂商,产品能力已经在金融、电信、政企等诸多重要行业得到了验证。自 2021 年起,OceanBase 已连续举办两届数据库大赛,旨在用坚实的数据库系统知识与过硬的实践环境,锻炼出一批真正可投入生产环境的数据库人才。
阿里的OceanBase数据库世界第一,底层原来使用了Paxos协议 前段时间相信都被阿里的OceanBase数据库刷屏了,它击败世界头号数据库厂商Oracle,登顶全球第一。先不看新闻内容,光是看标题就足以让人耳目一新了。又是“击败”,又是“第一”,又是“打破世界纪录”。即使是IT行业的门外汉,相信也会对这个消息感到振奋。但是你知道其底层其实使用的Paxos协议吗?如果你不知道也没关系,这篇文章主要就是让你理解Paxos协议到底是个什么东西?
相关文章
- InnoDB事务和锁
- 一个基于PDO的数据库操作类(新) 一个PDO事务实例
- java操作MySQL数据事务的简单学习
- springboot的事务的隔离级别与操作案例
- spring的annotation-driven配置事务管理器详解
- Java多线程批量操作,居然有人不做事务控制?
- 一天五道Java面试题----第十天(简述Redis事务实现--------->负载均衡算法、类型)
- 一天五道Java面试题----第七天(mysql索引结构,各自的优劣--------->事务的基本特性和隔离级别)
- 为什么事务没有回滚!
- WCF技术剖析之三十二:一步步创建一个完整的分布式事务应用
- 谈谈分布式事务之二:基于DTC的分布式事务管理模型[上篇]
- lightdb/PostgreSQL查看数据库,索引,表,表空间大小,事务和LSN(管理函数)