Hi everyone, I know this question is asked before but I want to realize some kind of failover in case of a servercrash, I did some research and testing already and noticed that most of the MySQL data is copied/mirrored to the second server. What I did till now: Install server 1 in normal mode Install server 2 in expert mode and setup the replication with server 1 The installation of server 2 is a full install, this means that I also installed the web interface Important: the testing is only done from the server 1 interface, as mentioned in the manual, normally there is only 1 management interface It all works fine and most of the data is mirrored on the 2nd server. The following parts are not replicated: CP Users - add user - edit user Monitor - System overview - CPU info Sites - Statistics Client - Template This is normal because this is done localy However, the goal is to create a perfect mirror which can run in no time when the primary (server 1) is down. To configure the mirror I installed the management console in case the first server is really dead and the webserver should be up in a short time The question: what are the things I have to pay notice to, are there part which can give problems and does anyone tried this before and have some idea's Please give some feedback, this week I will try to finish the combination and present some kind of manual (if it will work of course )
There is only 1 management interface, so the data you mentioned above is not mirrored to the slave. Entering the interface on the second server will break the replications, so do not install a interface on the second server.
Till, I'll try to make my questions more clear, I've read the manual and know that it is not the way it should be. However, the intension is to have some kind of "backup" CP and server, this one can not be used for managing the server(s), the management must be done from (and ONLY from) the primary (this last comment is for who want to try this anyway, it WILL break your server replication) When replicating the missing DB items to the secondary, is it possible to reconfigure the secondary and use this one to manage in case of a crash. There are situations that a server is really dead and it can't be repaired, in that case your management server is gone, what to do to re-establish the management server for managing the other server(s)? What I want to accomplish is creating a mirror combination, more like somekind of failover without using gluster, I've used it and when the servers are not physical on the same network (internet replication) it's "not done", the response can take 5 seconds of more and every change is a re-write of the MySQL DB. When the managementserver is down and for some reason must be rebuild, how can I re-establish the management console? I did read the forum(s) and manual, but I can't find a proper solution in case of a management server crash, maybe I missed something? Regards, Ronald
This is a one way replication, from master to slave. This implies that the slave can not be used as master. If you would change or add a single record on the slave, it would break the amster as there will be a ID conflict in the database then. So you can not use the slave as master server. When the amster is down, the salve will work without interruption, but you can not change the configuration trough the ispconfig interface until the master is up again.
i understand, i think what ncoc.nl whats should be considered i an other method. master / domain replications - should however be a feature that is high on the priority list. one if the easiest ways to do this would be to create a 3 steps plan. a > create a full confige backup + restore function for all master settings. b > create live full master / slaved master (note the name) replication. c > authority conversion / management. how: A> the backup part is fairly easy and doesn't require mutch explaination. B> this is what is discused in this topic ... C> this is the way how to make this actually work. (ill explain herunder) Case: you have a webhosting company with an ISPconfig cluster (or multiserver setup). with 1 master server. (single point of failure). now for any reason you maste server dies on you, i can be a routing issue, or a hardware failure on its side - or any other problem that might happen. what you want to do is to. get that server (service) up an running ASAP = T-0 (*TEN minutes ago). - In general Best Practice (tm) that would mean, 'running a failover' an exact coppy that could step in as soon as your router change the routing from %old internal ip% to %new internal ip% if anything would require you to change any functions, scripts locations or other, on the member servers to 'promote' the enslaved master to the real master state, this should be done by a single command protected by the master password send to each server via the remote api. i would dare saying that in 'the real webhosting world' this is wone of the highest profile feature requests, i have come accros in these forums. it could (and should) be advertised as one of THE most important new features for the release its implemented in... and a suggestion would be to make that the "next 'major' version (not just any bugfix release)" for tips trick, best practices and more, send me a pm, email or just find me on irc.freenode.net
I think I-chat make my point more clear, this is what i want to accomplish. Still working on it.... Regards, Ronald
@ncoc.nl - we may have simular interests, and i even though im not a programer or phpcoder - we migt want to get in touch, if your a member of Webhostingtalk (nl) - you might want to get in touch with me there - tip (tweakers.net lets you send email to me also) ill be seeing your mail and or dm on the wht forum soon - i hope..
This is nothing that needs any additional implementation or changes in ispconfig, as you use virtualisation for that. Simply run the ispconfig master as vm instance, this makes backups easy and offers all kind of failover functions. I use this setup on my systems for years now. As a "real webhsoter", you would run the master as dedicated system in a vm for security reasons anyway.
running a complet webserver (cluster) inside a vmware farm fixes this indead, but at the cost of quite a lot of resources - I know because i have done stuf like it before with vcenter and another operationg system, (but that doens't matter mutch) if it requires any patches to the code to create such a 'slaved master server' and/or to to upgrade a server to that role in a live setup. ill be happy to help, document and/or support the effort. whether this could be done by a virtualisation hack or not, isn't at all relevant in my book. nor should it be..
I'am not talking about vmware. VMware is a resource hog and not suitable for hosting services. For such a setup on a Linux servers you use software like OpenVZ which has nearly no computing overhead. You dont seem to understand the problems involved with that and why there can not be two masters. The problem is a general logical problem with unique ID's in clusters. If you have database (a) and database (b) and every database insert data, the the numerical ID's are unique for the database but will collide with the other database. So you can insert data only on one master at a time. There are several solutions for that, and all are related to the server setup without changes needed in ISPConfig. The most commonly used today is virtualisation. Another solution is to use mysql cluster as backend (see mysql homepage) instead of a single mysql database for the master server, so that you can install more then one frontend. Another alternative is to work with a mysql master-master replication between two interfece servers. As you see, thats all a question on how you configure your servers. Using virtualisation is the best way to do it and not a hack.
'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. example 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: apt/sources/universe
Would be great if you want to write such a new extension and share it with the community. But I'am not sure if its nescessary to reinvent the wheel for that. Mysql provides already functions for two or more master servers (master / master replication or mysql-cluster). For a hot standby system as you requested in your last post, you can use e.g. this: http://dev.mysql.com/doc/refman/5.0/en/ha-drbd.html http://dev.mysql.com/doc/refman/5.0/en/ha-heartbeat-drbd.html The ispconfig interface is basically a php/mysql "website". To get redundancy for the master server, you have to get redundancy of the master server mysql database. Instead of writing new mechanisms in ispconfig, you can configure mysql to be redundant and get as result a redundancy of the master server. So there are two options, either develop a new addon for ispconfig or use the exsiting mysql tools to configure the mysql database for redundancy.
