List:General Discussion« Previous MessageNext Message »
From:Lawrence Sorrillo Date:January 12 2010 6:36pm
Subject:Re: upgrading mysql
View as plain text  
Hi:

I want to ensure that right after the reload that the same data is 
present in both the master and the slave. They are in perfect sync. Then 
I think its safe to consider starting binary logging and replication 
etc. And after these are started, changes can start?

And in setting up replication in this manner I would not use the CHANGE 
MASTER... I will just

master-host=xxx.xxx.xxx.xxx
master-connect-retry=60
master-user=auser
master-password=apassword

in the my.cnf file and restart the slave server. From there it should 
start reading the binary logs and committing changes properly.

Is this correct?

~Lawrence


Shawn Green wrote:
> Lawrence Sorrillo 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.
>
> ok
>
>> 2. Ensure that replication on the slave is caught up to the last 
>> change on the master.
>
> why? You are just going to replace it later.
>
>> 3. stop binary logging on the master.
>
> why? You can just disconnect the slave
>
>
>> 4. stop replication on the slave.
>
> You can do this at step 2. Just issue STOP SLAVE IO_THREAD;  The SQL 
> thread can keep moving along.
>
>> 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)
>
> Yes. No need to create binary logs for the rebuild.
>
>> 6. dump the slave, stop old 4.1 server, start new 5.1 server and 
>> reload slave dump file under 5.1 server.
>
> There is a faster way.
>
>> 7. After loading is complete, test then start binary logging on 
>> master while still preventing updates to updates.
>
> Once you have QA-ed your new 5.1 master, you can shut it down then 
> copy the entire image (binaries and all) directly to the slave 
> machine.  This is much faster than rebuilding from a dump and it 
> ensures that you have identical data to start replication with.
>
> After the copy, then restart the master with binary logging.
>
>
>> 8. After loading slave, test then start slave (get configs in place 
>> and restart server).
>>
>
> Yes, it's always good to test any server image before putting it online.
>
> The CHANGE MASTER TO command to use for the slave will be at position 
> 4 of the first binary log created after the binary image was captured.
>
>
>> 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.
>
> You are correct. Because you are re-imaging your slave from your 
> master, there is no need to track binary log or relay log positions.
>
> See also:
> http://dev.mysql.com/doc/refman/5.1/en/replication-howto-rawdata.html
>
> ** SAFETY ADVICE ** - always ensure you have a clean binary backup of 
> any server you want to perform major maintenance to. In the off-chance 
> that something does happen to go wrong, you will have it available for 
> the fastest possible restore-to-original-state
>



Thread
upgrading mysqlLawrence Sorrillo12 Jan
  • Re: upgrading mysqlTom Worster12 Jan
    • RE: upgrading mysqlJoshua Gordon12 Jan
    • Re: upgrading mysqlLawrence Sorrillo12 Jan
      • Re: upgrading mysqlTom Worster12 Jan
        • Re: upgrading mysqlSuresh Kuna13 Jan
        • Re: upgrading mysqlLawrence Sorrillo13 Jan
          • Re: upgrading mysqlfsb13 Jan
          • Re: upgrading mysqlPaul DuBois14 Jan
  • Re: upgrading mysqlShawn Green12 Jan
    • Re: upgrading mysqlLawrence Sorrillo12 Jan
      • Re: upgrading mysqlPaul DuBois12 Jan
  • file per table performanceBryan Cantwell12 Jan
    • Re: file per table performanceJohnny Withers12 Jan