On Wed, 24 Jun 2009 19:25:58 -0700, "Elli Albek" <elli@xxxxxxxxxxxxxxx> wrote: > Thanks. > Does this configuration make squid cache and serve the files past their max > age if the parent is down, and get it from the parent if the parent is up? The monitor config closes the small window where squid may back itself into a problem sending to a dead peer and be forced to show the user a problem. The offline_mode config does what you want, BUT cannot be used safely during regular operation. Also it still has some level of leakage based on what you manage to cache before the outage. There are simply the best squid can offer on its own. Amos > > E > > -----Original Message----- > From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] > Sent: Monday, June 22, 2009 6:50 PM > To: Myles Merrell > Cc: squid-users@xxxxxxxxxxxxxxx > Subject: Re: Serving from the cache when the origin server > crashes > > On Mon, 22 Jun 2009 16:44:34 -0400, Myles Merrell <mmerrell@xxxxxxxxxxxx> > wrote: >> Is it possible to configure squid to continue serving from the cache, >> even if the originserver has crashed? >> >> We have squid setup using acceleration through a virtual host. Squid >> listens on 80, and our web server works on another server on port 81. >> Squid serves the majority of pages through the cache, and when it has to >> it gets them from the server. We'd like to be able to take the server >> down periodically, and have the squid cache continue to serve pages in >> the cache. >> >> Is this reasonable?, if so, is it possible? >> > > Sort of. Squid does this routinely for all objects which it can cache. The > state of the backend server is irrelevant for HIT traffic. > > I'm sure some of those who deal with high-uptime requirements have more to > add on this. These are just the bits I can think of immediately. > > For regular usage make sure that sufficiently long expiry and max-age are > set so things get cached for as long as possible. Also check the cache_peer > monitor* settings are in use. These will greatly reduce minor outages or > load hiccups. > > For best affect, the monitor settings and several duplicate parent peers > would be recommended. So that when one peer is detected down Squid simply > makes requests to the next one. Only the requests in action to the first > peer will experience any error. > > The newer the Squid (up to 2.HEAD snapshots) the better the tuning and more > options available for this type of usage. Several sponsors have spent a lot > getting 2.7 and 2.HEAD acceleration features added. > > > > For long'ish scheduled outages there are some other settings which can > further reduce impact but take planning to use properly. When an outage is > being scheduled ensure the max_stale config option has a reasonable but > longer period than you need for downtime. > > Give its some time to grab as much content as possible. You may want to run > a sequence of requests for no-so-popular pages that MUST be cached for the > duration. Then set the inappropriately named offline_mode in Squid just > before dropping the back-end. These will combine to make squid cache as > aggressively as possible and not seek external sources unless absolutely > required. > > > Amos
