So I've done some more digging on this.
1. Upgraded to MySQL 5.5.37 2. Made sure we didn't have any old/long running transactions--nothing more than a few seconds. 3. Did a dump/reload in to a new DB and started with an empty history list. A few days later, we're back up over 3mil in the list. We're currently writing about 50MB/s to that machine. Is it possible the purge thread just...can't keep up for some reason? How can I get better visibility in to how quickly the purge thread is working vs. how many undo entries are being put in the thread? Thanks, *Brad Heller *| Director of Engineering | Cloudability.com | 541-231-1514 | Skype: brad.heller | @bradhe <http://www.twitter.com/bradhe> | @cloudability <http://www.twitter.com/cloudability> We're hiring! https://cloudability.com/jobs <http://www.cloudability.com/jobs> On Sun, Sep 7, 2014 at 2:04 AM, Jesper Wisborg Krogh <my...@wisborg.dk> wrote: > Hi Brad, > > > -----Original Message----- > > From: Brad Heller [mailto:b...@cloudability.com] > > Sent: Sunday, 7 September 2014 03:07 > > To: MySQL General List > > Subject: MySQL 5.5.33 History list not purging? > > > > For some reason, the history list isn't purging on one of my masters. > This is > > causing all kinds of weird issues/behavior with reads. Here's the last 8 > or so > > hours of history list length: > > > > http://i.imgur.com/Q4DEeVi.png > > > > I would start looking for an old transaction. You can use SHOW ENGINE > INNODB STATUS or the information_schema.INNODB_TRX table to look for that. > > Best regards, > Jesper Krogh > MySQL Support > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/mysql > >
