在查一下 这个信息
select tenant_id,DATABASE_NAME,TABLE_NAME,PARTITION_NAME,TABLE_ID,TABLE_TYPE,LS_ID,ZONE,SVR_IP,role from oceanbase.CDB_OB_TABLE_LOCATIONS where table_type=‘user table’ and role=‘leader’;
2.primary_zone=RANDOM和primary_zone=zone1,zone2,zone3实际也是一样的。你当前不一致原因不是因为修改region导致的么
3.看你上述操作仅修改了region并未修改过primary_zone
4.当前仅修改了region，但是primary_zone目前还是三个zone不符合负载均衡的需求，这可能是属于非标操作了这边需要先去确认下。
当前如果修改primary_zone='zone1,zone2;zone3’就应该正常了
现在就是1006和1010两个租户的partition leader分布不一样(不应该分布到region=shanghai的zone上)，分析原因就是primary_zone设置的不一样，一个是random，一个是zone1，zone2，zone3.
把1006的primary_zone改成后者，所有的leader都不会分布到shanghai这个zone上
1 个赞
麻烦确认下是这个情况么
- primary_zone= random情况修改region=shanghai，仍存在leader分布在shanghai这个zone上
2.primary_zone= zone1，zone2，zone3情况修改region=shanghai，所有的leader都不会分布到shanghai这个zone上
确认是这个情况
1 个赞
这是另外一个租户mysql(1006),primary_zone=random，有2个 partition leader 在zone3上
test租户(1010),primary_zone=zone1,zone2,zone3 上的partition leader 不存在这个情况，都分布在zone1、zone2上。
1 个赞
修改zone的region，违反了primary_zone的约束的。
这种操作属于非标操作了，这边已经反馈，后续应该会添加限制同优先级zone存在多个情况下，禁止修改其中zone的region。
学习一下
你好，关于修改region这边内部讨论了一下。选举层判断是否是primary_region的逻辑是取z1的region作为判断标准，当z3的region被修改后，会认为z3不再是在primary_region中导致leader切主。
一般zone是绑定了region的，比如两地三中心都是物理上划分了固定region，实际场景下不应该有改region的动作。
关于后续是否限制修改region问题，预期用户是可以改完再调整所有租户primary_zone完成zone的region转换的。所以后续不会进行限制
非常好的！！！
学习一下！
实践出真知，感谢分享实战经验
赞一个！
宝贵的经验分享，谢谢！