I have a replication setup where one of those nodes started experiences a slow but steady memory leak.
The setup is kind of like this
M---->S
|
\/
FilteringSlave
| | | |
R1 R2 R3 RN
M is the standard production master, S is the main production slave. "FilteringSlave" is another slave, like S, but it's purpose it to replicate with a select few Replicate_Do_Table specified tables so a smaller binlog is what gets pushed over the wire out to remote slaves.
FilteringSlave is the one that has the slow memory week.
The stream is entirely innodb, FilteringSlave has a buffer pool of 2G. Over the course of about two weeks it's memory footprint in the system grows to 8+. Restarting the server does free up the memory but the leak restarts.
This filtering slave is just used for the purpose of trimming down binlogs and the only threads connecting to it are the remote DC replication threads (no applications talk directly to "FilteringSlave".
I looked over all the suggestions of usual suspects at http://www.mysqlperformanceblog.com/2012/03/21/troubleshooting-mysql-memory-usage/ but nothing turned up. No stored procedures being ran, no temporary tables showing up, no memory tables around.
Aside from fully bouncing the server this time I tried restarting all the replications threads in and out of "FilteringSlave" and restarted the event scheduler thread in hopes I could at least identify where this leak was. No avail, the memory footprint remained at it's current state of about 5G (again having crept up from ~2G on start up).
None of the other machines anywhere in this setup experience similar leaks.
This setup has been going overall for a couple years. The last thing that changes was upgrading to 5.5.25a.
I can't find anything any bug reports about this version having a memory leak but I'm starting to feel it's something to do w/ 5.5.25a and running a Replicate_Do_Table list defined.
Any ideas of what else to look for to try and identify the source of the leak?
