1、日志流和zone的个数是什么关系呢？是unit_num * primary_zone个数（是不是和副本类型有关，全能型的副本上才有日志流，看的是全能型副本的个数），就有多少个日志流吗？
比如：unit_num =2，PRIMARY_ZONE=‘zone1,zone2,zone3’ 也就是日志流个数是 23=6
假如PRIMARY_ZONE=‘zone1;zone2,zone3’ 采用分号分隔，那么 日志流个数是21 = 2
并且每个日志流可以属于多个分区，所以就会出现多个leader和follower，假如表有10个分区，日志流有2个，是不是每5个分区对应一个日志流（也就是有10个leader）
这样理解有问题吗？
2、副本数是不是默认就是zone的个数，并且创建表时也可以指定副本数但是最小是3个？而和observer个数没有关系？
@论坛小助手
几个概念：
1、日志流
数据变更记录的基本单位，包含多个 Tablet 和 Redo 日志；
2、副本
每个日志流可以有多个副本，副本类型决定了是否参与 Paxos 投票
3、Locality决定副本在zone的分布
是由Locality控制日志流副本在各 Zone 上的分布与类型，创建租户的时候默认不指定在集群的每一个可用区内各创建一个全功能副本；
4、Primary Zone
为租户设置Primary Zone，用以描述 Leader 副本的偏好位置
5、计算一个租户的日志流
公式：LS 数量 = UNIT_NUM * first_level_primary_zone_num
下面的例子理解first_level_primary_zone_num的值；
primary_zone=(zone1,zone2,zon3) 其first_level_primary_zone_num为3
primary_zone=(zone1;zone2,zon3) 其first_level_primary_zone_num为1
primary_zone=(zone1,zone2;zon3) 其first_level_primary_zone_num为2
注意：广播日志流只有1条，特殊情况，不符合上面计算公式
详细参考
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000821579
6、下面这个理解不对，涉及负载均衡。
每个日志流可以属于多个分区，所以就会出现多个leader和follower，假如表有10个分区，日志流有2个，是不是每5个分区对应一个日志流（也就是有10个leader）
每个日志流一个Paxos组，每个组一个leader，在4.x日志流的leader跟分区个数无关;
10个是否均匀打散分布在2个日志流跟负载均衡有关，不一定是平均分，详细参考上面的连接有详细均衡情况说明。
比如：unit_num =2，PRIMARY_ZONE=‘zone1,zone2,zone3’ 也就是日志流个数是 2 *3=6
假如PRIMARY_ZONE=‘zone1;zone2,zone3’ 采用分号分隔，那么 日志流个数是2 * 1 = 2
这一部分理解是对的 。 注意：日志流也是根据日志流组的形式出现，默认三副本形式
并且每个日志流可以属于多个分区，所以就会出现多个leader和follower，假如表有10个分区，日志流有2个，是不是每5个分区对应一个日志流（也就是有10个leader）
这句话有点问题：
一个observer 只能有一个或者0个 该租户的leader日志流 。该租户的 10个分区的leader副本都在这个observer上的话，仅仅一个leader 日志流。 select * from dba_ob_ls_locations. select * from dba_ob_ls; select * from dba_ob_tablet_locations 等ls 关键子的视图进行查看。 记住 一个租户在一个observer上仅仅一个leader日志流，最多一个 leader。
obclient>ALTER TENANT mq_t1 locality=“F{1}@zone_1,F{1}@zone_2,F{1}@zone_3”;
这么理解吧：
1-1-1 架构租户T的 UNIT=1 如图每个unit中3个表的假设共6个分区(非分区表看做特殊只有1个分区)；
primary_zone设置为(z1,z2,z3) ，期望日志流的1个leader打散在3个zone, 有3个日志流，每一个日志流有1个leader，其他为follower，形成一个Paxos组 ；
上面就是多个不同的分区聚合在一个日志流里面，比如在日志流1Paxos组中，对于T1P0、T1P1每一个分区单独起来就是其leader在observer1上(也就是你上面语句查出来看到的一个observer有多个leader效果)。
实际是该日志流的leader在observer1上，该日志聚合了多个表或者分区。
多谢，这部分明白了，我再请教个扩容的问题
也是，三个zone每个zone有1个observer，
首先调整primary_zone 不能扩容，前面的几个概念那里有回：
为租户设置Primary Zone，用以描述日志流 Leader 副本的偏好位置，它影响的日志流的leader 分布，不是用来扩容的！
扩容的话，如果是租户扩容，可以调整租户的规格(垂直扩容)或者unit_num(水平扩容)
你这里是增加一个zone,对于集群角度看是有4个zone，但是你之前创建租户的时候的
Locality决定副本在zone的分布 ，你的租户的副本是3副本，如果你要为他增加多一个副本，可以调整租户的Locality属性。
查询 select * from dba_ob_tenants where tenant_name=’<你租户名字>’ ,看一下LOCALITY字段就可以验证。
上面错误提示应该是你租户LOCALITY只有3个zone,而你设置primary_zone却是4个，提示你个数不对吧。
假如还是三个zone，每个zone上有一个observer，假如服务器资源有限了，那扩容的话只能是变为每个zone上两个observer，然后再去设置unit_num=2，来扩容，这样的话是不是分片表的数据就会打的更散呢？
并且这种扩容只能是每个zone都增加一个observer，不能只在单个zone上增加observer，因为这样的话unit_num没法调整，也就导致了新加的observer没用上。这样理解对吗？
如果服务器资源充足，可以直接调整unit规格来扩容。
扩容是是可以这么理解。
至于分片是否打得更散，不一定。
你可以primary_zone，干预OB也提供表组技术，当然对于分布式事务响应时延不敏感，打散是可以，甚至对表在设计的时候考虑分区，扩容的由OB集群自动均衡区打散，这样热点数据不集中在某些机器，性能也就上去。
好，多谢老师
我看官网上有写“ 通过调整 Primary Zone 实现租户扩缩容”以为是水平扩容
老师您好，再请教个问题，扩容完成后，我又进行了缩容，将unit_num 从 2 变为了 1 .
这时候是不是就可以把zone中没有unit的observer停机下掉了呢？我使用操作的租户进行连接这三台机器，发现连不上了
因为都是使用的obd操作的，那obd config.yaml文件中，手动扩容增加的几个节点的信息，是不是需要手动删除一下？
