Re: do i need to set up mysql cluster for mysql-ha to work?

Thanks. It's a good hint. We can not stop db service on production
site, so sync'ing 'old master' becomes a chanllege to us. Here is what
i am going to do:

- Promote slave:

1. stop replication on 'old slave'.
2. transfer cluster ip to 'old slave', 'old slave' becomes 'new
master', getting client updates.

[ this is the time we fix the 'old master'...]

- Integrate 'old master' back:

3. Stop all updates on 'new master'
4. Configure 'old master' as 'new slave', start replication on 'new slave'
5. When sync is done, stop replication on 'new slave'
6. Transfer cluster ip to 'new slave'/'old master', getting client new
updates on 'old master'
7. Configure 'new master' back as 'old slave', start replication.

Here is my questions:

How do i make step 4 as fast as possble? I want the 'new slave'
catching up with 'new master' in a very short time.

How do I know 'new slave' is already sync'ed with 'new master'?, i.e.,
'new slave' gets all updates it's missed.

Thanks very much!

--xinhuan

On Fri, 25 Mar 2005 01:41:05 -0200, Fernando Ipar
<[email protected]> wrote:
>  You're right, LOAD DATA FROM MASTER works just for MyISAM, but the innodb
> snapshot will work just as fine. 
>  In fact, the 'high level' algorithm would be: 
>  - stop data modifying queries on the slave (by issuing a lock, stopping the
> service, whatever)
>  - synch the fixed master with the slave ('load data..', 'ibbackup',
> 'tar',...)
>  - make sure the MASTER_LOG_FILE and MASTER_LOG_POS values are correct. I
> write this on bold, since LOAD DATA FROM MASTER
>  takes care of this automatically, but if you do a backup on your own, these
> values will be outdated
>  - reconfigure the master/slave relationship
>  - restart the service
>  
>  I would be interested in providing different methods to synch back to a
> 'fixed master', according to the configuration (mysql version, table
> handler, ...), so if you get this working with ibbackup and you'd like to
> share those scripts, they'll be welcome :). 
> 
>  
>      Regards, 
>      Fernando. 
>  
>  Xinhuan Zheng wrote: 
>  Thanks for explaination. So actually the failover is composed of 1) fake ip
> on slave and serve client requests 2) integrate master back. The step 1 is
> clear to me. The step 2 you said using 'load data from master'. That one
> just works for MyISAM. If i'm using InnoDB (mysql 4.1.10), i'm not sure if
> that works. Do i need to take innodb snapshot (we already have ibbackup tool
> installed) and sync the snapshot from slave to 'fixed master'? thanks again.
> --xinhuan On Wed, 23 Mar 2005 20:06:40 -0200, Fernando Ipar
> <[email protected]> wrote: 
>  Exactly. Right now, the script only handles the slave takeover when the
> master fails. I wasn't clear with the 'autimatic fixed master integration'
> thing :). By 'fixed master' I mean a replacement for the failed master that
> caused the slave to takeover (meaning that you solve whatever problem caused
> the master to fail, so it's now 'fixed'). By 'automatic integration' I mean
> having this server integrate back into the cluster and begin working again
> as master, automatically. However, using mysql >= 4.x, you can easily do
> this like this: (this is what's being scripted right now, and what will go
> into the next release after testing) - configure the fixed machine to work
> as slave to the 'new master' (the slave that did the takeover) - STOP THE
> 'new master'. This is important because we're going to update the original
> master with the changes that took place during the repair period, and we
> don't want any more changes to happen in the meantime. - do a LOAD DATA FROM
> MASTER on the fixed box - configure it as master - configure the slave again
> as slave to the fixed box - (hopefully) get it all working :) I'm sorry if
> my words were confusing, I have some trouble putting my ideas into text.
> Fortunately, it's easier to put them down as code ;). Regards, Fernando.
> Xinhuan Zheng wrote: what do you mean by automatic fixed master integration?
> I want to promote a slave automatically and later on when died master is
> fixed, let the master temporarily a slave to get all the updates. When this
> is done, switch master/slave back to their original role. The take_over.sh
> seems not having those functions, right? On Wed, 23 Mar 2005 16:57:14 -0200,
> Fernando Ipar <[email protected]> wrote: The takeover is invoked at
> slave_routine.sh, line 104. The takeover script just configures the cluster
> IP on the slave, so that new client requests are processed in this 'new'
> master (By the way, this means that, at the moment of a master failure,
> clients will experience problems like timeouts or connection errors. The
> lenght of this error period can be configured, using the SLAVE_SLEEP_TIME
> and SSH_PATIENCE parameters. You can read through the takeover.sh script if
> you want to know more about the takeover process. ARP spoofing is used in
> cases where the master won't release the cluster IP (there's a comment on
> slave_routine.sh briefly explaining one possible scenario for this). What we
> don't have now in the scripts is automatic integration of a fixed master.
> I'm working on this right now for a customer, and once the code is deemed
> stable, a new release will be ready. However, this method will only work
> automatically for MySQL versions 4.x or higher. Regards, Fernando. Xinhuan
> Zheng wrote: Good explaination. Now i understand how shared ip works. I have
> another question: it seems to me that the shared ip is taken over by slave,
> how does master and slave role get switched? In read world, I'd like to
> switch a died master to slave and promote a slave to a master temporarily
> and once master is fixed and get all updates from its slave, switch them
> back. I don't see all these in the scripts or probably I miss them. Can you
> please advise? thanks very much. --xinhuan -- ----------------------------
> Fernando Ipar - Director Seriema Systems Av. Italia 6201 601 3724 / 135
> www.seriema-systems.com -----------------------------
> ------------------------------------------------------- This SF.net email is
> sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May
> 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows
> Mobile(tm) platforms, applications & content. Register by 3/29 & save $300
> http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> _______________________________________________ mysql-ha-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mysql-ha-devel
> ------------------------------------------------------- This SF.net email is
> sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May
> 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows
> Mobile(tm) platforms, applications & content. Register by 3/29 & save $300
> http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> _______________________________________________ mysql-ha-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mysql-ha-devel --
> ---------------------------- Fernando Ipar - Director Seriema Systems Av.
> Italia 6201 601 3724 / 135 www.seriema-systems.com
> -----------------------------
> ------------------------------------------------------- This SF.net email is
> sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May
> 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows
> Mobile(tm) platforms, applications & content. Register by 3/29 & save $300
> http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> _______________________________________________ mysql-ha-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mysql-ha-devel
> ------------------------------------------------------- This SF.net email is
> sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May
> 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows
> Mobile(tm) platforms, applications & content. Register by 3/29 & save $300
> http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> _______________________________________________ mysql-ha-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mysql-ha-devel 
>  
>  -- ---------------------------- Fernando Ipar - Director Seriema Systems
> Av. Italia 6201 601 3724 / 135 www.seriema-systems.com
> -----------------------------
> ------------------------------------------------------- SF email is
> sponsored by - The IT Product Guide Read honest & candid reviews on hundreds
> of IT Products from real users. Discover which products truly live up to the
> hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________ mysql-ha-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mysql-ha-devel


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click