I am currently tasked with writing Software Requirements Specification (SRS) document for a project. Effective sharding (based on specific criterion) and Scalability are key requirements of the project.

Scalability is traditionally classified as a non-functional requirement. My question to the community is that if scalability is crucial to a project, would it still be classified as a non-functional requirement? Are their cases when scalability requirements would be best classified as functional requirements?

<!-- http://4.bp.blogspot.com/_aUgNMQ2wQTE/SUs_eaEFKSI/AAAAAAAAAoQ/FUG8BLpXtF0/s1600-h/Speed_Highway.jpg -->I've just finished taking the (EM-based) Performance Tuning course and the SQL Tuning course. It's always a strange feeling taking a course where I already have hands-on experience, or I was around in the early days when standards were being hammered out. Sometimes that odd feeling (I know

I had an interesting tuning case few days ago. The system serving high traffic using Innodb tables would be stalling every so often causing even very simple queries both reads and writes taking long time to complete, with progress almost paused (dropping from thousands to tens of queries per second).

On the surface the problem looked simple - in the processlist every so often you would see a lot of queries, mostly selects taking 10+ seconds while at the same time there was no significant iowait, neither high CPU usage. Closer examination showed there were hundreds of queries stuck in the innodb queue, with innodb_thread_concurrency set to 8

Happily enough innodb_thread_concurrency is the variable which can be set online so it is easy to try a few different values and see what works best. In this case we decided to try removing restriction on runnable queries all together by setting it to 0.

This week saw the release of OurDelta patchset d7 build of MySQL 5.0.67, basically a cleaned-up update of the earlier (and first) OurDelta d6 build. The number of downloads/fetches within the first few hours surpassed the total number from the previous weeks.

Downloads and yum/apt-get repository fetches now always go via one of our mirrors, as obviously the main server can’t possibly handle all that attention! By default you just get sent to “somewhere on the planet”, although you can tweak your repo setup to only use specific mirrors. If you want to become a mirror for OurDelta, drop us a line and we’ll be happy to add you in; the more the merrier!

Ubuntu 8.10 Intrepid is now also supported. We welcome input on which additional platforms are desirable.

There was a  …

In 2 years (ish):

• the majority of consumer bought machines (which will be laptops) will have SSD and not rotational media
• At the same time, servers with larger storage requirements will use disk as we once used tape.
• At least one Linux distributoin will be shipping with btrfs as default
• OpenSolaris will be looking interesting and not annoying to try out (a lot more “just work” and easy to get going).
• Unless Sun puts ZFS under a GPL compatible license so it can make it into the Linux kernel, it will become nothing more than a Solaris oddity as other file systems will have caught up (and possibly surpassed).
• There will be somebody developing a a MySQL compatible release based off Drizzle
• Somebody will have ported Drizzle back to Microsoft Windows… possibly Microsoft.
• X will still be used for graphics on Linux, although yet another project will …

James Purser of Open Source on the Air has done a podcast interview with Arjen Lentz about OurDelta, describing it as “a new distro for MySQL”.

The maximum length of a VARCHAR is only restricted by the maximum row length. In most storage engines, the maximum row length is the maximum allowed by MySQL, which is 65,535 bytes. Only the NDB storage engine has a different maximum value.

The VARCHAR data type has some overhead. If the length of VARCHAR is less than 255, one byte per row is used to store the actual length of the string. If the length of VARCHAR is greater than 255, the overhead cost of storing the string length is two bytes per row. Thus, the maximum length of a VARCHAR should be 65,533 bytes.

However, that is not the case:

mysql> CREATE TABLE max_len_varchar(fld VARCHAR(65533) CHARSET latin1);
ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs

mysql> CREATE TABLE …

I had this perplexing problem yesterday where a mysql dump and restore was producing different results when using MaatKit mk-table-checksum.

mk-table-checksum --algorithm=BIT_XOR h=192.168.X.XX,u=user,p=password --databases=db1 --tables=c
DATABASE TABLE   CHUNK HOST         ENGINE      COUNT         CHECKSUM TIME WAIT STAT  LAG
db1      c           0 192.168.X.XX InnoDB     215169         d1d52a31    2    0 NULL NULL
mk-table-checksum --algorithm=BIT_XOR h=localhost,u=user,p=password --databases=db1 --tables=c
DATABASE TABLE   CHUNK HOST      ENGINE      COUNT         CHECKSUM TIME WAIT STAT  LAG
db1      c           0 localhost InnoDB     215169         91e7f182    0    0 NULL NULL

It was rather crazy until I reviewed the mysqldump settings I was using, and I realized I was using –no-set-names.

So just what does this option remove. Here is a diff of mysqldump with and without.

He started talking …

We’ve packaged another alpha-version of our current work-in-progress version of workbench - version 5.1.4. We’ve added more features, fixed problems and started to build packages for Fedora Core 9 along with our binaries for Ubuntu 8.04.

MySQL Workbench OSS 5.1.4 Alpha - Linux

Source Tar Ball

ftp://ftp.mysql.com/pub/mysql/download/gui-tools/mysql-workbench-5.1.4alpha.tar.gz
ftp://ftp.mysql.com/pub/mysql/download/gui-tools/mysql-workbench-5.1.4alpha.tar.gz.md5

Binaries for Fedora Core 9

…