When using Apache, lower MaxClients to, say, 20. There is no advantage in having lots of Apache children stuck waiting for MySQL -- latency suffers and throughput does not improve.
Decrease @@global.wait_timeout -- why have idle connections clog the max_connections.
Clients should disconnect when they are through -- reconnecting is cheap.
If Opened_tables / Uptime > 2 (per second), increase table_open_cache. In the past, it was unwise to raise that too much -- the cache was linearly scanned. I think it is now hashed.
Open_tables / table_open_cache (0..100%) -- not as important as Opened_tables per second.
open_files_limit is indirectly controlled by the OS (ulimit -n). Sometimes the OS puts an unreasonably small limit here. 16K is not unreasonable.
"connections refused" -- do you mean "max_connections exceeded"? See SHOW STATUS LIKE 'Max_used_connections';
For your applications the user(s) should not have SUPER privilege. SUPER gets an 'extra' connection so you (the DBA) can connect and see what is going on.
Unfortunately, you have to let InnoDB purge all its moving parts (Redo Logs, Undo Logs, Dirty Pages, Index Changes, Log Buffer Contents, etc)
Going forward, I recommend the following : Set innodb_max_dirty_pages_pct = 0
By default, innodb_max_dirty_pages_pct is 75. If you set it to 0, it forces the InnoDB Storage Engine to flush every dirty page and its grandmother out of the InnoDB Buffer Pool without any pausing. It will either flush every page or flush it low enough so that new dirty pages enter the Buffer Pool as fast as old dirty pages are flushed out.
Flushing dirty pages and cleaning up transaction is what consumes the most time in a shutdown. Minimizing the number of pages shortens shutdown time.
You can monitor the following status variables
Watch them decrease until it hits zero or levels off. Then, you can issue a shutdown.
Here are additional settings you could use
Give it a Try !!!
Afterthoughts
Don't worry about dumping the buffer pool map and reloading. The output file is very small.
SATA/RAID0 sound scary to me. You should be using SAS/RAID10 for InnoDB.
At the very least you think about splitting up InnoDB data, logs, and system tablespaces into separate devices. See my earlier post MySQL on SSD - what are the disadvantages?
You should also think about getting away from Barracuda. See my old post innodb_file_format Barracuda
UPDATE 2014-12-07 18:14 EST
If you want to interrupt an InnoDB purge of everything and you don't want to preserve the data being fixed up, your only option is to set InnoDB Recovery Options. See my post The InnoDB log sequence number is in the future. If you use the innodb_force_recovery options, it may not let you do any more writes of InnoDB. If you a moderate amount of data, you could mysqldump whatever data can come out, shutdown mysqld, delete all data folders (except mysql schema), ib_logfile0, ib_logfile1, and ibdata1, start up mysql, reload data.
I cannot really help you if you have 1TB in a forced recovered state.
Best Answer
Did you get the very, very latest?
The latest stable build (here) is 5.1.19. However, the bug fix has been put in place for 5.2.21 (per here).
The absolute latest version available is 5.2.34, which should have the bug fix. However, that's not the latest stable version; it's just the latest generally available (GA) version. (It's available here, for what it's worth.)
Edit
Since you have the latest version (with the alleged bug fix), I would report this as a new bug.
My only advice... Try to figure out if there is an exact sequence of steps that you can perform to make this happen every time. Then give them all the information you can (including the version number you're using).