Turns out RethinkDB is a SSD database to watch in 2011. I’ve known about it for a while but it hasn’t really stood out just yet (I don’t know anyone running it in production).

That said, I’m excited by the potential.

What’s really shocking to me, is that while SSD and flash storage is very exciting, it wasn’t as revolutionary in 2010 as I would have liked to have seen.

I’m not sure why this is… there are people running them at scale but not significantly enough to make them a revolution.

RethinkDB is a MySQL data store optimized for solid state drives. Solid-state drives do away with moving parts and are extremely low-latency. Most database stores are designed for traditional hard drives and assume relatively high-latency. RethinkDB aims to allow database developers to take full advantage of the performance benefits of solid-state drives.

[From …

Percona is pleased to officially (and belatedly) welcome Sasha Pachev to our team of consultants.

Before joining Percona, Sasha worked as an independent MySQL consultant. Sasha was the original implementer and maintainer of MySQL replication from 3.23 to 4.02. He is also the author of MySQL Enterprise Solutions and Understanding MySQL Internals.

Sasha, a big welcome – we are fortunate indeed you’re working with us!

Entry posted by Ryan Lowe | No comment

Add to: …

refering Jeremy Cole's post on swapstorming under NUMA hardware, I'll note something potentially new.

While I've seen this "brick wall swapstorming" a few times before and since the post, I just saw some new OS installs not do this by default, and using the numactl to change the defaults is actually harmful to system interactivity.

In the brick-wall cases, two NUMA zones of ~30G each, plus a mysqld (or memcached) running with 45G of ram, would equal 30G in memory, and 15G in swap. Ugly.

In this case, I'm getting a little bit in swap, but a relatively even note dist.

Here's a box with no numactl tuning:

N0        :      7068733 ( 26.97 GB)
N1        :      7120258 ( 27.16 GB)
active    :     13355529 ( 50.95 GB)
anon      :     14187441 ( 54.12 GB)
dirty     : …

refering Jeremy Cole's post on swapstorming under NUMA hardware, I'll note something potentially new.

While I've seen this "brick wall swapstorming" a few times before and since the post, I just saw some new OS installs not do this by default, and using the numactl to change the defaults is actually harmful to system interactivity.

In the brick-wall cases, two NUMA zones of ~30G each, plus a mysqld (or memcached) running with 45G of ram, would equal 30G in memory, and 15G in swap. Ugly.

In this case, I'm getting a little bit in swap, but a relatively even note dist.

Here's a box with no numactl tuning:

N0        :      7068733 ( 26.97 GB)
N1        :      7120258 ( 27.16 GB)
active    :     13355529 ( 50.95 GB)
anon      :     14187441 ( 54.12 GB)
dirty     : …

In MySQL databases, the MyISAM table is the default database engine, which provides a variety of functions to manage fields and indexes. These tables are best used for table locking, which makes it very useful while performing real-time transactions on the websites. However, when these tables get corrupt due to any random reason it makes the trading done on the web very insecure. In such cases, you should try to repair MySQL table using some appropriate methods. If none of the methods succeed, then I would recommend you to use a third-party MySQL Repair software to repair MySQL database.

Taking a practical case into consideration in which the following error message is displayed while you are working on a MyISAM table in the MySQL database:

"MySQL error code 145 = Table was marked as crashed and should be repaired"

Cause:
The …

I did a clean install on my Macbook Pro this morning, part of the clean install means, re-downloading things like MySQL.

When I installed it, I noticed that the pref-pane wouldn’t start MySQL. Even when it asked for my admin password. I thought maybe it was a boot up issue, so I rebooted, and got an error telling me that the permissions for the start up item were in secure.

Here’s what I did to debug/fix the problem.

• Change permission of /Library/StartupItems/MySQLCOM/MySQLCOM
• edit /usr/local/mysql/support-files/mysql.server and edited line 46 and 47 to say

chown -R root:wheel /Library/StartupItems/MySQLCOM
x

[content_box style="yellow-box" title="Edit mysql.server file"]
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
[/content_box]

[break]
There is already a …

I've done a little change to the upstart script I published in a recent blogpost. The issue is with mysqld_safe which has a few issues it seems, but so far I haven't tracked them down exactly. Anyway, if mysqld_safe is not in your path and you run it with the full path (as I do in the Upstart script which is run by root that may well not have the mysql bin directory in it's path), then mysqld_safe will behave strange in at least 5.5 when called with the full path, i.e.
/mnt/mysql/bin/mysqld_safe --defaults-file=/etc/mysql/my.cnf &
will not work. If I then put the appropriate directory in my path, like this:
PATH=/mnt/mysql/bin:$PATH
/mnt/mysql/bin/mysqld_safe --defaults-file=/etc/mysql/my.cnf &
It still will not work as expected. In the first case, it complains that it cannot find my_print_defaults, …

Percona Server version 5.1.53-12.4 is now available for download. It is now the current stable release version.

Functionality Added or Changed

•  Percona Server 5.1.53-12.4 is based on MySQL 5.1.53.
•  New Features Added:
  • Precompiled UDFs for Maatkit (FNV and MurmurHash hash functions to provide faster checksums) are now included in distributions. Fixes feature request #689992. (Aleksandr Kuzminsky)
•  Other Changes:
  • innodb_doublewrite_file - It's no longer necessary to recreate your database and InnoDB …

MySQL development is on a roll so now is the time for me to request a fix for another obscure performance problem in InnoDB. The insert buffer is a feature that can make InnoDB much faster than you expect. It significantly reduces random IO required for secondary index maintenance. For servers that I care about I estimate (using data from SHOW INNODB STATUS) the reduction is between 2:1 and 5:1 and secondary index maintenance requires 20% to 50% of the random disk IO it would have used without the insert/change buffer. With MySQL 5.5 the insert buffer is now the change buffer as it does more.

Write-optimized engines

Write-optimized engines have become popular recently. HBase, BigTable and …

Last week Percona team published the benchmark results comparing beta XtraDB and MySQL 5.5 GA performance on their TPCC-like test workload (http://www.mysqlperformanceblog.com/2010/12/20/mysql-5-5-8-and-percona-server-being-adaptive). The results are very interesting because they are involving many questions about existing implementations of different features within InnoDB and bring new ideas as well. However, what is missing for me in this publication is an analyze of the tested workload and InnoDB issues.. - finally I've got much more questions than answers :-)) and it was pity for me to finish this year with a such "enigma" in my mind ;-)) So, as XtraDB is not ready yet, I was curious at least to get my own look on the Percona's TPCC-like workload and satisfy my curiosity ;-))

The main question not leaving …