With the HUGE news of Drizzle’s first GA, I thought it appropriate
that I spend some time discussing the testing that has gone into
this release.

I tend to agree with Stewart’s assessment of our quality – it is solid
and I think that you will find yourself pleasantly surprised and
not at all angry when using it, but it is always in the eye of
the user ; ) With that said, I did want to highlight some
areas of interest.

To begin with, as we are a fork of MySQL, the bulk of our test
suite comes directly from there as well. Most of the
standard mysql-test-run tests that are used to validate MySQL are
also used for Drizzle. All of the basics like …

I have been doing quite a lot of benchmarking recently.
I needed to find a safe way of measuring the time spend by the
database doing a long task, like catching up on a huge backlog of
accumulated replication updates. The problem with measuring this
event is that I can record when it starts, but I can't easily
detect when it finishes. My initial approach was to monitor the
database and count the tables rows to see when the task was done,
but I ended up affecting the task performance with my additional
queries. So I thought of another method.
Since I had control on what was sent from the master to the
slave, I used the following:
The initial time is calculated as the minimum creation time of
the databases that I know are created during the exercise. Let's
say that I had 5 databases named from db1 to db5:

set @START = (select min(create_time) from information_schema.tables where table_schema like "db%")

What is the big deal, you may ask? Well, read on and all
shall be revealed, intrepid reader ; )
As I mentioned an earlier post, our new test-runner – dbqp – allows us to define testing ‘modes’ which
all utilize the same system and server management code.

One only has to define a testManager (what does a test look like
/ how to organize tests) and a testExecutor (how to execute /
evaluate a test). The aim is for dbqp to be a one-stop shop
for test execution and to provide a clean and simple way to
manage and expand this.

I have just added –mode=randgen to the test-runner. The random
query generator is a significant part of Drizzle’s testing
strategy and we use a large number of tests with the …

In my previous post I described what it took to
add SQL support and a simple command line client to a NoSQL
storage. However, I needed not just ad-hoc testing with a client,
but a framework to automatically run and manage many tests.
I expect that automated tests are easy to understand, extend, and
maintain. When a test breaks, finding and debugging what broke
should be easy. Such qualities can not be met in a heterogeneous
test environment. Rather, it would be best if some common
language and toolkit was used. It's easiest for all when a
failing test can be run directly under a debugger.
In MySQL, this task is solved with a combination of 'mysqltest'
client-side testing tool and 'mysql-test-run', an automation
environment for functional tests.'mysqltest' is …

Tarantool offers clients a simple binary protocol
with basic data manipulation commands - GET, PUT, SET, DELETE.
All administrative commands, however, must be sent in textual
form to a separate, administative port. A separate port is useful
as long as there is no authentication support. Examples of
administrative commands are 'SAVE SNAPSHOT' or 'SHOW STAT'.
The whole thing had a few functional tests, but all of them
required to be run manually. If you're not the one who wrote it,
you probably wouldn't know how to run it.
I was looking for something that would be easy to write and easy
to run. It needed to be a lingua franca of testing, used both by
developers and quality assurance engineers. It would also be nice
to be able to easily express in the new framework test cases for
discovered bugs.
Of course, for an ex-SQL geek, SQL looked very much like the
lingua …

What I'd like to describe is how I tried to bring things that are
good about mysql-test-run, mysqltest and pushbuild, to the open
source project I'm currently working on, Tarantool.
Since names such as mysql-test-run, mysqltest, or pushbuild tell
little to those who don't know how testing is done at MySQL, I'll make a
series of blog posts and try explaining the elephant one piece at
a time.
In a nutshell, there is a collection of tools that enable [open
source] projects to do development in a "civilized" form. Some
projects only use select pieces of the puzzle, but the best
effects are, in my view, achieved when all pieces are made to …

Once upon a time, there was a policy in MySQL not to add new
features after the beta stage.
To my surprise, MySQL Workbench 5.2.30 introduces a new feature,
the query formatter. I gave it a try. The results are not
extremely encouraging. Granted, it's a plugin and not a feature
in the core application, but nonetheless one would expect
something more stable in a GA release, especially since the
plugin features are displayed in the main menu, and unless you
have read the announcement, you couldn't easily tell the core
from the plugins.
This is what I have got in just a few minutes:

A few days ago I saw an article about Semi-Synchronous Replication in MySQL 5.5. It
asks questions, and doesn't give answers beyond gut feeling. So I
thought that I would do some practical testing of this new
feature.
Before we go that way, though, let's revisit the theory.
How semi-synchronous replication worksFigure 1. A transaction with regular replication
With regular replication, you send a transaction to the master
(1). When the COMMIT is received, the master
executes it (2), and if successful it logs the transaction to the
binary log (3). The the master answers the client request (4)
with a successful result. In the meantime, the slaves replicate
the record (5).
What happens if the master crashes after point #4 and before a
slave has had a chance of getting the data in point #5? …

I have old applications that need to read (and
write) MyISAM tables that themselves receive lots of bulk
updates. Time to try MySQL-Proxy.

MySQL Proxy is light on documentation and very few people written
anything about working. Most of what I have read says
MySQL-Proxy is not ready for prim time. I have hope so I
had to give it a try.

I started with thee VMware servers. I setup one master and two
read only slaves. I tested the replication with
mysqlslap from another independent server and it
worked fine. The slave never ran more then a second behind.

You know already that InnoDB in MySQL 5.5 has great
improvements in performance and scalability. You will have to
wait a few months for that, though, because MySQL 5.5 is not
GA yet.
But if you need some extra performance in MySQL 5.1, you may
want to use the Innodb Plugin instead of the built-in one. As
of version 5.1.47, the Innodb plugin is of GA quality, and it
comes with a good out-of-the-box improvement compared to the
built-in engine.

To test my assumptions, I used one of my test Linux servers to
perform a sysbench on 5.0.91, 5.1.47 built-in and plugin, and
5.5.4. The MySQL servers were all configured with

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.