MySQL Upgrade Gotcha

I was trialling a MySQL database upgrade today (from 5.0 to 5.1) and hit a nasty little gotcha that I feel warrants a mention (mostly to myself). In its simplest form, the upgrade process is very straightforward and involves simply loading data dumped from MySQL 5.0 into a 5.1 database (using a regular mysql command), followed by a once-off execution of the mysql_upgrade command (to bring the various tables and grants up to date):

$ mysql -u root -p testdb < dumped50.sql
$ mysql_upgrade -u root -p testdb

However, when I tried the latter command, I received this error:

Looking for 'mysql' in: mysql
FATAL ERROR: Can't find 'mysql'

I did fine a simple solution here which was to first change to the directory containing the mysql_upgrade program itself and execute it from there:

$ cd /opt/coolstack/mysql/bin
$ ./mysql_upgrade -u root -p testdb

As I said, its a simple solution and I do tend to follow this general rule most of the time but nevertheless, the error generated when you don’t do this is far for informative.

Solaris Coolstack roadmap update

The Solaris Coolstack team have announced some important changes that impact on the future of the popular open source software stack. In a nutshell, they are combining their Cool Stack software (intended for use with Solaris 10) with their Web Stack software (intended for use for OpenSolaris) into a single software bundle, which will be known as Sun Web Stack.

Not only will this new stack be supported on Solaris 10 and OpenSolaris, but Linux support is also being added, as is full support for those using the software in production a capacity.

The first version of Sun Web Stack is scheduled for release in November 2008 and will follow the version numbering from Coolstack. Thus, the first release will be Sun Web Stack 1.4.

Source: Shanti’s Blog

Coolstack Squid Installation Notes

I recently installed Squid, the HTTP Proxy, for the first time. The version I installed was 2.6-STABLE16 and came as part of Solaris Coolstack 1.2. Here are some notes from the installation process:

Installation

The application on Solaris x86 using the pkgadd utility and the appropriate Coolstack Squid package file (CSKsquid_1.2_x86.pkg). The installation process also created a new SMF service called csk-squid.

Setup

This was the first time I had installed Squid so, after reading the documentation provided by Coolstack, I tried starting the Squid service. Unfortunately, it kept complaining about missing cache directories and file permissions, and would not start. In the end, a colleague directed me towards the squid -z command, which carried out all of the required post-installation setup and duly sorted out all of the directory/permissions problems.

Configuration

I only had to make two small changes to the Squid configuration file (/opt/coolstack/squid/etc/squid.conf):

  1. Squid uses port 3128 by default but, since our corporate firewall permits very few outbound ports, we modified squid to use port 8080 instead:
  2. http_port 8080

  3. We wanted to restrict access to the new HTTP Proxy to only a certain range of corporate IP addresses. This was easily achieved by adding a simple access rule as follows:
  4. acl my_networks src XXX.XXX.XXX.XXX/24
    http_access allow my_networks

Other than this, the process was surprisingly straightforward.

Trial migration from Coolstack 1.2 to 1.3.1

I got an opportunity to run a trial migration of several applications from Solaris Coolstack version 1.2 to version 1.3.1 recently. The Coolstack applications that we use include MySQL, Apache (including mod_jk), Tomcat and Memcached.

I had no problems at all with the Tomcat or Memcached upgrades but did hit 2 minor issues with MySQL and Apache (mod_jk actually).

1. MySQL

This involved going from MySQL 5.0.45 to 5.1.25 and whilst I found that a regular mysqldump of my MySQL 5.0 databases imported without error into MySQL 5.1, I did encounter some minor issues with user permissions later on. Fortunately, the guide to Upgrading from MySQL 5.0 to 5.1 proved very useful and revealed that I had missed an essential step in the upgrade process which was the use of the mysql_upgrade utility. There is lots more to read about in the upgrade guide and depending on your configuration, there may be more steps to be considered.

2. Apache (mod_jk)

Whilst the Apache upgrade (2.2.6 to 2.2.9) worked a treat, I found that mod_jk 1.2.26 employs stricter rules in relation to the placement of JkMount/JkMountFile commands in VirtualHosts. In my previous configuration, I had a single JkMount command inside my mod_jk.conf file (which in turn was included from the main httpd.conf file). However, using this configuration with Apache 2.2.9 and mod_jk 1.2.26, I found that my AJP load balancer was not working correctly for one of my VirtualHosts. It was only when I moved my JkMount command inside the scope of the VirtualHost that it started working again.

Other Comments

Most of the SMF service names in the Coolstack 1.3.1 applications have been renamed slightly. In Coolstack 1.2, all of the SMF service names began with csk- but now they all end with -csk instead. This was apparently done to make the service names more compatible with OpenSolaris but, to be honest, I find it a little bit annoying as we’ve written a number of useful scripts that manage these services explicitly by name.

Coolstack 1.3.1 includes two different versions of Tomcat (5.0 and 6.0) which install to different locations and have different SMF service names.

The Road to Solaris Coolstack 1.3.1

It would appear that the release of Coolstack 1.3.1 was a little more adventurous than previous versions, as the following timeline illustrates.

10 June 2008

Firstly, we had the launch of Coolstack 1.3 Release Candidate 1 which seemed to work fine on my 10u3 systems but was still technically only a candidate release.

11 July 2008

Then, around 4 weeks later, the official version of Coolstack 1.3 was released. This included a number of minor software revision enhancements but more importantly, included the addition of DTrace probes in applications such as MySQL, Ruby and Memcached. However, the addition of these probes required either the use of Solaris 10 U5 or the installation of a number of Solaris kernel patches, neither of which went down too well in the Coolstack community. As a result, this version 1.3 was withdrawn and 1.3RC1 became the official 1.3 release.

14 August 2008

In an effort to support Solaris versions prior to U5, the DTrace probes were backed out of the affected applications and Coolstack 1.3.1 was born. A number of other minor software enhancements were also added but in essence, 1.3.1 was all about satisfying the wider Coolstack community.

I did eventually get the opportunity to try out Coolstack 1.3.1 and did not encounter any major issues. We are planning a more comprehensive review of the reported MySQL performance gains though.

Solaris CoolStack 1.3 released

CoolStack is a collection of some of the most commonly used open source applications optimized for the Sun Solaris platform. The latest version of this software suite, Cool Stack 1.3, has just been released. Here is a brief overview:

Notable Additions

  • Python 2.5.2
  • Nginx 0.6.31
  • New Apache modules including mod_python, mod_ruby, mod_dtrace etc.

Updated Versions

  • Apache 2.28
  • Tomcat 5.5.26
  • MySQL 5.1.24
  • PHP 5.2.6
  • Memcached 1.2.5
  • Ruby 1.8.6p114 with Ruby Gems 1.1.1 and Rails 2.0.2

Other Enhancements

  • Ruby performance improvements in the order of 20-30% (with a further 8-15% coming down the line when Ruby 1.8.7 is released)
  • Better support for installing Ruby Gems that require native compilation on SPARC systems

The addition of Nginx an Python support along with the performance improvements in Ruby as well as the additional Apache modules are all very useful additions and have yet again come at just the right time for our organisation. Well done to Shanti and his team for providing almost exactly everything we were hoping for in this release, again!

Running multiple instances of MySQL with Solaris Coolstack 1.2

We recently had a requirement to run two instances of MySQL on two separate Solaris systems (for the purposes of dual-master replication). The systems in question were both SunFire T2000s running Solaris 10 (U3) and Coolstack 1.2 and already had a previous/single instance of MySQL running (SMF service csk-mysql).

In the end, it was a relatively straightforward exercise in that all we really did was replicate the existing instance (control script, configuration file and manifest file) and change the necessary bits of the resultant files so that the new instance was sufficiently different to the old, in the end, producing two independent SMF services (csk-mysql1 and csk-mysql2). Specifically, the following files were created:

MySQL Control Scripts:
/opt/coolstack/lib/svc/method/svc-cskmysql1
/opt/coolstack/lib/svc/method/svc-cskmysql1

MySQL Configuration Files:
/etc/my1.cnf
/etc/my2.cnf

MySQL Manifest Files:
/var/svc/manifest/network/cskmysql1.xml
/var/svc/manifest/network/cskmysql2.xml

The manifest files were identical but for the name of the service and the control script they invoke. The control scripts were also identical but for the configuration file and DBDIR that they use and the difference(s) in the configuration files were mainly in terms of the port numbers and socket files used.

Beware

The only thing that caught us out was in modifying the control scripts (to tell them which configuration file they should use). This was done by adding a --defaults-file argument to the invocation of mysql_safe. However, you need to ensure that this argument is the first one you pass to mysql_safe. Otherwise, MySQL will launch will not load the correct configuration settings. This is not (well) documented so beware!

Also, when trying to access the new instances via the mysql client, you will need to add the -P and -S arguments.

Native Ruby Gems require Sun Studio 12 with CoolStack 1.2

A substantial number of Ruby Gem packages are written in Ruby itself and install quite neatly using a simple gem install command. However, a number of Gem packages are partly written in C and require some compilation during installation (e.g. hpricot, fastthread and mongrel). This requires you to have a C compiler on the system where you are installing the packages, which is a real pain, but that’s a gripe for another day.

We recently upgraded to CoolStack 1.2 but when we tried to install the Gem packages above, we ran into trouble when the installer attempted to compile the native code for the package. The compiler (Sun Studio 11) complained about the definition of the NORETURN macro in /opt/coolstack/lib/ruby/1.8/i386-solaris2.10/config.h as follows:

syntax error before or at: __attribute__
warning: old-style declaration or incorrect type for:
__attribute__
warning: syntax error: empty declaration
...
cc: acomp failed for hpricot_scan.c

It turns out that the new version of Ruby (1.8.6) that is included with CoolStack 1.2 contains some GCC-oriented macro definitions that Sun Studio 11 does not support. The solution was to upgrade to Studio 12.

Huge thanks go to Basantk for helping to resolve this.

Solaris CoolStack 1.2 released

CoolStack is a collection of some of the most commonly used open source applications optimized for the Sun Solaris OS platform. I’ve been tracking the release of the next version, CoolStack 1.2, for some time and see that it has just been released. Here is a brief overview of what it gives you:

  • Apache 2.2.6 with mod_jk-1.2.25, mod_proxy and SMF support.
  • PHP 5.2.4 with FastCGI support.
  • APC 3.0.14.
  • MySQL 5.0.45 with ndbcluster and SMF support.
  • Memcached 1.2.2.
  • Squid 2.6.16 with SMF support.
  • Tomcat 5.5.23 with SMF support.
  • Ruby 1.8.6 with RubyGems and Rails 1.2.3.
  • lighttpd 1.4.18.
  • Perl 5.8.8 with DBI-1.59, DBD-mysql-4.005 and Sys-Syslog-0.18 extensions

As you can see, CoolStack is now a pretty serious software bundle and there isn’t much it doesn’t give you (although DTrace support for Ruby would be a useful addition). The addition of Tomcat and SMF support (SMF allows easier management of Solaris services) along with the additional Apache modules and updated revisions of Apache, MySQL, Ruby and Rails tick a large number of boxes in our organisation as we previously had to build several Apache modules by hand, struggled with lack of Perl DBI/DBD extensions and spent far too long constructing SMF manifests for many of the applications.

So, well done to Shanti and his team for providing almost exactly everything we were hoping for in this release! CoolStack has now become an integral part of our software infrastructure, reducing our service deployment times considerably.

Apache + Mongrel on Solaris

Apache is an excellent Web Server but does not handle Rails projects very well. Mongrel is a Ruby-based library that can assist things like Apache with management of dynamic content.

Credit / Reference Site

We owe a great deal of thanks to this article posted by codehale on the same topic. The article you are reading here is a summation of notes taken during a recent installation of Apache and Mongrel on the Solaris operating system, based on codehale’s article.
Prerequisites

Several software packages need to be pre-installed on Solaris in order for Mongrel to install and operate correctly. I have listed them below along with the version I used. The version of Apache and Ruby were both taken from the Solaris CoolStack software bundle.

  1. Apache 2.2
  2. Ruby 1.8.5
  3. Ruby Gems 0.9.2
  4. Ruby on Rails 1.2.3
  5. Sun Studio 11

To install the software, simply download (and unzip) the relevant file from the above site(s) and install it (as root) using the pkgadd –d command.

Installation Procedure
The system used for this installation was a SunFire T1000 running Solaris 2.10 (U3).

Step 1 – Download Mongrel

Commands

# gem install daemons gem_plugin mongrel mongrel_cluster --include-dependencies --no-rdoc --no-ri

Notes

  • When asked about which version of Mongrel and FastThread, we chose the newest version for ruby (not win32).
  • The above command will attempt to compile and install some native code and requires a C compiler. If you are using Sun Studio, you should also read my other post regarding Ruby and Sun Studio.
  • If you are using GCC, then you may also require ginstall. However, ginstall is not available for Solaris so we overcame this by installing the GNU coreutils package and then creating a symbolic link: /usr/local/bin/ginstall pointing at /usr/local/bin/install (after coreutils was installed).
  • The reference site above also recommends that the “sendfile” utility be removed from your system (if installed). We used the “pkginfo | grep sendfile” command to verify that it was not present on our system.

Step 2 – Configuring Mongrel Clusters

Commands

# cd /opt/tssg/feedhenry/wc
# mongrel_rails cluster::configure -e production -p 8000 -a 127.0.0.1 -N 3 -c /opt/myrubyapp/public
# vi /opt/myrubyapp/config/mongrel_cluster.yml (and change port setting to 8000 - see below)
# mongrel_rails cluster::start -c /opt/myrubyapp/config/mongrel_cluster.yml

Notes

  • The -N value above represents the number of clusters required. We followed the example and chose 3.
  • The second command above creates a mongrel_cluster.yml file. However, we noticed that the port setting in this file was incorrect after it was created. It was “ath” instead of 8000 (not sure why).
  • The final command should produce one line of output for each cluster configured indicating that each cluster was correctly started.
  • You should also examine the logs/mongrel.log file and ensure that the clusters started on the correct ports (8000, 8001, 8002 etc). This is how we noticed that the .yml file had the wrong port setting.
  • You can use the mongrel_rails cluster::stop command to stop the clusters again (-c option also required here)

Step 3 – Configuring Apache

You will need use some additional Loadable Modules for Apache. Refer to this post for details on which ones you need and how to build them. You can then follow the instruction in the reference post.

Once these files were configured and placed in the conf/extra directory, we simply had to make one change to the main Apache configuration file (conf/httpd.conf) to ensure that these new files were loaded by Apache. This consisted of the following command:

Include conf/extra/myapp*.conf

You should now be ready to start Apache (/opt/coolstack/apache2/bin/apachectl start)

Best of luck!