近日在客户现场进行进行ob数据库的高可用故障测试的时候，发现一些之前没注意的小细节，第一时间还以为是OB元数据出现问题，毕竟这个以前遇到过一次。在高可用测试的时候，一般会看表（分区）的leader副本在哪一个observer节点上，当机器故障的时候，观察leader副本的选主到哪一个节点上。这个时候统计leader副本总数竟然发现用__all_virtual_meta_table统计出来的结果和实际租户中表（分区）总数完全对不上。实际租户下一共有10张表，其中2张非分区表，8张分区表，其中都是采用hash分区做成128个分区。从以上的结果来看，理论上查询__all_virtual_meta_table中该租户leader总数应当为：128*8+2=1026个。但实际查询出来只有132个。
-- 客户现场查询结果：
-- 查询leader总数
obclient [oceanbase]> select svr_ip,count(*) from oceanbase.__all_virtual_meta_Table where tenant_id=1003 group by svr_ip;
+------------+---------+
| svr_ip | count(*)|
+------------+---------+
| 10.xx.xx.2 | 132 |
| 10.xx.xx.3 | 132 |
| 10.xx.xx.4 | 132 |
+------------+---------+
-- 查询dba_tables，可以知道该租户下各用户表分布情况
obclient [BMSQL]> select owner,count(*) from dba_tables group by owner;
+--------+----------+
| OWNER | COUNT(*) |
+--------+----------+
| BMSQL | 10 |
| SYS | 2 |
+--------+----------+
-- dba_tab_partitions结果。可以知道BMSQL用户下有8张分区表，每个分区表为128个分区
obclient [BMSQL]> select table_owner,table_name,count(*) from dba_tab_partitions group by table_owner,table_name;
+--------------+------------------+----------+
| TABLE_OWNER | TABLE_NAME | COUNT(*) |
+------------=-+------------------+----------+
| BMSQL | BMSQL_CUSTOMER | 128 |
| BMSQL | BMSQL_DISTRICT | 128 |
| BMSQL | BMSQL_HISTORY | 128 |
| BMSQL | BMSQL_NEW_ORDER | 128 |
| BMSQL | BMSQL_OORDER | 128 |
| BMSQL | BMSQL_ORDER_LINE | 128 |
| BMSQL | BMSQL_STOCK | 128 |
| BMSQL | BMSQL_WAREHOUSE | 128 |
+--------------+------------------+----------+
-- 内部环境查询结果：
-- 查询leader总数
obclient [oceanbase]> select svr_ip,count(*) from oceanbase.__all_virtual_meta_Table where tenant_id=1003 group by svr_ip;
+-------------+----------+
| svr_ip | count(*) |
+-------------+----------+
| 10.xx.xx.62 | 1026 |
| 10.xx.xx.63 | 1026 |
| 10.xx.xx.64 | 1026 |
+-------------+----------+
-- 查询dba_tables，可以知道该租户下各用户表分布情况
obclient [BMSQL]> select owner,count(*) from dba_tables group by owner;
+-------+----------+
| OWNER | COUNT(*) |
+-------+----------+
| TPCC | 10 |
+-------+----------+
-- dba_tab_partitions结果。可以知道BMSQL用户下有8张分区表，每个分区表为128个分区
obclient [BMSQL]> select table_owner,table_name,count(*) from dba_tab_partitions group by table_owner,table_name;
+-------------+------------------+----------+
| TABLE_OWNER | TABLE_NAME | COUNT(*) |
+-------------+------------------+----------+
| TPCC | BMSQL_WAREHOUSE | 128 |
| TPCC | BMSQL_DISTRICT | 128 |
| TPCC | BMSQL_CUSTOMER | 128 |
| TPCC | BMSQL_HISTORY | 128 |
| TPCC | BMSQL_NEW_ORDER | 128 |
| TPCC | BMSQL_OORDER | 128 |
| TPCC | BMSQL_ORDER_LINE | 128 |
| TPCC | BMSQL_STOCK | 128 |
+-------------+------------------+----------+
从以上两个环境查询结果可以看出，在当时会认为OB元数据出现了查询不准确了。后面在回来之后，咨询了OB专家，同时也查询了文档，关于元数据表（__all_virtual_meta_Table）的解释：对于表组tablegroup 来说，应该只会记录 PG (Partition Group) 的位置信息，不会记录具体某个表的分区的位置信息。如果加了binding=true的话，表组里面的表就再也没有自己独立的日志流了，一个pg对应一个日志流。如果binding=false的话，一个分区就对应一个独立的日志流。因此查询meta表之后算分区副本的公式就变成：用户BMSQL下128个分区+用户BMSQL下2张非分区表+用户SYS下2张非分区表=132个。
看到binding=true，不由的想起之前业务用了这个特性导致物理备份失败的案例。主要坑的点就是对于绑定的表组，不支持将表随意迁移进/迁移出该表组，只支持先删除其中所有的表，最后再删除该表组。如果看过比较早的官方性能测试里面文档都知道，它在这里就使用了这个特性，经过后来客户确认以及内部模拟确认，可以断定就是在建立表组的时候用了binding=true的特性导致查询meta表和以往的经验查询有出入。另外生产尽量别用这个特性，就单纯不支持将表随意迁出表组这一点，就是一个大坑，也可能会带来一些意外的惊喜哦。
写在最后，如果你在后续的运维中也遇到这个查询不符合预期，千万不要以为是元数据出现问题，也有可能是你使用的方式不对。
