766438 - Audit log rotation/purge on MySQL instances

Status: RESOLVED FIXED

(Data & BI Services Team :: DB: MySQL, task)

Description

[Matt Pressman [:mpressman]]

Now that we are utilizing more master/master setups and especially with hosts that

Comment 1

[Sheeri Cabral [:sheeri]]

I agree, but the best way to do this IMO is to use expire_logs_days, which on some machines is set to 60. I prefer to set it to 10, and just went through ALL the puppet config files and set it to 10 where it was 60.

That won't change running instances, but that's just logging into machines and doing a SHOW GLOBAL STATUS LIKE 'expire%';

Comment 2

[Matt Pressman [:mpressman]]

I'm with you on expire, but what about issues like webdev where users load and reload entire databases? I've got a script that runs in the background and manages the logs. It looks at slaves to determine which logs are no longer needed. I just figured we've seen quite a bit of disk warnings due to log buildup. I'm sure this is in relation to the volume of hosts being setup and us not knowing exactly how there being used. This would effectively remove the log rotation provided via mysql or system utilities.

Or if you think this is overkill and we can just treat those instances as one-offs I'm good with that too.

Comment 3

[Matt Pressman [:mpressman]]

Closing this out as it seems that the hosts that have alerted are behaving themselves. The only other host I see with issues is puppetdashboard1, however I found that the expire_logs_days was inadvertently set to 10 when I'm sure it was intended to be 1.