Earlier this week I posted how OpenJDK was knock, knock, knockin' on Lenny's door. At that time I also mentioned how it was already in Ubuntu and Fedora.
What I failed to mention, however, and was right under my very nose was that fact that OpenJDK had already made it into OpenSUSE 11. Thanks to MySQL Euro-community manager and former SUSE employee Lenz Grimmer, I was …
[Read more]Earlier this week I posted how OpenJDK was knock, knock, knockin' on Lenny's door. At that time I also mentioned how it was already in Ubuntu and Fedora.
What I failed to mention, however, and was right under my very nose was that fact that OpenJDK had already made it into OpenSUSE 11. Thanks to MySQL Euro-community manager and former SUSE employee Lenz Grimmer, I was …
[Read more]Question: Do you think you have what it takes to take a service from a few hundred thousand users to tens of millions of users in 1 year flat? If you do read on and perhaps become the next beloved scalability rockstar of our age.
We are looking for a data charmer. A mysql magician. A code hack. A funny man. A mad man. A passionate man. Or perhaps a woman who does all these things and more.
Here’s what you gotta do:
MySQL Community Team launches a competition for the users of new features of MySQL 5.1.
Submit your MySQL 5.1 Use Case Report to community(at)mysql.com by 31 August 2008 and win!
The answer is yes.
In this face off we have two numeric MySQL data types, both Integer. In fact MySQL has 9 different numeric data types for integer, fixed precision and floating point numbers, however we are just going to focus on two, BIGINT and INT. This design consideration is part of my recent presentation Top 20 Design Tips for Data Architects.
What is the difference?
We turn to the MySQL Reference Manual first, in 10.1.1. Overview of Numeric Types we see the
following.
INT[(M)] [UNSIGNED] [ZEROFILL]
A normal-size integer. The signed range is -2147483648 to 2147483647. The unsigned range is 0 to 4294967295.
BIGINT[(M)] [UNSIGNED] [ZEROFILL]
A large integer. The signed range is …
[Read more]I will be heading to my first OSCON next week where I will be presenting MySQL Proxy: from Architecture to Implementation in conjunction with Giuseppe Maxia .
As was written by Colin Charles Our booth is yours? Sun at OSCON, Sun/MySQL would appear to also have a reasonable turnout. So it will be good to see some old colleagues and friends, and hopefully meet some new contacts.
While I am based on the East Coast, I do also provide expert MySQL consulting for clients in any location. Should you like to find …
[Read more]Already scheduled for some time, but since it's a new location for MySQL training it's probably worth an extra mention. Ye that's right, MySQL itself has never held a training course in Canberra either (I know since I was the trainer ;-) except for some custom stuff. The DBA days are pretty soon but there are still some seats.
MySQL DBAsMon 4 Aug: MySQL Installation, Security and User
Management ($475)
Tue 5 Aug: MySQL Backup and Recovery ($475)
Wed 6 Aug: MySQL InnoDB Performance Tuning
($575) You can pick individual days if you want. For …
As promised, in this post I will update on the performance improvements another Kickfire beta customer is seeing relative to its query response times.
The customer in question is a successful mid-sized company in the network management space. As part of their network management offering, they provide network monitoring and analysis capabilities. They are currently using MySQL as their backend database. The trouble they are having is that they can’t scale beyond about 50GB of data without impacting their monitoring and analysis performance. What this translates to is that their customers can’t use their solution to monitor more than 30 days worth of network traffic. While this is OK for some, others are clamoring for the ability to track and analyze up to three years of traffic and willing to pay significantly more to do so. Today, if they try to accomodate these customers, the queries end up taking hours to run which is unacceptably …
[Read more]
CentOS 5 ships with version 5.0.22 of MySQL, which has a number
of issues, but I discovered a major one that I wasn't aware of
until yesterday. There is a problem in the 5.0.22 client that
causes empty strings, or strings consisting only of spaces to be
displayed as NULL:
http://bugs.mysql.com/bug.php?id=19564
CREATE TABLE test.x1 (c char(10)) ENGINE=MYISAM;
INSERT INTO test.x1 values (' ');
INSERT INTO test.x1 values ('');
-- on a 5.0.22 client (/usr/local/mysql):
mysql> select * from test.x1;
+------+
| c |
+------+
| NULL |
| NULL |
+------+
2 rows in set (0.00 sec)
-- on a 5.0.37 client (~/bin/mysql):
mysql> select * from test.x1;
+------+
| c |
+------+
| |
| |
+------+
2 rows in set (0.00 sec)