When using fastdfs and two storages, and one is used for backup, it is found that there is a type of file name that starts with "ag-". When using the <img> tag to display it immediately, it will report a 502 exception.
Check nginx's error.log to get
2017/09/25 17:39:09 [error] 13333#0: *30734 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 10.24.169.19, server: localhost, request: "GET /group1/M00/01/5E/ag-JjlnIzqmAdi3UAAOreY6LKcM688.jpg HTTP/1.1", upstream: "http://106.15.137.142:8081/group1/M00/01/5E/ag-JjlnIzqmAdi3UAAOreY6LKcM688.jpg?redirect=1", host: "10.135.237.203:8081"
Analyze the interaction process between the client and nginx as follows:
Generally, Nginx and Tracker are installed on a server, so the communication between them generally does not take too long to cause timeout
However, Nginx and Storage are generally not on the same machine, so the communication between Nginx and Storage may timeout, resulting in a 502 exception.
So you need to add the following configuration to Nginx
location /group1/M00{
add_header Content-Disposition "attachment;filename=$arg_n";
add_header Access-Control-Allow-Origin "*";
root /home/ubuntu/fastdfs/nginx-link/data;
ngx_fastdfs_module;
proxy_connect_timeout 300s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;
}
Later, I found that I still couldn't solve this problem. I continued to analyze and found that the files on the other storage were inaccessible. I checked that the nginx_fastdfs_module was not configured. After adding it, restart nginx and found that the abnormality of 502 was solved, but the insertion occasionally occurred. The picture takes a long time to display.
After some thought, I found that this was the result of the storage synchronization delay. Probably this tracker put the file on StorageA, but when accessing it, the Tracker found that StorageB was also available, and returned the IP and port of StorageB. But at this time, StorageB does not have this file, so it keeps waiting until StorageB synchronizes the data of StorageA.
View the tracker's configuration file with the following configuration:
# which storage server to download file
# 0: round robin (default)
# 1: the source storage server which the current file uploaded to
download_server=1
It means which storage server to choose to download the file. 0 means polling, which is the default value, and 1 means downloading the file from the source file server of the current file.
At this time, set it to 1, and it's fine.
So how does Tracker determine which one is the origin server? According to the file name, Tracker_Nginx_Module can deduce the source server IP and file timestamp according to the file name. Based on these two points, the source Storage server can be found.
1.http: //www.bubuko.com/infodetail-1873115.html
2.http://blog.csdn.net/mr_smile2014/article/details/52118541