int id = rand() % test_rows;
char* buf_end;
int blob_val = rand();
sprintf(buf, "update t1 set b = '");
buf_end = buf + strlen(buf);
memset(buf_end, 'g', blob_size);
buf_end += blob_size;
*buf_end++ = '\'';
sprintf(buf_end, " where id = %d", id);
break;
}
case Q_SELECT_DISTINCT:
{
int start_range = rand() % test_rows;
sprintf(buf, "select distinct word from t1 where id > %d and id < %d",
start_range, start_range + 100);
break;
} }
Listing 4.6 Explanation of query-type from MySQL source code. (continued)
For those not familiar with C, select-count-range, which is the default, will select the number of records from a range of keys starting at a random location and ending at 10 after. select-blob locates a record based on a random primary key value. It will then pull the entire record out, including the blob. update just updates a string column one random record, selected on a random value of the primary key. update-blob does the same as update, except it updates the blob column. select-distinct selects distinct strings from a random 100-wide range of primary keys.
Your Own Tests
While using pre-existing tests is convenient and saves development time, in some cases it is not sufficient to accurately predict the performance of MySQL for a certain application. Additionally, although MySQL has a reputation for sta-bility and performance, occasionally bugs are introduced during upgrades that may affect your application. Having your own testing procedures will make your upgrades much more trouble-free. You will not need to guess how stable the newly released version would be, as you will have a way to test it for your-self. To create your own test suite, you can expand the existing tests or write your own from scratch.
If you already have an application, you can simply run your MySQL server with the —log option while you try different things with your application as a user (or have a number of your beta testers to try it out), and then examine the log in the data directory to see your query patterns. If the application does not yet exist, you have to use your imagination and think of what kind of queries it will run most frequently.
Once you have an idea of your query patterns, you should write a program in C, Perl, PHP, Java, or whatever other client language you prefer that will execute queries with approximately the same pattern, and then time the operations that you are interested in. You might want to record the results of each query run against a test sample of your database on the first run, and use them as “master results” to compare against on subsequent runs. If the result does not match, you should signal an error. You should also record the performance timing for each query, and flag errors on subsequent runs if the new timing exceeds the
“master” timing by a wide margin. These suggestions, of course, assume that your application is functioning properly on the first run of the test.
When writing your own tests, focus on two aspects: functionality and perfor-mance. Functionality tests will ensure that all queries that are important in your application produce correct results, while performance tests will ensure that the application is stable under high load and provides acceptable response times.
One common way to create a functionality test for MySQL is to have a test suite for your entire application. As you test various features of your application, cer-tain MySQL queries will be executed. If there are any problems with MySQL that affect your application, they will show up in a thorough test suite. The same approach works for performance. The essence of this approach is that you treat MySQL as a module in your application, which needs to be tested just like any other module.
Many users like to test MySQL performance before they commit to developing their application with MySQL. They like to test 5 to 10 queries that will be com-mon in their application, and see how MySQL will handle them under load. One way to accomplish this task is to modify mysqlsyseval and add the desired type of query. To add a new query type, just add a new type to the QUERY_TYPE enum at the end, add the string for the new query type at the end of the types array in get_query_type(), and add a case statement for the new query type to run_thread() similar to the ones quoted earlier. Be sure to include at the end of the statement the variable buf, specifying the query you want to run. You can also change the table definition by modifying the argument to the sprintf() call, which builds the CREATE TABLE statement in benchmark_threads().
Your Own Tests 79
You may also consider extending the standard Perl benchmark, although this is a more difficult task. It would be worthwhile, though, if you want to compare MySQL performance on a particular query with other databases. The Perl benchmark uses the DBI interface, which is highly portable, and requires you to change only the value of $self->{'data_source'} and perhaps a couple of server-specific limit variables to be able to run the test against a different server.
If you would like to test raw functionality, you may want to consider extending the standard regression test suite. The advantage of this kind of test is that you can submit it to MySQL AB, and it will likely be accepted and included in the standard test suite. This guarantees that your test succeeds in all subsequent releases. To submit a test case in this format, send an e-mail to internals@lists.mysql.com.
Let’s illustrate the process with an example. Suppose we want to test the fol-lowing query:
SELECT a,b FROM t1 WHERE a > b;
on the table with the following data:
a b c
1 2 3
8 3 1
4 4 7
We first decide on the name of our test. Suppose we want to call it abctest. Cre-ate a file in the mysql-test/t directory called abctest.test. We put the following into the file:
drop table if exists t1; # clean up from possible previous crash create table t1 (a int, b int, c int); # create the table
insert into t1 (a,b,c) values (1,2,3),(8,3,1),(4,4,7); #populate the table
select a,b FROM t1 WHERE a > b; # run the query and check or record the result
drop table t1; # clean up after the work is done
and in the mysql-test directory run the following to record the result to com-pare against in the future:
./mysql-test-run —record —local abctest
Afterward, we check the result file to make sure it is correct and edit it as nec-essary. The result file is located in r/abctest.result, and will contain the output of the SELECT query. In version 4.0, in addition to the result of SELECT the queries that have been run during the test will also be recorded.
Now that we have created t/abctest.test manually and r/abctest.result by recording and possible subsequent manual editing, the test suite will contain
the abctest test, and it will be run every time you execute ./mysql-test-run.
To submit the test for inclusion, you need to send those two files to the MySQL development team. Please be aware that MySQL mailing lists do not accept attachments. You will need to put up the files at some download location, for example, on your FTP or HTTP server, and send the URL to internals@lists.mysql.com.
As you can see, there are numerous ways to create your own tests. You can choose the most appropriate method depending on your situation. Having a customized test suite for MySQL and your application as it integrates with MySQL will facilitate the development and maintenance processes and increase your system stability.
Your Own Tests 81
T
his chapter provides an overview of how to secure your MySQL server and discusses two particular aspects of security: security at the database level, and security at the operating system and network level. Every aspect of security is critical and needs to be scrutinized when you’re configuring a server.In a house with open windows, extra-strong door locks will protect you only from a criminal who is not good at climbing in through those windows.
When you’re considering system security, you should learn to think like a per-son who is trying to compromise your system. To be successful in securing a system, you need to develop a benevolently malicious mind—in other words, understand the mind of a bad guy well enough to predict what he is going to try.
However, you must also remember this fine line: Legitimate users should not be required to jump through an unreasonable number of hoops every time they need access to a system resource.
Let’s discuss how these general security principles apply to a MySQL server installation.