Details
-
Bug
-
Status: Open (View Workflow)
-
Critical
-
Resolution: Unresolved
-
10.3.32
-
None
-
Alma Linux
Description
When I do an:
mysqlcheck --auto-repair --verbose --optimize --all-databases
on my hosting site, the optimization/repair hangs on many databases on the wordpress options table.
Although these databases are small, the optimization hangs on the same table: wp_options.
Here is the process list after I eventually killed the optimization after 10+ minutes..
Killing doesn't help either – either it's the rollback or I don't know why but after it's killed, it stays like that.
This happens in about a dozen of the 300 databases that are being optimized. But prevents all other databases from being optimized, as the mysqlcheck gets stuck at these tables.
MariaDB [psa]> show processlist;
|
+------+-------------+-----------+--------------+---------+------+---------------------------------+---------------------------------------------------------------------------+----------+
|
| Id | User | Host | db | Command | Time | State | Info | Progress |
|
+------+-------------+-----------+--------------+---------+------+---------------------------------+---------------------------------------------------------------------------+----------+
|
| 1974 | admin | localhost | cb_web | Killed | 2443 | Parallel repair | OPTIMIZE NO_WRITE_TO_BINLOG TABLE `wp_options` | 0.000 |
|
| 6457 | admin | localhost | other_hst | Query | 388 | Parallel repair | OPTIMIZE NO_WRITE_TO_BINLOG TABLE `wp_options` | 0.000 |
|
| 7291 | admin | localhost | psa | Query | 0 | Init | show processlist | 0.000 |
|
+------+-------------+-----------+--------------+---------+------+---------------------------------+---------------------------------------------------------------------------+----------+
|
no warnings are shown, and SHOW WARNINGS shows nothing, nothing in the logs.
If the --optimize option is removed, it does NOT hang. The timing is enormous as the databases reside on SSD drive.
Attachments
Issue Links
- relates to
-
-
- Open
-