zone 优先级使用random和zone1;zone2;zone 3的区别是什么
在 OceanBase 中,primary_zone
参数用于指定租户提供读写服务的 Zone 的优先级。以下是两种常见设置的区别:
-
primary_zone = 'RANDOM'
:- 领导者(Leader)分区会随机分配到任何可用的 Zone。
- 这种设置可以使得流量均匀分布在所有 Zone 上,提高整体集群的利用率。
- 适用于需要均衡负载且没有特定读写需求的场景。
-
primary_zone = 'zone1;zone2;zone3'
:- 领导者(Leader)分区会优先分配到
zone1
,如果zone1
不可用,则会尝试分配到zone2
和zone3
。 - 这种设置可以确保在某些 Zone 出现故障时,仍然有备用的 Zone 可以提供服务。
- 适用于需要确保某个特定 Zone 优先提供服务的场景,例如
zone1
可能有更高的性能或更低的延迟。
- 领导者(Leader)分区会优先分配到
总结:
-
RANDOM
设置适用于需要负载均衡和最大化资源利用率的场景。 -
zone1;zone2;zone3
设置适用于需要确保特定 Zone 优先提供服务的场景。
检索到的文档如下:
当设置租户的 primary_zone
为 RANDOM
时,表示新建表分区的 Leader 随机到任一 OBServer 节点,使得不同分区的 Leader 分散在不同 Zone 的节点上,使得整个集群机器利用率达到最大化。而设置 primary_zone = 'zone1;zone2,zone3'
表示该租户优先由 zone1
提供读写服务,zone1
比 zone2
、zone3
的优先级高,zone2
和 zone3
是同一优先级。
检索到的文档如下:
在 OceanBase 数据库中,设置租户的 primary_zone
为 RANDOM
或 zone1,zone2,zone3
同优先级的主要区别在于 Leader 副本的分布策略:
- 当
primary_zone
设置为RANDOM
时,新建表分区的 Leader 会随机分配到任一 OBServer 节点,这种方式可以使流量均匀分布在各个节点上,提高整体集群的利用率。 - 当
primary_zone
设置为zone1,zone2,zone3
同优先级时,Leader 副本会在这些 Zone 之间进行均衡分布,每个 Zone 的优先级相同,但 Leader 的分配并不是完全随机的,而是根据算法在这些 Zone 之间进行平衡。
总结来说,RANDOM
方式更加随机,适合需要最大化集群利用率的场景;而 zone1,zone2,zone3
同优先级的方式则更加可控,适合需要在特定 Zone 之间进行均衡分布的场景。
检索到的文档如下:
除了提到的区别之外,Key 分区和 Hash 分区还有其他一些不同点:
-
分区键的选择:
-
Hash 分区:分区键可以是用户自定义的表达式,只要这个表达式的返回值为
INT
类型即可。 -
Key 分区:分区键只能是列,或者不指定。如果不指定分区键,那么分区键将是表的主键列。如果没有主键,有
UNIQUE
键,那么分区键将是UNIQUE
键。
-
Hash 分区:分区键可以是用户自定义的表达式,只要这个表达式的返回值为
-
适用场景:
- Hash 分区:适用于不能指定数据的分区键的列表特征,不同范围内的数据大小相差非常大,并且很难手动调整均衡的情况。它通常用于给定分区键的点查询,例如按照用户 id 来分区。
- Key 分区:适用于需要均匀分布数据的场景,尤其是当表中有主键或唯一键时,Key 分区可以利用这些键来确保数据的均匀分布。
-
内部实现:
- Hash 分区:使用用户提供的表达式或列进行哈希计算,然后根据哈希值进行分区。
- Key 分区:系统会对分区键做一个内部默认的哈希函数后再取模,用户通常无法通过简单的计算来得知某一行属于哪个分区。
-
分区键的类型:
-
Hash 分区:分区键必须是
INT
类型,或者是返回为INT
类型的表达式。 -
Key 分区:分区键可以是任意类型,不受
INT
类型的限制。
-
Hash 分区:分区键必须是
-
分区数量:
- Hash 分区:分区数量由用户在创建表时指定,且不支持新增或删除分区。
- Key 分区:分区数量同样由用户在创建表时指定,但不支持新增或删除分区。
-
分区命名:
- Hash 分区:如果创建时没有指定分区的名字,分区的命名由系统根据命名规则完成。对于一级分区表,每个分区分别命名为 p0、p1、…、pn。
- Key 分区:同样地,如果创建时没有指定分区的名字,分区的命名由系统根据命名规则完成。
检索到的文档如下:
根据提供的文档片段,每个 Zone 的优先级相同,但 Leader 的分配并不是完全随机的,而是根据一种平衡算法在这些 Zone 之间进行平衡。这种平衡算法涉及到多个方面,主要包括以下几个关键点:
-
LS Leader 均衡:在 LS 数量均衡的前提下,让 LS Leader 平均分布在 Primary Zone 上。例如,用户变更租户的
PRIMARY_ZONE
后,负载均衡后台线程会根据PRIMARY_ZONE
的第一优先级动态调整 LS 数量,之后再对 LS 进行切主,保证第一优先级的各 Zone 内均有且仅有一个 LS Leader。(来源:doc_id 7949) - 分布式选举优先级:在选举过程中,Leader 将通过续约动作感知 Follower 副本的优先级变化,当 Follower 副本的优先级高于自己的时候,Leader 将通过主动切主动作,将 Leader 转移至 Follower 副本。目前的优先级从高到低仅包含用户指定的 Leader 和 Primary Zone。(来源:doc_id 7805)
- Primary Zone 设置:Primary Zone 的设置隐含的包含了 Leader 偏好的 Region 位置。具体指用户设置 Primary Zone 时包含两层语义:被指定的 Primary Zone 为 Leader 的偏好 Zone 的 Region;被指定 Primary Zone 所在的 Region 为 Leader 偏好的 Region。Leader 会被优先调度到最高优先级的 Zone 上去,如果最高优先级的 Zone 上的副本不能成为 Leader,会优先选择同一个 Region 内的其他 Zone 作为 Leader 的位置,从而保证业务访问 OceanBase 数据库尽量不跨城。(来源:doc_id 18521)
详情请参考: