So I am currently working on a MySQL server that is showing
behavior as depicted in the following graph.
There can be several possible reasons for these sudden drops. I
am working on the issue and will be posting the results. Have you
experienced something similar?
A quick refresher on the locations MySQL uses to load up configuration options on Unix:
- /etc/my.cnf
- $MYSQL_HOME/my.cnf (sometimes this is your datadir, other times it's basedir)
- command line arg (defaults-extra-file)
- user's home directory (~/user/.my.cnf)
It's available in the MySQL docs, and there's a section on it in Pro MySQL, but it seems a need to remember the exact order only comes often enough to confirm that I haven't committed it to long-term memory.
A current project which now includes the use of PHP, MySQL Stored
Procedures, recursion, temporary tables, etc., and some of the
issues encountered along the way, leads me to write up these
notes to share with others. Hierarchical datasets have been
discussed before, and the means to traverse them in SQL. This
current dataset is not hierarchical, not even a partial ordering,
but a network, somewhat along the lines of a social network. In
this instance it is musicians who play for bands, and creating an
extended network by following up on other bands that musicians
played for, and also researching all members of a particular band
that a musician is a member of, ad infinitum or at least to
maximum recursion depth, currently set at 25.
Right now the stored procedures consist of two: a non-recursive
function that creates a temporary table and makes the initial
call to the recursive procedure. No resultsets are returned; the
PHP script that …
It's really hard for me to believe how time has just been flying.
Ever since I got back from the very awesome MySQL Camp at Google
headquarters, I have been planning to write about it but for one
reason or another, I couldn't.
Short version is that I had a great time at the MySQL Camp. I got
to meet a lot of new and old friends. It was like a dream come
true to hang out with everyone. Very special thanks to everyone I
met at the conference as I had some very good discussions. Also
thanks to:
Kevin Burton of TailRank for his idea
Jay Pipes for his
intense hard work to make this event a big success
Leslie "Hacker Herder" Hawthorn, Mickey, Kynan, Chris and others
for their excellent hospitality
Jeremy Cole and
…
It seems, people are clammering for a more consolidated help guide for SQL Performance tips.
Jay Pipes at the MySQL Camp ran a session Interactive Top 10 SQL performance Tips. There was plenty of input and discussion, and at the time Sheeri simply typed them into a wiki page for later work.
Well it seems even that rough list is popular at Del.icio.us ranking near the top of the Hot List on the front page. I saw it earlier and it was second or third, but didn’t think of taking a screen shot until now, but it’s still high.
I’d say that we could easily …
[Read more]A week ago I completely refreshed my MySQL Cluster setup (yea, been meaning to post on that) and was a little baffled when the 5.1.12 binaries didn't have the expected cluster programs (ndb_mgmd, ndbd etc). The earlier versions of 5.1.x I'd compiled from source so it had been awhile since using a binary, but on this refresh I didn't want to wait for the machines to configure and make.
When I couldn't find the cluster programs I chalked it up to failed memory, even though I swear I had seen something about the 5.1.x builds being more like the max builds of the past. I grabbed the source and forgot about it until today, when I came across this in the docs:
Due to a build slippage, binary distributions of MySQL 5.1.12 contain neither NDB Cluster nor Partitioning. We apologize for any inconvenience. Please upgrade to 5.1.13 as soon as it is available. if you build from source, you can execute configure with the --with-ndbcluster and …
[Read more]
Every place I have worked at has had the problem of "bad pushes".
This means that at some point someone commits code which should
have never been committed.
The specific problem I am thinking of is code that doesn't
compile or breaks certain common criteria (aka valgrind
warnings). Some of this you can automate out, but the automation
systems never seem to be perfect.
The typical solution I have seen to solve this problem is either
a "Wall of Shame" or "Who carries the pager". The pager method
means that someone, normally the last guy who broke the tree,
gets to be on call.
The "Wall of Shame" on the other hand is normally some sort of
page on an internal website showing who the culprit is for bad
pushes. Everyone will do this from time to time, but some people
will float to the top, and its pretty embarrassing to have this
pointed out.
I am not fond of methods which shame people. The …
Reading about Peter Zaitsev's feature idea about Finding columns which a query needs to access - which I would really like to see implemented - reminded me of a bug report I filed in 2004 and which bit me again only a few days ago. You can find it under Bug #7074 in the MySQL bug tracking tool. Although it is filed as a feature request, I think one should be aware of this, as it may cause problems in your applications (it did in ours).
Basically it is about explicitly specifying which columns you
need in a result set, instead of just using SELECT
*. This is generally a good idea, however if the table
contains BLOB columns, it becomes even more important, as …
Reading about Peter Zaitsev's feature idea about Finding columns which a query needs to access - which I would really like to see implemented - reminded me of a bug report I filed in 2004 and which bit me again only a few days ago. You can find it under Bug #7074 in the MySQL bug tracking tool. Although it is filed as a feature request, I think one should be aware of this, as it may cause problems in your applications (it did in ours).
Basically it is about explicitly specifying which columns you
need in a result set, instead of just using SELECT
*. This is generally a good idea, however if the table
contains BLOB columns, it becomes even more important, as …