Comments for Mark Leith

Comment on Implementing mysqldump –ignore-database by How to exclude a database from your dump with ZRM (MySQL Community help needed)

How to exclude a database from your dump with ZRM (MySQL Community help needed) — Tue, 08 May 2012 14:54:05 +0000

[...] month, Ronald Bradford, Giuseppe Maxia and Mark Leith spoke about how to simulate a mysqldump –ignore-database. This mysqldump option [...]

Comment on Implementing mysqldump –ignore-database by Mark Leith

Mark Leith — Fri, 20 Apr 2012 19:21:11 +0000

I just saw a patch get committed to trunk, given review and alike, I’m sure it will make it’s way in to a release some time soon..

Comment on Implementing mysqldump –ignore-database by Giuseppe Maxia

Giuseppe Maxia — Fri, 20 Apr 2012 12:35:03 +0000

Hi Mark!
Excellent news! Thanks.
Now, how long until the patch to this 8 year old bug gets into the actual mysqldump that we love and use daily?

Cheers

Giuseppe

Comment on Implementing mysqldump –ignore-database by Ronald Bradford

Ronald Bradford — Fri, 20 Apr 2012 01:22:08 +0000

Awesome. I wrote this quick fix for a RDS problem, knowing in my situation the GROUP_CONCAT length limitation. In one day, Giuseppe expands hacks, and you provide a workable patch for a future release.

That is the community spirit.

Comment on Monitoring MySQL IO Latency with performance_schema by Presenting File System Latency « Joyeur

Presenting File System Latency « Joyeur — Tue, 13 Dec 2011 20:14:41 +0000

[...] measure file system latency, without needing to use DTrace. Mark Leith posted a detailed article: Monitoring MySQL IO Latency with performance_schema, [...]

Comment on Monitoring MySQL IO Latency with performance_schema by Measuring File System Latency from Applications « Joyeur

Measuring File System Latency from Applications « Joyeur — Wed, 30 Nov 2011 17:49:23 +0000

[...] events in the new performance schema additions. Mark Leith has demonstrated this in a post titled Monitoring MySQL IO Latency with performance_schema. If that isnâ??t viable, or you are on older MySQL, or a different application entirely (MySQL was [...]

Comment on A Big Bag of Epic Awesomeness by Measuring File System Latency from Applications « Joyeur

Measuring File System Latency from Applications « Joyeur — Wed, 30 Nov 2011 16:50:51 +0000

[...] are on MySQL 5.5 GA and later, you can get similar information from the wait/io events in the new performance schema additions. Mark Leith has demonstrated this in a post titled Monitoring MySQL IO Latency with [...]

Comment on InnoDB Table and Tablespace Monitors by Mark Leith

Mark Leith — Mon, 31 Oct 2011 12:46:45 +0000

Hey Bobby,

If you want the output of SHOW ENGINE INNODB STATUS written to a file regularly, then that is exactly what the “innodb_status_file” variable does.. There is very very little overhead to this, and you can then process it regularly with your own scripts/tools. From the page you mentioned:

“InnoDB sends diagnostic output to stderr or to files rather than to stdout or fixed-size memory buffers, to avoid potential buffer overflows. As a side effect, the output of SHOW ENGINE INNODB STATUS is written to a status file in the MySQL data directory every fifteen seconds. The name of the file is innodb_status.pid, where pid is the server process ID. InnoDB removes the file for a normal shutdown. If abnormal shutdowns have occurred, instances of these status files may be present and must be removed manually. Before removing them, you might want to examine them to see whether they contain useful information about the cause of abnormal shutdowns. The innodb_status.pid file is created only if the configuration option innodb-status-file=1 is set.”

The warning on overhead is more from things like the lock monitor printing, which can result in far more data being captured. Also, there is no worry with error log sizes when using the status file, as the file is just overwritten every 15 seconds, rather than printing a status snapshot regularly to the error log, as is the case when you create the innodb_monitor table.

Comment on InnoDB Table and Tablespace Monitors by Bobby

Bobby — Fri, 21 Oct 2011 22:17:29 +0000

Hi Mark,

Thanks for the detailed information. Its very helpful.

From the documentation regarding enabling Innodb monitors, I can see “output generation does result in some performance decrement”
http://dev.mysql.com/doc/refman/5.5/en/innodb-monitors.html

Do you think there can be the same performance decrement if we don’t enable the Innodb monitors (by not creating the monitor tables), and just get the output of SHOW ENGINE INNODB STATUS into a file at regular schedules.
The purpose is to have regular snapshot information which can be used for analysis and comparison later when required. Just like we have in oracle with snapshot and AWR reports.

Thanks

Comment on Speaking at Oracle OpenWorld 2011 by Mark Leith

Mark Leith — Wed, 12 Oct 2011 09:44:08 +0000

Hey Ronald,

These have been uploaded to my “Presentations” page now:

http://www.markleith.co.uk/?page_id=262