sk77github / mysql-master-ha

Automatically exported from code.google.com/p/mysql-master-ha
0 stars 0 forks source link

Question about data synchronisation between slaves when master server is fully dead #48

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I think about next situation:
there are 4 machines
m1 - current master
m2 - slave, candidate to master
m3 - slave, candidate to master
m4 - slave, cannot be master

They are using asynchronous replication.
When m1 will fully dead (poweroff for example), mha_manager starts do failover
one of step of failover is synchronisation of binlogs between slaves. Mha finds 
slave with newest replication position, download binlog from it and apply diffs 
to other slaves.

there is a chance that m4 will have the newest data.
Will mha copy binlog from m4 and aplly diffs to m2 and m3, if m4 is defined as 
"cannot be master"?
Or will mha compare logs only between m2 and m3?

Original issue reported on code.google.com by obric...@balakam.com on 20 Dec 2012 at 2:19

GoogleCodeExporter commented 8 years ago
and after applying data to m2 and m3, mha should make one of them master,  
shouldn't it?

Original comment by obric...@balakam.com on 20 Dec 2012 at 2:21

GoogleCodeExporter commented 8 years ago
> Will mha copy binlog from m4 and aplly diffs to m2 and m3, if m4 is defined 
as "cannot be master"?
> Or will mha compare logs only between m2 and m3?

MHA copies binlog from m4. If MHA compares only m2 and m3, you'll lose events 
in m4. This should never happen (unless m4 is down and marked as ignore_fail).
Hope this solves your concern.

> and after applying data to m2 and m3, mha should make one of them master,  
shouldn't it?

MHA tries to promote m4 if m2 and m3 delays replication significantly (default 
is 100MB worth of binlog events). If you do not want to promote m4, set 
"no_master=1" parameter in m4.

Original comment by Yoshinor...@gmail.com on 20 Dec 2012 at 8:13

GoogleCodeExporter commented 8 years ago

Original comment by Yoshinor...@gmail.com on 21 Dec 2012 at 1:38