New in this release:
External PHP based binary log consumer. It wraps 'mysqlbinlog' and reads settings from an .ini file.
The consumer must be running in order to refresh views and collect table change logs.
MIN/MAX and COUNT(DISTINCT) are now supported, experimentally.
Many other improvements.

Before a monitoring and notification system for MySQL (and other infrastructure) can be fully conceived, a variety of questions must be asked. I’ve attempted to put some of the most important of them together in this post.

These are what I feel are some best practice recommendations.



#1 Define what is to be monitored.

• Is it a HOST?
  
• Is it a SERVICE?
  

#2 Determine what level of health monitoring is desirable.

• Basic Monitoring Probes (typically active checks)
  
  
  
  • Simple TCP/IP port up/down
    
  • Disk space, free memory, swap utilization, etc
    
  • File exists (or does not exist, or is not of at least X size)
    
  • Process is running/not running
    
  • etc
    
  
  
• Log Monitoring (typically passive checks)
  
  
  
  • System logs should be collected and analyzed.
    
  • Application logs should be collected an analyzed.
    
  • Any log monitoring software should issue alerts via the notification tool API for notification escalation,etc
    
  
  
• Application monitoring (combination of active/passive)
  
  
  
  • Simple service monitoring - send a string to this port and expect a response back(might be validated with regex)
    
  • Complex service monitoring which requires a custom plugin
    
  • Services for which nagios plugins already exist
    
  • Passive alerts sent directly from the application
    
  
  

#3 Determine what hosts and services require active checks.

• How often is the service/host checked?
  
• How is “flapping” handled? Flapping is repeated up/down states during a service check interval.
  
• Who is notified at failure?
  
• What is the notification escalation policy


• How do you respond to alerts, quiesce the notification, etc?
  

#4 Collect metrics when possible.

• Health checks should collect metrics whenever possible. For instance, a “server health” plugin, which monitors CPU,swap,memory, disk space, etc, should return the metrics for the services which are being monitored. This avoids pulling for resource utilization AND alerting.
  
• Metrics collection may be resource intensive on the monitoring server.
  
• What is the long term policy for metrics collection, aggregation and reporting?
  

#5 Define the alerting/notification requirements.

• What is the SLA on the service?
  
• What is the SLA on the response to an alert?
  
• Who is to be notified when the service fails?
  
• What is the escalation policy?
  

#6 Define the notification escalation policy based on the SLA for the response.

• When an alert is not answered who is it escalated to?
  
• How is it escalated (email, sms, etc)
  
• What are the incentives for timely alert/notification response?
  
• Disincentives for non-timely response?
  

#7 Pick the right tools.

• I like Nagios. It is pluggable, supports metrics collection and it is reliable.
  
• Try not to reinvent the wheel too much.
  
• Try to come up with integrated monitoring/metrics collection and reporting. Keep as little operational data in your operational databases as possible. Limit operational monitoring databases to one month of historical data, in addition to maintaining status and notification information. Move historical information into a dedicated metrics reporting database schema.
  

This post is sparked by a recent message on an internet mailing list, where an engineer tried to restore a 40GB MySQL production backup for disaster recovery purposes. Unfortunately, the backup could not be restored and an error is returned from the program. It us unclear (to me) if this is due to a problem with the recovery tool, the original source database or with the backup itself.

I guess the individual never tested RESTORING the backups they were taking, which any production DBA will tell you is absolutely necessary.

Don't let yourself get into the unthinkable situation where all your data is "backed up", but you have no way to restore it. A corrupted, improperly taken or unrecoverable backup is worse than useless, particularly is one's faith is placed in it.

In order to protect your operation:

1) Make regular, logical backups of your data with a tool such as 'mysqldump'. Store at least one copy of these backups off site, with one or more copies preferably in a geographically remote location. These represent a "last prayer" for data recovery if all other methods fail, or if a severe event destroys local copies of data and backups. The DBA responsible for backup/recovery should verify the backup and fingerprint the contents to ensure that any copies are not corrupted.

2) Use hot backup tools to maintain an additional binary backup locally. LVM snapshots or other technology can be used for these backups.

3) TEST both of these backups with full restores to staging machines. This is a great way to keep your staging environment up-to-date with regular production refreshes while at the same time verifying the integrity of your backup system.

4) Use local replication to maintain a dual master/single writer replication "ring". DO NOT balance reads between both masters.

5) In addition, use replication to maintain a geographically remote second copy of your data.

6) Set up two data centers, and reserve one for failover operations. Once again, avoid the temptation to load balance between them, as this makes capacity planning for an outage much more difficult. Serving geographically remote regions with a local datacenter can be very advantageous, however, so careful capacity planning taking into account increased latency during failover is very important should you choose do so. Servers can quickly exceed the expected maximum number of connections when latency is high.

7) Code your application to be tolerant of service degredation, including service latency.

8) Set up regular backup infrastructure in both data centers. You need backups when you fail over, and you need to continue to maintain backups should one datacenter fail completely with little or no hope of restoration.

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
        ) 
        union 
        (select 'No'
        ) 
        limit 1;
+-----+
| Yes |
+-----+
| Yes |
+-----+
1 row in set (0.00 sec)

mysql>  (select 'Yes' 
          from dual 
         where 5 between 10 and 1 
        ) 
        union 
        (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 most applications specifically check that the lower bounds is lower than the upper bounds in left to right order. Logically, a number between 1 and 10 is also between 10 and 1.

I encountered this on my own benchmarking application that generates BETWEEN clauses.

So generate BETWEEN clauses with caution. Perhaps you would be better off with two >= and <= expressions instead of the more convenient BETWEEN.

Fix your licensing model so that mirrors can legally maintain copies of your documentation, so that I'm not left sitting in the dark when your website goes down.

What if Oracle shut MySQL down today? They absolutely could. With the documentation not in the GPL, when Oracle pulls the plug on the websites, well, goodbye docs. It isn't legal to mirror them elsewhere.

Unlike COUNT(expression), COUNT(DISTINCT expression) is not a distributable function. That is, the expression can not be computed by looking at only the changed rows in the table change logs.

---

The following view can not be FAST refreshed with Flexviews today:

SELECT a a_alias, 
       b b_alias, 
       c c_alias, 
       COUNT(DISTINCT d) d_alias
  FROM T1
 GROUP BY a, b, c;

However, a dependent child materialization could be created to support the value for COUNT(DISTINCT d):

-- child materialization, dependent subview
--There will be one row for each DISTINCT value of d

SELECT a a_alias, 
       b b_alias, 
       c c_alias, 
       count(*) d_alias_cnt
  FROM T1
 GROUP BY a, b, c, d;

The original view could then be rewritten as:

SELECT a a_alias, 
       b b_alias, 
       c c_alias, 
       (SELECT COUNT(*) 
          FROM child_materialization) d_alias
  FROM T1
 GROUP by a_alias, b_alias, c_alias;

This can easily be done manually with the current implementation, you just have to be careful to always refresh the child materialization first, before refreshing the dependent view.

I am seriously considering porting Flexviews directly into Drizzle. I'm excited about replication plugins as this may make it easy to produce the necessary table change logs to support the materialization logic. Drizzle is becoming completely plugin oriented, so eventually materialized view rewrite and other cool features could be implemented too as optimizer plugins.

I'm quite the emotional person, so I end up saying something along the lines of the subject to oh, say, two or three people, some days. I emotionally invest myself in things that I probably shouldn't, as all of us are probably guilty of that from time to time.

I was particularly mean spirited in my recent post about the TPC-H(tm) benchmark when I suggested that an unnamed analyst should perhaps leave the industry behind. I didn't really mean that.

I choose to give the TPC-H(tm) numbers significance, especially as an indicator of price/performance ratios. Kickfire kicks ass with a PP ratio of $0.81 per QPPH. This is very impressive. You can choose to disagree if you like.

mysql> select now() + interval 2918472 day;
+------------------------------+
| now() + interval 2918472 day |
+------------------------------+
| 9999-12-31 16:14:03          |
+------------------------------+
1 row in set (0.00 sec)

mysql> select now() + interval 2918473 day;
+------------------------------+
| now() + interval 2918473 day |
+------------------------------+
| NULL                         |
+------------------------------+
1 row in set, 1 warning (0.00 sec)

Hehe.

There has been a lot of discussion in the blogosphere recently about benchmarks, and I can't help but notice that a lot of the comments and opinions are harsh, sometimes downright mean, and alas uninformed.

Why do people care so much about a benchmark. IT IS JUST NUMBERS PEOPLE.

Seriously (and this isn't directed at any one person in particular):

Who doesn't like to play "my thing is bigger than your thing" every once in awhile, but you don't have to take it so personally. If a vendor wants to waste money running a huge benchmark for little profit - WHO CARES? There must be some audience for the benchmark results, but if you aren't it, why bother screaming at the top of your lungs that the benchmark is ludicrous, or useless or ineffective. Just ignore it.  You obviously are not the intended audience.  If you are the intended audience and you still don't care, then go play another game.  You've obviously tired of the industry.

People spend way too much time arguing about unimportant things, particularly when they don't understand the underlying technical issues to the fullest extent possible.

I personally want to say:
I think ParAccell's TPC-H result is impressive. Running the TPC-H queries at 30TB is an ENGINEERING MARVEL, regardless of the amount of tech that was necessary to produce the result. Period. If your database can run 30TB TPC-H, then fine, feel free to criticize the 30TB results and BEST THEM, otherwise, give some fucking credit where credit is due. dudes. seriously.

fine print:
I work for Kickfire, who has published audited TPC-H benchmark results on the Kickfire MySQL Appliance.  
My opinions here don't represent Kickfire.  This is my blog, with my own opinions.

I've been wanting to do some benchmarking of different databases, tuning of various database parameters, different I/O subsystems, etc. I put myself together a new high-end workstation/mid-range server system to test with.

I stopped by Central Computers the other day, and in one of their nice glass display cases I saw the ASUS Z8NA-D6C motherboard, the first ATX dual socket 1366 motherboard. I decided to make that the centerpiece of my new system.

The goods:
ASUS Z8NA-D6C motherboard
OCZ 850W power supply
2 quadcore E5504 Xeon processors (2GHz/4MB cache)
12GB unbuffered DDR3 super talent memory
Adaptec 5805 unified SATA/SAS w/ 512MB cache
4 Hitachi Deskstar 7200RPM 1TB SATA drives
2 OCZ Vertex 250GB SSD drives
2 Patriot Memory Warp V3 250GB SSD drives
EVGA Nvidia GTX285 video card
Creative X-Fi sound card

So far performance has been great.

I recently purchased two of these drives on recommendation from a friend, but they are really terrifically horrible drives, especially for MySQL. I won't be accepting his recommendations anymore. I have the same problem with BOTH drives, and surprisingly the drives seem to have more problems and perform worse in RAID0 than as JBOD.

The drives lock up during random write, even for small block transfers. The only way to get the drive to respond after it 'locks', is to power cycle it or the computer.

The following tests were done on my Adaptec 5805 Dual Core RAID controller so I'm sure it isn't the controller's fault. Just to make sure, I tested a Highpoint 2320, a 3ware 9650se and onboard NVIDIA raid (as a PC enthusiast, I have a lot of RAID controllers to test) and all performed similarly.

Random write to the SSD (anything larger than 512K will lock the drive):



Random write to 4 SATA Hitachi hard disks:

It uses MySQL proxy, and MySQL proxy quietly refuses to work with these versions. The client reports 'Lost connection to MySQL server' during the authentication phase with 'error 0'.

I've filed Bug #45167 to track the issue.

As a workaround you can comment out the check for the version in src/network-mysqld.c +920

      if (recv_sock->challenge &&
          recv_sock->challenge->server_version > 50113 && recv_sock->challenge->server_version < 50118) {


        /**
         * Bug #25371
         *
         * COM_CHANGE_USER returns 2 ERR packets instead of one
         *
         * we can auto-correct the issue if needed and remove the second packet
         * Some clients handle this issue and expect a double ERR packet.
         */


        con->state = CON_STATE_ERROR;
      }

Apparently "we can auto-correct the issue", but the code fails to, and instead just returns CON_STATE_ERROR and disconnects. Without writing anything into the log.

YOU HAVE NO IDEA HOW LONG IT TOOK TO FIGURE THIS OUT

I sent mails to the proxy-discuss mailing list, which apparently never showed up. Talking with Jan back and forth, he thought it might be 'old_passwords=1' at first, but that wasn't the problem. Only after sending him debug information directly from strace, did he realize that the above code was at fault, and suggest I comment it out. So thanks Jan, I really appreciate the help, but I wish I didn't have to modify the code.

This isn't because I dislike changing the code, but because Enterprise Manager isn't open source. And it includes GPL components like MySQL proxy, but it isn't easy to replace the proxy component without changing the enterprise monitor packaging which is closed source, and not redistributable, as you have to go through the trial process or download the licensed binaries directly.

The MySQL manual for str_to_date states:
If str contains an illegal date, time, or datetime value, STR_TO_DATE() returns NULL. An
illegal value also produces a warning.

Surely "I'm_not_a_valid_date" is not a valid date, time or datetime value.

mysql> select str_to_date("I'm_not_a_valid_date","I'm_not_a_valid_date");
+------------------------------------------------------------+
| str_to_date("I'm_not_a_valid_date","I'm_not_a_valid_date") |
+------------------------------------------------------------+
| 0000-00-00                                                 |
+------------------------------------------------------------+
1 row in set (0.00 sec)

The problem here is that values in the format string which are not preceded by the percent sign (%) are treated as constant characters which must match the input string exactly. Normally these characters are used as delimiters. For example, the dash characters in the format string '%Y-%m-%d'.

For example:

mysql> select str_to_date('2008?01?01','%Y?%m?%d');
+--------------------------------------+
| str_to_date('2008?01?01','%Y?%m?%d') |
+--------------------------------------+
| 2008-01-01                           |
+--------------------------------------+
1 row in set (0.00 sec)

The ambiguity comes into play when both strings consist ONLY of matching characters with NO format specifications:

mysql> select str_to_date('2008?01?01','2008?01?01');
+----------------------------------------+
| str_to_date('2008?01?01','2008?01?01') |
+----------------------------------------+
| 0000-00-00                             |
+----------------------------------------+
1 row in set (0.00 sec)

I think this should return NULL, because no format characters have been specified, therefore no legal date should be output.

I've filed Bug 44891 to let MySQL decide.

From the MySQL manual:
BIT_COUNT(N)

Returns the number of bits that are set in the argument N.

-------

I thought that meant that it returned the number of bits which needed to be set in order to store the value. To store 2^32 you need 33 bits of storage, with only one bit /set/. I expected 33 instead of 1.

#tested on 5.0.45 and 5.1.32-community
mysql> select i, pow(2,i), bit_count(pow(2,i)) from pow2;
+----+------------+---------------------+
| i  | pow(2,i)   | bit_count(pow(2,i)) |
+----+------------+---------------------+
|  1 |          2 |                   1 |
|  2 |          4 |                   1 |
|  3 |          8 |                   1 |
|  4 |         16 |                   1 |
|  5 |         32 |                   1 |
|  6 |         64 |                   1 |
|  7 |        128 |                   1 |
|  8 |        256 |                   1 |
|  9 |        512 |                   1 |
| 10 |       1024 |                   1 |
| 11 |       2048 |                   1 |
| 12 |       4096 |                   1 |
| 13 |       8192 |                   1 |
| 14 |      16384 |                   1 |
| 15 |      32768 |                   1 |
| 16 |      65536 |                   1 |
| 17 |     131072 |                   1 |
| 18 |     262144 |                   1 |
| 19 |     524288 |                   1 |
| 20 |    1048576 |                   1 |
| 21 |    2097152 |                   1 |
| 22 |    4194304 |                   1 |
| 23 |    8388608 |                   1 |
| 24 |   16777216 |                   1 |
| 25 |   33554432 |                   1 |
| 26 |   67108864 |                   1 |
| 27 |  134217728 |                   1 |
| 28 |  268435456 |                   1 |
| 29 |  536870912 |                   1 |
| 30 | 1073741824 |                   1 |
| 31 | 2147483648 |                   1 |
| 32 | 4294967296 |                   1 |
+----+------------+---------------------+
32 rows in set (0.00 sec)


[edit] I'm a boob.  I forgot to subtract one.  all powers of two do only have one bit set.  I'm still not feeling well and taking cold medication.

In a blog post today, Stefan of the MySQL documentation team says that the MySQL documents will not be open sourced. Now, I have to go back and review the MySQL CE Keynote that Karen gave, but I'm pretty sure she said to the audience that it was "going to happen". Why would she even bother bringing it up in the keynote if it was never really being considered anyway? There has been little community input on this, and I for one am outraged that a GPL product would not release the documentation as GPL too.

I'm now totally convinced that MySQL does not understand, and will never understand the MySQL community.

Is this an opportunity for Oracle to try to stall community participation in MySQL? I don't want to be paranoid, but this could just be the hints of bold new changes in MySQL strategy, especially considering Karen's keynote mention of GPLing the docs.

I think the Free Software Foundation should protest MySQL's latest move and coordinate a letter-writing campaign in support for open source documentation for open source licensed software. Sun is actively moving to thwart the efforts of the community by not putting the documentation under the GPL license.

Is it time for an open source version of the MySQL documentation to emerge from the community? Keeping manuals in sync between multiple versions of multiple product lines requires a very large team of contributors. An entire team at MySQL is responsible for documentation changes. I'm not sure that the community can sustain useful database innovation while also being burdened under the weight of recreating the omnibus MySQL documentation set.

I went looking for the MySQL 5.4 documentation today, but alas I could not find it. In particular, I went looking for the list of changes between 5.1.34 and 5.4.1.

If 5.4.1 is beta then it should definitely have documentation, at least in beta form. This is especially true in light of the Sun MySQL conference keynote kind of dangling a carrot on a stick, as it were, with a question to the audience about opening the docs up under the GPL. The comments system also needs updated too. I think that if public comments are available on the web site, then those comments should have a rating system attached so that crappy, wrong and useless manual comments can easily be filtered. But I digress.

So, Sun, when are going to release all the MySQL documents under the GPL? Is it going to be in the MySQL 5.4 time frame, or in some far off hazy future? And why are there no 5.4 documents available online, when the binaries are already available for download?

I appreciate the timing of the release of the binaries with the conference, but for me, some documentation about changes and information about how to get the most out of the new release would be beneficial.

In particular I have questions about the new BKA algorithm, any new or changed my.cnf parameters related to the performance changes, and a quick overview of all the new features and changes since MySQL 5.1.

That isn't too much to ask, is it?

At today's keynote by Mark Callaghan one of the new options he talked about are table change logs. He mentioned they might be of use to external applications, like Flexviews, which he mentioned but not directly. He asked if the guy who wrote it was in the audience, so I got to wave my hand and yell 'Flexviews!'.

I caught up with Mark at the Facebook party this evening. I had a chance to talk to him not only about the change logs, but also about Kickfire and the SQL chip. He asked me what I thought about working at Kickfire and I smiled and said I love it. I think I said "I've never been able to join a billion row table to a hundred million row table, sort, group and get results back in less than a minute" and I'm sure the smile never left my face.

As far as the table change logs, he verified:

• The global transaction id will be stored in the table


• OLD and NEW rows will be available for updated rows

This is great news for Flexviews (http://flexviews.sourceforge.net). Currently triggers must be used to maintain table change logs and this incurs a very high performance penalty for writes. With storage engine level change logs, this penalty is much reduce because the version information for the rows needs to be maintained for rollback purposes anyway. MVCC is great.

I also spoke with the folks over at the Primebase booth about getting similar change-logging enabled for PBXT tables as well.

So far I'm enjoying the conference immensely. See you tomorrow!

Just like this time last year (I hope this isn't a perennial event) everybody is expressing fear, uncertainty and doubt about the future of MySQL in the wake of yet another acquisition. What is going to happen?

MySQL isn't going to disappear tomorrow. Or even in the next ten years. Why?

• The internet runs on the LAMP stack. There is so much technological infrastructure dedicated to MySQL that anybody would be crazy to think that it is going to disappear anytime soon. Hell, lots of companies still run 4.0 databases.


• The MySQL codebase is GPL. Even if Oracle just closed up the MySQL office and set everybody packing the source code is ours to use, to repackage, to redistribute and to enhance. Drizzle already exists as a fork and others could emerge. I don't think that forks and alternative distributions are bad.


So if MySQL isn't going to disappear, what is going to happen (not that I really know)?


• Support contracts might get more expensive in the Oracle world.


• MySQL will continue to provide a low barrier-to-entry and high performance database for small enterprises and OLTP environments. There will still be lots of consulting and support opportunities for these companies. Large companies already running MySQL will be less likely to switch to an alternative technology unless compatibility with their existing apps can be ensured, or there is a clear value prop in terms of price/performance from an alternative technology.
  
• The community might move behind a new fork of MySQL. Drizzle is a good alternative, but its goals are not aligned with all use cases of the MySQL database, in particular data warehousing and analytics. This obviously could change in the future.
  
• Oracle could actually improve MySQL. MySQL needs improved triggers, stored procedures, materialized views, roles and other features. MySQL 5.1 was in RC for almost two years and a lot of stagnation has happened. A lot of planned features are half-ass or half-baked.
  
  Honestly, these are probably pretty much the same things people said last year about the Sun acquisition. Has anything /really/ changed over the last year, except community getting shafted by not having enough version numbers remaining? We still have a buggy 5.1 release, the conference is an explosion of marketing diarrhea and nobody is certain about the future of MySQL.
  
  I find it funny that I started as an Oracle DBA, and I guess technically, I am again!

There are two problems with the CAST function in all versions of MySQL:

bug#43774CAST(CAST(value) as TIME as DATETIME ) returns the wrong value.

example:
mysql> select '0000-00-00 21:00:00' expected, cast(cast('21:00:00' as time) as datetime) actual;
+---------------------+---------------------+
| expected | actual |
+---------------------+---------------------+
| 0000-00-00 21:00:00 | 2021-00-00 00:00:00 |
+---------------------+---------------------+
1 row in set (0.00 sec)

bug#43865CAST( -1.0 as UNSIGNED) yields 0 instead of MAXINT and returns a warning.

example:
create table t1(c1 int signed,
c2 decimal(5,2),
c3 float(5,2)
);

insert into t1 values (-1,-1,-1);

ACTUAL RESULT:

select cast(-1.0 as unsigned), cast(c1 as unsigned), cast(c2 as unsigned), cast(c3 as
unsigned) from t1 \G
*************************** 1. row ***************************
cast(-1.0 as unsigned): 0
cast(c1 as unsigned): 18446744073709551615
cast(c2 as unsigned): 0
cast(c3 as unsigned): 18446744073709551615
1 row in set, 2 warnings (0.00 sec)

mysql> show warnings;
+-------+------+---------------------------------------+
| Level | Code | Message |
+-------+------+---------------------------------------+
| Error | 1292 | Truncated incorrect DECIMAL value: '' |
| Error | 1292 | Truncated incorrect DECIMAL value: '' |
+-------+------+---------------------------------------+
2 rows in set (0.01 sec)

EXPECTED RESULT:
cast(-1.0 as unsigned): 18446744073709551615
cast(c1 as unsigned): 18446744073709551615
cast(c2 as unsigned): 18446744073709551615
cast(c3 as unsigned): 18446744073709551615
1 row in set, 0 warnings (0.01 sec)

Here the division between td1.c1 and td2.c2 is correct:

select td1.c1, td2.c2, td1.c1/td2.c2, -99 / 0.03    
  from testdata td1,         
       testdata td2   
 where td1.c1 = -99 
   and td2.c2 = 0.03 
 limit 1;

+------+------+---------------+------------+
| c1   | c2   | td1.c1/td2.c2 | -99 / 0.03 |
+------+------+---------------+------------+
|  -99 | 0.03 |    -3300.0000 | -3300.0000 |
+------+------+---------------+------------+
1 row in set (0.00 sec)

Here DISTINCT is added to the query.  The result is incorrect:

select distinct td1.c1, td2.c2, td1.c1/td2.c2, -99 / 0.03    
  from testdata td1,         
       testdata td2   
 where td1.c1 = -99 
   and td2.c2 = 0.03 
 limit 1;

+------+------+---------------+------------+
| c1   | c2   | td1.c1/td2.c2 | -99 / 0.03 |
+------+------+---------------+------------+
|  -99 | 0.03 |     -999.9999 | -3300.0000 |
+------+------+---------------+------------+
1 row in set (0.00 sec)

see MySQL bug#41814
http://bugs.mysql.com/bug.php?id=41814

The query returns correct (approximate) results on FLOAT columns:

select distinct td1.c1, td2.c2, td1.c1/td2.c2, -99 / 0.03 
  from testdata2 td1, 
       testdata2 td2 
 where td1.c1 = -99 
   and td2.c2 between 0.02 and 0.04;
+------+------+-------------------+------------+
| c1   | c2   | td1.c1/td2.c2     | -99 / 0.03 |
+------+------+-------------------+------------+
|  -99 | 0.03 | -3300.00007376075 | -3300.0000 |
+------+------+-------------------+------------+
1 row in set (0.00 sec)