Author: metatron
Description:
When accessing INFORMATION_SCHEMA, query hangs up on random schemas and causes a widespread block for that server/listener.
- This occurs especially when accessing INFORMATION_SCHEMA through listener s2/s4/s5.labsdb (192.168.99.12). No timeout.
- This occures also when accessing INFORMATION_SCHEMA through listener s1.labsdb (192.168.99.1), but here with kill/timout of 16 sec.
-both: kill clean-ups take up to 500 sec.
- This does not occur when accessing INFORMATION_SCHEMA through listener s3.labsdb (192.168.99.3) - still old DB.
Currently, access to INFORMATION_SCHEMA on new Servers is basically very slow. A simple query takes up to 3 sec (if it doesn't hang up). As (console)-clients do auto-rehashing on connect (unless it's turned off), they hang, too.
Maybe it's realted to spinning-rust, but this doesn't explain the difference between s1 and eg. s5. - and it shouldn't hang up at all, even if running slow.
Is there something like innodb_stats_on_metadata enabled for tokuDB? Or are some schemas kind of broken?
References:
http://tools.wmflabs.org/tools-info/misc/schema-block-hang.png
http://tools.wmflabs.org/tools-info/misc/schema-block-cleanup.png
Simple Metadata-query:
SELECT table_schema, data_length, index_length
FROM INFORMATION_SCHEMA.TABLES
WHERE table_schema = '<some_schema>'
Version: unspecified
Severity: critical