背景
日志流是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
2. 日志流的数量
刚才的测试中日志流的数量会跟随 primary_zone 的变化而变化，实际上公式为：
日志流数量 = unit number * primary_zone的第一级个数
数据均衡与手工 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;
