In my experience there has been a driving factor, a mindset of those who make the purchasing decisions and are not necessarily technically knowledgeable, that the value of an item somehow equates to the money spent acquiring it. A company I worked for years ago catered to this mindset by way of pricing their product according to factors such as speed, capacity, and price of the target computer. The same software was delivered to all customers, but the understanding was that owners of computers would somehow expect software to be valued in relation to their computer. Owners of expensive computers would expect to have to purchase expensive software for it, and distrust something viewed as too cheap, whereas owners of lower priced systems would not want to pay as much for the software by the same token.

Times have changed but the value/price mindset continues. One place I was at a few years ago seemed caught up in the mindset. They hired …

After I mentioned in this blog posting a week ago that I’d make an announcement on August 28 concerning my future priorities, I received different reactions. Mostly there seems to be a lot of understanding and appreciation for what I’ve contributed to the fight for balanced patent policy, and that’s great. But some people misunderstood my remark: the decision hasn’t been taken yet, and it’s not an appropriate point in time to say which outcome is more likely because a lot can still happen in one week. Come August 28, I’ll decide and announce.

What transpired from of the responses isn’t really a surprise: to many people I’m simply “Mr. NoSoftwarePatents” because that’s the context in which they first came to know me. My backgrounder …

Looking at the list of referrers for this blog, I found one coming from Mike Kruckenberg. First of all it is a nice post to read for anyone who (has to) work with databases, so be sure you take a look.

Moreover I learned about LogBuffer which I did not know before. So if anyone else dealing with databases does not know it yet, maybe you will it as interesting as I did.

I've released version 0.1.146 of the innotop MySQL and InnoDB monitor. You can download innotop from the original article.

I re-arranged some information to be more compact and readable in this version, but there isn't really much new functionality. This is mostly a bug-fix release to prevent crashes when innotop encounters unexpected information, or doesn't find some information it expects to exist. It's still very much beta software, so it may die unexpectedly. See this article about what information I need to debug and fix crashes.

Crashes should not cause any loss of information or other problems, by the way. It's completely safe to run, because it doesn't modify anything, it just reads status information. Up till now I've preferred …

There are whole books on the subject about building a great design that is scalable and portable among developers and or administrators.

Then there are whole books on the subject of capacity and scalability for the database layer.

Then there are novels from developers that in many cases really don't know the tricks of the DBMS they are working with, and create elaborate abstraction layers that automatically generate SQL for the DB in question from objects and such.

But, with all these people who tell you how to do it, actually can they prove that it works under a constant high workload for many people all at the same time.

I can boast this. Flickr does over 4 BILLION+ queries per day, 2 BILLION of which are SELECTS. Most of our data is REAL TIME queries from the database layer. We don't do any fancy tricks to dedicate resources to API calls to certain servers; they hit the SAME servers …

Well, it’s been completed a few weeks now, but I’ve finally reworked the Connector/MXJ and Connector/J sections of the MySQL Reference Manual, which in turn means the Connectors chapter has been completed.

read more

I’ve released version 0.1.146 of the innotop MySQL and InnoDB monitor. I re-arranged some information to be more compact and readable in this version, but there isn’t really much new functionality. This is mostly a bug-fix release to prevent crashes when innotop encounters unexpected information, or doesn’t find some information it expects to exist. It’s still very much beta software, so it may die unexpectedly. See this article about what information I need to debug and fix crashes.

As I already announced last week I started MySQL Performance Forums project focusing on MySQL Performance discussions as it names says.

I spend planty of time replying questions and thought it would be good idea to provide weekly overviews of most interesting topic discussed. Here is the list for last week:

Ways to perform full text search on Chinese texts with MySQL

Replication of Summary tables only

Overhead of enabled general query log

Complex join vs running many queries

…

I was looking for an alternative to MySQL Cluster for large tables, less critical tables but still important enough ones ;)

I got MySQL cluster up and running for most of my tables, but we need some tables that are storing log information, it's not really critical, but we don't want to loose it anyway. As we don't want to put that stuf in memory I was looking into replication those tables. Now Linux-HA takes care of which mysqld instance to talk to , but if I fail over the active database IP the applications start writing to the 2nd node which is the replication slave for a couple of tables. That's perfect for the Cluster tables, but it's pain for the replicated InnodB tables as replication breaks and I can't migrate back automagically.

Upon reading the --read-only parameter in the replication documentation I tought I had found the solution, only to realise this actually puts the whole mysql in read-only also the tables being used …