How to remove database in a safe way

When you have to drop a large database, you’ll encounter some problems, mainly replication lag. Now I’ll show you how to avoid this.

What can cause replication lag when you drop a database? First, it takes some disk I/O to unlink the files, and secondly, MySQL will scan through the buffer pool to see if there are pages from that database or not. On a huge (or at least big) database this could take seconds or even minutes, what means your slaves will collect lag for seconds or (of course) even minutes.

Continue reading “How to remove database in a safe way”

Mambocollector – MySQL -> statsd data collector

We love graphs.

Really love them. I think everyone likes graphs to collect data about the current state of their system, and needless to say, why.

Of course, sometimes it is painful to create graphs, but graphite could make this process easier, so we use them.

The graphite ecosystem makes data collection simple, when you send some data to statsd via simple UDP packets it will put them to a carbon database, and graphite will draw the lines. The only thing that can make this hard, is the question of ‘How can I collect my data to send?’

Well, I’ve checked many ways to solve this problem, but I didn’t find anything simple enough.

So, I wrote a daemon called ‘Mambocollector’ to deal with this problem. It is far from perfect, it has bugs, and I am not sure if it isn’t used too many resources when we collect a too many data, but it is working fine for my current needs. The project can be found on GitHub, feel free to use it, or participate in that.
UPDATE: This version was bugging badly, I rewrote it in Go.