(mysql.info) upgrade

 
 2.10 Upgrading MySQL
 ====================

 
* upgrading-from-5-0           Upgrading from MySQL 5.0
* upgrading-from-4-1           Upgrading from MySQL 4.1 to 5.0
* upgrading-to-arch            Copying MySQL Databases to Another Machine
 
 As a general rule, we recommend that when upgrading from one release
 series to another, you should go to the next series rather than
 skipping a series. For example, if you currently are running MySQL 3.23
 and wish to upgrade to a newer series, upgrade to MySQL 4.0 rather than
 to 4.1 or 5.0.
 
 The following items form a checklist of things that you should do
 whenever you perform an upgrade:
 
    * Before upgrading from MySQL 4.1 to 5.0, read 
      upgrading-from-4-1) as well as  news. These provide
      information about features that are new in MySQL 5.0 or differ
      from those found in MySQL 4.1. If you wish to upgrade from a
      release series previous to MySQL 4.1, you should upgrade to each
      successive release series in turn until you have reached MySQL
      4.1, and then proceed with the upgrade to MySQL 5.0. For
      information on upgrading from MySQL 4.1 or earlier releases, see
      the `MySQL 3.23, 4.0, 4.1 Reference Manual'.
 
    * Before you perform an upgrade, back up your databases, including
      the `mysql' database that contains the grant tables.
 
    * Some releases of MySQL introduce incompatible changes to tables.
      (Our aim is to avoid these changes, but occasionally they are
      necessary to correct problems that would be worse than an
      incompatibility between releases.) Some releases of MySQL
      introduce changes to the structure of the grant tables to add new
      privileges or features.
 
      To avoid problems due to such changes, after you upgrade to a new
      version of MySQL, you should check your tables (and repair them if
      necessary), and update your grant tables to make sure that they
      have the current structure so that you can take advantage of any
      new capabilities. See  mysql-upgrade.
 
    * If you are running MySQL Server on Windows, see 
      windows-upgrading.
 
    * If you are using replication, see  replication-upgrade, for
      information on upgrading your replication setup.
 
    * If you previously installed a MySQL-Max distribution that includes
      a server named `mysqld-max', and then upgrade later to a non-Max
      version of MySQL, `mysqld_safe' still attempts to run the old
      `mysqld-max' server. If you perform such an upgrade, you should
      remove the old `mysqld-max' server manually to ensure that
      `mysqld_safe' runs the new `mysqld' server.
 
 You can always move the MySQL format files and data files between
 different versions on the same architecture as long as you stay within
 versions for the same release series of MySQL. If you change the
 character set when running MySQL, you must run `myisamchk -r -q
 --set-collation=COLLATION_NAME' on all `MyISAM' tables. Otherwise, your
 indexes may not be ordered correctly, because changing the character set
 may also change the sort order.
 
 If you are cautious about using new versions, you can always rename
 your old `mysqld' before installing a newer one. For example, if you
 are using MySQL 4.1.13 and want to upgrade to 5.0.10, rename your
 current server from `mysqld' to `mysqld-4.1.13'. If your new `mysqld'
 then does something unexpected, you can simply shut it down and restart
 with your old `mysqld'.
 
 If, after an upgrade, you experience problems with recompiled client
 programs, such as `Commands out of sync' or unexpected core dumps, you
 probably have used old header or library files when compiling your
 programs. In this case, you should check the date for your `mysql.h'
 file and `libmysqlclient.a' library to verify that they are from the
 new MySQL distribution. If not, recompile your programs with the new
 headers and libraries.
 
 If problems occur, such as that the new `mysqld' server does not start
 or that you cannot connect without a password, verify that you do not
 have an old `my.cnf' file from your previous installation.  You can
 check this with the -print-defaults option (for example, `mysqld
 --print-defaults').  If this command displays anything other than the
 program name, you have an active `my.cnf' file that affects server or
 client operation.
 
 It is a good idea to rebuild and reinstall the Perl `DBD::mysql' module
 whenever you install a new release of MySQL. The same applies to other
 MySQL interfaces as well, such as the PHP `mysql' extension and the
 Python `MySQLdb' module.

Info Catalog

(mysql.info) post-installation

(mysql.info) installing

(mysql.info) downgrading

automatically generated byinfo2html

(mysql.info) upgrade

Menu