Categories
Uncategorized

Sun Breaks MySQL’s Source Install

I was supposed to go to Medjool to meet up with the Zappos crew, but instead I ended up helping a pal with a MySQL database upgrade problem with version 5.1.24-rc.

The upgrade was a cluster fuck!

These steps for upgrading MySQL have served me well for the past 9 years.

tar cvf backup_data.tar /usr/local/mysql/var/*
gzip backup_data.tar
cd /usr/local/src/mysql-5.1.24-rc
./configure --prefix=/usr/local/mysql --with-mysqld-user=mysql --with-ssl
make
make install
scripts/mysql_install_db

Then I’d just run ‘/usr/local/libexec/mysqld –user=mysql &’ and I’d be on my merry way to happily computing on the web.

But now wiith version 5.1.24-rc of MySQL, I’d have to ask what the heck are they doing at Sun to MySQL?

When I started the server, I noticed that the state files were running in /var . Big fail there, since the prefix is defined as /usr/local/mysql .

Also, I noticed that when I ran scripts/mysql_install_db there were more path errors:

FATAL ERROR: Could not find /fill_help_tables.sql

Then the biggest source of fail occured when I ran this:

/usr/local/libexec/mysqld –print-defaults

/usr/local/mysql/libexec/mysqld would have been started with the following arguments:

--port=3306 --socket=/tmp/mysql.sock --skip-locking --key_buffer=16M 
--max_allowed_packet=1M --table_cache=64 --sort_buffer_size=512K 
--net_buffer_length=8K --read_buffer_size=256K 
--read_rnd_buffer_size=512K --myisam_sort_buffer_size=8M 
--log-bin=mysql-bin --server-id=1 --user=mysql 
--pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
--port=3306 --basedir=/usr --datadir=/var/lib/mysql --tmpdir=/tmp
--language=/usr/share/mysql/english --skip-external-locking --bind-address=127.0.0.1
--key_buffer=16M --max_allowed_packet=16M --thread_stack=128K --thread_cache_size=8
--query_cache_limit=1M --query_cache_size=16M --expire_logs_days=10 --max_binlog_size=100M
--skip-bdb 

Once again, path errors, and –skip-bdb is an option that doesn’t even exist for mysqld!!!!!!

Here was my fix for the scripts’ install:

./scripts/mysql_install_db --no-defaults --port=3306 --socket=/tmp/mysql.sock \ 
--skip-locking --key_buffer=16M --max_allowed_packet=1M --table_cache=64 \
--sort_buffer_size=512K --net_buffer_length=8K --read_buffer_size=256K  \
--read_rnd_buffer_size=512K --myisam_sort_buffer_size=8M --log-bin=mysql-bin \ 
--server-id=1 --user=mysql --pid-file=/var/run/mysqld/mysqld.pid \
--socket=/var/run/mysqld/mysqld.sock \
 --port=3306 --basedir=/usr/local/mysql --datadir=/usr/local/mysql/var \
--tmpdir=/tmp --language=/usr/local/mysql/share/mysql/english --skip-external-locking \
--bind-address=127.0.0.1 --key_buffer=16M --max_allowed_packet=16M \
--thread_stack=128K --thread_cache_size=8 --query_cache_limit=1M \
--query_cache_size=16M --expire_logs_days=10 --max_binlog_size=100M

Here’s my fix for how the server must start from now on:

/usr/local/mysql/bin/mysqld_safe --no-defaults --port=3306  \
--socket=/tmp/mysql.sock --skip-locking --key_buffer=16M  \
--max_allowed_packet=1M --table_cache=64 --sort_buffer_size=512K  \
--net_buffer_length=8K --read_buffer_size=256K  \
--read_rnd_buffer_size=512K --myisam_sort_buffer_size=8M  \
--log-bin=mysql-bin --server-id=1 --user=mysql  \
--pid-file=/var/run/mysqld/mysqld.pid  \
--socket=/var/run/mysqld/mysqld.sock --port=3306  \
--basedir=/usr/local/mysql --datadir=/usr/local/mysql/var  \
--tmpdir=/tmp --language=/usr/local/mysql/share/mysql/english  \
--skip-external-locking --bind-address=127.0.0.1 --key_buffer=16M  \
--max_allowed_packet=16M --thread_stack=128K --thread_cache_size=8  \
--query_cache_limit=1M --query_cache_size=16M  \
--expire_logs_days=10 --max_binlog_size=100M &

All that just to start a server, so now, I’m totally telling my friends to use PostgreSQL instead. Sure it’s slower and doesn’t scale as much by a factor of 4 compared to MySQL, but hey, maybe it’s time for something new.

5 replies on “Sun Breaks MySQL’s Source Install”

or you could use a my.cnf file ad specify –defaults-file
–skip-bdb is removed as BDB engine no longer is shipped with mysql.
maybe you have things set in /etc/my.cnf? unless you have –no-default-file, mysql will read it.

Also, none of this would have anything to do with Sun, the engineering organisation is exactly the same as it was (except that above Marten there is now Rich Green and Jon Schwartz). Everything else is *exactly* the same (well… my pay slips do come from another company now… but that’s it).

Hope this helps,
stewart

I’d have to disagree. The my.cnf file has usually been re-configured with the right prefix. The fact that I have to edit the my.cnf when in the past I didn’t have to shows that it’s broken.

I lost the bugid, but that’s actually the result of a bugfix in the way my.cnf’s are discovered in the install scripts.

I had this back and forth with some mysql’ers a few months ago when I pulled up 5.0.51 (which also has this “fix”) and found I could no longer do easy sandboxed installs combined with a running production mysql system. Apparently it was always trying to detect and use a global my.cnf, but it was broken until recently.

Fiddled with it a little, gave up, and decided to mv the my.cnf for the purposes of doing said install.

Also. the instructions did change a bit… mysql_upgrade_whatever.

Leave a Reply

Your email address will not be published. Required fields are marked *