Home |  MySQL Buzz |  FAQ |  Feeds |  Submit your blog feed |  Feedback |  Archive |  Aggregate feed RSS 2.0 English Deutsch Español Français Italiano 日本語 Русский Português 中文
Showing entries 1 to 30 of 44 Next 14 Older Entries

Displaying posts with tag: rant (reset)

+1 Vote Up -0Vote Down
Benchmarking and benchmarketing both have a purpose. Both also have a bad reputation. A frequently expressed opinion is that benchmark results are useless. I usually disagree. I don't mind benchmarketing and think it is a required part of product development but I am not fond of benchmarketing disguised as benchmarking.

Benchmarketing is a common activity for many DBMS products whether they are closed or open source. Most products need new users to maintain viability and marketing is part of the process. The goal for benchmarketing is to show that A is better than B. Either by accident or on purpose good benchmarketing results focus on the message A is better than B rather than A is better than B in this context. Note that the context can be critical and includes the hardware, workload, whether both systems were properly configured and some attempt to

  [Read more...]
Everything is awesome
+1 Vote Up -0Vote Down
My kids watched the new Lego movie today and spent the rest of the day repeating "Everything is amazing". I spent a few hours reading MongoDB documentation to help a friend who uses it. Everything wasn't awesome for all of us. I try to be a pessimist when reading database documentation. If you spend any time near production then you spend a lot of time debugging things that fail. Being less than optimistic is a good way to predict failure.

One source of pessimism is database limits. MongoDB has a great page to describe limits. It limits index keys to less than 1025 bytes. But this is a great example that shows the value of pessimism. The documentation states that values (MongoDB documents) are not added to the index when the index key is too large. An optimist might assume that an insert or update statement fails when

  [Read more...]
Legacy isn't a dirty word
+3 Vote Up -0Vote Down
Pardon the rant but the winter storm has kept me in a hotel away from home for a few days. I exchanged email this week with someone pitching a solution to a problem I don't have (MySQL failover). But by "I" I really mean the awesome operations team with whom I share an office. The pitch got off to a bad start. It is probably better to compliment the supposed expertise of the person to whom you are pitching than to suggest they are no different than COBOL hackers working on Y2K problems.

Unfortunately legacy is a bad word in my world. Going off topic, so is web scale. I hope we can change this. The suggestion that MySQL was a legacy technology was conveyed to me via email, x86, Linux and a laptop. Most of those have been around long enough to be considered legacy technology. DNA and the wheel are also legacy technology. Age isn't the issue. Relevance is determined

  [Read more...]
The Foundation Exists!
+0 Vote Up -0Vote Down
I have been wondering what the Foundation has been up to. I had high hopes for it and even contributed money but it has been very quiet. Fortunately I learned that it has been busy making decisions, maybe not in public, but somewhere. And at Percona London we will be told why it forked MariaDB prior to 5.6 and reimplemented a lot of features.

In other news the Percona London lineup looks great and I appreciate that Oracle is part of it.
on nuodb and falcon
+3 Vote Up -0Vote Down

Warning: this is a mixture of historical content, biases, stupid marketing and unknown/proprietary/closed source technologies. Proceed with caution.

NuoDB marketing was sending out this message, encouraging me to blog (they were looking for bloggers too):

And while Facebook sharded MySQL 4000 times, even they call it a “fate worse than death.”

We’ve seen this phrase before and it did not come from us. For whatever reason NewSQL echo chamber is repeating this with less and less truth in it. In various whitepapers (all behind registration walls) they mention some analyst estimates and try to put a parallel between operating costs of large companies and something a new developer would do, as if everyone is living under same constraints.

I don’t know if NuoDB is a good technology for the

  [Read more...]
Good news, MySQL 5.6.11 is here
+4 Vote Up -1Vote Down
MySQL 5.6.11 is here with many useful bug fixes. Not so good news - you won't be able to read about those bugs beyond the brief text in the release notes as many of the bug reports are behind the support paywall. If you have lots of time to spare maybe you can read diffs in the source tree on launchpad.

This is a lousy way to grow a community, especially the community contributing many of the useful bug reports, reproduction cases and some patches. I just reviewed the 5.6.11 release notes and I am impressed that lots of problems were fixed. Many of the bugs were reported by my team and for those bugs there are public reports.

Pro tip - file a public bug report, then link a support request to it to keep bugs open. Google/Bing are great for searching bugs.mysql.com.
My presentation from Fosdem
+1 Vote Up -0Vote Down

Last weekend I attended my first Fosdem conference. It was great to finally visit the conference that might be the biggest open source conference in the world. It's also an amazing experience how our Belgian friends pull off such a magnificent event purely with volunteer effort. You might say the conference itself is very much open source: free entry, created by volunteers. Organizers estimated that this year there were 7000+ attendees on campus. A hard data point was over 2300 simultaneous devices connected to Wifi.

I presented an introduction to Galera Cluster for MySQL. Due to problems with my personal laptop, I had to resort to an old version of the same presentation I had uploaded to Slideshare last year. (This is a variation of the old rule: The best way to backup your code is to publish it online as open

  [Read more...]
(less) open source
+16 Vote Up -0Vote Down
Regression tests for some bugs are not published in new MySQL releases. This was reported by the MariaDB project and Ronald. There are also delays in updating bzr after recent releases, but there have been delays in the past. Questions about what has changed have not been answered, so we are left to guess.

This matters to me. I spend a lot of time doing QA for MySQL and backporting fixes from new releases to the branch I support at work. It is much easier and safer to backport a few bug fixes than to upgrade a large number of servers. MySQL is much harder to make better when tests are missing and bzr is no

  [Read more...]
The value of being open
+7 Vote Up -0Vote Down
Do you lurk on the MariaDB and Ubuntu mailing lists? Maintainers might prefer to have an open bugs database.
Error injection tests for InnoDB would be nice
+2 Vote Up -0Vote Down
I am trying to figure out why an InnoDB table was lost when a DDL statement failed. I think it was a RENAME TABLE statement. I have yet to find the root cause but I did find that InnoDB doesn't report some errors when RENAME fails so the user thinks that the table was renamed, the FRM file is renamed, and the ibd file is not renamed. This is only a problem for files not in the InnoDB system tablespace so --innodb_file_per_table=1 must be used. This is bug 64144.

As I wrote in a previous blog post, it is time to add error injection tests to InnoDB.
Marketing a bug in 3 easy steps
+0 Vote Up -0Vote Down

  • File a request for crash recovery tests and wait a few months
  • File a request for error injection tests during InnoDB DDL and wait a few months
  • Lose a table during alter table because untested error handling is incorrect and blog about it
  • Great work, bug #12704861 was fixed!
    +2 Vote Up -0Vote Down
    MySQL Community Server 5.1.60 has been released and I am very happy because the release notes state that bug #12704861 has been fixed. I know this bug quite well. As my readers are very busy let me provide all of the details that have been made available to the community:
    InnoDB Storage Engine: Data from BLOB columns could be lost if the server crashed at a precise moment when other columns were being updated in an InnoDB table. (Bug #12704861)
    Multi-master, NoSQL and MySQL
    +6 Vote Up -0Vote Down
    The MySQL family has been innovating rapidly. New features need names and sometimes those names are confusing. Describing something as multi-master or a NoSQL solution has confused me.

    Multi-master requires one of conflict prevention, conflict resolution or faith. MySQL Cluster provides both conflict prevention and resolution as described in these great posts. Regular MySQL has minimal support for conflict prevention (auto-increment-offset can prevent insert conflicts) and thus requires faith that the application does the right thing. Regular MySQL gets conflict prevention via synchronous replication when used with Galera.

      [Read more...]
    Technical debt
    +4 Vote Up -0Vote Down
    Last time I checked there was one test in the MySQL test suite (mtr) that covers one case for crash recovery. Perhaps there is a private test suite. Given that I modify InnoDB and replication code and that I frequently debug crashes at work I wish there were more tests. I added many tests in the Facebook patch for crash recovery to confirm that recovery works for the replication slave, replication master and InnoDB. While doing so I found at least one bug in rpl_transaction_enabled. While working on global transaction IDs Justin found a few bugs in official MySQL that prevented recovery after the slave crashed. These were fixed  in official MySQL 5.1 so there is a lot of value in having tests like this. But there is a lot more that should be tested including:

    • crash recovery during DDL. There are windows where recovery is

      [Read more...]
    Wating For The Miracle
    +0 Vote Up -0Vote Down

    A short discussion with Baron at Henrik's blog has stirred my eloquence.

    Baron points to a great post by Josh Berkus where Josh contemplates the database clustering issues from a novel viewpoint. The post is really insightful. But I'm going to top that (albeit not so skilfully).
    In his post Josh maintains that existing PostgreSQL clustering solutions do a poor job satisfying user needs because developers concentrate too much on technological choices and too little on use cases, which he identifies three: Transactional User, Analytic User, Online User. And all developers need to do is just make three (only three) clustering solutions that would satisfy each of those use cases well. And all

      [Read more...]
    Is this a new feature?
    +8 Vote Up -0Vote Down
    Is this an amazing new feature or the next step after the change to bugs.mysql.com? I was about to file a bug report to improve the MySQL manual, but that won't happen now:

  • Go to page for MySQL Reference manual
  • Type text in "Search Manual" box on the left-hand side of the page
  • End up at login.oracle.com sign in page
  • Scaling-out OLTP load on Amazon EC2 revisited.
    +0 Vote Up -0Vote Down

    It's been long known that Galera optimistic replication and enterprise-size databases are a match made in heaven. Today we're going to get a little closer to testing this statement.
    We'll have look at how Galera can scale out Sysbench OLTP complex 60 million rows workload in EC2. This is a first proper benchmark for 0.8 series and also the first benchmark of MariaDB/Galera port, so I'll start modest, just to see how it goes. I chose m1.large instances with 7.8Gb of RAM for server nodes and c1.xlarge instance for a client - I don't want the client to be a bottleneck.

    For comparison I have also measured performance of a stock standalone MariaDB 5.1.55 server. I used the standard my.cnf that comes with MariaDB Debian package with the following alterations:


      [Read more...]
    Where have the bugs gone?
    +19 Vote Up -2Vote Down
    The incoming bug rate over the past 7 days is much lower than the past 14 days. Maybe this is a blip. But commits to trunk have begun to use 8-digit bug numbers that do not reference entries in bugs.mysql.com. I think something has changed but nothing has been announced. I like bugs.mysql.com. We all benefit by sharing bug reports and I   [Read more...]
    Drizzle beta is here!
    +8 Vote Up -3Vote Down

    Can we please tone down the marketing? It is great to see a community project grow, especially in the MySQL family. But you are judged by successful deployments, not by the class libraries used by your project.

    Drizzle is only more reliable than MySQL when it keeps the replication log and InnoDB in sync during crash recovery. But it does not do that today. Official MySQL supports this on a master via sync_binlog. MySQL slaves do this today via rpl_transaction_enabled which is available in the Facebook and Google patches. I think it is also available in Percona Server, MariaDB and XtraDB.

    I have been told

      [Read more...]
    For the n-th time, ReiserFS is not a cluster file system
    +6 Vote Up -1Vote Down

    Neither is ext3. Nor ext4. Nor btrfs. And thus, none of these will work on dual-Primary DRBD. Nor active-active shared storage. Nor any synchronously replicated active-active SAN. And we’re telling you very clearly.

    So if you choose to ignore all warnings and put ReiserFS on dual-Primary DRBD, and mount it from two nodes, you’ve just signed up for wrecking your data. And when that happens, don’t come whining. And don’t blame DRBD or any other of the technologies you may be choosing to employ while ignoring the documentation.

      [Read more...]
    Yesterday I heckled a speaker.
    +13 Vote Up -2Vote Down

    It's frustrating seeing examples of MySQL being slow as an example of why you should use NoSQL. If you have an invested interest[1] in comparing two technologies that are already apples to oranges, the least you can do is optimize both. If you can't do it, don't share it.

    This came out of a talk on Cassandra. "MySQL" is not on the slide, but it was mentioned in reference to MySQL:

    SELECT * FROM tweets WHERE user_id IN (SELECT follower FROM followers WHERE user_id = ?) order by time_tweeted DESC LIMIT 40;
    Let me simulate that for you:
    CREATE TABLE `tweets` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `user_id` int(11) NOT NULL,
      `info` text,
      PRIMARY KEY (`id`),
      [Read more...]
    Why don't you use X?
    +9 Vote Up -0Vote Down
    Sometimes I am asked why don't I use X instead of official MySQL. The answer is simple. I like to use it because I have been using it, the MySQL development team (including InnoDB) has done great work this year and because change is expensive. The cost of change includes the cost of evaluating the alternatives and the cost of deploying them. The cost of change also includes the features I won't work on because I am doing an evaluation. I also use it because the quality of new 5.1 releases has been very high this year. I know because I test them and some of the alternatives.

    My initial evaluation criteria are simple. I don't like compiler or valgrind warnings. The alternative should not introduce new ones. I like regression tests. The alternative should not disable or fail existing tests. If the existing test is somewhat bogus, then it should be fixed. I love

      [Read more...]
    Building MariaDB with the InnoDB plugin
    +10 Vote Up -2Vote Down
    This post was inspired by a couple events. But I won't explain them other than to say I think there have been too many subjective comments (or FUD) about quality. This is an attempt to quantify whether the grass is greener on the other side.

    Today I tried to build MariaDB with the InnoDB plugin. I was told his is now supported. The last time I checked XtraDB replaced the InnoDB plugin in MariaDB. MPAB had a reasonable reason for doing this as they don't want to test both the InnoDB plugin and XtraDB. But I prefer choice, despite the many great features in XtraDB.

    First I tried using the 5.3 release. That failed fast. I prefer fast failures over obscure ones:

    ./configure --enable-thread-safe-client --with-plugins=partition,csv,blackhole,myisam,heap,innodb_plugin --without-plugin-innobase --with-fast-mutexes --with-extra-charsets=all

      [Read more...]
    Best practices
    +7 Vote Up -0Vote Down
    Back in the day we wrote C without support for type checking. Many bugs were missed because of this. Someone wrote lint and many bugs were prevented. Not everyone takes advantage of tools that prevent easily fixed errors. MySQL builds are done without using the -Wall option in gcc to generate more warnings. Nor do they use the -Werror option to fail on warnings. This allows for some silly things in production releases like bug 51289 (return NULL for a function that is declared to return double):

      [Read more...]
    How MySQL can placate the communtiy
    +5 Vote Up -1Vote Down
  • Announce
  • Release
  • This works as long as the gap between Announce and Release is not unreasonably large. The Announce step was done last week. We can all help with the Release step by using a 5.5 beta, reporting bugs and reading the excellent documentation for MySQL 5.5 and InnoDB 1.1.
    Fast reads or fast scans?
    +5 Vote Up -0Vote Down
    MyISAM is frequently described and marketed as providing fast reads when it really provides fast index and table scans. This is a more narrow use case as fast reads implies great performance for most queries while fast scans implies great performance for single-table queries that are index only or do a full table scan.

    MyISAM caches index blocks but not data blocks. There can be a lot of overhead from re-reading data blocks from the OS buffer cache assuming mmap is not used. InnoDB and PBXT are 20X faster than MyISAM for some of my tests. However, I suspect that mutex contention on the key cache is also a factor in the performance differences.

    While there are many claims about the great performance of MyISAM. There are not as many examples that explain when it is fast. Alas, the same marketing technique is being repeated with NoSQL to the disadvantage of MySQL.

      [Read more...]
    Thoughts on Drizzle
    +14 Vote Up -0Vote Down
    I wish the case for Drizzle could be made without bashing MySQL. Sometimes it is, but too often it isn't. I guess this is karma.

    This isn't a rant against Drizzle. This is a rant against pulling up Drizzle by pushing down MySQL. I occasionally have negative things to say about MySQL, but I usually say them to get the problems fixed. We have lots of complaints about MySQL because we use it in production.

    What have I learned about the Drizzle vision?
    • Drizzle will re-think everything
      • Alas, I have problems to solve today. While I am passionate

      [Read more...]
    The Lack of Flexibility of Stored Procedures in MySQL
    +0 Vote Up -4Vote Down

    Over three years ago I wrote about how you cannot use a stored procedure in a subquery. Well, it’s 2010, and I’m still annoyed by this and a handful of other things.

    I was just working today on a report consisting of a series of queries, taking about a minute to generate. Some of the data would be created in a temporary table and queried against multiple times for performance reasons, and ultimately spit out into a CSV file for someone to examine later. I also would like to be able to return the result set, and perform queries on it, which is much faster than querying a view.


      [Read more...]
    again, on benchmarks
    +6 Vote Up -0Vote Down

    Dear interweb, if you have no idea what you’re writing about, keep it to yourself, don’t litter into the tubes. Some people may not notice they’re eating absolute crap and get diarrhea.

    This particular benchmark has two favorite parts, that go with each other together really well:

    I didnt change absolutely any parameters for the servers, eg didn’t change the innodb_buffer_pool_size or key_buffer_size.


    If you need speed just to fetch a data for a given combination or key, Redis is a solution that you need to look at. MySQL can no way compare to Redis and Memcache. …

    Seriously, how does one repay for all the damage of such idiotic benchmarks?

    P.S. I’ve ranted at benchmarks before, and will continue doing so.

    Bad Web Developers Don’t Scale
    +2 Vote Up -1Vote Down

    Over the last 5 years, I’ve read so many articles about how X doesn’t scale. PHP, MySQL, SQL Server, Apache, you name it – everything gets a bad rap. Everyone has a different idea of scale and size, and sadly most people think their site with 1 million page views a month can’t handle the load because whatever technology they chose to use supposedly doesn’t scale.

    Guess what folks – the problem probably isn’t the language you chose, or the database you’re using. Unless you’re actually big (many millions of pageviews per day), you can usually run just fine with a straight up LAMP stack on a few servers. The real issue is that your dev team has no idea how to write software or use the tools they have available.

    At this point, I wonder – what is everyone’s expectation? At what point does someone

      [Read more...]
    Showing entries 1 to 30 of 44 Next 14 Older Entries

    Planet MySQL © 1995, 2014, Oracle Corporation and/or its affiliates   Legal Policies | Your Privacy Rights | Terms of Use

    Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.