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 18

Displaying posts with tag: crash (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...]
    Are MariaDB tests adding anything extra over Oracle MySQL tests?
    +3 Vote Up -0Vote Down

    I grabbed all the tests introduced in MariaDB 5.5.32 (i.e. “bzr diff -rtag:mariadb-5.5.31..mariadb-5.5.32 mysql-test/” and some foo) and threw them in their own test file. I only kept tests for crashing bugs and ignored those that required plugins (there were two or three, but nothing major). So now I have a test file that should crash MariaDB 5.5.31 and probably before. But, the question is: does this crash Percona Server or MySQL?

    While it is excellent to see the MariaDB guys including tests for their crashing bugs, are these MariaDB specific or do they affect other MySQL flavours?

    I built a release build of top of trunk Percona Server and ran the test against it. I got no crashes. In a debug build,

      [Read more...]
    Initial Reactions to MySQL 5.6
    +3 Vote Up -0Vote Down

    New versions of MySQL are always interesting to try out. Often they have features which I may have asked for myself so it’s satisfying to see them eventually appear on a system I use. Often other new features make life easier for the DBA. Finally we hope overall performance will improve and managing the server(s) will be come easier.

    So I had a system which needs to make heavy writes, and performance was a problem, even when writing to SSDs. Checkpointing seemed to be the big issue and the ib_logfile size in MySQL 5.5 is limited to 4 GB. That seems a lot, but once MySQL starts to fill these files (and this happens at ~70% of the total I believe),  checkpointing kicks in heavily, and slows things down.  So the main reason for trying out MySQL 5.6 was to see how things performed with larger ib_logfiles. (Yes, MariaDB 5.5 can do this too.)

    Things improved a lot for my

      [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...]
    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):

    http://bugs.mysql.com/bug.php?id=61842

    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):

    http://bugs.mysql.com/bug.php?id=61101

    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...]
    Unexpected mysqld crashing in 5.5
    +3 Vote Up -2Vote Down

    An update of MySQL from 5.0 to 5.5 on CentOS 5.5 64bit has not resulted in a good experience. The mysqld process would then crash every few minutes with the following message.

    101120 8:29:27 InnoDB: Operating system error number 22 in a file operation.
    InnoDB: Error number 22 means ‘Invalid argument’.
    InnoDB: Some operating system error numbers are described at
    InnoDB: http://dev.mysql.com/doc/refman/5.1/en/operating-system-error-codes.html
    InnoDB: File name /tmpfs/#sql6cf3_5c_0.ibd
    InnoDB: File operation call: ‘aio write’.
    InnoDB: Cannot continue operation.
    

    The work around was to change the tmpdir=/tmpfs (which was a 16G tmpfs filesystem) to a physical disk.

    The referenced URL didn’t provide any more information of help. Unlike Bug #26662 O_DIRECT is not specified as the flush method.

    A Quick Review of Stack Traces
    Employee +5 Vote Up -0Vote Down
    I'll try to pass on some basic knowledge about those confusing stack traces we sometimes see in the mysql error logs.  What can you tell from them, what are they useful for, and how to validate them?
    Debugging Crashes
    We tried to improve postmortem debugging of crashes + stack traces in the error log:o) old versions of mysqld only printed numerical numbers instead of function names (if you're lucky!)o) some platforms/architectures printed no stack trace what-so-ever!o)

      [Read more...]
    How to crash mysqld intentionally
    +0 Vote Up -0Vote Down

    While some may think I’m daft, I have a legitimate reason for wanting to crash mysqld. However first we need to find a way to crash it.

    Great thanks to Alan K, Mark L, Harrison and Hartmut on #mysql-dev for several suggestions and a config option I was unaware of. My investigation even lead to a documentation bug logged as #51739.

    My first thought was to find a known bug and if necessary install the correct version to test that. A good one was suggested, Bug #48508 which fails on several versions that I will use to demonstrate with, however the simplest way is to issue kill -11

    By default, no core file will be produced which is what I’m seeking but with the right options this is possible. First, the user running mysqld probably has a

      [Read more...]
    How to tell when using INFORMATION_SCHEMA might crash your database
    +8 Vote Up -2Vote Down

    There are those that are very adamant about letting people know that using INFORMATION_SCHEMA can crash your database. For example, in making changes to many tables at once Baron writes:

    “querying the INFORMATION_SCHEMA database on MySQL can completely lock a busy server for a long time. It can even crash it. It is very dangerous.”

    Though Baron is telling the truth here, he left out one extremely important piece of information: you can actually figure out how dangerous your INFORMATION_SCHEMA query will be, ahead of time, using EXPLAIN.


    In MySQL 5.1.21 and higher, not only were optimizations made to the INFORMATION_SCHEMA, but new values were added so that EXPLAIN had better visibility into what MySQL is actually

      [Read more...]
    Crash recovery, again
    +5 Vote Up -0Vote Down

    There’s one stage in InnoDB crash recovery where it reads log file, you know, this one:

    InnoDB: Doing recovery: scanned up to log sequence number 354164119040
    InnoDB: Doing recovery: scanned up to log sequence number 354169361920
    

    On a machine with bigger logs it will start spending nearly 100% CPU somewhere in recv_scan_log_recs. Guess what it does…. -fno-inline builds to the rescue:

    #0  mem_block_get_len at ./include/mem0mem.ic:86
    #1  mem_heap_get_size at ./include/mem0mem.ic:591
    #2  recv_scan_log_recs at log/log0recv.c:2727
    

    And:

    samples  %        symbol name
    8467     72.9222  mem_heap_get_size
    291       2.5062  recv_add_to_hash_table
    95        0.8182  mem_block_get_len
    

    To speak in layman’s terms, InnoDB does SUM(LENGTH(allocation)) on its relatively wide memory (tens, hundreds of thousands of entries) arena,

      [Read more...]
    thread_stack_size in my.cnf
    +2 Vote Up -0Vote Down

    Many configs have thread_stack_size configured explicitly, but that can cause rather bad trouble:

    • if the stack inside a thread it’s too small, you can get segfault crashes (stack overflow, essentially). Particularly on 64-bit.
    • if the stack is too large, your system cannot handle as many connections since it all eats RAM.

    Let mysqld sort it out, on startup it does a calculation based on the CPU architecture, and that’s actually the most sensible. So for almost all setups, remove any thread_stack_size=… line you might have in my.cnf.

    Calculating your database size
    +2 Vote Up -0Vote Down

    I generally use the following MySQL INFORMATION_SCHEMA (I_S) query to Calculate Your MySQL Database Size. This query and most others that access the MySQL INFORMATION_SCHEMA can be very slow to execute because they are not real tables and are not governed by physical data, memory buffers and indexes for example but rather internal MySQL data structures.

    Mark Leith indicates in his post on innodb_stats_on_metadata that Innodb performs 8 random(ish) dives in to the index, when anybody accesses any of SHOW TABLE STATUS, SHOW INDEX, INFORMATION_SCHEMA.TABLES,INFORMATION_SCHEMA.STATISTICS for InnoDB tables. This can have an effect on performance, especially with a large number of Innodb tables, and a poor ratio of innodb_buffer_pool_size to disk data+index

      [Read more...]
    MySQL Workbench on Snow Leopard
    Employee_Team +0 Vote Up -0Vote Down

    As all you Mac users (and probably many non-Macies) know Apple released Snow Leopard (Mac OS X 10.6) recently, even though this release was announced for September previously. Since a large part of the MySQL Workbench user base works on OS X it was clear that many of you will test Workbench on the new OS. However, so far we haven’t had the opportunity to do the same (too busy fixing bugs on released OSes) and hence we did not know about incompatibility problems there.

    In the meantime several users did tests and reported us a crash on startup of the application, which means you cannot use MySQL Workbench on Snow Leopard for the time being. We are currently preparing build, test and developer machines with it and will hand out a fixed WB release as soon as possible. So, please stay patient. It’s only a matter of days.

    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...]
    MySQL Proxy - what if it crashes?
    Employee +2 Vote Up -0Vote Down

    While I hope the MySQL Proxy never crashes, it will happen, there will be some strange (or maybe not so strange) usage or workload and it will die.

    To avoid this, you could decide not to use it, or maybe you could use something like Linux HA to have more than one MySQL Proxy running at all times. Or you could use one of the new features that comes with the version 0.7.0.

    What is it?
    We now have a --keepalive option. As the name indicates, if the mysql proxy process dies/crashes, it will come back up in a few seconds (less than 5 seconds).

    How does







      [Read more...]
    MythTV recover Lost+Found
    +0 Vote Up -0Vote Down

    My MythTV store lives on an LVM volume that is spread over 2 disks, one of them is an external USB disk. So the cleaninglady seems to have touched a cable and after coming back from holiday I had a read-only filesystem that afer a remount had about 350Gb in lost+found with irrelevant filenames.

  • total 337407844
  • drwx------ 2 tv tv 4096 Dec 17 22:47 .
  • drwxrwxrwx 15 tv tv 4096 Dec 17 22:44 ..
  • -rw-r--r-- 1 root root 423343556 Dec 14 07:10 I303109.RCN
  • -rw-r--r-- 1 root root 2990538924 Dec 13 19:05 I303107.RCN
  • -rw-r--r-- 1 root root 1023691768 Dec 13 08:10 I319494.RCN
  • -rw-r--r-- 1 root root 1023622348 Dec 13 07:45 I327684.RCN
  • -rw-r--r-- 1 root root 423735892 Dec 13 07:10 I327682.RCN
  • -rw-r--r-- 1 root root 466749476 Dec 12 15:43 I135169.RCN
  • -rw-r--r-- 1 root root
  •   [Read more...]
    Navicat For MySQL Bugs Filed
    +0 Vote Up -0Vote Down

    Navicat For MySQL is a GUI for MySQL developers. I've tried a few tools before but somehow got attached to Navicat due to a few nice features that I'm not going to go into right now. Navicat suffers from a couple of annoying bugs and random crashes. I don't know if I can help fix the random ones but if I can at least file the ones I can reproduce, everyone wins. I have the latest as of today version 8.0.23.

    Bug [NAL-15328]: Structure Sync Fails to notice encoding differences

    Last Update: 13 Mar 2008 12:38 PM Last Replier: Mayho Ho Status: Open Department: Navicat Support Center Created On: 13 Mar 2008 09:52 AM

    Structure sync doesn't see the difference between my columns that are utf8 and that are latin1. This is a severe bug. I relied on it to compare some production tables and wasn't aware some fields weren't utf8 in one

      [Read more...]
    some results of rainbow
    Employee +0 Vote Up -0Vote Down
    ok folks. here's some results:



    mysql> select last_errno,count(*) from
    queryqueue group by last_errno;
    +------------+----------+
    | last_errno | count(*) |
    +------------+----------+
    | 0 | 1600796 |
    | 1048 | 1971 |
    | 1053 | 1 |
    | 1139 | 35 |
    | 1267 | 19722 |
    | 1270 | 4243 |
    | 1271 | 8944 |
    | 1416 | 2284 |
    | 1580 | 23225 |
    | 2003 | 28 |
    | 2013 | 1606 |
    +------------+----------+
    11 rows in set (0.00 sec)


    error 2013 means lost connection to server (read: server crashed).
    so there are many bugs found already. 1606 crashes out of 1.6 million
    executed queries, is great.

    check my rss feed for the



























      [Read more...]
    Showing entries 1 to 18

    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.