<div dir="ltr"><font face="verdana, sans-serif" color="#000000">Hi Stefan,</font><div><font face="verdana, sans-serif" color="#000000"><br></font></div><div><font face="verdana, sans-serif" color="#000000">Good question, but never encountered such issue in 3 months, I use a dedicated private network for Mysql and One which is 172.x.x.x. so my storage, Kvm nodes and all communicate with 172.x.x.x network. I have another lan network in 10.x.x.x series which is only used to access sunstone and used for VM lan network.</font></div>
<div><font face="verdana, sans-serif" color="#000000"><br></font></div><div><font face="verdana, sans-serif"><font color="#000000">I know MySQL replication is the most flexible way to deal with scalability. If not done right, how</font><span style="color:rgb(0,0,0)">ever, replication can result in disaster.</span></font></div>
<p style="color:rgb(0,0,0)"><span class=""><font face="verdana, sans-serif">The most common problem with replication is <i>primary key collision</i>. Primary key collision involves two MySQL servers creating table rows containing different data, but the same primary key. When this happens replication stops. With replication stopped, the difference between the data on the servers grows. At some point the weirdness gets noticed. Then begins the painful process of recovery, of trying to weave masses of conflicting data into a whole.</font></span></p>
<p><span class=""><font face="verdana, sans-serif"><font color="#000000">You can overcome this issue by adding the below in mysql config files while configuring M/M replication</font></font></span></p><p><font color="#000000" face="verdana, sans-serif">Mysql Server A Config file</font></p>
<p><span style="color:rgb(0,0,0);font-family:verdana,sans-serif">auto-increment-increment = 2</span><br></p><p><font color="#000000" face="verdana, sans-serif">auto-increment-offset = 1</font></p><p><span style="color:rgb(0,0,0);font-family:verdana,sans-serif"><br>
</span></p><p><span style="color:rgb(0,0,0);font-family:verdana,sans-serif">Mysql Server B Config file</span><br></p><p><font color="#000000" face="verdana, sans-serif">auto-increment-increment = 2</font></p><p><span style="color:rgb(0,0,0);font-family:verdana,sans-serif">auto-increment-offset = 2</span></p>
<p style="color:rgb(0,0,0)"><span class=""><font face="verdana, sans-serif">This situation happens when you use M/M database simultaneously to write data on both the servers, However in my setup, though it is M/M replication and both Mysql are in Active/Active mode the write only happens on Server A unless the fail-over is triggered and services like One and sunstone starts on Server B with virtual ip up on server B.</font></span></p>
<p style="color:rgb(0,0,0)"><font face="verdana, sans-serif">So even if the communication between Mysql is stopped the fail-over will not triggered as it is configured on 10.x.x.x ip and not 172.x.x.x and server A will still be the master and once the communication are up it will sync the data with server B without any data collision.</font></p>
<p><font face="verdana, sans-serif"><font color="#000000">The fail-over process is automatic, Ucarp on server B sends keepalive request to Server A and when it finds the eth0 and virtual IP down on server A the script (vip-up.sh) is executed on server B and assigns virtual IP to it then starts the one and sunstone services. </font></font></p>
<p style="color:rgb(0,0,0)"><font face="verdana, sans-serif">The fail-back also happens in same way but in reverse order, it stops the services and then removes the IP from server B and assigns it to server. Fail-back executes vip-down.sh script.</font></p>
<p style="color:rgb(0,0,0)"><font face="verdana, sans-serif">If you have any questions you can get back to me :)</font></p><p style="color:rgb(0,0,0)"><font face="verdana, sans-serif">Thanks and Regards</font></p><p style="color:rgb(0,0,0)">
<font face="verdana, sans-serif">Kiran Ranjane </font></p><p style="color:rgb(0,0,0);font-family:'Times New Roman';font-size:medium"><span class="" style="font-family:'Arial Rounded',Helvetica,Arial,sans-serif;font-size:1em"><br>
</span></p></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 31, 2014 at 12:59 PM, Stefan Kooman <span dir="ltr"><<a href="mailto:stefan@bit.nl" target="_blank">stefan@bit.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Quoting kiran ranjane (<a href="mailto:kiran.ranjane@gmail.com">kiran.ranjane@gmail.com</a>):<br>
<br>
> I have tested this and it works well. I get only 3 to 4 timeout request<br>
> when fail-over is triggered so this is quite instant and simple to<br>
> troubleshoot in-case of issues, No split brain as M/M replication is used<br>
> and both the database and always in sync, Mostly all the sync is from one<br>
> side Server A to B because server A is the master node and services are<br>
> running on one server at a time. Services on Server B starts only after<br>
> fail-over is triggered so the syncing of data from B to A is always less<br>
> because it is used as standby cloud storage server.<br>
<br>
</div>You state "No split brain as M/M replication is used ...". But what if<br>
communication between server A and B is lost? Server A becomes master<br>
and starts one. Server B becomes master and starts one. They both update<br>
the one database, but replication is not (yet) happening because no<br>
communication is possible so no issue yet. After communication is<br>
restored replication continues, and this might work without errors<br>
(although I have my doubts about that). One master node (B) will proably<br>
shuts itself down. Master A continues to run. I wonder how healthy the<br>
one database is after such an incident. Do you do manual fail-overs or<br>
automatic ones?<br>
<br>
Gr. Stefan<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
| BIT BV <a href="http://www.bit.nl/" target="_blank">http://www.bit.nl/</a> Kamer van Koophandel 09090351<br>
| GPG: 0xD14839C6 +31 318 648 688 / <a href="mailto:info@bit.nl">info@bit.nl</a><br>
</font></span></blockquote></div><br></div>