Frankly, I didn't entirely understand what you were proposing. I got lost around step 6.
Is the issue total time for the procedure or service downtime? On 1/12/10 12:58 PM, "Lawrence Sorrillo" <sorri...@jlab.org> wrote: > This is two upgrades done in sequence(the reload takes about three hours > per machine) . I can do what I am proposing in parallel. > > Do you see it as problematic? > > ~Lawrence > > > Tom Worster wrote: >> How about: >> >> 1 shut down the slave, upgrade it, restart it, let it catch up. >> >> 2 shut down the master, upgrade it, restart it, let the slave catch up. >> >> ? >> >> >> >> >> >> On 1/12/10 12:34 PM, "Lawrence Sorrillo" <sorri...@jlab.org> wrote: >> >> >>> Hi: >>> >>> I want to upgrade a master and slave server from mysql 4.1 to mysql 5.1. >>> >>> I want to so something like follows: >>> >>> 1. Stop all write access to the master server. >>> 2. Ensure that replication on the slave is caught up to the last change >>> on the master. >>> 3. stop binary logging on the master. >>> 4. stop replication on the slave. >>> 5. dump the master, stop old 4.1 server, start new 5.1 server and reload >>> master dump file under 5.1 server ( binary logging is turned off) >>> 6. dump the slave, stop old 4.1 server, start new 5.1 server and reload >>> slave dump file under 5.1 server. >>> 7. After loading is complete, test then start binary logging on master >>> while still preventing updates to updates. >>> 8. After loading slave, test then start slave (get configs in place and >>> restart server). >>> >>> I am thinking that in this scenario I dont have to bother with recording >>> binlog file names and position etc etc. >>> That both servers will have the same databases abd replication and >>> binary logging will start on the two databases with no data loss and >>> continue forward. >>> >>> >>> Comments? >>> >>> ~Lawrence >>> >>> >>> >>> >> >> >> > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
