Wednesday, March 23, 2011

Re: High availability deployments

Hi,

First at all, if you're working with real high availability system you already
have resolved most of the single point of failure problems, and other non-
django related issues (like broken hardware, broken network connections etc.)

And by looking what you're experiencing now indicates that you haven't done
not your homework about real high availability systems.

And finally about Django:

Django itself by design uses share nothing architecture, so if you don't
deliberately program something that is shared it won't cause any side-effects.

When run behind webservers you must shut down all instances gracefully (let
them complete last request before closing them down) to avoid loss of data.

On Thursday 24 March 2011 08:29:00 Shamail Tayyab 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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home


Real Estate