2
Shane Bester made a suggestion as a comment on my bug report which explains that this is a known bug and will be resolved in next release. More importantly, there is a workaround which I've tried with great success. Thanks Shane wherever you are!
internal_tmp_mem_storage_engine=MEMORY
Shane said this:
Thanks for the test data. Found a workaround on 8....
1
SELECT t1.run_name, hardware_used, COUNT(*) times_used
FROM hardware t1
JOIN hardware t2 USING (hardware_used)
WHERE t1.run_name >= t2.run_name
GROUP BY t1.run_name, hardware_used
ORDER BY t1.run_name;
fiddle
1
If your instances are accessible over the net than you can simply dump the prod instance on the dev instance via the host having required utilities and access to both instances:
mysqldump --host 10.20.30.40 \
-u myaccount1 \
-pmypassword1 \
--all-databases \
--events \
--routines \
| mysql --host 20.30.40....
1
Suggestions to consider for your my.cnf [mysqld] section
innodb_lru_scan_depth=100 # from 1024 to conserve 90% of CPU cycles used for function
innodb_buffer_pool_instances=8 # from 16 to reduce overhead until more RAM is avail
innodb_flush_neighbors=2 # from 0 to clear innodb_buffer_pool_pages_dirty quicker
thread_cache_size=100 # from 13 to reduce ...
1
ibdata1 never shrinks.
.ibd files never shrink.
When a table is in ibdata1 and is ALTERed, space in that file is temporarily consumed, thereby possible stretching the file.
With .ibd, an ALTER will probably create a new copy, then toss the old one, thereby temporarily using diskspace, then releasing it.
There are too many variables to make any predictions. ...
Only top voted, non community-wiki answers of a minimum length are eligible
