On the link specified it says: "Note: mysql-4.0.26 will be used as the starting point, and mysql-5.0.18-r30 as the target version. Replace any of these versions with your own." Shouldn't the last sentence say "Replace your own version with any version within that range." or am I missing something? Thanks.
Or "Replace your own version if it doesn't fall within that range."
You could also make the for statement more verbose in the guide so the user can see clearly what is being done if you feel that is appropriate. Script: #!/bin/bash for tmpfile in /usr/lib/*mysql* do echo -e "Moving ${tmpfile} to ${tmpfile}.TMP" mv "${tmpfile}" "${tmpfile}.TMP" echo -e "Linking ${tmpfile}.TMP to ${tmpfile}" ln -s "${tmpfile}.TMP" "${tmpfile}" done Output: sepoy ~ # ./tmp.sh Moving /usr/lib/libmysqlclient.so to /usr/lib/libmysqlclient.so.TMP Linking /usr/lib/libmysqlclient.so.TMP to /usr/lib/libmysqlclient.so Moving /usr/lib/libmysqlclient.so.15 to /usr/lib/libmysqlclient.so.15.TMP Linking /usr/lib/libmysqlclient.so.15.TMP to /usr/lib/libmysqlclient.so.15 Moving /usr/lib/libmysqlclient.so.15.0 to /usr/lib/libmysqlclient.so.15.0.TMP Linking /usr/lib/libmysqlclient.so.15.0.TMP to /usr/lib/libmysqlclient.so.15.0 Moving /usr/lib/libmysqlclient.so.15.0.0 to /usr/lib/libmysqlclient.so.15.0.0.TMP Linking /usr/lib/libmysqlclient.so.15.0.0.TMP to /usr/lib/libmysqlclient.so.15.0.0 Moving /usr/lib/libmysqlclient_r.so to /usr/lib/libmysqlclient_r.so.TMP Linking /usr/lib/libmysqlclient_r.so.TMP to /usr/lib/libmysqlclient_r.so Moving /usr/lib/libmysqlclient_r.so.15 to /usr/lib/libmysqlclient_r.so.15.TMP Linking /usr/lib/libmysqlclient_r.so.15.TMP to /usr/lib/libmysqlclient_r.so.15 Moving /usr/lib/libmysqlclient_r.so.15.0 to /usr/lib/libmysqlclient_r.so.15.0.TMP Linking /usr/lib/libmysqlclient_r.so.15.0.TMP to /usr/lib/libmysqlclient_r.so.15.0 Moving /usr/lib/libmysqlclient_r.so.15.0.0 to /usr/lib/libmysqlclient_r.so.15.0.0.TMP Linking /usr/lib/libmysqlclient_r.so.15.0.0.TMP to /usr/lib/libmysqlclient_r.so.15.0.0 Moving /usr/lib/mysql to /usr/lib/mysql.TMP Linking /usr/lib/mysql.TMP to /usr/lib/mysql Moving /usr/lib/mysql-500 to /usr/lib/mysql-500.TMP Linking /usr/lib/mysql-500.TMP to /usr/lib/mysql-500
Also another problem I had was that because I had bin logging commented out in my.cnf like this: # log-bin I was getting the following error when dumping: mysqldump: Error: Binlogging on server not active This was due to the inclusion of the --master-data option. Once I took that out it worked fine. Something for you to consider.
vivo, chriswhite, comments?
Also, the UTF-8 conversion guide for the dump file arrives a little too late. It is stated after it has been fed back into mysql so as I was following the guide sequentially I would have had to do that and refeed the file back in. It'd be nice if the user was reminded of that prior to feeding. Btw, if I'm thinking in the wrong way about any of this please let me know.
#c0 , #c1 The slotted versions actually are those with revision (ending) "-r30". This guide cope the migration between wichever unslotted version an the slotted ones. you can upgrade from whichever version as a start. #c2 I disagree here, because it's better to have the simplyest code possible to cut and paste, however it can be explained better that we are moving files and symlink them. #c3 A comment should be added that if binary logs are disabled then "--master-data" should be changed in "--master-data=0". #c4 it's possible to state at the beginning of the charapter that the user s hould read it entirely before continue ?
Also take a look at Comment #8 of bug 121164, more than one user must fight with files not removed by portage ...
also answered to these answer during this time : Hi Francesco, I've seen a lot of users complain about the slotted migration since you went to bed. - 'eselect set mysql 1' - wrong command order - user error. = it is "eselect mysql set 1" - running the correct eselect command gets this strange output to stderr: 'find: mysql: No such file or directory'. I've got the strace output, but I can't find WHERE find is being called from. = fixed, app-admin/eselect-mysql-1.0.0-r1 - Same user as the last item, the /etc/mysql and /etc/init.d/mysql-500 symlinks were NOT created. = fixed, app-admin/eselect-mysql-1.0.0-r1 - If the service name is /etc/init.d/mysql-$VER, please make it look in /etc/mysql-$VER/ for it's configuration by default, instead of /etc/mysql/. = mysql installed files already do this, if you have a previous /etc/mysql directory eselect-mysql can't symlink /etc/mysql-500 to /etc/mysql, rename /etc/mysql to something else and run "eselect mysql set 1 " again . - Error that shows up in building: ... Unpacking mysql-4.1.16.tar.gz to /t/portage/mysql-4.1.16-r30/work Unpacking mysql-extras-20060115.tar.bz2 to /t/portage/mysql-4.1.16-r30/work /usr/portage/eclass/mysql_fx.eclass: line 57: local: `,': not a valid identifier * using "010_all_slot-my-print-default-r1.patch" ... = NEED MORE INFO Another two. - innodb seems to act weird, because of this stuff #GENTOO#innodb_buffer_pool_size = 16M As the defaults that are actually used because of the commenting don't match the current settings. fixed, INCVS, to avoid reinstall edit the /etc/mysql-500/my.cnf and remove every occurence of "#GENTOO#" string. - User has a 60Gb MySQL database . They arranged 60Gb of space to try and make the dump into, but even as mysqldump | bzip2 -9 >file.bz2, it didn't fit into the 60Gb of space. How safe is moving the data directory? = This is because dump are ascii data, bigger than binary tables unless u have _huge_ indices. switching say from dev-db/mysql-5.0.18 to dev-db/mysql-5.0.18-r30 is _totally_ safe do one of these two things: a) stop the databases, then _move_ the data from /var/lib/mysql to /var/lib/mysql-500 or b) change "datadir" value in "/etc/mysql-500/my.cnf to" "/var/lib/mysql"
Created attachment 78664 [details, diff] mysql-upgrade-slotted.xml.patch Comment added. Regarding the first point, well, it's hard to state any more clearly that users should obviously upgrade their existing versions of mysql, whatever those may be. Re: #2: I agree with vivo; the bash example is easy to read. Its purpose is fairly obvious. Re: #3: Comment added to the doc, as requested. Re: #4: I don't see a need for such an explicit warning. I think we generally assume that readers don't blindly follow guides without modification or reading ahead at least a few sentences (if not a paragraph!). Otherwise, we would probably have to add such notes to every single doc in the repository. As it is, I think the existing <note>s etc. are sufficient. In regards to the link to bug #121164, I'll wait before adding anything to the doc. I need confirmation from the mysql experts (ChrisWhite or anyone else can jump right in here).
When Franceso and Jack responded to #c4 did they actually mean #c5? Anyway, what I am saying regarding that is that the least that can be expected of a step by step document is that it is sequential regardless of how the user is reading it or how the user is expected to read it. Even if it is a small sentence that says above the command "Please read note below before proceeding". When I write how-to's I always make the steps sequential and if a particular step is less important or applicable in only some situations I will still make it a step but label it as optional. If you think it is unnecessary then I will accept it but I thought I'd make it clear what I meant. Thanks.
I had to change this: # mysql-500 --defaults-file=/etc/mysql-500/my.cnf < BACKUP_MYSQL_4.0.SQL to # mysql-500 --defaults-file=/etc/mysql-500/my.cnf --socket=/tmp/mysqld.sock < BACKUP_MYSQL_4.0.SQL or it gave me an error about not being able to locate /var/run/mysql/mysqld-500.sock
Created attachment 78707 [details, diff] mysql-upgrade-slotted.xml-2.1-2.2.patch patch for comment 11, I've forgot this in the moment of adding the "socket" option to the configuration file
Hi, today I did emerge -u world and my mysql-5.0.18 got not upgraded, but per "emerge -up" output emerge claimed it installs new package mysql-5.0.18-r30. This went through so now I have two versions. My question is. How can I have only one mysql version (the default user choice I guess). Do I have have to set some extra flag? In the meantime I have realized the http://www.gentoo.org/doc/en/mysql-upgrade-slotted.xml document. I think emerge should warn user more if it is going to silently install yet another version of the same package. But, thanks anyway, will proceed further as per the docs and move the directory with data to teh new location and edit the config file.
I suggest the following two fixes to the config file. -#log = /tmp/mysqld.sql +log = /var/log/mysql-500/mysqld.log # I believe large tmp files are more xpected to be placed under the /var path, # which is typically on another disk and not in the root filesystem (which be # mostly for read-only disk IO and is often tuned for that in kernel) # /var is expected to be for many RW operations, sometimes small files, # sometimes huge, but definitely a lot of data is expected to be housed in there -tmpdir = /tmp/ +tmpdir = /var/tmp/ Personally I also increase the max_allowed_packet to 1G because 16M is often not enough here and the actual size is always allocated as necessary so it is not convenient to have this value low. Yes, it only protects the server from sending too much data to the client who has already aborted the connection, if I remeber right.
After reading also comment in bug #121152 I could add that the following show what happened for me automatically: Only these two files were left after I unmerged the 5.0.18 version: etc/mysql: total 20 -rw-r--r-- 1 root root 4196 Jan 22 20:24 my.cnf -rw-r--r-- 1 root root 1702 Jan 5 17:34 mysqlaccess.conf # eselect mysql list Available MySQL versions: [1] 5.0.x # eselect mysql show Current default MySQL version: (unset) # After moving the datadir to the new location, and "rm -rf /etc/mysql" I get: # /etc/init.d/mysql start * Caching service dependencies ... [ ok ] * ... * working on 0 * Cannot access /etc/mysql/my.cnf ! * MySQL datadir is empty or invalid * Please check your my.cnf : [ !! ] # I propose to improve the init.d script to die when "eselect mysql show" does not return valied version number and pointing the user to run "eselect mysql set 1". Or even better, running it automagially, mot users will have only one version when they hit the "(unset)" issue, right?
(In reply to comment #13) > Hi, > today I did emerge -u world and my mysql-5.0.18 got not upgraded, but per > "emerge -up" output emerge claimed it installs new package mysql-5.0.18-r30. > This went through so now I have two versions. > > My question is. How can I have only one mysql version (the default user > choice I guess). "Code Listing 4.3: Cleanup the old version" of the doc >Do I have have to set some extra flag? In the meantime I have no need of extra flags > realized the http://www.gentoo.org/doc/en/mysql-upgrade-slotted.xml document. > I think emerge should warn user more if it is going to silently install yet > another version of the same package. > But, thanks anyway, will proceed further as per the docs and move the directory > with data to teh new location and edit the config file. > This is done for many packages already, apache, gcc, php and others, the difference here is that we are installing _exactly_ two of the same version. This is so an exeptional case that we can't ask to portage to cover this, and it's done hopefully only one time in the life of a package, when it migrate from a un-slotted version to a slotted one. May be know how this work could explain it more. every ebuild define a variable called SLOT, for packages that don't support different installed versions the value for this variable is "0". When a package can have multiple versions the value of this variable assumes different values, generally related to the version string (in the case of mysql it's a decimal number formed by mayor and minor ver. i.e. 401=4.1.x 500=5.0.x) this mean that 5.0.17 and 5.0.18 will have the same value for slot (500) and will never get installed toghether. The problem now is that until the present all mysql has been marked with SLOT=0 this because we _cannot_ install 4.1 and 5.0 toghether without modifing a bit the install procedure. During this migration phase an unslotted and a slotted version can wrongly coexist in the same box this is why the migration document exist. A backward change of the slot for already installed mysql _is_ possible but can potentially broke the systems in a much worst manner, because of the paths of installed files are overlapping, so this has not a chance. Regarding the way to inform the users about the change, I've done GWN, forum, user, server, dev maillist, and warnings from the ebuild, and at the moment of writing I can't see a way to reach a bigger number of users.
(In reply to comment #14) > I suggest the following two fixes to the config file. > > -#log = /tmp/mysqld.sql > +log = /var/log/mysql-500/mysqld.log Be warned this log file is a plain text SQL log file, to be used only for _debugging_, deprecated from MySQL ab and will be removed in future versions. There is another binary log format file, enabled by default but used mainly for replication, this has place in "datadir" as per upstream default. > > # I believe large tmp files are more xpected to be placed under the /var path, > # which is typically on another disk and not in the root filesystem (which be > # mostly for read-only disk IO and is often tuned for that in kernel) > # /var is expected to be for many RW operations, sometimes small files, > # sometimes huge, but definitely a lot of data is expected to be housed in > there > -tmpdir = /tmp/ > +tmpdir = /var/tmp/ > There is also a difference on how this directoryes are cleaned from most sysadmins, tmpdir is not widely used by MySQL, but this argument need to be analized in more dept, I'll do it > > Personally I also increase the max_allowed_packet to 1G because 16M is often > not enough here and the actual size is always allocated as necessary so it is > not convenient to have this value low. Yes, it only protects the server from > sending too much data to the client who has already aborted the connection, if > I remeber right. Most system could not support 1Gb of packet size, the memory is allocated, and our defaults need to be used on most desktops. max_allowed_packet limit the size of an insert query, i.e. if you do insert of a single row it limit you to insert row with a size of 16 Mb that is enough on most installation, how many people store blobs >= 16 Mb in a database ?
(In reply to comment #15) > After reading also comment in bug #121152 I could add that the following show > what happened for me automatically: > > Only these two files were left after I unmerged the 5.0.18 version: > etc/mysql: > total 20 > -rw-r--r-- 1 root root 4196 Jan 22 20:24 my.cnf > -rw-r--r-- 1 root root 1702 Jan 5 17:34 mysqlaccess.conf Beacuse this files are CONFIG_PROTECTed, an unmerge could not touch them, you need to run again "eselect mysql set 1" after manually a manual (backup and) remove. [snip] > # > > I propose to improve the init.d script to die when "eselect mysql show" does > not return valied version number and pointing the user to run "eselect mysql > set 1". Or even better, running it automagially, mot users will have only one > version when they hit the "(unset)" issue, right? > midly, the start script could work also without /etc/mysql/my.cnf if /etc/mysql-500/my.cnf exist, to achieve this however you need to edit /etc/conf.d/mysql file to have a variable mysql_slot_500=( ) .
(In reply to comment #14 and #17) The max_allowed_packet does not mean mysql will allocate such memory. It only says what is the allowed maximum. A lot of people using genomic data hit this problem, as seen in bugs filed at mysql.com, etc. I don't mind you leaving it at 1M, 16M was the max value allowed in some 5.0.2 but even that was buggy. Lots of programs still do not get even the 16M barrier right. (In reply to comment #15 and #18) Per the /etc/mysql/ issue ... I just wanted to confirm in my case no files were adversely left in the filesystem, like in the previous case of another user. In summary, thanks for all your effort on this.
Created attachment 79011 [details, diff] mysql-upgrade-slotted.xml.patch Same patch as before, but now reflects the doc which has changed since the patch was first submitted.
(In reply to comment #20) > > Same patch as before, but now reflects the doc which has changed since the > patch was first submitted. > looks good to me
060208 21:54:18 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQ L server acts as a master and has his hostname changed!! Please use '--log-bin=vrapenec-bin' to avoid this problem. Please replace "log-bin" in my.cnf template with "log-bin-index". The best would be according to the above to use "log-bin=$hostname" but haven't tried that. "log-bin-index" works for me.
(In reply to comment #21) > looks good to me In CVS. What about the above comment? vivo, any additional changes that need to be made?
slotted mysql has been moved out of the tree.
Francesco, please fix/improve the /etc/mysql/my.cnf file as proposed throughout this bugreport before closing this. Not all issues raised here are solved. Do we really have to fire another bugreport, which will remain in bugzilla for months?
