We're all wrong... :) We're all wrong... Yes... Well first at all regradless of any programing language etc. there must be a service level agreement that states what that magical "high availabilty" really means. Usually, even in very critical systems there is reservation for short downtimes to do system upgrades. And then there must be ways to of course measure it...
It's just that you can't go around asking questions about "We have a setup in which we can't afford downtime (even while deployment)". It litterally reads that you don't do upgrades. Without having any more context of an application in question of course there are several techniques that can be made to smoothen out end user experience. Simplest way is to use redundant servers and hot plug mechanisms to be able to drop off servers to be upgraded. Basically it means that server can tell in advance that it's going offline from pool of servers thus being very graceful to end user. This still leaves huge problem with data(base) migrations and upgrades since making them atomic is not easy task - it basically requires graceful downtime. So making system really highly available you need setup something frontend loadbalancing proxy with hot plug capability and 2 application servers. And preferably all replicated to at least second set of hardware to make sure that site will be up at the all times. And finally. Django does itself follows "shared nothing" principle. Thus making it scalable (and redundant) by default and most of the time even very transparently. Slightly old, but still good chapter to read how djang can scale up and be redudant: http://www.djangobook.com/en/1.0/chapter20/ On Thursday 24 March 2011 17:43:40 Cal Leeming [Simplicity Media Ltd] wrote: > You need to handle this within your code logic. > > The problem is, when a 500 Error is given back, you don't know what > actually happened on the server side. For all you know, it could have been > half way through its task. > > You need to add logic within the client side and server side code, to > handle any events like this. > > On Thu, Mar 24, 2011 at 6:29 AM, Shamail Tayyab <pleoma...@gmail.com> wrote: > > Hi, > > > > We have a setup in which we can't afford downtime (even while > > > > deployment). > > > > Our setup is based on lighttpd + django (on fcgi via flup). What my > > problem is, when we restart django, the site goes down for about a > > couple of seconds (and all API calls to DB remains incomplete > > resulting in 500.html being rendered for users). > > > > We need a setup in which we can restart our system in a safe way. > > > > As an initial thought, instead of 1 site instance, lets have 2, then > > use lighty's load balancing to have both the instances run, then drop > > the previous instance. > > > > Is this feasible? Will it lead to inconsistencies? How can I still > > ensure that calls on previous instance completely stops before > > dropping it? > > > > Any other way to do this? > > > > > > Tx > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django users" group. > > To post to this group, send email to django-users@googlegroups.com. > > To unsubscribe from this group, send email to > > django-users+unsubscr...@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
