Failed disk + proxy_intercept_errors
mdounin at mdounin.ru
Mon Feb 17 15:54:38 UTC 2020
On Fri, Feb 14, 2020 at 04:14:28AM -0500, chocholo3 wrote:
> Thanks a lot for your response.
> From what you are saying I understand another option:
> current server section - Server A
> copy the same configuration and use some other spare drive as a
> proxy_cache_path configure that as - Server B
> Configure both server sections to listen on unix socket instead of network.
> Create a third server C configuration that will listen on network and will
> proxy_path to Server A with proxy_intercept_errors on and error_page served
> from location that will proxy_path to Server B.
> Is something like this supposed to work? Or it would be better to have the
> there completely independent configuration (like to use some other software
> for server C).
> (I'm asking because I did something like that i the past and it broke a bad
> way. It started serving 500 to everyone. I kind of fear to try it in
> production again.)
As I already tried to explain in the previous message, there are
edge cases which cannot be solved by error handling, at all.
As long as you only care about disk errors which happen before
sending response headers and result in serving 500, just
error_page should be enough. Using additional proxying layer
might help to cover some additional errors which happen during
sending first bytes of the response body.
The only perfect solution, however, is to use disk-level
redundancy - for example, a simple software mirror on two disks is
trivial to configure and will help a lot.
More information about the nginx