The answers to the last pop quiz are up. So here’s another pop quiz…good luck!
Ah, the perils of working in a shared, client environment. One client has us using a login that is not exclusive to us. I prefer using bash; the client is set to use zsh. This is not a problem in and of itself. However, there is a section in the .profile that is causing me issues, let me show you.
In Spotting the Wolf in Sheep’s Clothing, Frank Mash writes about a specific person who is spreading fear, uncertainty and doubt about MySQL. Now, this always gets me, especially with MySQL. For how long will MySQL be the bastard stepchild of the database world? Because really, it’s been a full-fledged DBMS for at least 5 years. Don’t hate MySQL for the wrong reasons and there are plenty of reasons to hate MySQL. But hating MySQL because “it sucks” or because “it doesn’t have blah feature” — which, 9 times out of 10, it has — is just wrong.
I would not wish this task on my worst enemy. My friend, good luck and best wishes but I’m afraid I just can’t help you, because that much suffering is way too much for me.
I wrote this post because I feel there is a great need for it. The number of people struggling with unstable query plans due to bind peeking in Oracle 10G is enormous, to say the least. More than that, solutions like disabling bind variable peeking are driving us away from understanding the root cause of the problem and applying the right fix to it.
If you have a 12-server MySQL Cluster with, 1 Management Node, 3 SQL Nodes, 2 Data Node Groups, and 4 Data Nodes per group. And each machine is configured to allocate 1G of memory for its function, how much data (data + indexes) can you store in total in your cluster?
No one has ever come out and formally asked me for a document that states “Best Practices to Scale Application X”. It is an unusual demand, since it’s something many of us at Pythian have implemented, but it’s been more of an ad hoc, iterative process — and rightly so, since architectures must be so organic, and so tailored to the application. What’s more, no one has ever brought us on board so early in the game that we have a hand in actually — gasp! — doing the design and data-model from the get-go. Woo hoo!
I got to troubleshoot an amazing situation a few weeks ago. I think it is essentially inconceivable that allowing a single query to run on your system can flip another query’s plans and cause major performance issues (and in this case even downtime!). Sometimes it’s coincidence, sometimes it’s load, and sometimes it’s a single ad hoc query with a new predicate that starts the slowly-ticking time bomb. Here is how it happens and how to fix it.
Kenny Tilton posted about database troubleshooting, and he anecdotally illustrates and elaborates on a law of troubleshooting that I strongly agree with: Always solve the first problem. The corollary to his law is that “there only is the first problem.” I’m not sure I entirely agree with that one, but I will admit that that corollary is true at least 90% of the time, which is often enough to make it an incredibly useful insight.
I have been automating to make the life of my team members easier. As part of the DBA service, we offer monitoring in the form of alerting, and also in the form of daily checks to ensure everything is running smoothly. Daily checks consist of things that do not need to be checked every minute, but should be checked frequently. This is very valuable to ensure that no changes get lost. A DBA might be adjusting the configuration, but forget to put the final changes in the config file. In that case, the next day our daily checks will throw a warning, and that DBA will say “oh yeah, I forgot to put that into the config file!”