美文网首页
OceanBase4.0:理解日志流

OceanBase4.0:理解日志流

作者: 轻松的鱼 | 来源:发表于2024-08-07 14:32 被阅读0次

背景

日志流是V4 版本引入的新技术,其目的是为了降低 paxos 协议的开销。

在 V4版本以前,每个分区的多个副本组成一个 paxos 组,每个 paxos 组要进行心跳检测、选举投票、log同步,可以想象一旦表数量或者分区数量很多,paxos 协议带来的开销会非常大;甚至即使没有任何业务流量,也会消耗也会消耗好几个 CPU 用于 paxos 的心跳检测、选举投票。也是因为这个 V4以前版本建议单个observer的分区数量少于5万。

现在每个租户在每个observer上的所有分区 leader 副本都动态绑定在一个日志流上,与其他 observer 上的 follower 副本所在的日志流组成一个 paxos 组,paxos 组的数量从万级下降到个位数,大量减少开销。所以 V4 版本不再有分区数量的限制。

另外,分区到日志流是动态绑定的:当集群增加新的服务器,或者内部进行负载均衡时,可以把分区从源端的日志流动态解绑并重新绑定到目的端的日志流,从而实现分区动态迁移。

V4 还加入了一个术语:tablet,即分片,在V4以前OceanBase中直接用“分区”来表示一个“分片”,因为OB就是通过定义分区来进行数据打散的,但这在分布式数据库领域中并不通用,改用 tablet 是应有之义。除了术语变化之外,还需要注意的是内部系统视图里新加入了 tablet_id 这个对象。

tips:在OceanBase中分区=分片=tablet

日志流是“单机分布式一体化”概念的核心创新,官方发了多篇博客解析其含义。本文从运维层面分享如何理解日志流,如何通过日志流人工移动分区的位置。

日志流属性

日志流可以理解为 paoxs 协议层面的分片的容器,一个日志流里可以容纳多个分片。它拥有的属性基本和分片一样,同样有副本数量、副本角色、副本类型、成员这些属性。

通过 CDB_OB_LS_LOCATIONS、CDB_OB_LS 视图可以查看日志流的属性,可使用如下命令:

select TENANT_ID,LS_ID,SVR_IP,ZONE,ROLE,MEMBER_LIST,PAXOS_REPLICA_NUMBER,REPLICA_TYPE from CDB_OB_LS_LOCATIONS where tenant_id=1004;
select * from CDB_OB_LS where TENANT_ID=1004;

可以看到 1004 号租户有两个日志流,其中 LS_ID=1 这个比较特殊,它用来存储系统表,每个租户默认都有这么一个日志流。因此实际上这个租户只有一个日志流,所有表的分片都放在这个日志流上,leader 在 zone1 上(primary_zone=zone1;zone2;zone3),副本数量是3。

1. 日志流的 primary_zone 属性

这里最值得注意的一点是日志流是有 primary_zone 属性的,我们做一个测试:将租户的 primary_zone 从 “zone1;zone2;zone3” 修改成 random,再观察下日志流有什么改变:

obclient [oceanbase]> SELECT tenant_id,tenant_name,PRIMARY_ZONE,LOCALITY FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'hucq_ora';
+-----------+-------------+-------------------+---------------------------------------------+
| tenant_id | tenant_name | PRIMARY_ZONE      | LOCALITY                                    |
+-----------+-------------+-------------------+---------------------------------------------+
|      1004 | hucq_ora    | zone1;zone2;zone3 | FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3 |
+-----------+-------------+-------------------+---------------------------------------------+
1 row in set (0.011 sec)

obclient [oceanbase]> alter tenant hucq_ora PRIMARY_ZONE='RANDOM';
Query OK, 0 rows affected (0.149 sec)

obclient [oceanbase]> SELECT tenant_id,tenant_name,PRIMARY_ZONE,LOCALITY FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'hucq_ora';
+-----------+-------------+--------------+---------------------------------------------+
| tenant_id | tenant_name | PRIMARY_ZONE | LOCALITY                                    |
+-----------+-------------+--------------+---------------------------------------------+
|      1004 | hucq_ora    | RANDOM       | FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3 |
+-----------+-------------+--------------+---------------------------------------------+
1 row in set (0.011 sec)

然后可以看到日志流变成了3个,并且 primary_zone 设置的很有意思:

  • 1001 号日志流的 primary zone 是 zone1(在这个日志流里的分片的 leader 副本都会落在 zone1 上)
  • 1006 号日志流的 primary zone 是 zone2
  • 1007 号日志流的 primary zone 是 zone3
租户的 primary_zone 是 random,实际上就是通过日志流设置不同的 primary_zone 属性来控制这个租户下所有分片的 leader 副本均匀打散在 3个 zone。 通过CDB_OB_TABLE_LOCATIONS 视图可以查看表、分片的日志流分布以及 leader 分布:

2. 日志流的数量

刚才的测试中日志流的数量会跟随 primary_zone 的变化而变化,实际上公式为:

日志流数量 = unit number * primary_zone的第一级个数
具体常用的几个架构场景对应的日志流数量: 举例,unit_num=2,primary_zone=random(或者 zone1,zone2,zone3)的日志流属性如下:

数据均衡与手工 transfer

数据均衡的原理:通过日志流的数量和每个日志流的 primary_zone 实现的。

  • 副本数量的均衡:然后按照 tablet 数量以及占用磁盘大小,将 tablet 分配到不同的日志流,这样每个日志流里的 tablet 数量和大小大致是均衡的;

  • 副本 leader 的均衡,在1的基础上,每个日志流设置不同的 priamry_zone,就能保证每个日志流里的 tablet 的 leader 副本落在指定 observer 节点上,达到 leader 均衡。

另外还涉及到 tablegroup 机制等,详细可翻阅官方文档:数据均衡

再来说说手工 transfer 的操作,举个例子:两张表做关联查询(并且它们不在同一个 database 或者用户下,不能加入到同一个表组),但是它们的 leader 副本不在一个 observer 节点上,因此需要跨节点查询,如果 rpc 次数过多必然导致性能大幅下降,需要手工把两张表移动到一个 observer 节点上。

这个操作本质上就是把一个分片从一个日志流移动到另一个日志流,说白了只要两张表在同一个日志流上,那么他们的副本分布必然一样(分布在同样的3个observer 节点,并且 leader 副本在同一个 observer 节点)。命令如下:

--先通过 CDB_OB_TABLE_LOCATIONS 视图查看需要移动的表的 table_id、OBJECT_ID
--然后再查询另一张表所在的 LS_ID(即日志流ID)

--然后通过下面这个命令移动表即可
ALTER SYSTEM TRANSFER PARTITION TABLE_ID [=] table_id, OBJECT_ID [=] object_id TO LS ls_id TENANT = 'tenant_name';

tips:命令中使用 TABLE_ID + OBJECT_ID,同一张表的不同分区 TABLE_ID 一样,OBJECT_ID 不一样。

注意事项:transfer要等待活跃事务完成(默认100ms)。当活跃事务本身持续时间较长,且业务侧持续开启新事务时,transfer等不到活跃事务结束,导致transfer持续失败。可以考虑开启 transfer 杀事务机制规避:

alter system set _enable_balance_kill_transaction=true tenant=xxx;
alter system set _balance_wait_killing_transaction_end_threshold='20s' tenant=xxx;

相关文章

  • 有序队列与异步拼接任务

    最近遇到一个问题,有两个日志流(kafka)需要进行拼接,但是两个日志流并不是同步进行,而是其中一个日志流存在10...

  • logstash使用filter删除不需要的日志

    数据流 日志的流转路径:logstash收集log4j的日志,并对日志进行过滤,输出给elasticsearch,...

  • kafka和rocketmq

    kafka:日志传输rocketmq:订单,交易,充值,流计算,消息推送,日志流式处理,binglog分发 0. ...

  • 常用工具类

    字符串 流 文件 日志 多语言 测试

  • 数据库日志的原理

    数据库日志主要分为普通日志、重点日志两种类型 普通日志很容易理解这里就不赘述,重点日志着重介绍 一、innodb引...

  • 流(Streams)

    只在记录日志时使用流。 定义: 流是 printf() 和 scanf() 的替代。 优点: 有了流,在输出时不需...

  • JAVAio流理解

    1.IO流的概念: 2.IO流的分类: 1.通过流动的方法:输入 输出 2.通过操作单位:字节 字符 3.乱码情...

  • 理解“心流”

    心流(英语:Mental flow)在心理学中是指一种人们在专注进行某行为时所表现的心理状态。如艺术家在创...

  • 【K8s 精选】CKA - 了解日志架构和节点级日志

    1.日志架构简介 容器化应用的日志记录常用方式就是写入标准输出和标准错误流。集群日志级日志的存储和生命周期与节点、...

  • 11.log

    XI. 日志 把日志当作事件流 日志 使得应用程序运行的动作变得透明。在基于服务器的环境中,日志通常被写在硬盘的一...

网友评论

      本文标题:OceanBase4.0:理解日志流

      本文链接:https://www.haomeiwen.com/subject/utticjtx.html