Invalidating query cache entries replication
However, the Query Cache still does some work before finding out that query_cache_size is 0 and returning.For example, Query Cache::invalidate() builds up a list of tables used, and calls Query Cache::invalidate_table().
Visit Stack Exchange I'm running a 4 servers master-master cluster of My Sql. Replication topology: 1 - 1 UPDATE It seems that server 3 has its SBM at 0, while the other servers are jumping up and down. It looks like the server is busy doing something, and there is a huge delay between when the server gets the statement, and when it executes it. After disabling cache, server 4 is ok but 1&2 are still having this issue. id=60696 If anyone knows how to fix it, i would be glad to hear There is one flaw with mysql's seconds_behind_master value: it only takes into account the position relative to one upstream hop away.Updated changelog entry: The server unnecessarily acquired a query cache mutex even with the query cache disabled, resulting in a small performance decrement.Now if the server is started with query_cache_type set to 0, it does not acquire the query cache mutex.What is left to investigate is if it really is possible to read query_cache_size in a concurrent environment and if the rare but occasional lack of consistence when the query_cache_size change is an issue for the overall system performance. After review, it may be pushed to the relevant source trees for release in the next version.You can access the patch from: 2666 Kristofer Pettersson 2008-10-16 Bug#38551 query cache can still consume [very little] cpu time even when it is off.