Thanks to everyone who came. Definitely check out the recording below!

Heyo everybody!

Coming up this Wednesday, October 2nd, 2013 at 12:00pm pacific (19:00 GMT) is another exciting #DBHangOps. Join the google hangout to discuss:

• MySQL Utilities from Chuck Bell!
• How do you constrain over-consumption of resources by competing applications?
• Network vs. Local storage for MySQL
  • How do you use this for HA? Do you use DRBD or floating VIPs?
• Secure connections to MySQL (using SSL) (requested by Daniel)
  • Do you have experience with this? What’s the performance impact?
• PCI Certification with MySQL — what changed for you?
• MySQL-isms!
  • (From Gerry) Sub SELECTs — Why aren’t these as mature as other databases?
  …

And all set. Check out the recording:

Hello everybody!

Coming up this Wednesday, July 23rd, 2013 at 12:00pm pacific (19:00 GMT) join in to hear:

• Brandon Johnson from Mozilla talk about an issue he recently worked through with XtraBackup and the process he took to identify and resolve the issues.

And also take part in discussion around:

• How do you apply production schema changes?
  • Do you use pt-online-schema-change?
    • Issues to watch out for
  • Just run the alter!
  • Pull from a pool and apply

Make sure to follow the #DBHangops twitter search, the DBHangops Twitter Feed, or this blog …

A fascinating post-mortem on high profile network failures:

This post is meant as a reference point–to illustrate that, according to a wide range of accounts, partitions occur in many real-world environments. Processes, servers, NICs, switches, local and wide area networks can all fail, and the resulting economic consequences are real. Network outages can suddenly arise in systems that are stable for months at a time, during routine upgrades, or as a result of emergency maintenance. The consequences of these outages range from increased latency and temporary unavailability to inconsistency, corruption, and data loss. Split-brain is not an academic concern: it happens to all kinds of systems–sometimes for days on end. Partitions deserve serious consideration.

Hi everyone!

Here’s a video of this week’s #DBHangOps:

March 27th at 12:00pm PDT (19:00 GMT) is when the next #DBHangOps is gonna go down. Check out the twitter search and hop on the google hangout to contribute some discussion! This week’s topics are:

• MySQL and puppet
  • Sheeri Cabral shared a pastebin of a puppet manifest used at Mozilla: http://scabral.pastebin.mozilla.org/2251358
• MySQL “Gotchas” (round 2)
  • MySQL Bug on predicate deadlocks due to locking non-existent rows
• A shoutout for NWCNA 2013 from Sheeri. Submit …

Introduction
Debugging SQL code is a very important task these days. Unfortunately not all database servers support this feature. And MySQL is one of such servers. In spite of its wide feature set, debugging is not implemented in it. So the problem is that MySQL provides no API functionalities for code debugging. But the necessity to debug SQL code does not disappear and becomes more and more important each year. Some companies that develop tools to access data of MySQL server databases create their own debuggers that solve this problem to some extent.

Types of Debuggers
Now we will consider the types of debuggers that can be implemented for MySQL server and principles of their work.

The first way of debugging stored procedures is to divide their code to separate statements and send each statement separately. This way execution is being emulated, …

The article describes the ways to debug MySQL stored routines with a GUI tool.

This is a tale of the bug lp:798213. The bug report has the initial report, and a summary of the real problem obtained after detailed analysis, but it does not describe the processes of getting from the former to the latter. I thought it would be interesting to document this, as the analysis of this bug was rather tricky and contains several good lessons.

Background

The bug first manifested itself as a sporadic failure in one of our random query generator tests for replication. We run this test after all MariaDB pushes in our Buildbot setup. However, this failure had only occured twice in several months, so it is clearly a very rare failure.

The first task was to try to repeat the problem and get some more data in the form of binlog files and so on. Philip kindly helped with this, and …

Lets paint the picture:

Scenario part 1 : Migrating a couple thousand stored procedures from database technology X to mysql
Scenario part 2 : Legacy system where the people who wrote it left a long time ago
Scenario part 3 : Developers sure can get real creative and invent all kinds of ways to get data (eg: having a stored proc which formulates a big query using concat after going through a bunch of conditions (fair enough), BUT the parts making up the different queries are stored in a table on a database rather than within the stored proc itself) … talk about KIS – Keep it simple!!
Scenario part 4 : This stored proc references 18 tables, 4 views, and another two stored procedures on 5 databases

Now close your eyes and try to imagine that for a few seconds, nah kidding don’t want you to hurt yourself.

I wonder, who’s gonna cover my health insurance if i go crazy? :)

mysql 02:55:47 DEV …

I use MacOS X for most of my development work, but part of my job is writing apps that run on all major Unixes and Win32. Most of the time bugs and memleaks are "portable", meaning that they appear on all platforms in the same way and fixing them on your dev-platforms, fixes them everywhere else.

Well, "most of the time".

Today I had the joy of a win32 only mem-leak. We actually ''bisect''ed it down to the locking support for openssl that we just added http://www.openssl.org/docs/crypto/threads.html. But starring at the code didn't reveal anything obvious. So, back to the tools. Let them find it.

Going through the web on the search for "how to find mem-leaks on win32" I came along:

• http://wiki.winehq.org/Wine_and_Valgrind

The idea is …

I had an interesting IRC discussion the other day with Monty Taylor about what turned out to be a limitation in Valgrind with respect to debugging memory leaks in dynamically loaded plugins.

Monty Taylor's original problem was with Drizzle, but as it turns out, it is common to all of the MySQL-derived code bases. When there is a memory leak from an allocation in a dynamically loaded plugin, Valgrind will detect the leak, but the part of the stack trace that is within the plugin shows up as an unhelpful three question marks "???":

==1287== 400 bytes in 4 blocks are definitely lost in loss record 5 of 8
==1287==    at 0x4C22FAB: malloc (vg_replace_malloc.c:207)
==1287==    by 0x126A2186: ???
==1287==    by 0x7C8E01: ha_initialize_handlerton(st_plugin_int*) (handler.cc:429)
==1287==    by 0x88ADD6: plugin_initialize(st_plugin_int*) …