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