Understanding reload @@config_all vs reload @@metadata in Dble and How to Resolve Metadata Issues

The article uses Dble version 3.21.06.0 to illustrate common problems where tables or columns cannot be found after creating or modifying them on backend nodes.

Problem 1: After starting Dble and creating table sharding_2_t1 on all backend nodes, executing reload @@config_all still results in missing metadata for the table.

Problem 2: After adding an age column to table sharding_4_t1 on all backends, reload @@config_all allows queries using the new column but fails when the column is referenced in an ORDER BY clause.

The article then describes the usage of the two reload commands as documented in the Dble official manual.

reload @@config_all (equivalent to reload @@config after version 2.19.09.0) reloads all configuration files (user.xml, db.xml, sharding.xml). Optional flags: -s: skip testing backend connections. -f: close frontend connections for all changed dbGroups (with -r all dbGroups are treated as changed). -r: force reloading all backend connection pools without smart change detection.

When this command is executed, only metadata for tables whose configuration has changed is reloaded; unchanged tables retain their previous metadata unless the -r flag is used.

reload @@metadata reloads all metadata and supports filtered expressions such as:

reload @@metadata where schema=? [and table=?]

reload @@metadata where table in ('schema1.table1','schema2.table2',...)

The key distinction is that reload @@config_all only updates metadata when the configuration itself changes, whereas reload @@metadata must be run manually to synchronize metadata after backend schema changes.

Analyzing the two problems, the article concludes that both errors stem from the misconception that reload @@config_all always refreshes metadata; in reality it only does so when configuration changes occur. Therefore, after creating tables or adding columns without altering Dble configuration, the correct command to synchronize metadata is reload @@metadata.

For Problem 2, the query SELECT age FROM sharding_4_t1 succeeds because Dble forwards the simple query directly to the backend where the column exists, but the ORDER BY age fails because Dble needs metadata for the column to perform ordering.

To troubleshoot metadata issues, the article recommends using check full @@metadata, which lists all tables' metadata and supports various filters. The command reveals that the metadata for sharding_2_t1 and sharding_4_t1 had not been synchronized.

After executing reload @@metadata, a subsequent check full @@metadata shows that the metadata for both tables is now correct, allowing normal operations without errors.

Images illustrating the error messages and the successful metadata synchronization are included throughout the article.