Why Direct DB Updates Fail in Nacos and How to Properly Batch Update Configurations

When managing dozens of micro‑services with Nacos as a dynamic configuration center, it is tempting to skip the web console and execute a raw UPDATE statement on the Nacos backend database to change a configuration item such as a database connection URL. The update seems to succeed, but the services do not pick up the new value until the configuration is manually edited and republished in the Nacos console.

Core Reason: Bypassed MD5 Checksum and Event Notification

Nacos is not merely a static viewer for configuration data; it is an active, real‑time, event‑driven configuration management platform. Directly modifying the database skips two essential mechanisms:

Data consistency verification (MD5 checksum)

Configuration update notification

The critical field is the md5 column in the config_info table.

Standard Configuration Publishing Process

User operation : Publish a new configuration via the Nacos web console or Open API.

Server processing :

Compute MD5 : Nacos calculates an MD5 hash of the submitted content field.

Store data : The new content and its MD5 value are saved into the content and md5 columns of the database.

Publish notification : After storage, the server pushes a change notification to all clients that have subscribed to the configuration, containing dataId, group and the new md5 value.

Client response : Each client compares the received MD5 with the MD5 of its locally cached configuration; if they differ, the client pulls the full configuration from the server.

This flow guarantees real‑time, low‑latency updates while avoiding unnecessary network traffic.

What Happens When You Update the Database Directly

User operation : Execute UPDATE config_info SET content = 'new content' WHERE ....

Database state : The content column is updated, but the md5 column remains the hash of the old content, leaving the row inconsistent.

Server state : Nacos server is unaware of the change because no API call refreshes its internal cache or triggers an event.

Client state : Clients receive no change notification, continue using the old configuration, and assume nothing has changed.

Thus the modification appears successful in the database but is invisible to the running services.

Why Clicking “Publish” in the Console Fixes the Issue

When you open the edit page, Nacos loads the current content (the manually edited value). Clicking the “Publish” button fully triggers the standard flow described above:

The server receives the new text.

It recomputes the MD5 of the new content.

It stores both the new content and the newly computed MD5 into the database, correcting the inconsistency.

It pushes a configuration‑change notification to all subscribed clients.

Clients receive the updated MD5, detect the difference, and immediately pull the new configuration, resolving the problem.

Practical Advice: Proper Way to Batch‑Update Nacos Configurations

Direct database manipulation is unsafe and will not trigger the necessary events. The recommended approach is to use Nacos’s Open API, which supports programmatic and automated configuration management.

Example curl command to publish or modify a configuration:

curl -X POST "http://[NacosServerAddress]:8848/nacos/v1/cs/configs" \
  -d "dataId=[Data ID]" \
  -d "group=[Group]" \
  -d "tenant=[Tenant ID, if any]" \
  -d "content=[New configuration content]" \
  -d "type=yaml"   # specify format such as properties, json, etc.

This command can be wrapped in a shell or Python script that iterates over a list of dataId and

content> values, enabling safe and reliable bulk updates.

Conclusion

Nacos’s configuration update mechanism involves MD5 verification, event‑driven notifications, client long‑polling, and active pushes. Bypassing this mechanism by editing the database directly breaks consistency and prevents clients from seeing the changes. Always use the official API or console to modify configurations; this is the best practice for maintaining a stable and reliable system.