I’ve been lately compiling and generating .deb packages for several MySQL and MariaDB recent versions, and I wanted to try them more in depth -specially MySQL 8.0 and MariaDB 10.2, both of which are still in development.

Several people have already given their first impressions (or will do soon), and testing early is the best way to catch bugs and regressions, and get them fixed before the official release. In fact, as I will comment later, I ran into breaking bugs on both MySQL 8.0 and MariaDB 10.2, which I …

Many installations of MySQL server come with a built-in database called test. It's initially empty, and you might wonder what it's for, or even if you can delete it without any problems.

What is it for? 

The test database is installed by the MySQL Server RPM as part of the mysql_install_db process, and some other package managers run that script too. If you run that script as part of a manual install of MySQL, you'll get the same effect. It creates the database by creating an empty directory called "test" in the data directory, and creates wide-open access to the database test and any database with a name beginning with test_ by inserting a couple of rows into the mysql.db table that give everyone full access to create or use those databases.

The configuration is designed to make it easy for new users to create a playground or sandbox database to work with, one that doesn't require asking the DBA …

I grabbed all the tests introduced in MariaDB 5.5.32 (i.e. “bzr diff -rtag:mariadb-5.5.31..mariadb-5.5.32 mysql-test/” and some foo) and threw them in their own test file. I only kept tests for crashing bugs and ignored those that required plugins (there were two or three, but nothing major). So now I have a test file that should crash MariaDB 5.5.31 and probably before. But, the question is: does this crash Percona Server or MySQL?

While it is excellent to see the MariaDB guys including tests for their crashing bugs, are these MariaDB specific or do they affect other MySQL flavours?

I built a release build of top of trunk Percona Server and ran the test against it. I got no crashes. In a debug build, I got two. One was to do with REPAIR on an ARCHIVE table and the other was “SELECT UNIX_TIMESTAMP(STR_TO_DATE(’2020′,’%Y’));”. I found the same thing for a debug build of top of tree MySQL.

All the other tests …

Note: if you're reading this using a feedreader, please make sure you've updated to the updated TheAquarium feed.

Once upon a time, it would have been considered madness to even attempt to create 30,000 tables in InnoDB. That time is now a memory. We have customers with a lot more tables than a mere 30,000. There have historically been no tests for anything near this many tables in the MySQL test suite.

So, in fleshing out the test cases for this and innodb_dict_size_limit I was left with the not so awesome task of making the test case run in remotely reasonable time. The test case itself is pretty simple, a simple loop in the not at all exciting mysqltest language that will create 30,000 identical tables, insert a row into each of them and then drop them.

Establishing the ground rules: I do not care about durability. This is a test case, not a production system holding important data which means I can lie, cheat and steal to get …

In this article I will describe how to test the plain and the encrypted SMTP/POP3/IMAP and HTTP protocols with telnet and the openssl s_client command.

list of references

For a complete list of available commands for the used protocols check the RFCs please:

• RFC – Post Office Protocol – Version 3
• RFC – Simple Mail Transfer Protocol
• RFC – INTERNET MESSAGE ACCESS PROTOCOL – VERSION 4rev1
• RFC – Hypertext Transfer Protocol — HTTP/1.1

SMTP sending mail

In the first example I will open a telnet connection to a SMTP Server on …

Hi,

We are currently running code coverage for MySQL Cluster testing and have hit a few bumps along the road when it cam to collecting the "block" coverage for the NDBD.

I wanted to share them here for others that might run into similar frustrations when doing testing code coverage.

Gcov accumulates during each run information on which functions and lines of code are called and a total for the times called.

The problem comes from when gcov dumps this information out. The actual data is dumped on the "exit" of the program.

After much time tracking this issue down, it turns out that the NDBD code had been changed to use _exit() instead of just exit()

What is the difference?

exit()
Terminate the process after cleanup.

_exit()
Terminate process immediately.

So by calling _exit(), gcov never had a …

One of our colleagues, Dimitri, at the Paris Sun solution center has developed a real neat and useful tool called dim_STAT. To make it short it's a tool for both high-level and detailed, monitoring and performance analysis of Solaris and Linux systems.

Data is collected and saved in a MySQL database, and it provides a very functional web base user interface. It allows real time or off line monitoring, multi-host etc.

Actually what is really interesting with dim_STAT is that, when I'm benchmarking or tryinng to find a performance bottleneck, I can collect all the data I need and come back later for analysis.

Recently, Dimitri has added a new tool db_STRESS, that allows us to put load on a database system and gives a high level metric (TPS: Transactions per seconds) and therefor allows us to compare how different systems compare together.
The point of this post is …

One of our colleagues, Dimitri, at the Paris Sun solution center has developed a real neat and useful tool called dim_STAT. To make it short it's a tool for both high-level and detailed, monitoring and performance analysis of Solaris and Linux systems.

Data is collected and saved in a MySQL database, and it provides a very functional web base user interface. It allows real time or off line monitoring, multi-host etc.

Actually what is really interesting with dim_STAT is that, when I'm benchmarking or tryinng to find a performance bottleneck, I can collect all the data I need and come back later for analysis.

Recently, Dimitri has added a new tool db_STRESS, that allows us to put load on a database system and gives a high level metric (TPS: Transactions per seconds) and therefor allows us to compare how different systems compare together.
The point of this post is …