'finaly' we experts care to disagree on a matter,
but really i have worked with cloud solutions wmware and others. some with better features for this and some with better features for that. so please lets not get in to that to much.
the fact of the matter is that running virtualisation of one particular node, just to make that single node fail-over-able (is that a correct word?) could be called in general 'bad practic' or at least a dirty hack to fix a problem that shouldn't be there.
i admit that i haven't spent a lot of time reviewing your code yet, since i havent had the time to ask a programmer of mine to help me with that.
so i cant 'at this point' tell you how mutch code could or should be altered / edited / or updated to implement this ' fix'
so at this point i want this to be absolutely clear;
If i say and think that with the help of some proper prammers / coders i might be able to 'fix' this 'problem' and the licence of this product permits it (wasn't it bsd?) - than i will, if it suites me or the comunity, try to do so.
- But it is not an attack on you, or your programming skills, it is not an atack on your judgement, it is an attempt to implement a feature and givving it back to a community that grants us use of great software.
So please dont tell me what cannot or will not be done
(unless the licence forbids it), because if someone 'at some point' may offer to implement it, it will not just save you a lot of work, or save you the recources spent un running virtualisation, it wil also ad a greate restore mechanism to your 'multi-server setups'
now to get beck on topic...
i never said that there are going to be 2 master servers. i said that there would going to be an 'enslaved' masters server. feel free to look up what master/slave means in the IT-dictionairy. - basicly it means that it could be a master server, but it is traped by its own master. it will do the exact same thing as its master does, at the exact (or nearly exact) same time. up until the point where its master dies, and it can 'automaticly' take over because its allready in sync.
webserver a b and c ar part of a mutli server setup where a is the master b is its enslaved replica and c is all the other servers...
now server a fails dies explodes or is relaced by a tech.
b will automaticly 'discover' that server a is no longer there and it will than (via the remote api telll all the c servers, that it is now there new master.. and thus that they should stop querying server a for commands but ask it (b) instead.
there you have it - your network is now fault-tolerant...
now lets say that you buy a new server d to replace server a.
step one: enslave server d to b (as b is now the master).
step two: when in sync either disable b, or tell it to revert back to slave mode - now there is no more b so d will kick in, it tells all your c servers that IT now is thair new king and ruler.
here you go, these might be the first steps in documentation about a feature that may be implemented in the near future by you or maybe some other weard guy that like to share great software with:
Last edited by i-chat; 19th April 2011 at 13:38.