请帮忙就此问题提供建议。
CPU 上的正常负载为 20-30% us + sy。从从属服务器（相同版本）恢复数据库文件后，开始出现周期性问题。mysql 开始以 100% 的负载加载 CPU（us + sy 按比例增长）。队列不断增长，一切都变慢了。但使用 mysqladmin flush-tables 几个小时后就会恢复正常。
运行 mysql 2 x E5506 24Gb RAM 的专用 Linux 服务器，数据库大小 50Gb。
[OK] Currently running supported MySQL version 5.0.51a-24 + lenny4-log
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics --------------------------------------- ----
[-] Status: + Archive-BDB-Federated + InnoDB-ISAM-NDBCluster
[-] Data in MyISAM tables: 33G (Tables: 1474)
[-] Data in InnoDB tables: 1G (Tables: 4)
[-] Data in MEMORY tables: 120K (Tables: 3)
[-] Reads / Writes: 91% / 9%
[-] Total buffers: 12.8M per thread and 7.1G global
[OK] Maximum possible memory usage: 15.8G (66% of installed RAM)
4000 - 5500 RPS
key_buffer = 1536M
max_allowed_packet = 2M
table_cache = 4096
sort_buffer_size = 409584
read_buffer_size = 128K
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 500
query_cache_size = 100M
thread_concurrency = 24
max_connections = 700
tmp_table_size = 4096M
join_buffer_size = 4M
max_heap_table_size = 4096M
query_cache_limit = 1M
low_priority_updates = 1
concurrent_insert = 2
wait_timeout = 30
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
innodb_buffer_pool_size = 1536M
innodb_log_buffer_size = 4M
innodb_flush_log_at_trx_commit = 2
如何解决这个问题？
答案1
我认为你需要进一步缩小正在发生的事情的范围，然后才能得到好的答案。我会开始打开慢查询日志，看看它是否由任何特定查询引起，也许运行 mysqlcheck 作为健全性测试。
答案2
您是否尝试过执行从从服务器到主服务器的同步？（不应该工作）或在主服务器上恢复从服务器的转储？