| Bug #117202 | mysqlsh "stuck" for a long time after DDL load | ||
|---|---|---|---|
| Submitted: | 13 Jan 17:15 | Modified: | 14 Jan 14:24 |
| Reporter: | Vinicius Ruoso | Email Updates: | |
| Status: | Not a Bug | Impact on me: | |
| Category: | Shell Dump & Load | Severity: | S5 (Performance) |
| Version: | 8.4.3 | OS: | Ubuntu (24.04) |
| Assigned to: | MySQL Verification Team | CPU Architecture: | Any |
[14 Jan 4:53]
Alfredo Kojima
you can see what it's doing by starting mysqlsh with --verbose --log-sql=all --log-level=debug3
Description: When running the util.loadDump utility for a large number of tables (~500k), after the DDL is executed and the view DDL is completed, the process takes 100% of one CPU for a long time, after the output below: Checking for pre-existing objects - done Executing common preamble SQL - done Executing DDL - done Executing view DDL - done Can you clarify what is being done after that step that can take so long to run? How to repeat: Create a dump from a database with a large number of tables. Run the loadDump utility like the command below: util.loadDump("dumpdata", {dryRun: false, threads: 128, loadDdl: true, loadData: false, ignoreExistingObjects: true, updateGtidSet: "off"}) After view DDLs are done executing, you can see that one CPU spikes to 100% and there is no feedback on what is happening. System metrics do not show any relevant disk or network IO.