Baron posted something interesting about agent vs agent-less monitoring in response to Rob.

While reading it, I couldn’t help thinking that the distinction is somewhat misleading, if not wrong.

I’d go so far as to say that agent-less doesn’t exist as such. Why do I say such heresy?

Trivially, you need some piece of software to collect data. With munin you configure a server that triggers scripts on the monitored servers. The set of data sources is governed by what you install in the correct directory on the monitored server. Cacti relies on SNMP heavily and also …

Rob Young has posted a few blog entries lately on the MySQL Enterprise monitoring software. His latest post claims that agent-based monitoring is equivalent to extensibility (MySQL Enterprise Monitor: Agent = Extensibility).

I think this is conflating two completely distinct properties of a monitoring solution. Cacti is extremely extensible, with a plugin-based architecture and [...]

Baron posted something interesting about agent vs agent-less monitoring in response to Rob.

While reading it, I couldn’t help thinking that the distinction is somewhat misleading, if not wrong.

I’d go so far as to say that agent-less doesn’t exist as such. Why do I say such heresy?

Trivially, you need some piece of software to collect data. With munin you configure a server that triggers scripts on the monitored servers. The set of data sources is governed by what you install in the correct directory on the monitored server. Cacti relies on SNMP heavily and also …

Baron posted something interesting about agent vs agent-less monitoring in response to Rob.

While reading it, I couldn’t help thinking that the distinction is somewhat misleading, if not wrong.

I’d go so far as to say that agent-less doesn’t exist as such. Why do I say such heresy?

Trivially, you need some piece of software to collect data. With munin you configure a server that triggers scripts on the monitored servers. The set of data sources is governed by what you install in the correct directory on the monitored server. Cacti relies on SNMP heavily and also …

If you decide to copy over one table from MySQL installation to another installation, this could be done as simple as copying over your-table-name.* in data directory. Ofcourse, to do this, the database should not be running at the time of copying.

For example, for tables created by MyISAM storage engine, the files to be copied for table mytable are mytable.frm, mytable.MYD and mytable.MYI. The ".frm" file contains table definition, the ".MYI" contains info about index and ".MYD" contains data.

If you do this kind of stuff often, you may want to dump the header of the ".frm" header file. I just wrote a script for this. You can download this php script "frmdump" from here. Note that it is a php script, but meant to be run from command line (not to be used as web page) :

   $  ./frmdump   mytable.frm
  
Dumping  mytable.frm using .frm header format ... …

If you decide to copy over one table from MySQL installation to another installation, this could be done as simple as copying over your-table-name.\* in data directory. Ofcourse, to do this, the database should not be running at the time of copying.

For example, for tables created by MyISAM storage engine, the files to be copied for table mytable are mytable.frm, mytable.MYD and mytable.MYI. The ".frm" file contains table definition, the ".MYI" contains info about index and ".MYD" contains data.

If you do this kind of stuff often, you may want to dump the header of the ".frm" header file. I just wrote a script for this. You can download this php script "frmdump" from here. Note that it is a php script, but meant to be run from command line (not to be used as web page) :

   $  ./frmdump   mytable.frm
  
Dumping  mytable.frm using .frm header format ... …

If you decide to copy over one table from MySQL installation to another installation, this could be done as simple as copying over your-table-name.\* in data directory. Ofcourse, to do this, the database should not be running at the time of copying.

For example, for tables created by MyISAM storage engine, the files to be copied for table mytable are mytable.frm, mytable.MYD and mytable.MYI. The ".frm" file contains table definition, the ".MYI" contains info about index and ".MYD" contains data.

If you do this kind of stuff often, you may want to dump the header of the ".frm" header file. I just wrote a script for this. You can download this php script "frmdump" from here. Note that it is a php script, but meant to be run from command line (not to be used as web page) :

   $  ./frmdump   mytable.frm
  
Dumping  mytable.frm using .frm header format ... …

Percona is looking to hire someone to develop Maatkit, among other things.

If I weren’t having so much fun being the consulting team lead, I’d be doing it myself. (In fact, I’m still hacking on it a lot. Got some pretty fun stuff done this weekend.) I don’t know what the rest of the world thinks, but I think Maatkit is a damn enjoyable project to work on. Hopefully someone else will have the same kind of mindset and want to get paid for it, unlike poor working-on-the-weekends me.

I’m not stepping away from the project. It’s just grown a lot, and there is room and money to grow it much more. This is actually the best compliment to the project: that it is worth hiring someone to keep improving it. Lots of people are using it, and there’s a lot …

My post on what it’s like to write a technical book was a stream-of-consciousness look at the process of writing High Performance MySQL, Second Edition. I got a lot of responses from it and learned some neat things I wouldn’t have learned if I hadn’t written the post. I also got a lot of questions, and my editor wrote a response too. I want to follow up on these things.

Was I fair, balanced and honest?

I really intended to write the post as just “here’s what it’s like, just so you’re prepared.” But at some point I got really deep into it and lost my context. That’s when I started to write about the things that didn’t go so smoothly with the publisher, …