I will also be showing you how I manage MySQL upgrades and versions on my database machines. This includes keeping the previous version of software for emergency rollback. You never know when an unexpected bug or feature will cause problems for you, so it’s good to keep at least one historical version on hand. I highly suggest that you let the new version of MySQL burn-in for at least 48 hours before migrating the binaries and upgrading the rest of your boxes.

There have been cases where a version of MySQL that I’ve compiled has introduced problems. The majority of the time this is related to replication or collations. Whatever the case, I had the need to rollback to a version that was working fine. You can typically do this for minor upgrades (e.g. 5.1.51 to 5.1.50) with a relative confidence. That level of certainty does not apply to major and major-minor (5.0.x to 5.1.x or 4.x to 5.x).

In order to accomplish this, I keep all versions of MySQL in the same directory with at least one previous version. My versions are installed in /opt. The installation directory is always named mysql-[version]. For example, if I’m installing MySQL 5.1.52, the path to the installation will be /opt/mysql-5.1.52. This let’s me keep a lot of historical versions on hand while also installing and distributing new versions without stopping MySQL. The production version is a symbolic link to the full path of the installation. For example, if version 5.1.51 is the production version, my symbolic link would be created like this:

ln -s /opt/mysql-5.1.51 /opt/mysql

A listing of /opt would yield something like this:

drwxr-xr-x  4 root root 4096 Sep 20 20:52 ./
drwxr-xr-x 25 root root 4096 Sep 23 23:42 ../
lrwxrwxrwx  1 root root   17 Sep 20 20:36 mysql -> /opt/mysql-5.1.51/
drwxrwxr-x  9 root root 4096 Jul 23 21:40 mysql-5.1.50/
drwxrwxr-x  9 root root 4096 Sep 20 20:34 mysql-5.1.51/

Notice that the previous version, 5.1.50, still exists in the event I have to rollback. If this happens, I simply take the following actions:

• Stop the running MySQL instance
• Destroy the existing symbolic link
• Create a new symbolic link that points to the previous version
• Start MySQL via /opt/mysql/bin/mysqld_safe
• Verify the problem no longer exists

The same logic applies to upgrading, but rather than creating a symbolic link to the previous version, it gets pointed to the new.

Prior to actually configuring, compiling and installing the new version of MySQL, we need to set some flags for the C and C++ compilers. This is where much of the optimization will come into play. Keep in mind that this is not all-inclusive, and there’s likely more compiler optimizations you can make for your distribution and hardware.

CPU-specific Flags

Depending on whether you’re using Intel or AMD processors, you will have some different flags to set. In my case, I’m using dual Xeon 5460s. The flag I use is SSE4.1, which is labeled for Core i7, but is generically used for X5400/5500 CPUs as well.

If you’re using AMD, you will have a different list to choose from. The full list of CPU flags can be found here. The generic, x86_64 architecture flag for AMD is athlon64.

Passing these flags to the compiler is done with two Linux environmental variables: CFLAGS and CXXFLAGS. CFLAGS is for the C compiler while CXXFLAGS is for the C++.

Now that we have the CPU-specific flags worked out, let’s discuss additional optimization flags. One of the most important flags you’ll set is the optimization flag (-O). There are technically five levels of optimization, but I’ll discuss only three: -O1, O2 and O3. Each of these levels represents GCC’s attempt to optimize the code produced from the source files. I’ll briefly explain these:

• O1 – Level one optimizes common features that don’t require speed-space tradeoffs. The executable produced by this level is usually faster and smaller in size than with no optimization.
• O2 – Level two includes level one optimizations and many, many others. Generally speaking, this is the route to go with on most distributions.
• O3 – This includes all optimization possibilities. Be careful using this one as is produces a rather large executable. While in some cases this may produce faster code, it has had the opposite affect with me. The only way to truly know if you should choose level two or three is trial and error. Compile the same version of MySQL with both flags and test which is faster.

The other two are O0 or no optimization and Os optimizes to produce the smallest possible executable for systems constrained by memory and disk.

For a full list of features that are optimized by level, see this image.

The next flag is "pipe". Pipe directs GCC to take piped input and use RAM whenever possible rather than disk. In most cases, you won’t see a big performance gain from this, but we’re trying to achieve maximum results. Next we look at C++ flags.

There are two additional flags passed to the C++ compiler in conjunction with those mentioned above: no-exceptions and no-rtti.

The flag no-exceptions removes error handling as it relates to exceptions in the produced C++ code. MySQL actually recommends this flag in order to increase the stability of the produced executable.

Finally we come to no-rtti. The answer to this is simple: MySQL doesn’t use RTTI, so the result is a smaller and potentially faster executable.

Our CFLAGS and CXXFLAGS declaration will look like this for Intel:

CFLAGS="-O2 -msse4 -pipe" CXXFLAGS="${CFLAGS} -fno-exceptions -fno-rtti"

and this for generic AMD:

CFLAGS="-O2 --march=athlon64 -pipe" CXXFLAGS="${CFLAGS} -fno-exceptions -fno-rtti"

Go ahead and execute that in your shell, setting the environmental variables. If you’d like to test that they’re valid, issue the following commands:

echo $CFLAGS
echo $CXXFLAGS

Executing the Configure Script

The configure scripts works to produce a valid makefile. The makefile contains the instructions to compile, install and clean the MySQL distribution you’re working with. There are some important options to pass to this script that will produce a faster binary. Not all fall under this category, and I’ll discuss each option shown in the example below:

./configure \
  --prefix=/opt/mysql-5.1.52 \
  --enable-static \
  --with-charset=utf8 \
  --enable-thread-safe-client \
  --without-debug \
  --with-fast-mutexes \
  --enable-assembler \
  --with-plugins=innobase,partition

Prefix (–prefix) creates a variable that prefixes all installation directives. In the example above, we use /opt/mysql-5.1.52. This means that all executables, man pages, directories and scripts will be placed inside that specified directory.

Enable static (–enable-static) enables static linking to components. There is a trade-off with this. While it produces a faster executable, the footprint of the file is much larger. We will be able to dramatically reduce that later, however.

Setting the character set to UTF-8 (–with-charset=utf8) allows us to support multiple languages and characters outside of the default Latin character set. This is optional and by far not an optimization technique. It could easily be argued that this has the opposite affect, but if you plan to support a global audience, I’d suggest choosing this option.

Enabling a thread-safe client (–enable-thread-safe-client) produces the client software such as mysql, mysqladmin, mysqldump, etc. with thread-safe capabilities.

Disabling debugging (–without-debug) is an obvious performance booster. We most definitely don’t want MySQL to be worrying about providing that kind of information on a production system.

Fast mutexes (–enable-fast-mutexes) is another one of those trial and error situations. Depending on your machine, fast mutexes may or may not provide benefit. As with optimization level three, you will have to experiment to determine whether you should use this option.

Using an assembler (–enable-assembler) tells MySQL to use those versions of some string functions. This provides some optimization but not a lot.

You need to determine which plugins (–with-plugins) to use with your distribution. This is an application-level decision and the less you use the better off you are. InnoDB is the premier transactional engine for MySQL, so I’d highly suggest enabling and using it. The partition plugin allows you to scale your tables based on your defined criteria.

Now that we’ve prepped our software, it’s time to compile and install! This is my favorite part. I truly enjoy watching the makefile instruct GCC to chunk the source code and produce the fastest possible software. This makes me a super-dork, but it is what it is.

Execute the following command in your shell:

make

This starts the compilation of the software. Get up, stretch your legs and grab some coffee. This is going to take a while.

Once the compilation is complete, we’re ready to install the software. This is an easy one:

make install

List your /opt directory to ensure the software is good to go:

ls -al /opt

strip /opt/mysql-5.1.52/libexec/mysqld

You can also execute this on any binary file within your new distribution, but mysqld is certainly the most important.

Activating the New MySQL Version

Activating the new MySQL version is easy:

• Stop the running MySQL instance:

  /opt/mysql/bin/mysqladmin shutdown

• Destroy the existing symbolic link:

  rm /opt/mysql

• Create a new symbolic link that points to the new version:

  ln -s /opt/mysql-5.1.52 /opt/mysql

• Start MySQL via /opt/mysql/bin/mysqld_safe:

  /opt/mysql/bin/mysqld_safe --user=mysql &

There are additional optimization techniques you take use when configuring your MySQL instance (such as CPU priority), but I’ll save that for another entry.

MySQLi stands for MySQL Improved, and is available from MySQL versions >= 4.1.3 and must be compiled in PHP with –with-mysqli=/path/to/mysql/bin/mysql_config.

There are three hierarchical classes with MySQLi:

1. mysqli – Represents a connection between PHP and a MySQL database
2. mysqli_stmt – Represents a prepared statement
3. mysqli_result – Represents the result set obtained from a query against the database

Each one of these classes represent a different situation. The mysqli class is absolutely necessary because you will be communicating only through this class. It contains the connection to the other two classes (mysqli_stmt and _result). For instance, if you were executing a SELECT statement to pull cities from the states table, you would do something like the following:

 
<?php
$mysqli = new mysqli('hostname','username','password','database');
//This is where we will query the database and pull using the cities/states SELECT statement
// If the result returns true
if ($result = $mysqli->query("SELECT city FROM state WHERE state='AL'")) {
// So the result returned true, let's loop and print out each city.
// The number of rows returned is assigned to the property "num_rows" in the mysql_result class
echo 'For the state of AL, there are '.$result->num_rows.' cities.
';
// The "fetch_object()" method is the equivalent of the old mysql_fetch_object() function. It allows access to the returned rows within the resouce object ($result in this case).
while ($row = $result->fetch_object()) {
echo 'City Name: '.$row->city.'
';
}
} else {
// Notice below that the errors are still contained within the mysqli class. This means that each result will affect a single "error" property. In otherwords, if your result fails, the error returned from MySQL is assigned to the property "error".
// This means the query failed
echo $mysqli->error;
} // end else
$mysqli->close();
?>

Before we go any further, let’s look at each one of the methods and parameters of the mysqli and mysqli_result class. This tutorial will not cover the mysql_stmt class, as this will be “Part 2″, which will cover prepared statements, and will be available within the next week.

Part 3 of the mysqli tutorial will cover transactions using the InnoDB engine.

mysqli Class Methods:

• mysqli – construct a new mysqli object
• autocommit - turns on or off auto -commiting database modifications
• change_user - changes the user of the specified database connection
• character_set_name - returns the default character set for the database connection
• close - closes a previously opened connection
• commit - commits the current transaction
• connect - opens a new connection to MySQL database server
• debug - performs debugging operations
• dump_debug_info - dumps debug information
• get_client_info - returns client version
• get_host_info - returns type of connection used
• get_server_info - returns version of the MySQL server
• get_server_version - returns version of the MySQL server
• init - initializes mysqli object
• info - retrieves information about the most recently executed query
• kill - asks the server to kill a mysql thread
• multi_query - performs multiple queries
• more_results - check if more results exist from currently executed multi -query
• next_result - reads next result from currently executed multi -query
• options - set options
• ping - pings a server connection or reconnects if there is no connection
• prepare - prepares a SQL query
• query - performs a query
• real_connect - attempts to open a connection to MySQL database server
• escape_string - escapes special characters in a string for use in a SQL statement, taking into account the current charset of the connection
• rollback - rolls back the current transaction
• select_db - selects the default database
• set_charset - sets the default client character set
• ssl_set - sets ssl parameters
• stat - gets the current system status
• stmt_init – initializes a statement for use with mysqli_stmt_prepare
• store_result - transfers a resultset from last query
• thread_safe - returns whether thread safety is given or not
• use_result - transfers an unbuffered resultset from last query

mysqli Class properties:

• affected_rows - gets the number of affected rows in a previous MySQL operation
• client_info - returns the MySQL client version as a string
• client_version - returns the MySQL client version as an integer
• errno - returns the error code for the most recent function call
• error - returns the error string for the most recent function call
• field_count - returns the number of columns for the most recent query
• host_info - returns a string representing the type of connection used
• info - retrieves information about the most recently executed query
• insert_id - returns the auto generated id used in the last query
• protocol_version - returns the version of the MySQL protocol used
• server_info - returns a string that represents the server version number
• server_version - returns the version number of the server as an integer
• sqlstate - returns a string containing the SQLSTATE error code for the last error
• thread_id - returns the thread ID for the current connection
• warning_count - returns the number of warnings generated during execution of the previous SQL statement

The best way to explain the usage of the mysqli class is to show by example. There are too many methods and properties to go over in this tutorial, so I will only give examples of some.

It’s important to note that some of these methods listed, aren’t methods at all. For instance, if you wanted to get the client library version of MySQL, you would use mysqli_get_client_version(), which returns the integer version. Here is an example:

<?php
printf("Client version: %d\n", mysqli_get_client_version());
?>

You are forced to use the functions since there is no need for the connection to the actual database.

You have already seen the usage of the mysql_result connection from the mysqli class, so let’s go over some more examples:

Getting some info on the result from the mysql database:

<?php
$mysqli = new mysqli('localhost','db_user','my_password','mysql');
// Get all the MySQL users and their hosts
$sql = "SELECT user, host FROM user";
// If the query goes through
if ($result = $mysqli->query($sql)) {
// If there are some results
if ($result->num_rows > 0) {
// Let's show some info
echo 'There were '.$result->num_rows.' rows returned.
';
echo 'We selected '.$result->field_count.' fields in our query.
';
echo 'Our thread ID is '.$mysqli->thread_id.'
';
// Ok, let's show the data
while ($row = $result->fetch_object()) {
echo 'Username: '.$row->user.' :: Host: '.$row->host.'
';
} // end while loop
} else {
echo 'There are no results to display. Odd how we connected to this database and there are no users.';
} // end else
} else {
// Notice the error would be within the mysqli class, rather than mysql_result
printf("There has been an error from MySQL: %s",$mysqli->error);
} // end else
// Close the DB connection
$mysqli->close();
?>

Here we used some common methods and properties to test and display information. Next week we will go over prepared statements and how they might assist in your scripts.

If you have any questions regarding MySQLi, please feel free to put comments and I will answer them soon.

– Will

Navicate MySQL is certainly the tool of choice for my DBA needs. As a developer/DBA, I handle large amounts of data, and am continuously altering and adding databases, tables and fields. Navicat has certainly helped me in this aspect.

This is not a tutorial for Navicat, but this will be coming soon. Right now, I want to introduce some capabilities of Navicat, and show how it differs from other database tools. First, here is a list of features for Navicat:

1. Timeout Reconnection for SQL server
2. Data and Structure Synchronization
3. New Query Builder – create query from different databases
4. Query Parameter
5. SQL Console
6. View Builder
7. Views, Stored Procedure and Triggers creation
8. Private Key for SSH Tunnel
9. Supports all MySQL versions
10. SSH Tunnel
11. HTTP Tunnel
12. Foreign Keys
13. Foreign Key Data Selection
14. Unicode and Character Set Support
15. Edit text in Blob field
16. Print Table Structure
17. Import data from ODBC
18. Import / Export data up to 18 most popular formats including MS Access, MS Excel, XML, PDF and TXT.
19. Create Schedule for Backup, Import / Export, Data Transfer, Saved Queries and Data Synchronization.
20. Create Reports with visual Report Builder
21. Report Archive – Reports can be saved as an archive file (.raf) for backup and increased portability.
22. Create Report Archive from command line

The best advantage is PremiumSoft keeps up with the MySQL versions! Yes, you heard me correctly. When MySQL 5 went into production, this tool had already supported stored procedures, triggers, views, and other MySQL 5 features! Keep in mind that I have tried quite a few tools in my time to include SQLYog (decent, but just not enough features), phpMyAdmin (too slow, but is web based and free), MySQL Query Browser (crashes all the time, but is free), MySQL Administrator (is okay, but doesn’t do a whole lot), MySQL Maestro (just boring and useless IN MY OPINION!), as well as others.

If you want to download a trial version of Navicat, go to http://www.navicat.com/detail.html. They have different licenses and it works on Windows, Linux, and Mac OS X.

If you do download the trial, please post comments on here for your experience.

*NOTE* I am in NO WAY affiliated with PremiumSoft CyberTech Ltd, so don’t cry that I work for them.

The mysqldump tool is a backup program that is distributed with every MySQL download. If you aren’t familiar with the bin directory within your MySQL distro, then it’s time to start playing around with the tools inside it.

According to MySQL AB, a man named Igor Romanenko was the original author of the mysqldump tool. As with all software, especially open source, it has been hacked, smacked, slapped around and rewritten 17 times since then (those aren’t actual statistics). When using the mysqldump tool, it produces SQL statements to create table structure, populate tables, or both.

I will assume you are using Linux command line to practice using this tool, but the same principles apply to Windows. Please do not play with production data if this is your first time using this application. You can screw things up if you aren’t careful.

The first step is to get into the MySQL bin directory. If your installation of MySQL is in /usr/local/mysql, then let’s get there by typing the following:

cd /usr/local/mysql/bin

Now that we are inside our bin directory, let’s list the files within and see what we’ve got.

ls

Now you should see the mysqldump tool along with a bunch of other stuff that will eventually get covered in other tutorials. Although we are only going to cover the commonly used and mostly basic options, let’s look at all that can be used with mysqldump. Click here to view them.

The command to backup an entire database is simple:

mysqldump database_name > filename_to_create.sql

Keep in mind that you will likely be required to use the –p (password) and/or –u (username) to backup a database. That user must have permissions to access that particular database. For instance, if we needed to backup the mysql database, and were using the root user, we would type the following:

mysqldump mysql > mysql_backup.sql –u root –p

At this point, MySQL will prompt us to input a password for the user root. After doing so, the backup process will begin, and a new file filled with all of the SQL creations and inserts for the mysql database will be available. Pretty handy, huh? What if we need to backup ALL databases? This is actually just as simple!

With the list of options provided with the link above, one of the option was “–all-databases”. This will dump all databases into the file you command. Let’s try it!

mysqldump –all-databases > alldbs.sql –u root –p

This will dump all databases into an SQL file called alldbs.sql. Now that we have finally backed up some databases, what do we need to do to restore them?

This can actually be a little tricky at first. You won’t be using mysqldump to do this, but rather mysql itself. There are two possible ways to do this. The first is to restore the data directly (using brute force). I don’t like this way, and if the SQL is formatted perfectly, then you could run into some issues. At all costs, here is the format:

mysql db_name < file.sql

Again, permissions will be a factor here. Here is my favorite method:

mysql –e “source backup_file.sql” db_name

That’s it! That is way too easy.

Before closing this tutorial, I want to show you how to copy databases and their data from one server to another. This is extremely handy if you have a development, test, and production area serving different databases:

mysqldump –opt db_name | mysql –host=remote_host -C db_name

The mysqldump tool is just too cool!  If you have any questions, feel free to email me.