Frun1na opened a new issue, #5672: URL: https://github.com/apache/rocketmq-dashboard/issues/5672
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version branch: `rocketmq-studio` git commit id: `6a68042f` deployed as: docker compose (`deploy/docker-compose.yml`, existing MySQL volume) ### Runtime Environment OS: Ubuntu 22.04 (WSL2) — no local Docker integration, so the scripts could not be executed here; the failure mode below is read off the guards and MySQL's documented behaviour for a missing table MySQL: 8.0 (the compose service) browser: not applicable ### Connected RocketMQ Cluster RocketMQ version: not applicable — the defect is in the MySQL upgrade scripts access mode: not applicable deployment: not applicable ### Describe the Bug Two files under `deploy/mysql/` still address tables that #2317 renamed on 2026-08-17, and nothing in the repository ever migrates the rename for an existing volume: - `upgrade-instance-id-pk.sql` (added 2026-08-13, untouched since) updates `rmq_topic`, `rmq_group`, `rmq_acl_rule`, `rmq_acl_user`, `rmq_data_source`, `rmq_instance`; the first two were renamed to `rmq_instance_topic` / `rmq_instance_group` by #2317. - `upgrade-query-history-context.sql` (added 2026-08-07, untouched since) alters `rmq_message_query` and `rmq_trace_query`, renamed to `rmq_instance_message` / `rmq_instance_trace` by the same commit. - `grep -rn "RENAME TABLE" .` finds nothing, and `deploy/mysql/` contains no script that bridges the old names to the new ones, so a volume created before 2026-08-17 never gets them. Two consequences, both of them wrong: 1. **On any database created or upgraded after #2317** (which is every deployment from the current branch), running these scripts aborts. Their guards probe a *column* or an index on the old table rather than the table itself, so an absent table reads as "needs the change": ```sql SET @message_query_column_exists := (SELECT COUNT(*) FROM information_schema.columns WHERE table_schema = @schema_name AND table_name = 'rmq_message_query' AND column_name = 'cluster_id'); SET @message_query_sql := IF(@message_query_column_exists = 0, 'ALTER TABLE rmq_message_query ADD COLUMN cluster_id VARCHAR(255) AFTER result_count', 'SELECT 1'); ``` `count = 0` → `ALTER TABLE rmq_message_query …` → `ERROR 1146 (42S02): Table 'rocketmq.rmq_message_query' doesn't exist`, and the `mysql` client stops at the first error in batch mode. `upgrade-instance-id-pk.sql` has no guard at all, so it fails on its very first `UPDATE rmq_topic t JOIN …`. 2. **On a volume that still has the old tables**, the scripts run, but every statement that touches a renamed table lands in a table the application no longer reads (`RmqMessageQuery` maps to `rmq_instance_message`, `RmqTraceQuery` to `rmq_instance_trace`), so the migration reports success without bringing the deployment closer to the current schema — only the parts that touch surviving tables (such as `rmq_instance.id`) take effect. The scripts tell operators to run them ("存量 MySQL 数据卷增量迁移", "Run once on existing deployments"), and the project has already fixed this exact class of defect once: #4722 ("The nameserver unique-key migration script references a dropped column and always aborts") was fixed by #4721. ### Steps to Reproduce 1. On a database initialized from `server/src/main/resources/db/schema.sql` (the authoritative DDL), list the tables: `rmq_topic`, `rmq_group`, `rmq_message_query` and `rmq_trace_query` do not exist; `rmq_instance_topic`, `rmq_instance_group`, `rmq_instance_message` and `rmq_instance_trace` do. 2. Run `mysql -uroot -p rocketmq < deploy/mysql/upgrade-query-history-context.sql`: the prepared `ALTER TABLE rmq_message_query …` fails with error 1146. 3. Run `mysql -uroot -p rocketmq < deploy/mysql/upgrade-instance-id-pk.sql`: the first statement fails with error 1146 on `rmq_topic`. 4. Check `git log -S "rmq_message_query" -- server/src/main/resources/db/schema.sql` and the #2317 commit message: the rename is the source of the mismatch, and no script renames anything. ### What Did You Expect to See? Either the scripts work on the schema they claim to upgrade, or they say plainly that the deployment is outside the supported upgrade path — instead of failing with a raw driver error halfway through, or silently writing to tables nobody reads. ### What Did You See Instead? Two scripts that cannot succeed on a current database, no migration for the #2317 renames at all, and no statement anywhere that pre-#2317 volumes are unsupported. ### Additional Context - I am happy to implement whichever direction maintainers pick: (a) add the missing rename migration (rename the four tables in the right order, then let the existing scripts run against the current names), or (b) declare pre-#2317 volumes unsupported and make it explicit — for example guard the two scripts on table existence so they skip with a message, and update their headers and `deploy/README.md`, which currently only mentions the demo scripts. - What cannot stay as it is: a "run this on existing deployments" instruction that aborts with `1146`, and a rename with no migration behind it. - duplicate check: searched open/recent issues and PRs for `rmq_message_query`, "upgrade script", "existing volume" and "table rename"; the only related item is the closed #4722/#4721 pair for the nameserver script. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
