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 45 Next 15 Older Entries

Displaying posts with tag: bug (reset)

On responsible bugs reporting
+1 Vote Up -0Vote Down
Let me start with questions related to responsible MySQL bugs reporting that I'd like to be discussed and then present a history behind them.

Assuming that you, my dear reader from MySQL Community, noted or found some simple sequence of SQL statements that, when executed by authenticated MySQL user explicitly having all the privileges needed to execute these statements, crashes some version of your favorite MySQL fork, please, answer the following questions:
  • Do you consider this kind of a bug a "security vulnerability"?
  • Should you share complete test case at any public site (MySQL bugs database, Facebook, your personal blog, any)?
  • Should you share just a description of possible "attack vector", as Oracle does when they publish security bug fixes?
  • Should you share just a stack trace or failed assertion information,

  •   [Read more...]
    Recalculating InnoDB Persistent Statistics - a Story of the Bug Report
    +0 Vote Up -0Vote Down
    One of the first posts in this blog was about reporting MySQL bugs "properly", in a way that maximizes chances for it to be processed really soon. I had written the following there:
    "Ideally, you should provide a complete test case and/or instructions that any reader can use to reproduce your problem"
    Indeed, if one can just copy/paste something to mysql command line client or run some file attached to see the problem, chances are high for the bug to be processed really soon. We all like to get low hanging fruits from time to time, and Oracle engineers who work on bugs are not exceptions. But does this mean that bug without clear test case has no value and is going to be ignored?

    It should NOT be the case. Let's

      [Read more...]
    New MySQL 5.6-Feature host_cache_size does not work
    +1 Vote Up -0Vote Down

    Today as i was learning for the new MySQL 5.6-certification (more about that in a later post) i stumbled again across the host_cache-Table that was added to MySQL in 5.6.5. Before that you had no chance to check which hosts are already known by the MySQL-server.

    So thats a pretty good feature for us. And even better: you could resize the size of the host_cache now! Whoohoo, awesome! As we have a lot of servers that need to connect to one of our MySQL-server and we could not switch to ip-based-authentication we were really happy to tune the host_cache-size without recompiling MySQL.

    Unfortunately i noticed that the performance_schema.host_cache table only holds 128 rows and that the content was changing everytime i checked. So i logged in to a server that wasn’t already in the host_cache-table, made a connection attempt to the mysql server

      [Read more...]
    phpMyAdmin breaks Replication in MySQL 5.6
    +0 Vote Up -0Vote Down

    Recently i updated to MySQL 5.6 and we were really excited about the very good overall performance. But beside a major bug concerning wrong results when running a SELECT that includes a HAVING based on a function (see http://bugs.mysql.com/bug.php?id=69638) we also noticed that from time to time the replication breaks with the following error:

    Last_SQL_Errno: 1590
    Last_SQL_Error: The incident LOST_EVENTS occured on the master. Message: error writing to the binary log

    After some investigation it seemed like this happens if one modifies some user privileges, so we stumbled upon http://bugs.mysql.com/bug.php?id=68892.

    Essentially the bug report says that if you use the wrong syntax for GRANT-statements the

      [Read more...]
    Fix for INFORMATION_SCHEMA.PARTITIONS losing table stats
    +0 Vote Up -0Vote Down

    Here is a fix for the MySQL/TokuDB/MariaDB bug I reported earlier today.  I think this fix is correct (it is only one line) but I don’t delve into the storage engine very often (and particularly not into ha_partition.cc) so I think it would be good to wait for Oracle (or Percona, MariaDB, or Tokutek) to validate that it is correct before using it.

    diff -u ha_partition.cc /tmp/ha_partition.cc 
    --- ha_partition.cc 2013-04-05 05:27:18.000000000 -0700
    +++ /tmp/ha_partition.cc 2013-05-27 02:45:01.680676228 -0700
    @@ -6455,9 +6455,11 @@
    void ha_partition::get_dynamic_partition_info(PARTITION_STATS *stat_info,
    uint part_id)
    handler *file= m_file[part_id];
    DBUG_ASSERT(bitmap_is_set(&(m_part_info->read_partitions), part_id));
    + info(HA_STATUS_CONST |
      [Read more...]
    xtrabackup_51: not found & no ‘mysqld’ group in MySQL options
    +0 Vote Up -0Vote Down
    Recently I happen to setup a new MySQL instance with my tools – a standard MySQL 5.1+, xtrabackup setup and last-hotbackup.tar.gz. To restore from the backup we used xtrabackup binaries and ran into issues following standard commands (assuming no changes): To prepare the backup I used apply-log as follows: $] innobackupex-1.5.1 --defaults-file=/usr/local/mysql/data/backup-my.cnf --apply-log  /usr/local/mysql/data --ibbackup […]
    Got a packet bigger than ‘slave_max_allowed_packet’ bytes and binlog_format = STATEMENT | MIXED
    +0 Vote Up -0Vote Down
    Send to Kindle

    Got a packet bigger than ‘slave_max_allowed_packet’ bytes and binlog_format=STATEMENT|MIXED

    Since version 5.1.64 MySQL introduces a new variable named slave_max_allowed_packet, which was introduced to allow large updates using row-based replication do not cause replication to fail when exceeded max_allowed_packet.

    The problem is if you have you replication using binlog_format=STATEMENT or binlog_format=MIXED it ignores this option and use as

      [Read more...]
    Maximum Open Files
    +0 Vote Up -0Vote Down

    Recently I was discussing with some colleagues the possibility of consolidating some MySQL servers. While the servers are not heavily loading (averaging less than 1,000 queries a second) they are pretty large in terms of storage requirements. Each server has roughly 200 databases on each with approximatley 50 tables. Thats 10,000 tables per server.  Each server contains up to 1 terabyte of data so if you consolidated servers at a 10:1 ratio you would have 10 terabytes of data, 2,000 databases and 100,000 tables with 10,000 queries per second average load.


    Alright, that's a lot. And without testing I don't know if it would work. It probably wouldn't.  But it might. And if it did, it would save the company a significant amount of money.  But, while discussing this,  someone brought up that open files limit might be a

      [Read more...]
    IOUG Podcast 24-AUG-2012 Rumors of MySQL’s Doom by Oracle / Design Piracy
    +2 Vote Up -4Vote Down
    For the week of August 24th, 2012: Everybody’s Preparing for OpenWorld Dispelling the Rumors of MySQL’s Impending Doom On Piracy of Design IOUG Podcast 24-AUG-2012 Rumors of MySQL’s Doom by Oracle / Design Piracy Subscribe to this Podcast (RSS) or … Continue reading →
    Nasty InnoDB regression in MySQL 5.5.25
    +3 Vote Up -0Vote Down

    We just ran into a nasty InnoDB bug that only seems to exist in MySQL 5.5.25:

    An InnoDB update that modifies a rows primary key can trigger some recursive behavior that creates new rows until all disk space is exceeded. This does not affect all primary key updates in general but only gets triggered when a few other conditions are also met, so you're not too likely to run into it, but if you do your mysqld server will waste a lot of IO bandwidth and storage space on this and will usually eventually run out of disk space.

    read more

    Using the MySQL stack trace to isolate bugs
    +2 Vote Up -0Vote Down

    I came across an interesting error reported on #mysql the other day. When I went through it with the reporter it looks like we uncovered up to two bugs in InnoDB (or rather XtraDB as it was Percona Server). I thought it might be useful to go through the error message, including the stack trace, to show that you don't need to be a developer to track down some useful information.

    read more

    MySQL DoS
    +1 Vote Up -1Vote Down
    There is a nice demo of  MySQL Bug 13510739 on Eric Romang's blog

    I've published this blog to make this content available on planet.mysql.com.
    A (little) MySQL bug story…
    +1 Vote Up -0Vote Down

    I just want to share about a strange behavior of one of our MySQL server yesterday.
    This server is a 5.1.50 MySQL server on debian 4.0 (Yes, I know…)

    When a “mysqld got signal 6” error occurred yesterday, the MySQL server crashed and didn’t want to restart.
    Then, I found these informations in the error log file :

    /usr/local/mysql/bin/mysqld: File '*** glibc detected ***
    malloc():memory corruption: 0x00002aac2d5ab460 ***' not found (Errcode: 2)
    120306 17:19:47 [ERROR] Failed to open log (file '*** glibc detected ***
    malloc():memory corruption: 0x00002aac2d5ab460 ***', errno 2)
    120306 17:19:47 [ERROR] Could not open log file
    120306 17:19:47 [ERROR] Can't init tc log
    120306 17:19:47 [ERROR] Aborting
    120306 17:19:47 InnoDB: Starting shutdown...
    120306 17:19:53 InnoDB: Shutdown completed; log sequence number 55 1061584593

      [Read more...]
    Twitter bug found!
    +0 Vote Up -0Vote Down

    Some days ago while I’m looking for what are saying about a mysql.com server down I found a twitter bug:

    Is not a big deal, to repeat this bug you must follow these steps:

    1. Find any term, in this case “mysql.com” then in results looking for a word that have the search term as a part of them (ex dev.mysql.com) and select the a part or entire word:

    2. Press Ctrl + C,  some HTML codes appear from nowhere:

      [Read more...]
    Nasty Regression Bug Seems Fixed in 5.5.18
    +7 Vote Up -0Vote Down

    For those who saw my previous post about the crashing (regression) bug with SELECT COUNT(DISTINCT) on InnoDB with Primary Key (PK), you’ll be interested to know my test case does not crash in 5.5.18 (which was just released).

    I’ve only tested my test case thus far, but it seems fine.

    Unfortunately, the fix is not mentioned in the 5.5.18 changelogs though.

    And there is no mention (yet, anyway) of a fix in the bug report I filed (though it was designated a ‘duplicate’, so it wouldn’t necessarily be updated).

    I’m trying to get confirmation from the MySQL Dev Team on this (via the bug report), and will update this post if/when I hear anything.

    I’ll also perform some of

      [Read more...]
    MySQL SSL Users: BEWARE This Bug
    +1 Vote Up -1Vote Down

    If you’re using MySQL and SSL, you might want to glance over this article and give your setup a quick test.

    I’ve uncovered an alarming bug in 5.5 where one could gain access to your MySQL instance just knowing the username and password (not having any SSL certificate, key, etc.)!

    Of course, I’ve filed a bug about it here:


    It’s been over 4 days now, and not one comment from the MySQL Bug/Dev Team.

    So once again, I feel the need to share this bug with the public, in case you are using SSL with 5.5, and think your connections are secure, or that only users with the certs/key could gain access.

    For SSL Users, you’ll already have this set up, but for those who don’t, I’ve simply got mysqld (5.5.15 and 5.5.16 thus far) running with the

      [Read more...]
    Nasty Regression Bug: SELECT COUNT(DISTINCT) crashes InnoDB when WHERE operand is in Primary Key or Unique Index
    +8 Vote Up -0Vote Down

    In 5.5, a crashing, regression bug exists if you use SELECT COUNT(DISTINCT) *and* one of the WHERE operands is in the Primary Key (or just a unique index).

    This simple crash (if only one row is in the table) will crash mysqld.

    Of course I’ve filed a bug report, but that has been nearly 3 months and no updates yet.

    Here is the bug I filed (which you won’t be able to view):


    Really, the only thing that happened to my bug report was that it was designated a duplicate of another bug (which we also cannot view):


    Based on the id, and the submitted dates of bugs 61100 and 61102, this initial bug (61101) was filed on May 9, 2011. So, in fact, this bug has been present for over 5

      [Read more...]
    xtrabackup incremental backups
    +0 Vote Up -0Vote Down

    We wanted to optimize and test backups for one of our new large scale setup before we could finalize on the backup plan. Our challenge was the data volume was almost 30x more than our normal volumes. Since this involved large volume of data we thought this might be a good candidate to test incremental backups. We wrote a wrapper script to save the states between full backups and incremental backups and did some tests with smaller data sets. It worked perfectly fine. The version of xtrabackup we were testing was 1.6.2.

    The incremental backups were completing well within 30minutes. We set out to test what would happen if the amount of incremental diff was large. While doing this test, we started getting backup failures with the following error

    20110726_225312.log-110727 00:56:10 innobackupex: Starting to backup .frm, .MRG, .MYD,

      [Read more...]
    Undocumented ALTER TABLE that does *nothing* (useful)
    +1 Vote Up -0Vote Down

    (at least since MySQL 5.1.42)

    alter table t1 force;

    Pretty neat huh? In fact, in Drizzle this will end up doing a copying alter table. Not useful.

    There’s an over four year old bug report in MySQL (Bug#24091).

    I’m just going to remove that bit from the parser in Drizzle – it makes no sense.

    MySQL 5.5.8 GA and PHP 5.3.4 don’t get along with libmysql
    +0 Vote Up -0Vote Down

    Today I discovered that you are unable to compile the current stable PHP version 5.3.4 with yesterday’s MySQL 5.5.8 GA release. I was able to download the current MySQL 5.1.54 and compile without issue.

    You can find all the gory details in Bug #58987 however I was able to edit a number of MySQL include file to get a build. Does this mean it’s a MySQL packaging problem or a PHP problem I don’t know, but I would hope that Oracle in the testing phase of a GA release test this against popular programming languages starting with the LAMP stack to ensure compatibility such as what I uncovered.

    Storage Engine API state graph
    +2 Vote Up -0Vote Down

    Drizzle still has a number of quirks inherited from the MySQL Storage Engine API (e.g. BLOBs, row buffer, CREATE SELECT and lack of DDL transaction boundaries, key tuple format). One of the things we fixed a long time ago was to have proper methods for StorageEngines to be called for: startTransaction, startStatement, endStatement, commit and rollback.

    If you’ve had to implement a transactional storage engine in MySQL you will be well aware of the pattern

      [Read more...]
    Update on “A Tale Of a Bug”
    +1 Vote Up -0Vote Down

    The bug I talked about a little while ago has now also had the fix I wrote committed to the mysql-trunk 5.5.6-m3 repository.

      [Read more...]
    A tale of a bug…
    +3 Vote Up -2Vote Down

    So I sometimes get asked if we funnel back bug reports or patches back to MySQL (http://mysql.com) from Drizzle. Also, MariaDB adds some interest here as they are a lot closer (and indeed compatible with) to MySQL. With Drizzle, we have deviated really quite heavily from the MySQL codebase. There are still some common areas, but they’re getting rarer (especially to just directly apply a patch).

    Back in June 2009, while working on Drizzle at Sun, I found a bug that I knew would affect both. The patch would even directly apply (well… close, but I made one anyway).

    So the typical process of me filing a MySQL bug these days is:

    • Stewart files bug
    • In the next window of Sveta being awake, it’s verified.

    This happened within a

      [Read more...]
    ENUM now works properly (in Drizzle)
    +1 Vote Up -1Vote Down

    Over at the Drizzle blog, the recent 2010-06-07 tarball was announced. This tarball release has my fixes for the ENUM type, so that it now works as it should. I was quite amazed that such a small block of code could have so many bugs! One of the most interesting was the documented limit we inherited from MySQL (see the MySQL Docs on ENUM) of a maximum of 65,535 elements for an ENUM column.

    This all started out from a quite innocent comment of Jay‘s in a code review for adding support for the ENUM data type to the embedded_innodb engine. It was all pretty innocent… saying that I should use a constant instead of the magic

      [Read more...]
    Best Practices: Additional User Security
    +0 Vote Up -0Vote Down

    By default MySQL allows you to create user accounts and privileges with no password. In my earlier MySQL Best Practices: User Security I describe how to address the default installation empty passwords.

    For new user accounts, you can improve this default behavior using the SQL_MODE variable, with a value of NO_AUTO_CREATE_USER. As detailed via the 5.1 Reference Manual


    Prevent the GRANT statement from automatically creating new users if it would otherwise do so, unless a nonempty password also is specified.

    Having set this variable I attempted to show the error of operation to demonstrate in my upcoming

      [Read more...]
    New CREATE TABLE performance record!
    +0 Vote Up -0Vote Down

    4 min 20 sec

    So next time somebody complains about NDB taking a long time in CREATE TABLE, you’re welcome to point them to this :)

    • A single CREATE TABLE statement
    • It had ONE column
    • It was an ENUM column.
    • With 70,000 possible values.
    • It was 605kb of SQL.
    • It ran on Drizzle

    This was to test if you could create an ENUM column with greater than 216 possible values (you’re not supposed to be able to) – bug 589031 has been filed.

    How does it compare to MySQL? Well… there are other problems (Bug 54194 – ENUM limit of 65535 elements isn’t true filed). Since we don’t have any limitations in Drizzle

      [Read more...]
    MySQL 5.5.4 looks awesome.
    +5 Vote Up -0Vote Down

    Been at the MySQL conference the last few days, and I have to say, I’m really blown away by MySQL 5.5.4‘s improvements.  Last year I keynoted and I begged Oracle on stage to realize that MySQL and InnoDB under one roof represented opportunity.  It’s clear they heard the community – this is some serious progress, and right when we needed it.

    Jeremy Zawodny’s blog post covers most of the stuff I’m really excited about, and there are some great detailed technical slides

      [Read more...]
    Ubuntu Karmic's Network Manager Issues
    +1 Vote Up -1Vote Down
    Since Ubuntu 8.04 aka Hardy Heron, I've had issues with every new release. As Ubuntu evolves into being a viable desktop OS alternative, its complexity has been growing and with the new and improved looks new challenges arise. This bug in particular has been very difficult to diagnose and I can't imagine anyone without enough Linux experience to overcome it on their own, so I decided to summarize the steps I took to fix it ... and vent my frustration at the end.

    The Symptom

    I came across the issue for the first time while trying Ubuntu's Karmic Netbook remix. After overcoming the typical Broadcom wifi driver, Network Manager would connect, but Firefox would fail to load the web pages 90% of the time. Using ping in the command line worked just fine. Maybe I needed to update the software packages to get the latest
      [Read more...]
    Will your production MySQL server survive a restart?
    +3 Vote Up -0Vote Down
    Do you know if your production MySQL servers will come back up when restarted? A recent support episode illustrates a number of best practices. The task looked trivial: Update a production MySQL server (replication master) with a configuration tuned and tested on a development server. Clean shutdown, change configuration, restart. Unfortunately, the MySQL daemon did not just ‘come back’, leaving 2 sites offline. Thus begins an illuminating debugging story. First place to look is the daemon error log, which revealed that the server was segfaulting, seemingly at the end of or just after InnoDB recovery. Reverting to the previous configuration did not help, nor did changing the InnoDB recovery mode. Working with the client, we performed a failover to a replication slave, while I got a second opinion from a fellow engineer to work out what had gone wrong on the server. Since  [Read more...]
    Be careful with BETWEEN clauses, because the MySQL optimizer is not smarter than a fifth grader!
    +2 Vote Up -7Vote Down
    edit: I filed MySQL bug#46867 about this issue.

    Ask anyone who has learned to count the following two questions. The answer to both of which should be yes.

    Q:Is 5 between 1 and 10? A: Yes

    Q:Is 5 between 10 and 1? A: Yes

    Ask MySQL those same questions:

    mysql>  (select 'Yes' 
               from dual 
              where 5 between 1 and 10
            (select 'No'
            limit 1;
    | Yes |
    | Yes |
    1 row in set (0.00 sec)
    mysql>  (select 'Yes' 
              from dual 
             where 5 between 10 and 1 
            (select 'No') 
            limit 1;
    | Yes |
    | No  |
    1 row in set (0.00 sec)

    This is a problem because applications may produce BETWEEN clauses. I don't think

      [Read more...]
    Showing entries 1 to 30 of 45 Next 15 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.