A Virtual MySQL Users Group

This is a cross-post of something I just put up on Google+. My username on G+ is Keith Murphy. If you are interested please search me out on G+ and comment on the post.  Thanks!! km

-------------------------

I have an idea that I wanted to see if there would be interested people who would like to pursue it. One of things I love to do is participate in MySQL Users groups. When I had the chance I was able to go to user groups in various places I have lived or been. However, my home for a long time has been in an area that isn't heavily populated so there is no actual user groups closer than six hours drive away. I did attempt to start a user group in the nearest city several years ago but it didn't get off the ground.

Anyways, I have been using G+ for some months now and I would like to expand my professional usage of it. One of the great new features that Google added recently was "hangouts". If you don't know what they are, it's simply a way to video conference with a group.

My idea is simple. Why not form a MySQL Users Group in G+? For those of us who don't have one near them I think it would be a great idea. As far as I can see a hangout could work just like a normal users groups just without the drinks and pizza (sorry, but you will have to provide your own). Someone would need to run the meeting, someone would be able to do a presentation (you can share your desktop with the hangout). I'm sure there would be a few things to work out but I think it would be quite cool to meet people not just in your local area but potentially all over the world.

So if you have any interest please let me know by commenting on the post. If we can get a few people interested I would love have a plan for a meeting in early March. Of course the more the merrier! Feel free to share this post.

km

New directions (somewhat)

Lately I have been working with a large pool of fairly hetrogeneous MySQL. Similar to a pool of web servers we have almost 100 MySQL servers across two data centers that are the same in terms of platform/schema etc. These aren't our only servers, just the largest group of them.  Previously everything I had done was with smaller numbers of server (30 or less) or larger numbers of servers but across multiple pools/customers. When you work on a single large pool of servers it brings some interesting challenges. While I certainly can apply everything I have learned up to this point, it brings on some new  problems/issues/headaches.

So, I wanted to take things in bit of a different direction and talk about some of problems that you see when managing large groups of servers like this. Over the next few months as time permits I want to discuss the issues that come up and how you can manage many servers like this. Time, unfortunately, has been a challenge for the last several years. I don't know how often I will be able to post but I will make every attempt to do this on a semi-regular basis.

Save

km

A New Platform Supported

Ever hear of Red Hat Enterprise Linux 6.0? It was released on November the 10th of 2010 . . just over a year ago. In the last couple of days Oracle released the latest version of MySQL Server (5.5.18). Along with the bug fixes, etc they released RPM packages that cover RH EL 6.

Finally. A year later.

Not one given to griping, but really..does it take that long to roll packages for the new version? There were no significant changes in the operating system..in fact the RH EL 5 packages worked on RHEL 6 from my (albeit) limited experience with the combination.

I don't jump onto new versions of operating systems as soon as they come out. I prefer to let others be my beta testers before I put something into production. However, waiting a year seems a bit extreme for this release.

Even so, it's out now so enjoy! Now we have no excuse for not deploying 5.5.

km

R.I.P. Kickfire

If the news/rumor mill  is correct than Kickfire may be down for the count. The website for Kickfire is http://www.kickfire.com but it appears to be down. I spent some time with the Kickfire time several years ago when they were first getting ramped up and I have always thought the core idea was sound. The center of Kickfire's technology was a card that supplied hardware acceleration for SQL queries. It's a phenomenal idea in my opinion. In practice it could provide for some incredible query acceleration.

I don't know enough of the situation to speculate on why Kickfire seems to have failed. I haven't spoken to anyone from Kickfire in almost a year, if not more. Some have speculated it was because the product was built on MySQL. I don't believe that. The market that Kickfire was targeting was not the same as those who download either the community or enterprise version of MySQL. If you think otherwise you don't understand the Kickfire product.

If the rumors/news are true I am saddened for the people who worked there who believed in what they were doing and have been let down.  It doesn't matter if it was a problem with what the product was built upon, failures of executive leadership, or a matter of timing with the poor economy over last few years. I would think it was much more of the economy than anything else.  Regardless of the reasons a once promising technology is now dead. People are out looking for work when times aren't at their best.

I truly hope someone picks up the idea down the road. Remember the old non-accelerated graphics cards from 15 year ago when Windows 95 was all the rage? Rememberhow slow they ran? Now think about a the nice modern Nvidia or ATI GPUs that are powering your Windows 7 desktop now. The difference in power is simply astounding. The promise of Kickfire was that it could bring the same power as those GPUs to your database server.

It might be another 10 years or more before someone can create a true general purpose SQL accelerator card. One that doesn't require specialized knowledge to work with. You don't have to tweak your operating system to truly utilize your graphics card. You just load the appropriate drive (or the operating system loads it during installation) and the GPU is used to its potential. As a DBA I don't want to learn new programming or new query optimization techniques to use a new piece of hardware. I want to plug it in and benefit from it.

Just my two cents.

keith

Query cache != bad!!

*** I wrote this in late September last year and it has languished in my draft folder. Man, I should pay more attention to such things!! Sorry for the delay.

A couple of people have written lately about the query cache.

Konstantin wrote here Marc wrote here.

Konstantin believes the query cache should be removed from the server. Mark didn't make any recommendations one way or the other -- although he did post tests that show that the performance can fluctuate quite a bit according to version. While I would absolutely say you should monitor and test your setup there are cases where it can make a dramatic difference. I just looked at a configuration on a client's server where the query cache was enabled and serving over 3,000 queries a second from cache. Yes, from cache. In the same week I have seen another client's configuration where the query cache was slowing things up and I recommended that the QC be turned off.

As with all configuration changes you make to a server, you should always monitor the results of the change. The results of your changes may or may not be what you expect. I for one would say the QC should stay right where it is .. turned off by default and available for your use if you so desire. Additional intelligence built into the query cache would be nice but it is useful in many cases as is.