The latest from the MySQL community

A few weeks ago I held a MySQL University Session about MySQL Proxy. Thanks to our docs team we now have

• the IRC log,
• the slides and
• the voice recording

online.

If you are interested in writing your own scripts for the proxy, check out the Writing LUA Scripts for MySQL …

So… stealing the idea from Peter, does anybody have any suggestions for MySQL Cluster related things to have at the UC next year (April)? Either leave a comment or email me (first name at mysql dot com).

khoi vinh?s piece on the poor user-interface design of enterprise software was my latest forward to the business-intelligence list. this is something that has bothered me about vertical-market software for a long time, and i have mentioned it in passing before.

i think it stems from a certain combination of ignorance and laziness. i say ?ignorance? because vertical-market software often comes from the hands of domain experts who just sort of cobble something together because they don?t really know better. the ?laziness? comes in when they don?t …

This tool allow to deploy large number of MySQL replication Slaves (and Master servers)

It is available on Ruby Forge: http://rubyforge.org/projects/vladenvironment/ The tool is based on Vlad the Deployer and is written on Ruby

The following is a true story:

A few months ago, I wrote my mother-in-law a check. A couple of weeks later, it was returned to me with a letter from the bank which said: "Instrument is not negotiable."

I had absolutely no idea what that meant, so I took it, with the check to the bank. The teller had no idea, and neither did the branch manager.

Finally, a young trainee said "Oh, I know! We went over this last week in training." She then pointed out that a check is a negotiable instrument if it has five things filled in: name, numeric amount, written amount, signature, and date. In my haste to pay my mother-in-law, I forgot to fill in the date on the check.

For all you software developers who want to say "those banks are so #!@@^* !$%*^", let's try to do a better job of explaining what our software does first.

Very fast, as it turns out. While writing the chapter on replication for the upcoming second edition of High Performance MySQL, I decided to do a little test and measure replication speed more accurately than I’ve seen others do before. The first edition of the book measured replication speed by inserting on the master and polling on the replica. Giuseppe Maxia later followed up on that by improving the polling process, and found events typically replicated within a half a millisecond.

If you have been MySQL User for many years you might remember the times when MySQL had "zero bugs policy", this is when all known bugs really were fixed before release was made. To be honest at that time bugs were reported via bugs mailing list not via bugs database as they are now so they were not tracked so accurately but still there was intention and all known serious bugs were fixed before release was made.

Over years this policy had few changes, transforming to something like "no critical bugs in production releases" and in practice releases moved to predictive schedule rather than based on the moment when all bugs were fixed.

To tell you the truth this was inevitable - with so huge amount of users as MySQL has and growing MySQL complexity you can't hope to have zero bugs, especially as some bugs are design bugs which require a lot of work to get fixed. But at the same time MySQL for very long time kept silence about known bugs …

A few weeks ago I held a MySQL University Session about MySQL Proxy. Thanks to our docs team we now have

• the IRC log,
• the slides and
• the voice recording

online.

If you are interested in writing your own scripts for the proxy, check out the Writing LUA Scripts for MySQL …

Test-Commander Eric was working on the log-replay task and as he is at my place right now, we have put our heads together to get a working prototype together.

---
-- log queries going throw the proxy on request and
-- provide a commands to work on the logged queries
--
-- * PROXY SET GLOBAL replay.log_queries = (true|false)
--   log queries sequentially (used by SAVE)
-- * PROXY SET GLOBAL replay.fake_mysqld = (true|false)
--   return the logged resultset for known queries
--
-- * QUERYLOG SAVE INTO "filename"
--   dump the queries into a file and reset the log buffer
-- * QUERYLOG LOAD FROM "filename"
--   load logged queries back into the query_log (used by the
--   fake_mysqld)
-- * QUERYLOG SHOW

What is this useful for ? ... hmm ...

The first goal is creating a fake-mysqld allowing us to run proxy tests without have to have a mysqld on the box.

As a proof-of-concept we logged the SHOW GLOBAL STATUS going through the proxy …