Upgrade went smoothly for me. I use postfix, apache, online-bookmarks, gallery2 and syslog-ng with mysql and all work fine at mysql-4.1.14 after using the upgrade process. However, revdep-rebuild does not pick up the fact that /usr/nagios/bin/nagios (net-analyzer/nagios-core) needs to be rebuilt. Maybe I don't know the right option to feed revdep-rebuild to catch this one, but there is no man page for it _________________"Blessed is he who finds happiness in his own foolishness, for he will always be happy".

The upgrade manual says "Under certain conditions it's possible to directly upgrade to the next major version of MySQL". What are those conditions exactly? I want to upgrade using the fast but dangerous method because the safe and slow method will come with too much downtime (pretty large tables and a lot of them). Is there also a way to compile the programs that depend on mysql against mysql-4.1 while 4.0 is still installed & running (as binary packages, not-yet-merged ofcourse, but when the time is there it will be a lot faster to emerge)_________________Fan of the "Survivor Warriors of the Evil Empire of Bloody Destruction and Bloody Darkness"

The upgrade manual says "Under certain conditions it's possible to directly upgrade to the next major version of MySQL". What are those conditions exactly? I want to upgrade using the fast but dangerous method because the safe and slow method will come with too much downtime (pretty large tables and a lot of them). Is there also a way to compile the programs that depend on mysql against mysql-4.1 while 4.0 is still installed & running (as binary packages, not-yet-merged ofcourse, but when the time is there it will be a lot faster to emerge)

Why not "just" copy your current system to a chroot jail where you would do the update + build binary packages for quick merge on production system?

The upgrade manual says "Under certain conditions it's possible to directly upgrade to the next major version of MySQL". What are those conditions exactly? I want to upgrade using the fast but dangerous method because the safe and slow method will come with too much downtime (pretty large tables and a lot of them). Is there also a way to compile the programs that depend on mysql against mysql-4.1 while 4.0 is still installed & running (as binary packages, not-yet-merged ofcourse, but when the time is there it will be a lot faster to emerge)

I use phpMyAdmin, Wordpress and MediaWiki. I followd the instructions. But I got an error when trying to import the data again. Something of the key length being too big at line 1402 (max length 1000 bytes). I had to downgrade again before I had time to find out what the problem was. It is a important server.

I use phpMyAdmin, Wordpress and MediaWiki. I followd the instructions. But I got an error when trying to import the data again. Something of the key length being too big at line 1402 (max length 1000 bytes). I had to downgrade again before I had time to find out what the problem was. It is a important server.

What should I do?

Check your my.cnf for this setting... I believe that should fix it. I don't recall the exact param though.

I use phpMyAdmin, Wordpress and MediaWiki. I followd the instructions. But I got an error when trying to import the data again. Something of the key length being too big at line 1402 (max length 1000 bytes). I had to downgrade again before I had time to find out what the problem was. It is a important server.

What should I do?

you have an error like "ERROR 1071 (42000) at line n: Specified key was too long; max key length is 1000 bytes"
problem described in http://bugs.mysql.com/bug.php?id=4541". to "workaround" it. open the backup.sql, go to line "n", look down a few lines, insert "CHARACTER SET latin1" in the column that cause problem. for example here is my greylist database

However, revdep-rebuild does not pick up the fact that /usr/nagios/bin/nagios (net-analyzer/nagios-core) needs to be rebuilt. Maybe I don't know the right option to feed revdep-rebuild to catch this one, but there is no man page for it

Mybe rebuilding all packages having the mysql use flag would be a good thing:

you have an error like "ERROR 1071 (42000) at line n: Specified key was too long; max key length is 1000 bytes"
problem described in http://bugs.mysql.com/bug.php?id=4541". to "workaround" it. open the backup.sql, go to line "n", look down a few lines, insert "CHARACTER SET latin1" in the column that cause problem. for example here is my greylist database

This is not entirely MySQL related, but it happened right after I upgraded to 4.1

vpopmail doesn't seem to work anymore with qmail somehow O_o.
It authentificates quite well with courier-imap though, no problems logging and reading IMAP folders, but with qmail, I just get those in the logs:

Anyone have any clues on hwo to fix this? I can login with the vpopmail user fine under MySQL, and of course, I recompiled vpopmail, since for example, vuseradd works fine (I can add users to my virtual domains this way)

# Point the following paths to different dedicated disks
tmpdir = /tmp/
#log-update = /path-to-dedicated-directory/hostname

# you need debug use flag enabled to use this ones.
# if needed uncomment them, start the server and issue
# #tail -f /tmp/mysqld.sql /tmp/mysqld.trace
# this will show you *exactly* what's appening in your server ;)

# Uncomment the following if you are using BDB tables
#bdb_cache_size = 4M
#bdb_max_lock = 10000

# The following is the InnoDB configuration
# if you wish to disable innodb instead
# uncomment just the next line
#skip-innodb
#
# the rest of the innodb config follows:
# don't eat too much memory, we're trying to be safe on 64Mb boxes.
# you might want to bump this up a bit on boxes with more RAM
innodb_buffer_pool_size = 16M
# this is the default, increase if you have lots of tables
innodb_additional_mem_pool_size = 2M
#
# i'd like to use /var/lib/mysql/innodb, but that is seen as a database :-(
# and upstream wants things to be under /var/lib/mysql/, so that's the route
# we have to take for the moment
#innodb_data_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
#innodb_log_group_home_dir = /var/lib/mysql/
# you may wish to change this size to be more suitable for your system
# the max is there to avoid run-away growth on your machine
innodb_data_file_path = ibdata1:10M:autoextend
# we keep this at around 25% of of innodb_buffer_pool_size
# sensible values range from 1MB to (1/innodb_log_files_in_group*innodb_buffer_pool_size)
innodb_log_file_size = 5M
# this is the default, increase if you have very large transactions.
innodb_log_buffer_size = 8M
# this is the default, and won't hurt you.
# you shouldn't need to tweak it.
set-variable = innodb_log_files_in_group=2
# see the innodb config docs, the other options are not always safe
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
# Remove the next comment character if you are not familiar with SQL
#safe-updates

Man, this is scary. I don't want to have to spend another whole day reinstalling, reconfiguring, swearing at things, and in general having a very bad time like I did when I upgraded Postfix and, more recently, Apache.

Is there any hope of this MySQL situation becoming less of a disaster for Gentoo users? Are there any compelling reasons to upgrade? I skimmed the changes list, but didn't see anything that would make it worth the hassle.

Man, this is scary. I don't want to have to spend another whole day reinstalling, reconfiguring, swearing at things, and in general having a very bad time like I did when I upgraded Postfix and, more recently, Apache.

For me, at least, this was a much easier upgrade than the apache upgrade. Everything in 4.1 is basically as it was in 4.0 -- the main hassle here is just that this involves significant downtime due to all the compiling and reloading of data.

Quote:

Are there any compelling reasons to upgrade? I skimmed the changes list, but didn't see anything that would make it worth the hassle.

If it doesn't seem worth it, just mask the newer releases. I suspect a bunch of people will, and I also suspect that Gentoo will continue to support the 4.0.X line, just as they've continued to support the 3.23.X line.

i tried to import the typo3 sql databases into the new mysql server, but it fails, cause all german umlauts (äöü) gets broken. . I have also several wordpress installations. I don't know, how i can fix this issue._________________--
cu denny