Last night at the Golang-DC meetup I spoke about building (MySQL) database applications with Go. The meetup was well attended and people were very enthusiastic about Go. I spent a few minutes talking about Go in general, how VividCortex uses Go (we’ve built our agents, API servers, and all backend processes with Go), why we like it, some of the nice things it enables like making it easy to build very resilient programs, and then I gave the presentation, which I’ve embedded below.

Live from the PHP Summit conference in Munich: NoSQL in MySQL. A couple of hours ago I gave a talk about NoSQL in MySQL, contents: what is NoSQL, what is HandlerSocket, what is the InnoDB Memcached Plugin InnoDB and how to use with PHP, is this NoSQL? Slides are below.

NoSQL in MySQL from Ulf Wendel

(PDF download)

The talk was called a night session. Night session means, its the last talk for the day. After eight hours packed with workshops everybody is a bit tired and exhausted. What else could I do but tell them a bed story. What else …

We are planning the kickoff meeting of the Bangalore MySQL User Camp:
We would like to invite all MySQL enthusiasts at Bangalore to join.
Plan is to have at-least one meeting every quarter and give an opportunity to all to participate, attend and speak.

Agenda for 22 March Meeting:
1700-1715: Introductions
1715-1730 : Meet the MySQL Development team @ Bangalore
1730-1815 : Introduction to MySQL 5.6
1815-1830 : Q&A & Plan for the next meeting
1830-1900 : Tea and informal networking

Venue:
Conf Rom 0C001,
Ground Floor, B Wing, Oracle,
Kalyani Magnum Software technology Park
1st Main, J P Nagar 7th Phase,
Bangalore 560076

You can also join the google group "bangalore-mysql-user-camp" where we will be announcing further meetings etc.

Facebook is a major user of MySQL and has pushed the performance limits of the technology. Their MySQL experts have deep, hands on knowledge of the technology. I’m pleased to welcome Mark Callaghan, Software Engineer for Database Infrastructure at Facebook, back again this year to the Percona Live MySQL Conference & Expo to share his expertise. Mark was a keynote speaker at last year’s conference and will appear this year with a group of Facebook MySQL experts:

• Domas Mituzas, …

As some of you may or may not know, I’ve maintained a list of all InnoDB Plugin versions as they’ve historically contained a different version (entirely different numbering scheme) than the MySQL distribution they were included with.

This list was most helpful for troubleshooting various InnoDB issues when the plugin may (or may not) have been involved, and/or for benchmarking, etc. And it’s fair to say it was more useful when the InnoDB plugin was not the mainstream, which it is now.

However, with the latest releases, in MySQL and MariaDB, the “InnoDB Version” simply matches the “MySQL Version”. These “latest releases” include: MySQL 5.6.10, MySQL 5.5.30, MySQL 5.1.68, and MariaDB 5.5.30

Of course this isn’t the most newsworthy story, but having maintained this “list” the past couple/few years, I was happy to see the change, …

MySQL 5.6 introduces a number of new features designed to improve the security of MySQL. There's the new master_info_repository variable that lets you store replication connection information in a table instead of a lowly text file, new warnings telling users that they should use SSL/TLS, there is a new option to give replication user & password with START SLAVE instead of CHANGE MASTER, and there's mysql_config_editor to encrypt passwords. The problem with these features is that they are a form of Security through Complacency: these things make you feel more secure, but the realistic benefits disappear behind the curtains of Security Theater as soon as an even marginally-determined intruder comes along. In this post, I'll look at some of the new security features in MySQL 5.6 and, however well-intentioned they may be, the danger of relying on these features.

…

I'm a big fan of common_schema. It's a really powerful and flexible tool, and I'm always looking for new ways to use it.

Last week I had to update millions of rows across many databases to tokenize some persisted URL values, and I remembered reading Baron Schwartz's recent blog post about using the common_schema split feature. Baron's use case was deleting data, but I figured this could work well to break my large updates into chunks too. I had already written the update statements I wanted to execute, and after five minutes reading the common_schema documentation I was ready to try it out on a dev database.

One …

I'm a big fan of common_schema. It's a really powerful and flexible tool, and I'm always looking for new ways to use it.

Last week I had to update millions of rows across many databases to tokenize some persisted URL values, and I remembered reading Baron Schwartz's recent blog post about using the common_schema split feature. Baron's use case was deleting data, but I figured this could work well to break my large updates into chunks too. I had already written the update statements I wanted to execute, and after five minutes reading the common_schema documentation I was ready to try it out on a dev database.

One …

With real possibilities and opportunities, blogging is getting mature day by day, and so is the technology and its innovations. The combination of both becomes a dazzling medley, which is called as Log Buffer. Enjoy this week’s stunning Log Buffer #311.

Oracle:

Sudip Datta is writing about database as a service.

Premature optimization, (probably) because of Donald Knuth’s famous line “premature optimization is the root of all evil,” (see Structured Programming with go to Statements) is, at the very least, a controversial topic.

Are you using the application server that best serves your changing business needs? Maybe it’s time to consider an upgrade? Suggested by …

With MySQL 5.5 the default storage engine was changed to InnoDB. This was a good step as most users expected MySQL to support transactions, row level locking and all the other InnoDB features, but with 5.1 they sometimes forgot to choose the right storage engine. As most databases don't have multiple storage engines and many MySQL users changed the default storage engine to InnoDB this made the switch to MySQL easier and the default behaviour more in line with what people expect from a relational database.

Changing the storage engine can of course be done on a per table or per instance basis (default-storage-engine in my.cnf). The temporary tables created with 'CREATE TEMPORARY TABLE ...' should not be forgotten. The performance of InnoDB or MyISAM for temporary tables can have quite some impact, especially with slow storage, a buffer pool which is too small to hold the complete dataset or very small temporary tables. In MySQL 5.6 …