共计 2374 个字符，预计需要花费 6 分钟才能阅读完成。
作者：吴金玲
爱可生 dble 我的项目团队成员，次要负责 dble 相干的日常测试工作，善于对 dble 中呈现的问题进行排查。酷爱测试工作，余生欲将测试工作进行到底。
本文起源：原创投稿
* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。
同步元数据，reload @@config_all or reload @@metadata？
一、本文以 dble 3.21.06.0 版本为例，首先让咱们来看看社区常常遇到的几类找不到表或者表字段的问题
sharding.xml 的要害配置如下：
问题 1 ：启动 dble 后，在所有后端节点都建设了表 sharding_2_t1，而后在 dble 治理端执行 reload @@config_all 命令，查问表 sharding_2_t1 数据及向表 sharding_2_t1 中插入数据，均报找不到表的 metadata 信息（如下图所示），为什么？
问题 2 ：在后端节点对表 sharding_4_t1 减少一个 age 字段，且已确保所有后端节点都减少了这个字段，而后执行 reload @@config_all，对表进行查问应用新增的字段没问题，但应用 order by 就提醒找不到这个字段（如下图所示），为什么？
二、在答复呈现以上问题的起因之前，首先让咱们来看看 reload @@config_all 和 reload @@metadata 的应用阐明（具体可参见 dble 官网文档：https://github.com/actiontech…），这样可能使咱们更好的了解问题
1.reload @@config_all（2.19.09.0 版本之后性能齐全等同于 reload @@config）
从新加载所有配置，波及 3 个 xml 配置文件（user.xml，db.xml，sharding.xml），同时 reload @@config_all 还有 3 个可选参数的模式：reload @@config_all [-s] [-f] [-r];
-s 跳过测试后端链接，默认不加此参数会对配置中的后端链接进行测试，测试失败将返回 ERROR；
-f 敞开所有变更的 dbGroup（同时加 - r 参数则所有 dbGroup 都会被视为变更）相干的处于事务中的前端链接, 如果无此参数默认仅将相应后端链接放入旧链接池。
-r 不做智能判断, 将所有后端连接池全副从新加载一遍。不加此参数时，将对新配置进行智能判断，只会对增删改的连接池做变更，不影响未作变更的连接池。
相干影响 ：当执行此命令时，表的配置信息产生变更时，波及到的表的 meta 信息才会被重载，否则放弃原有表 meta 信息。另外，如果蕴含 -r 参数则不做上述判断，全副从新加载 meta 数据。如果不蕴含 -r 然而蕴含 -s 参数，则对 metadata 是否须要从新加载的计算时，疏忽所有 dbGroup/dbInstance 的变更。留神，不能在配置变更中体现的某些变动是无奈从新加载 metadata 的，比方一个带有默认 shardingNode 的 schema 尝试通过删除配置将拆分表或者 global 表变成非拆分表是不符合规范的。该当防止这种操作。
2.reload @@metadata
reload @@metadata 的作用是从新加载所有元数据信息，同时还有两种扩大的过滤表达式的模式：
reload @@metadata where schema=? [and table=?]：从新加载指定 schema 中所有表或指定表的元数据信息。
reload @@metadata where table in (‘schema1.table1′ ,’schema2.table2′,’schema1.table3’,…)：从新加载 schema1 中 table1,table3 和 schema2 中 table2 的元数据信息。
从以上 reload @@config_all 和 reload @@metadata 的应用阐明能够看出，二者在加载元数据时的次要区别为：reload @@config_all 只会对配置中的变更项进行从新加载 metadata，对配置未做变更的项须要手动执行 reload @@metadata 同步变更的元数据。
三、了解了 reload @@config_all 及 reload @@metadata 的区别后，咱们再来剖析呈现后面两个问题的起因。
不难看出，问题 1 和问题 2 的报错都是因为在配置没有产生变更的状况下，在后端节点建表或批改表构造后，认为能够通过执行 reload @@config_all 同步到变更的表的元数据导致的。这里使用者有一个常见的误区，认为所有场景下执行 reload @@config_all 都会触发从新加载元数据，但实际上只有当配置同时产生变更时才会同步更新元数据，其余场景都须要手动执行 reload @@metadata 将后端表的元数据同步到 dble 中。
另外，问题 2 中为什么 select age from sharding_4_t1 可能查问胜利，这是因为此查问属于简略查问，间接下发语句到后端节点执行即可，dble 外部不须要用到 age 字段，而后端节点存在 age 字段，所以执行胜利。
四、为了便于排查元数据相干的谬误，能够应用 check full @@metadata 查看以后 dble 中所有表的元数据信息。
check full @@metadata 还反对按多种条件过滤（具体可参见 dble 的官网文档：https://github.com/actiontech…）
通过以上查问后果不难发现，表 sharding_2_t1 和表 sharding_4_t1 的元数据均未同步到更新。
执行 reload @@metadata 后，再次执行 check full @@metadata 查问元数据信息：
通过以上后果能够看到表 sharding_2_t1 和表 sharding_4_t1 曾经同步到正确的元数据信息，此时能够对表进行惯例操作而不会报错：
