[lvs-users] maintenance on fallback node

[support at remsnet.de]

Hello Oscar,

NATIVE LVS don't understand sql at all - tcp/stcp/udp only.

Any sql checks on Layer 7  must be handeld by i.e ldirectord , keepalived , pen  via scripting.


ldirectord mysql Cluster sample  solutions:

Replicated  - http://clusterlabs.org/wiki/Load_Balanced_MySQL_Replicated_Cluster

mysql NDB cluster -  see i.e at  https://www.howtoforge.com/setting-up-a-loadbalanced-mysql-cluster-with-mysql5.1-p4

Galea HA  -  http://www.fromdual.com/unbreakable-mysql-cluster-with-galera-and-lvs

Myself  prefer to an Galea or NDB Setup due to more renundant and mo more hassel with replication issues ...

hope this helps.



--
Mit freundlichen Grüßen / Best Regards

Horst Venzke ; PGP NET : 1024G/082F2E6D ;  http://www.remsnet.de

Legal Notice: This transmittal and/or attachments may be privileged or confidential. It is intended solely for the addressee named above. Any review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you.


> Gesendet: Freitag, 10. April 2015 um 10:16 Uhr
> Von: "Oscar Salvador" <osalvador.vilardaga at gmail.com>
> An: lvs-users at linuxvirtualserver.org
> Betreff: [lvs-users] maintenance on fallback node
>
> Hi everybody!
> 
> I was testing some things with LVS, and some questions raised. Let me
> explain:
> 
> Imagine we have two mysql-servers(or whatever), and we want a setup
> Master-Spare.
> Then we have the following config:
> 
> ===================
> checktimeout=15
> checkinterval=1
> autoreload=no
> quiescent = no
> maintenancedir = /var/run/ldirectord-downed-hosts/
> 
> #mysql
> virtual=xx.xx.xx.xx:3306
>         real=xx.xx.xx.XY:3306 gate
>         fallback=xx.xx.xx.YX:3306 gate
>         service=mysql
>         login="monitoring"
>         passwd="password"
>         request="show status;"
>         scheduler=wlc
>         protocol=tcp
>         checktype=negotiate
> ===================
> 
> 
> So, when from some site I connect to xx.xx.xx.xx:3306, and when xx.xx.xx.XY
> becomes unavailable for some reason, real-server is deleted and
> fallback-server goes up.
> I can force that with a:
> touch /var/run/ldirectord-downed-hosts/xx.xx.xx.XY, then xx.xx.xx.YX comes
> up.
> 
> But now there is something I don't understand quite well.
> Imagine I'm doing some maintenance in the fallback node: xx.xx.xx.YX
> 
> I though that maybe just doing:
> 
> touch /var/run/ldirectord-downed-hosts/xx.xx.xx.YX
> 
> lvs would detect that the fallback-server is not accesible, so it only has
> the real-server.
> But then, if the real-servers goes down for some reason(just imagine a
> voluntary 'server mysql stop'), lvs will delete the real-server and put
> fallback-server in its side.
> But that is a problem from my point of view, because I do not want do mess
> with fallback-server while I'm doing some maintenance.
> 
> Actually the same aproach is like:
> 
> When xx.xx.xx.XY is alive:
> 
> TCP  xx.xx.xx.xx:3306 wlc
>   -> xx.xx.xx.XY:3306          Route   1      0          4
> 
> Then if we stop mysql from xx.xx.xx.XY, xx.xx.xx.YX becomes available :
> 
> TCP  xx.xx.xx.xx:3306 wlc
>   -> xx.xx.xx.YX:3306          Route   1      0          4
> 
> 
> But if I stop mysql from xx.xx.xx.YX, nothign is happening, lvs does not
> delete xx.xx.xx.YX from the server lists.
> 
> Maybe I'm doind something wrong?
> 
> thank you very much
> _______________________________________________
> Please read the documentation before posting - it's available at:
> http://www.linuxvirtualserver.org/
> 
> LinuxVirtualServer.org mailing list - lvs-users at LinuxVirtualServer.org
> Send requests to lvs-users-request at LinuxVirtualServer.org
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: addressbook.vcf
Type: text/x-vcard
Size: 1086 bytes
Desc: not available
Url : http://lists.graemef.net/pipermail/lvs-users/attachments/20150417/83d9536d/attachment.vcf