store-stale might be useful too; http://www.squid-cache.org/Doc/config/refresh_pattern/ Cheers, On 26/05/2011, at 2:35 PM, Amos Jeffries wrote: > On Wed, 25 May 2011 10:16:46 -0700, melissa schellenberg wrote: >> We're performing an upgrade on the CMS that is sitting behind Squid, >> and we want Squid to serve up ALL pages from its cache during the >> hour >> or two of the upgrade, so that no requests are made to the CMS during >> that time. Is there a "hero mode" setting that we can toggle in >> Squid? Or should we be pre-loading all cached pages with long expiry >> times beforehand? >> I've been reading some rather old threads "offline mode" but that >> seems to be applying only to forward proxying. Thanks in advance for >> any help! > > There is a magic option. The very badly named "offline_mode" causes > squid to grab things as greedily as possible for caching. Turn it ON for > a while leading up to the outage, some days usually. > > Also, run a check of the Expires: headers being used by site content. > That is an absolute limit on cache storage. Bumping up the short ones to > after the outage is over will reduce unavailable objects for the > duration. > > Check max_stale (if available in your Squid) is set much longer than > the outage time. Several multiples of the outage period would probably > be best, this has to cope with data stored at the start of the > offline_mode turn-on as well as stuff requested just before outage. > > Remove "must-revalidate" and "proxy-revalidate" cache controls wherever > possible for a while leading up to the outage. This trades problems with > unavailable objects for problems with stale objects, so care is needed. > In general if you can easily remove a must-revalidate safely you may > benefit long-term by leaving it that way :) > > Also, maybe have a "sorry downtime" page to redirect posts to: > acl POSTs method POST PUT > deny_info http://example.com/sorry.html POSTs > http_access deny POSTs > > > You likely will miss some things. But those will help a lot. > > > Alternatively, if this is super critical you could start the outage by > taking a static mirror of the site then pointing Squid to use that > temporarily. Sending this static copy with a fixed Expires: set to the > end of the upgrade outage will make all new requests transition to the > new site version at a easily determined time. > > Amos > -- Mark Nottingham mnot@xxxxxxxxxxxxx
