Bug #45033 Mention skip slave when trigger/routines needs re-creation replication upgrade
Submitted: 22 May 2009 11:14 Modified: 6 Oct 2009 18:20
Reporter: Susanne Ebrecht Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Documentation Severity:S4 (Feature request)
Version:5.1 OS:Any
Assigned to: Paul DuBois CPU Architecture:Any

[22 May 2009 11:14] Susanne Ebrecht 
Description:
http://dev.mysql.com/doc/refman/5.1/en/replication-upgrade.html

It is clearly said here that you should first upgrade slave and then the master.

Consider, in a productive system, the master will run during upgrading the slave.

Customer mentioned here that would be nice to add the following to the documentation:

"As it may be necessary to drop and recreate triggers and stored routines during the upgrade it is IMPERATIVE when you start a slave to disable replication to ensure that no triggers are missed. This is done using the --skip-start-slave from the command line or skip_start_slave option in the server's my.cnf. Only once the upgrade is complete can you remove these options to ensure that replication continues normally with the new upgraded 5.1 instance."

How to repeat:
Read http://dev.mysql.com/doc/refman/5.1/en/replication-upgrade.html

Suggested fix:
see above
[6 Oct 2009 18:20] Paul DuBois 
Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant products.

Add this:

   Some upgrades may require that you drop and re-create
   database objects when you move from one MySQL series to the
   next. For example, collation changes might require that table
   indexes be rebuilt. Such operations, if necessary, will be
   detailed at Section 2.4.1.1, "Upgrading from MySQL 5.0 to
   5.1." It is safest to perform these operations separately on
   the slaves and the master, and to disable replication of
   these operations from the master to the slave. To achieve
   this, use the following procedure:
   
    1. Stop all the slaves and upgrade them. Restart them with
       the --skip-slave-start option so that they do not connect
       to the master. Perform any table repair or rebuilding
       operations needed to re-create database objects (such as
       use of REPAIR TABLE or ALTER TABLE, or dumping and
       reloading tables or triggers).

    2. Stop the master and restart it without the --log-bin
       option to disable the binary log. You should also
       disallow client connections. For example, if all clients
       connect via TCP/IP, start the server with
       --skip-networking.

       Perform any table repair or rebuilding operations needed
       to re-create database objects. (The reason that the
       binary log should be disabled during this step is so that
       these operations are not recorded in the log and sent to
       the slaves later.)

    3. Restart the server with --log-bin to enable the binary
       log and without --skip-networking so that clients and
       slaves can connect.

    4. Restart the slaves, this time without the
       --skip-slave-start option.