使用 Nginx 过滤网络爬虫

现在有许多初学者学习网络爬虫,但他们不懂得控制速度,导致服务器资源浪费。通过 Nginx 的简单配置,能过滤一小部分这类爬虫。

方法一:通过 User-Agent 过滤

Nginx 参考配置如下:

    location / {
        if ($http_user_agent ~* "scrapy|python|curl|java|wget|httpclient|okhttp") {
            return 503;
        }
        # 正常请求
    }

这里只列出了部分爬虫的 User-Agent,需要更多请参考:GitHub – JayBizzle/Crawler-Detect

注意:User-Agent 很容易修改

方法二:block IP

通过禁止某个 IP 或者某个 IP 段访问,也能起到一定效果。 Nginx 示例配置如下:

deny 178.238.234.1;
deny 1.32.128.0/18;

方法三:rate limit

通过限制某个 IP 的访问频率,避免一部分 CC (Challenge Collapsar)攻击。

Nginx 示例配置如下:

http{ 
    #定义一个名为allips的limit_req_zone用来存储session,大小是10M内存,
    #以$binary_remote_addr 为key,限制平均每秒的请求为20个,
    #1M能存储16000个状态,rete的值必须为整数,
    #如果限制两秒钟一个请求,可以设置成30r/m
    limit_req_zone $binary_remote_addr zone=allips:10m rate=20r/s;
    ...
    server{
        ...
        location {
            ...
            #限制每ip每秒不超过20个请求,漏桶数burst为5
            #brust的意思就是,如果第1秒、2,3,4秒请求为19个,
            #第5秒的请求为25个是被允许的。
            #但是如果你第1秒就25个请求,第2秒超过20的请求返回503错误。
            #nodelay,如果不设置该选项,严格使用平均速率限制请求数,
            #第1秒25个请求时,5个请求放到第2秒执行,
            #设置nodelay,25个请求将在第1秒执行。

            limit_req zone=allips burst=5 nodelay;
            ...
        }
        ...
    }
    ...
}

当然,攻击者也可以使用代理IP来破除频率限制。建议在网站前面加一层 CDN。

使用systemctl设置Nginx、PHP、Mysql开机启动

CentOS 7继承了RHEL 7的新的特性,例如强大的systemctl,而systemctl的使用也使得以往系统服务的/etc/init.d的启动脚本的方式就此改变,也大幅提高了系统服务的运行效率。但服务的配置和以往也发生了极大的不同,说实在的,变的简单而易用了许多。

CentOS 7的服务systemctl脚本存放在:/usr/lib/systemd/,有系统(system)和用户(user)之分,像需要开机不登陆就能运行的程序,最好还是存在系统服务里面,即:/usr/lib/systemd/system目录下,每一个服务以.service结尾,一般会分为3部分:[Unit]、[Service]和[Install]

我们可以使用systemctl -a来查看所有服务,如果列表里面没有Nginx,PHP、Mysql,又想借助于systemctl来进行统一管理的话,就到上述所说的/usr/lib/systemd/system目录下面创建以下文件吧

Nginx之nginx.service文件[自定义]

[Unit]
Description=nginx
After=network.target
[Service]
Type=forking
PIDFile=/usr/local/nginx/logs/nginx.pid
ExecStart=/usr/local/nginx/sbin/nginx
ExecReload=/usr/local/nginx/sbin/nginx -s reload
ExecStop=/usr/local/nginx/sbin/nginx -s stop
PrivateTmp=true
[Install]
WantedBy=multi-user.target

PHP之php.service文件[自定义]

[Unit]
Description=php
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/php/sbin/php-fpm
ExecStop=/bin/pkill -9 php-fpm
PrivateTmp=true
[Install]
WantedBy=multi-user.target

Mysql之mysqld.service文件[安装的时候软件自动生成]

[Unit]
Description=MySQL Community Server
After=network.target
After=syslog.target
[Install]
WantedBy=multi-user.target
Alias=mysql.service
[Service]
User=mysql
Group=mysql
#systemctl status就是根据pid来判断服务的运行状态的
PIDFile=/var/run/mysqld/mysqld.pid
# 以root权限来启动程序
PermissionsStartOnly=true
# 设置程序启动前的必要操作。例如初始化相关目录等等
ExecStartPre=/usr/bin/mysql-systemd-start pre
# 启动服务
ExecStart=/usr/bin/mysqld_safe
# Don't signal startup success before a ping works
ExecStartPost=/usr/bin/mysql-systemd-start post
# Give up if ping don't get an answer
TimeoutSec=600
#Restart配置可以在进程被kill掉之后,让systemctl产生新的进程,避免服务挂掉
Restart=always
PrivateTmp=false

上述文件创建完成后,只要使用systemctl enable 命令就可以将所编写的服务添加至开机启动了。例如:

#将php服务添加至开机启动。执行enable命令后,会自动创建一个软链接/etc/systemd/system/multi-user.target.wants/php.service指向此文件。
systemctl enable php.service
#查看php是否已设置为开机启动
systemctl is-enabled php.service

注意

[Unit]部分主要是对这个服务的说明,内容包括Description和After,Description用于描述服务,After用于描述服务类别

[Service]部分是服务的关键,是服务的一些具体运行参数的设置,这里 Type=forking是后台运行的形式,PIDFile为存放PID的文件路径,
ExecStart为服务的具体运行命令,ExecReload为重启命令,ExecStop为停止命令,PrivateTmp=True表示给服务分配独立的临时空间。[Service]部分的启动、重启、停止命令全部要求使用绝对路径,使用相对路径则会报错!

[Install]部分是服务安装的相关设置,可设置为多用户的

服务脚本按照上面编写完成后,以754的权限保存在/usr/lib/systemd/system目录下,这时就可以利用systemctl进行配置了

使用systemctl start [服务名(也是文件名)]可以测试服务是否可以成功运行,如果不能运行则可以使用systemctl status [服务名(也是文件名)]查看错误信息和其他服务信息。然后根据报错进行修改,直到可以start,如果不放心还可以测试restart和stop命令。

Nginx支持HTTPS并且支持反爬虫

自己写了若干爬虫, 但是自己的网站也有人爬, 呵呵, 这里介绍一种Nginx反爬.我在阿里云只开放80端口, 所有一般端口都通过Nginx进行反向代理. 通过Nginx, 我们还可以拦截大部分爬虫.

然后我们再给自己的网站加上HTTPS支持.

Nginx安装

我的系统如下:

jinhan@jinhan-chen-110:~/book/Obiwan/bin$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.3 LTS
Release:    16.04
Codename:   xenial

安装(如果有apache服务器, 建议卸载了, 或者改Nginx的默认端口):

sudo apt-get install nginx

此时已经开启了80端口, 并且配置处在etc/nginx

lsof -i:80

cd /etc/nginx

Nginx服务一般配置

将配置放于conf.d/*

PHP配置(可忽视)

server{
    listen 80;
    server_name php.lenggirl.com;
    charset utf-8;
    access_log /data/logs/nginx/www.lenggirl.com.log;
    #error_log /data/logs/nginx/www.lenggirl.com.err;

    location / {
            root   /data/www/php/blog;
        index index.html index.php;
        #访问路径的文件不存在则重写URL转交给ThinkPHP处理
        if (!-e $request_filename) {
            rewrite  ^/(.*)$  /index.php/$1  last;
            break;
        }
    }

    ## Images and static content is treated different
    location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|xml)$ {

        access_log        off;
        expires           30d;
        root /data/www/php/blog;
     }

    location ~.php/?.*$ {
    root        /data/www/php/blog;
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        #加载Nginx默认"服务器环境变量"配置
        include        fastcgi.conf;

        #设置PATH_INFO并改写SCRIPT_FILENAME,SCRIPT_NAME服务器环境变量
        set $fastcgi_script_name2 $fastcgi_script_name;
        if ($fastcgi_script_name ~ "^(.+.php)(/.+)$") {
            set $fastcgi_script_name2 $1;
            set $path_info $2;
        }
        fastcgi_param   PATH_INFO $path_info;
        fastcgi_param   SCRIPT_FILENAME   $document_root$fastcgi_script_name2;
        fastcgi_param   SCRIPT_NAME   $fastcgi_script_name2;        
    }
}

Go配置

通过server_name, 用域名访问, 全部会到80端口, 根据域名会转发到8080

域名请A记录到该机器IP地址.

vim /etc/nginx/conf.d/www.lenggirl.com.conf

server{
    listen 80;
    # 本地测试时可以将域名改为: 127.0.0.1
    server_name www.lenggirl.com;
    charset utf-8;
    access_log /root/logs/nginx/www.lenggirl.com.log;
    #error_log /data/logs/nginx/www.lenggirl.com.err;
    location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://localhost:8080;

    # 这个就是反爬虫文件了
    include /etc/nginx/anti_spider.conf;
    }   
}

日志文件要先建立:

sudo mkdir -p /root/logs/nginx

查看配置是否无误, 并重启:

sudo nginx -t
sudo service nginx restart
sudo nginx -s reload

访问127.0.0.1会发现502错误, 因为8080端口我们没开! 此时访问localhost会发现, 这时Nginx欢迎页面出来了, 这是默认80端口页面!

反爬虫配置

增加反爬虫配额文件:

sudo vim /etc/nginx/anti_spider.conf

#禁止Scrapy等工具的抓取  
if ($http_user_agent ~* (Scrapy|Curl|HttpClient)) {  
     return 403;  
}  

#禁止指定UA及UA为空的访问  
if ($http_user_agent ~ "WinHttp|WebZIP|FetchURL|node-superagent|java/|FeedDemon|Jullo|JikeSpider|Indy Library|Alexa Toolbar|AskTbFXTV|AhrefsBot|CrawlDaddy|Java|Feedly|Apache-HttpAsyncClient|UniversalFeedParser|ApacheBench|Microsoft URL Control|Swiftbot|ZmEu|oBot|jaunty|Python-urllib|lightDeckReports Bot|YYSpider|DigExt|HttpClient|MJ12bot|heritrix|EasouSpider|Ezooms|BOT/0.1|YandexBot|FlightDeckReports|Linguee Bot|^$" ) {  
     return 403;               
}  

#禁止非GET|HEAD|POST方式的抓取  
if ($request_method !~ ^(GET|HEAD|POST)$) {  
    return 403;  
}  

#屏蔽单个IP的命令是
#deny 123.45.6.7
#封整个段即从123.0.0.1到123.255.255.254的命令
#deny 123.0.0.0/8
#封IP段即从123.45.0.1到123.45.255.254的命令
#deny 124.45.0.0/16
#封IP段即从123.45.6.1到123.45.6.254的命令是
#deny 123.45.6.0/24

# 以下IP皆为流氓
deny 58.95.66.0/24;

在网站配置server段中都插入include /etc/nginx/anti_spider.conf, 见上文. 你可以在默认的80端口配置上加上此句:sudo vim sites-available/default

重启:

sudo nginx -s reload

爬虫UA常见:

FeedDemon             内容采集  
BOT/0.1 (BOT for JCE) sql注入  
CrawlDaddy            sql注入  
Java                  内容采集  
Jullo                 内容采集  
Feedly                内容采集  
UniversalFeedParser   内容采集  
ApacheBench           cc攻击器  
Swiftbot              无用爬虫  
YandexBot             无用爬虫  
AhrefsBot             无用爬虫  
YisouSpider           无用爬虫(已被UC神马搜索收购,此蜘蛛可以放开!)  
jikeSpider            无用爬虫  
MJ12bot               无用爬虫  
ZmEu phpmyadmin       漏洞扫描  
WinHttp               采集cc攻击  
EasouSpider           无用爬虫  
HttpClient            tcp攻击  
Microsoft URL Control 扫描  
YYSpider              无用爬虫  
jaunty                wordpress爆破扫描器  
oBot                  无用爬虫  
Python-urllib         内容采集  
Indy Library          扫描  
FlightDeckReports Bot 无用爬虫  
Linguee Bot           无用爬虫  

使用curl -A 模拟抓取即可,比如:

# -A表示User-Agent
# -X表示方法: POST/GET
# -I表示只显示响应头部
curl -X GET -I -A 'YYSpider' localhost

HTTP/1.1 403 Forbidden
Server: nginx/1.10.3 (Ubuntu)
Date: Fri, 08 Dec 2017 10:07:15 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive

模拟UA为空的抓取:

curl -I -A ' ' localhost

模拟百度蜘蛛的抓取:

curl -I -A 'Baiduspider' localhost

支持https

见: https://certbot.eff.org/#ubuntuxenial-other

首先执行:

apt-get update
apt-get install software-properties-common
add-apt-repository ppa:certbot/certbot
apt-get update
apt-get install python-certbot-nginx 

然后执行这个按说明操作:

certbot --authenticator standalone --installer nginx --pre-hook "nginx -s stop" --post-hook "nginx"

之前/etc/nginx/conf.d/www.lenggirl.com.conf文件变更如下:

server{
        listen 80;
        # 本地测试时可以将域名改为: 127.0.0.1
        server_name www.lenggirl.com;
        charset utf-8;
        access_log /root/logs/nginx/www.lenggirl.com.log;
        #error_log /data/logs/nginx/www.lenggirl.com.err;
        location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_pass http://localhost:4000;

        # 这个就是反爬虫文件了
        # include /etc/nginx/anti_spider.conf;
        #
}

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/www.lenggirl.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/www.lenggirl.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    } # managed by Certbot

}

那些实用的Nginx规则

一、概述

大家都知道Nginx有很多功能模块,比如反向代理、缓存等,这篇文章总结下我们这些年实际环境中那些有用的Nginx规则和模块,大部分是用法的概括及介绍,具体细节在实际配置时再自行google。

二、内置语法

先介绍Nginx默认已支持的内置功能,靠这些基本就满足大部分的web服务需求。

2.1 proxy代理

proxy常用于两类应用场景,一类是中转,如异地科学的上网方式,另外一类是到后端服务的负载均衡方案。

用反向代理时候,需要特别注意里面的域名默认是在nginx启动时候就解析了,除非reload否则一直用的是当初解析的域名,也就是说不能动态解析。

但这个问题是可以通过别的模块或者用内置字典变量方式来解决。

resolver 114.114.114.114;
server {
    location / {
        set $servers github.com;
        proxy_pass http://$servers;
    }
}

2.1.1 中转

针对某个域名进行中转:

server {
listen 172.16.10.1:80;
    server_name pypi.python.org;
    location ~ /simple {
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_pass http://pypi.python.org;
    }
}

注意如果是前后端域名不一样的话需要处理proxy_redirect的301跳转之类的显示,否则在跳转时候会跳转到proxy_pass的域名。

另外可以直接代理所有80端口的http流量:

server {
    listen 80;
    server_name _;
    resolver 114.114.114.114;
    set $URL $host;
    location / {
        proxy_pass http://$URL;
    }
}

如果是想代理https的站点也不是不可能,只是需要自行处理CA证书导入即可,而且经过https中转的流量对nginx是透明的,也就是有证书的时候做窃听和劫持的情况。

2.1.2 负载均衡

这是代理的另外一个常见用法,通过upstream到多个后端,可以通过weight来调节权重或者backup关键词来指定备份用的后端,通常默认就可以 了,或者可以指定类似ip_hash这样的方式来均衡,配置很简单,先在http区域添加upstream定义:

upstream backend {
    ip_hash;
    server backend1.example.com weight=5;
    server backend2.example.com weight=5;;
}

然后在server里面添加proxy_pass:

location / {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
}

做负载均衡的时候可以智能识别后端服务器状态,虽然可以智能地proxy_next_upstream到另外的后端,但还是会定期损失一些正常的“尝试性”的连接,比如过了max_fails 次尝试之后,休息fail_timeout时间,过了这个时间之后又会去尝试,这个时候可以使用第三方的upstream_check模块来在后台定期地自动探索,类似这样:

check interval=3000 rise=2 fall=5 timeout=2000 type=http;

这样替代用户正常的连接来进行尝试的方式进一步保障了高可用的特性。

还有就是在做前端代理的时候也是这样的方式,直接proxy_pass到后端即可,比如CDN的场景。

2.2 防盗链

普通的防盗链是通过referer来做,比如:

location ~* .(gif|jpg|png|bmp)$ {
    valid_referers none blocked *.example.com server_names ~.google. ~.baidu.;
    if ($invalid_referer) {
        return 403;
    }
}

再精细一点的就是URL加密,针对一些用户IP之类的变量生成一个加密URL通常是针对文件下载时候用到,可以通过openresty来写lua脚本或者是accesskey之类的模块来实现。

2.3 变量

nginx里面支持正则匹配和变量配置,默认的变量比如remote_addr、request_filename、query_string、server_name之类的,这些组合在一起可以做很多规则,或者还有日志里面status、http_cookie等。

还有在进行多域名配置时候可以用通配符,比如:

server_name ~^(www.)?(.+)$;
root /data/web/$2;

这样就实现了自动进行域名的目录指派。

变量方面,比如配置变量a=1:

set $a 1;

下面这个案例配合if判断来做有更大的用处。

2.4 if判断

nginx里面支持一些简单的if判断,但是没有多重逻辑的语法,多个判断条件用起来需要结合变量的方式来实现,比如允许ip地址为10.10.61段和和192.168.100段的用户访问,其余的拒绝,返回405状态码:

set $err 0;
    if ( $remote_addr ~ 10.10.61.){
        set $err 0;
    }
    if ( $remote_addr ~ 192.168.100.){
        set $err 0;
    }
    if ( $err = 1){
        return 405;
    }

这样通过一个err变量比较巧妙实现了需求。

2.5 error_page

有用到后端proxy的地方需要加上这句话才可以传到状态码到nginx:

fastcgi_intercept_errors on;

具体配置一般是配置到具体的错误URL页面,比如:

#返回具体状态码
error_page 404 403 /4xx.html
#返回200状态码
error_page 404 403 =200  /error.html

或者采用callback的方式统一做处理:

error_page 404 403 = @fallback; 
location @fallback {
    proxy_pass http://backend;
    access_log /data/logs/404_error.log access;
}

这样在重定向时不会改变URL,然后把404页面直接返回。

2.6 rewrite

rewrite做一些301、302之类的跳转,同时也可以在CDN前端做“去问号”缓存的效果。

location /db.txt {
    rewrite (.*) $1? break;
    include proxy.conf;
}

另外最常见的跳转写法:

rewrite ^/game/(.*) /$1;

把/game/test跳转为/test的效果,注意这样是没有状态码的,如果访问正常就直接返回200状态码。

可以在后面加个permanent参数,就变为了301 Moved Permanently,或者添加redirect改为302跳转。

同理,还可以进行多个正则匹配进行URL重组,比如:

rewrite ^/download/(.*)/lastest/(.*)$ /file/$1?ver=$2 break;

2.7 日志字段

想针对每个连接进行日志留档,可以在nginx日志那里配置好字段,比如记录cookie之类的数据。

在log_format字段里面加入$http_cookie变量即可。

另外post的数据可以永久保留在文件里面,比如用来做http的日志备份,包括get和post的原始数据,把这个值开启即可:

client_body_in_file_only  on;

然后post的数据就会保存在nginx/client_body_temp文件夹里面。

2.8 internal关键词

这个关键词很少见,但有时候是很有用的,比如在有很多规则时候,突然需要针对某个目录转为nginx内部处理。

location ^~ /upload/down/ {
alias /data/web/dts/dtsfile/down/;
internal;
}

2.9 try_files

字面意思是尝试,后面可以接多个目录或者文件,比如kohana框架:

try_files $uri /index.php?$query_string;

先看是否有URL这个文件,没有的话再调用index.php来处理,或者支持状态码处理:

try_files /foo /bar/ =404;

没有这两个文件的话返回404状态。

2.10 auth认证

可以做简单的用户登录认证方式,其中的passwd_file得通过apache的htpasswd命令来生成。

auth_basic "Restricted";
auth_basic_user_file passwd_file;

认证通过之后每次访问会在头部添加Authorization字段包含用户名密码的base64加密密文给服务端。

2.11 gzip

普通的线上web站点gzip压缩是必须要开的,压缩一些文本类型的文件再返回给用户。

注意必须手动指定全需要压缩的类型,比如css、js之类的,线上配置如下:

gzip on;
gzip_min_length  2048;
gzip_buffers     4 16k;
gzip_vary   on;
gzip_http_version 1.1;
gzip_types  text/plain  text/css text/xml application/xml application/javascript application/x-javascript ;

2.12 mime配置

很久以前基本是忽略这个配置,但手游流行之后就发现异常了,需要让手机浏览器知道返回的apk后缀是什么类型,否则类似IE浏览器会以zip后缀返回,需要加上:

application/vnd.android.package-archive apk;
application/iphone pxl ipa;

2.13 限速

限速包括限制请求的并发数和请求的下载速度。

简单的限制某个线程的下载速度就直接加上一句话就可以了:

limit_rate 1024k;

要限制某个IP的并发数之类的就需要用ngx_http_limit_req_module和ngx_http_limit_conn_module模块了,不过是默认就编译好的。

比如使用一个 10M 大小的状态缓存区,针对每个IP每秒只接受20次的请求:

limit_req_zone $binary_remote_addr zone=NAME:10m rate=20r/s;

2.14 location匹配

location匹配有多种方式,常见的比如

location  = / 
location  / 
location ^~ /test{

是有优先级的,直接 ”=” 的优先级是最高的,一般就用”~”这个符号来匹配php就好了,不过是区分了大小写的:

location ~ .*.php$

2.15 文件缓存

返回给用户的文件一般都配置了过期时间,让浏览器缓存起来。

比如缓存14天:

expires 14d;

针对某些特殊的文件就需要location匹配之后进行禁止缓存配置:

add_header Cache-Control no-cache;
add_header Cache-Control no-store;
expires off;

2.16 缓存文件

nginx可以作为ATS这样的缓存服务器来缓存文件,配置也比较简单,不过我们很少用,除非一些特殊的场合,参考配置:

#先在全局下面定义好缓存存放的目录
proxy_cache_path  /data/cache/ levels=1:2 keys_zone=cache_one:10m inactive=7d max_size=10g;
proxy_temp_path   /data/cache/proxy_temp_path;
proxy_cache_key   $host$uri$is_args$args;
#然后在server里面的location匹配好目的文件,加入下一段即可
proxy_cache cache_one;
proxy_cache_valid 200 304 24h;
proxy_cache_valid any 10m;
proxy_pass https://$host;
proxy_cache_key $host$uri$is_args$args;
add_header  Nginx-Cache "$upstream_cache_status"; 3. 内置模块

三、内置模块

nginx含有大量的模块可以支持多种复杂的需求,比如源码目录src/http/modules里面就有很多c模块的代码,或者直接通过./configure –help|grep module来查看有哪些内置模块,编译时候直接加上就可以了。

除了nginx内置的模块,网络上还有很多第三方的模块,可以通过编译时候加参数–add-module=PATH指定模块源码来编译。

下面介绍一些我们线上用过而且比较赞的内置模块。

3.1 stream

端口转发的模块,从nginx1.9版本才开始支持,包含tcp和udp的支持,和IPTABLES相比这个虽然是应用层,会监听端口,但是配置起来很方便,比IPTABLES灵活,在tcp模块下面添加类似vhost的server就可以了,方便自动化管理,参考配置:

server {
    listen PORT;
    proxy_pass IP:PORT;
    access_log /data/logs/tcp/PORT.log;
}

3.2 http_realip_module

nginx反向代理之后,如何让后端web直接获取到的IP不是反向代理的iP,而是直接获取到用户的真实IP呢,就需要这个模块了,不需要代码那里再做类似X-Real-IP的变量特殊判断。

3.3 http_slice_module

在做CDN时候可以用到,让一个大文件分片,分成多个小文件通过206断点续传到后端,然后再组合起来,避免大文件直接回源导致多副本和多次回源的问题。

3.4 http_secure_link_module

前面说到的防盗链可以用这个来做,但是这个一般是针对那种文件下载时候用到的,比如从网页下载时候,服务端生成一个加密URL给用户,然后这个URL有过期时间之类的,避免此URL被多次分享出去,不过普通的素材加载还是用普通的防盗链即可。

3.5 http_sub_module

替换响应给用户的内容,相对于sed之后再返回,比如可以在需要临时全局修改网站背景或者title时候可以一次性处理好。

四、扩展项目

简单介绍下大名鼎鼎的两个基于nginx的扩展项目,也是我们线上有很多地方用到的。

4.1 openresty

集成lua脚本,几乎可以完成任何普通web相关的需求。

比如URL加密进行防劫持和防盗链,服务端动态生成一串aes加密的URL给CDN,CDN的openresty解密之后用普通的URL转发到后端,然后再返回给用户正确的内容。

4.2 tengine

淘宝的nginx修改版,实现了很多nginx的收费功能或者是特殊功能,比如动态加载、concat合并请求,动态解析等。

我们python开发的后台基本都是用的这个版本,主要是利用了concat的合并素材的功能。

五、结语

Nginx是个非常实用软件,部分功能已经超越了普通的web服务定位,同时它具备开源、轻量、自动化等特性,能有效解决实际工作中很多特殊场景的需求,祝Nginx在全球的份额持续攀升~

Linux下NFS的搭建

NFS是Network File System的简称,即网络文件系统。NFS是系统间进行文件共享的一种网络协议,它允许用户像访问本地文件一样去访问网络上共享的文件。

CentOS 自带NFS功能
若没有需安装:yum install -y nfs-utils rpcbind

  • 本次实验平台: CentOS release 6.8 (Final)
  • 服务端IP:172.17.99.67
  • 客服端IP:172.17.99.61

一、环境搭建

1. 编辑配置文件/etc/exports

vim /etc/exports

/ane/data/LBLOGS        172.17.99.61(rw,sync,no_root_squash)
/ane/data/LPLOGS        *(ro,sync)
#表示只有172.17.99.61有读写权限LBLOGS,只有读权限LPLOGS

2. 修改固定端口

vim /etc/sysconfig/nfs

RQUOTAD_PORT=30001
LOCKD_TCPPORT=30002
LOCKD_UDPPORT=30002
MOUNTD_PORT=30003
STATD_PORT=30004

二、搭建NFS

1. 创建nfs共享目录

mkdir /ane/data/LBLOGS -p
mkdir /ane/data/LPLOGS -p

2. 启动nfs

service nfs start
service rpcbind start

3. 在客服端查询

showmount -e 172.17.99.131
clnt_create: RPC: Program not registered
#此报错是因为启动nfs应用顺序错误导致

4. 重启nfs

service nfs stop
service rpcbind stop
#必须按以下方式顺序启动
service rpcbind start
service nfs start

5. 客服端查询

showmount -e 172.17.99.67
Export list for 172.17.99.67:
/ane/data/LBLOGS        172.17.99.61(rw,sync,no_root_squash)
/ane/data/LPLOGS        *(ro,sync)

6. 挂载

mount -t 172.17.99.67:/ane/data/LBLOGS /ane/data/LBLOGS
mount -t 172.17.99.67:/ane/data/LPLOGS /ane/data/LPLOGS

7. 检查

mount | grep nfs

172.17.99.67:/ane/data/LBLOGS on /ane/data/LBLOGS type nfs (ro,vers=4,addr=172.17.99.67,clientaddr=172.17.99.61)
172.17.99.67:/ane/data/LPLOGS/ on /ane/data/LPLOGS type nfs (rw,vers=4,addr=172.17.99.67,clientaddr=172.17.99.61)

三、nfs其他配置

1. 其他报错

mount 172.17.99.131:/ane/data/YTLOGS/ /ane/data/YTLOGS/
mount.nfs: access denied by server while mounting 172.17.99.131:/ane/data/YTLOGS/
#因为版本的问题导致
mount -o v3 172.17.99.131:/ane/data/YTLOGS/ /ane/data/YTLOGS/   #指定版本挂载即可

2. 按需自动挂载(间接映射)

#修改不活动状态的超时时间
vim /etc/sysconfig/autofs

TIMEOUT=300
修改为为
TIMEOUT=600
也就是将不活动状态的超时时间由5分钟修改为10分钟。

3. 开机挂载

vim /etc/fstab

172.17.99.67:/ane/data/LPLOGS /ane/data/LPLOGS nfs defaults 0 0

4. 卸载nfs挂载

umount /ane/data/LPLOGS

Over~

使用Samba替代NFS

之前项目组之中一位离职的同事给我们搭建的数据平台, 用的是Suse。 后来因为计算平台需要迁移到Spark之上, 我们就需要让Spark能方便的读取到SUSE之中的数据文件。

方案1:SUSE NFS Server

因为之前项目组最常用的文件分享协议就是NFS了。 我们的FreeNas服务器上面, 存储了几十T的数据文件。

因此我们首先尝试的是NFS的方法。 Google之后:

尝试了以下命令:

yast2 -i nfs-kernel-server 
# or zypper install -y nfs-kernel-server

但是不管上面哪个命令, 都会报错:

Warning: Legacy commandline option -y/--no-confirm detected. Please use -n/--non-interactive instead.
File '/repodata/repomd.xml' not found on medium 'http://download.opensuse.org/update/13.2/'

Abort, retry, ignore? [a/r/i/? shows all options] (a): a
ABORT request: Aborting requested by user

非常奇怪的问题, 后来又经过Google, 发现原因:

Yes, @tboerger is right. 13.2 reached EOL, this is why the repositories are no longer around. This doesn’t depend on this project.

From: https://github.com/openSUSE/docker-containers-build/issues/23

敢情是这位哥们用的SUSE版本太老了?!

方案2: Samba出马

正在一筹莫展甚至想把数据文件全部迁移到另外一个Ubuntu机器之时, 忽然发现这一台SUSE已经安装了Samba Server 服务, 只是没有启用而已。

现在回想起来, 这个SUSE的Samba Server的安装,也真是奇葩, 官网文档写的也很不详细。

现在总结一下:

  • 执行命令: yast2
    如图选中“Samba Server”

未分类

  • Workgroup 默认, 选择Next

未分类

  • Domain Controller 依然默认, Next

这一个功能我猜是某些域名才能访问。 具体没有试过~

未分类

  • 这一步要注意, 选择启动的时候自动启动

未分类

  • 注意, 需要手动设定账号信息, 否则在其他地方能看到目录, 就是进不去

假设原来已经有一个用户账号 hadoop, 执行下面的命令, 给这个账号设置一下密码:

suse2:~ # smbpasswd -a hadoop
New SMB password:
Retype new SMB password:
Added user hadoop.

这里设置的密码,可以跟原来的SSH密码一样。

设置完成之后, 我们可以在Windows上面直接使用UNC的方式访问了:

UNC的方式: \10.206.132.119

未分类

Ubuntu Client Mount Samba server

因为我们的需求是让Spark能方便的读取SMB服务器上面的数据, 最方便的方法还是直接mount。

当然可以使用smbclient, 不过在Spark之中读取数据的时候, 就不那么友好了。

mount命令也很简单,参考下面的格式:

sudo mount //10.206.132.119/users/hadoop/airsupport_da /data/airsupport/airsupport_da -o user=hadoop,password=xxxx

事后小结

  1. SUSE的文档相比Ubuntu感觉真心很少,而且也不是很友好。
    很多网友的文章, 感觉也是很久以前的东西。 特别是看到有人说某某东西EOS之后, 内心是有一些崩溃的。

  2. 后来简单调查了一下, Samba的稳定性确实要比NFS要好一些。
    我们的NFS Server 经常命令行卡死。
    解决方案: 不好意思, 暂时无解~ 重启服务器吧。

NFS-mount 跨服务器文件挂载

一、什么是NFS?

NFS:network file system,网络文件系统,允许服务器之间通过TCP/IP协议进行资源共享。NFS客户端可以透明的读写NFS服务器上的文件,就像操作本地文件一样。

二、为什么要用NFS?NFS什么好处?

  1. 节省空间:客户端磁盘空间较少,可以挂载到另外的服务器上,以节省本地存储空间。

  2. 网络受限:有些公司内部服务器无法访问外网,但是一些操作需要用到外网权限,就可以将公司服务器挂载到可以访问外网的服务器上,在另外的服务器上进行操作。

三、怎么挂载呢?

场景:服务器A的/mnt目录 挂载到 服务器B上的/test目录上

配置服务器A

1、需要检查是否具有nfs服务

$ ls -al /etc/init.d/nfs-kernel-server // 查看是否存在nfs服务

如果没有 需要手动安装 nfs-kernel-server 服务

$ sudo apt-get install nfs-kernel-server

2、修改 /etc/exports文件(需要root权限),增加要挂载的目录 /mnt *(rw,sync)

其中/mnt是要被挂在的目录,*表示任何服务器,也可以写客户端的IP地址,(rw,sync)表示挂载文件系统时的策略,rw表示读写,sync表示同步进行IO操作,还有其他的一些选项async(非同步进行IO操作)。

3、重启nfs服务

$ sudo /etc/init.d/nfs-kernel-server restart

配置服务器B

以root权限执行下面命令进行挂载

$ sudo mount -t nfs 10.24.21.143:/mnt /test

-t nfs 表示挂载类型是nfs,10.24.21.143:/mnt表示服务器A的IP及需要被挂载的目录,/test表示挂载到服务器B的目录。
执行下列命令查看是否已经挂载成功

$ mount | grep nfs // 如果成功,能够看到挂载的信息

四、配置过程中遇到的坑

其中在服务器B进行挂载时遇到报错如下:

mount: wrong fs type, bad option, bad superblock on 10.24.21.143:/mnt,
       missing codepage or helper program, or other error
       (for several filesystems (e.g. nfs, cifs) you might
       need a /sbin/mount.<type> helper program)

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

错误信息中提到

you might need a /sbin/mount.<type> helper program

指在mount过程中用到了 /sbin/mount.nfs程序,而/sbin/mount.nfs是nfs-common提供的,需要手动运行下面的命令安装一下就好了。

$ sudo apt-get install nfs-common

NFS介绍、NFS服务端安装配置、NFS配置选项

NFS 介绍

NFS(Network File System)即网络文件系统,是FreeBSD支持的文件系统中的一种,它允许网络中的计算机之间通过TCP/IP网络共享资源。在NFS的应用中,本地NFS的客户端应用可以透明地读写位于远端NFS服务器上的文件,就像访问本地文件一样。NFS的数据传输基于RPC(remote procedure call)协议。

  • NFS 应用场景是:A,B,C 三台机器上需要保证被访问到的文件是一样的。A共享数据出来,B和C分别去挂载A共享的数据目录,从而B和C访问到的数据和A上的一致。
    • 例子:跑了一个网站,上面传输了很多图片,用户访问一个图片时,需要从A机器上去请求,但A机器负载高,为了分担负载,就多弄了两台机器,B机器C机器同时提供服务;正常的话,需要到A机器上才能拿到数据,但是B机器和C机器做了负载均衡,分担了相同的服务器,那么用户也有可能到B机器或者C机器上;那么用户请求到B机器上的时候,如何才能获取到A机器上的数据呢;要么把A机器的数据传输到B机器上,同时传输到C机器上,但是这个不能时时更新,(用户上传的数据是存放在A机器上,但用户请求的时候数据是请求到B机器上)这样A上的数据还没到B上面去,就会导致用户请求获取的数据访问不到,访问为空,为404;那么NFS服务就可以解决这个问题,将A机器的数据共享到B机器、C机器,通过NFS来实现。有NFS服务以后,上传到A机器上的数据,B机器或C机器上就能马上看到和调用。NFS可以实时同步数据。
  • NFS原理图

未分类

NFS服务需借助RPC协议实现通信。

服务端需要启动一个NFS服务,服务端要想给客户端提供服务,需要借助RPC协议,RPC协议是由rpcbind服务所实现的;在centos 5或者之前的版本叫portmap服务,centos6及之后的版本叫rpcbind服务,这两个都是一个服务,最终实现了RPC协议的通信,NFS服务默认不会监听任何端口(启动服务,但不会监听端口),最终监听端口,实现RPC通信的过程是由rpcbind服务产生的RPC协议实现的,RPC协议 默认监听的端口是111 端口;

整个流程为: 服务端的NFS服务监听一个端口通过RPC协议监听的端口,再去告诉客户端RPC协议,然后NFS客户端通过本机的RPC端口回传数据信息到服务端NFS监听的端口,最终实现通信.

NFS 服务端安装配置

准备两台虚拟机,一台作为服务端,一台作为客户端。

服务端配置

服务端IP:192.168.159.131

  • 安装NFS工具:
[root@localhost ~]# yum install -y nfs-utils rpcbind
  • 配置

编辑/etc/exports 文件,加入下面内容:

[root@localhost ~]# vim /etc/exports

/home/nfstestdir 192.168.159.0/24(rw,sync,all_squash,anonuid=1000,anongid=1000)
// /home/nfstestdir 要分享出去的目录是哪一个,这个目录是不存在的,后期还需要创建。
// ip段 为指定要给哪个ip段机器去分享这个目录,也可以写单个ip。
  • 启动NFS服务

在yum安装完成后,系统会自动启动rpcbind服务(在服务端进程名为systemd),默认监听的端口为111端口

[root@localhost ~]# ps aux | grep rpc

rpc 2390 0.0 0.0 64964 1044 ? Ss 21:19 0:00 /sbin/rpcbind -w
root 3826 0.0 0.0 112680 972 pts/0 R+ 21:31 0:00 grep --color=auto rpcbind
[root@localhost ~]# netstat -lntp 
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name 
tcp 0 0 0.0.0.0:111 0.0.0.0: LISTEN 1/systemd 
......
tcp6 0 0 :::111 ::: LISTEN 1/systemd 
......

启动NFS服务:

[root@localhost ~]# systemctl start nfs

//启动NFS 服务是会自动帮你启动rpc相关的服务
将NFS服务加入开机启动项:
[root@localhost ~]# systemctl enable nfs
Created symlink from /etc/systemd/system/multi-user.target.wants/nfs-server.service to /usr/lib/systemd/system/nfs-server.service.

客户端配置

IP : 192.168.159.132

  • 安装NFS工具
[root@localhost ~]# yum install -y nfs-utils
  • 客户端挂载

检查客户端是否有权限访问服务端文件:

[root@localhost ~]# showmount -e 192.168.159.131 //131为服务端ip
clnt_create: RPC: Port mapper failure - Unable to receive: errno 113 (No route to host)
// 报错!说明网络不通,不能和192.168.159.131 的113端口通信。

解决办法:
1、检查服务端NFS服务是否开启(有没有监听111端口)
2、如果确认服务端NFS服务已经开启,那么检查防火墙状态,关闭服务端和客户端firewalld和SELinux防火墙(systemctl stop firewalld)
关闭防火墙后再次检查客户端是否有权限访问服务端文件:

[root@localhost ~]# showmount -e 192.168.159.131

Export list for 192.168.159.131:
/home/nfstestdir 192.168.159.0/24
// 客户端已有权限访问服务端

开始挂载:

[root@localhost ~]# mount -t nfs 

192.168.159.131:/home/nfstestdir /mnt/
// -t 指定文件系统类型
[root@localhost ~]# df -h

文件系统 容量 已用 可用 已用% 挂载点
......
192.168.159.131:/home/nfstestdir 16G 5.2G 11G 33% /mnt
  • 测试

在客户端/mnt目录下创建test文件

[root@localhost ~]# touch /mnt/test
[root@localhost ~]# ls -l /mnt/
总用量 0
-rw-r--r--. 1 mysql mysql 0 1月 16 22:05 test
查看服务端/home/nfstestdir/目录:
[root@localhost ~]# ls -l /home/nfstestdir/
总用量 0
-rw-r--r--. 1 mysql mysql 0 1月 16 22:05 test
// 存在个客户端上一样的文件,实现了同步共享。

其中,文件的用户和用户组都为mysql,是因为之前nfs服务端配置时,指定了anonuid=1000,anongid=1000。

服务端:

[root@localhost ~]# awk -F ':' '$3==1000 {print $0}' /etc/passwd
mysql:x:1000:1000::/home/mysql:/bin/bash
客户端:
[root@localhost ~]# awk -F ':' '$3==1000 {print $0}' /etc/passwd
mysql:x:1000:1000::/home/mysql:/bin/bash
// 由于两边uid都为1000,所以都为mysql用户。所以文件的所属组和所属主是由服务端配置文件中定义的anonuid,anongid决定的。(假设两个服务器上uid1000不是同一个用户,则同步文件在两个服务器上的属主和属组是不一样的。)

NFS配置选项

  • rw 读写
  • ro 只读
  • sync 同步模式,内存数据实时写入磁盘/ 内存数据实时写入磁盘,这样会降低磁盘效率。
  • async 非同步模式 // 每隔一段时间把内存数据刷入磁盘一次,如果突然断电,会丢失一本分数据。
  • no_root_squash 客户端挂载NFS共享目录后,root用户不受约束,权限很大
  • root_squash 与上面选项相对,客户端上的root用户收到约束,被限定成某个普通用户
  • all_squash 客户端上所有用户在使用NFS共享目录时都被限定为一个普通用户
  • anonuid/anongid 和上面几个选项搭配使用,定义被限定用户的uid和gid

MySQL无主键延迟优化(slave_rows_search_algorithms)

我们知道,MySQL有一个老问题,当表上无主键或唯一键时,那么对于在该表上做的DML,如果是以ROW模式复制,则每一个行记录前镜像在备库都可能产生一次全表扫描(或者二级索引扫描),大多数情况下,这种开销都是非常不可接受的,并且产生大量的延迟。在无主键有二级索引的情况下会比无主键无索引情况要好一些,但同样可能会造成大延迟,下面有个案例。

在MySQL 5.6中提供了一个新的参数:slave_rows_search_algorithms, 可以部分解决无主键表导致的复制延迟问题,其基本思路是对于在一个ROWS EVENT中的所有前镜像收集起来,然后在一次扫描全表时,判断HASH中的每一条记录进行更新。

首先,我们执行下面的TestCase:

 --source include/master-slave.inc
 --source include/have_binlog_format_row.inc
 connection slave;
 set global slave_rows_search_algorithms='TABLE_SCAN';
 connection master;
 create table t1(id int, name varchar(20);
 insert into t1 values(1,'a');
 insert into t2 values(2, 'b');
 ......
 insert into t3 values(1000, 'xxx');
 delete from t1;
 ---source include/rpl_end.inc

随着 t1 数据量的增大,rpl_hash_scan.test 的执行时间会随着 t1 数据量的增大而快速的增长,因为在执行 ‘delete from t1;’ 对于t1的每一行删除操作,备库都要扫描t1,即全表扫描,如果 select count(*) from t1 = N, 则需要扫描N次 t1 表, 则读取记录数为: O(N + (N-1) + (N-2) + …. + 1) = O(N^2),在 replication 没有引入 hash_scan,binlog_format=row时,对于无索引表,是通过 table_scan 实现的,如果一个update_rows_log_event/delete_rows_log_event 包含多行修改时,每个修改都要进行全表扫描来实现,其 stack 如下:

#0 Rows_log_event::do_table_scan_and_update
#1 0x0000000000a3d7f7 in Rows_log_event::do_apply_event 
#2 0x0000000000a28e3a in Log_event::apply_event
#3 0x0000000000a8365f in apply_event_and_update_pos
#4 0x0000000000a84764 in exec_relay_log_event 
#5 0x0000000000a89e97 in handle_slave_sql (arg=0x1b3e030) 
#6 0x0000000000e341c3 in pfs_spawn_thread (arg=0x2b7f48004b20) 
#7 0x0000003a00a07851 in start_thread () from /lib64/libpthread.so.0
#8 0x0000003a006e767d in clone () from /lib64/libc.so.6

这种情况下,往往会造成备库延迟,这也是无索引表所带来的复制延迟问题。

如何解决问题:

  1. RDS为了解这个问题,会在每个表创建的时候检查一下表是否包含主建或者唯一建,如果没有包含,则创建一个隐式主建,此主建对用户透明,用户无感,相应的show create, select * 等操作会屏蔽隐式主建,从而可以减少无索引表带来的影响;

  2. 官方为了解决这个问题,在5.6.6及以后版本引入参数slave_rows_search_algorithms ,用于指示备库在apply_binlog_event时使用的算法,slave_rows_search_algorithms的文档描述的非常清晰,该变量由三个值的组合组成(就三种算法):TABLE_SCAN,INDEX_SCAN, HASH_SCAN,可以任意组合。其中TABLE_SCAN与INDEX_SCAN是已经存在的,也是默认组合配置,表示如果有索引就用索引,否则使用全表扫描。本文主要研究HASH_SCAN的实现方式。

参数组合(摘自log_event.cc: 9633~9648)

/*
  Decision table:
  - I  --> Index scan / search
  - T  --> Table scan
  - Hi --> Hash over index
  - Ht --> Hash over the entire table

  |--------------+-----------+------+------+------|
  | IndexOption | I , T , H | I, T | I, H | T, H |
  |--------------+-----------+------+------+------|
  | PK / UK      | I         | I    | I    | Hi   |
  | K            | Hi        | I    | Hi   | Hi   |
  | No Index     | Ht        | T    | Ht   | Ht   |
  |--------------+-----------+------+------+------|
*/

hash_scan的实现方法

简单的讲,在apply rows_log_event时,会将 log_event 中对行的更新缓存在两个结构中,分别是:m_hash, m_distinct_key_list。 m_hash:主要用来缓存更新的行记录的起始位置,是一个hash表; m_distinct_key_list:如果有索引,则将索引的值push 到m_distinct_key_list,如果表没有索引,则不使用这个List结构; 其中预扫描整个调用过程如下: Log_event::apply_event

Rows_log_event::do_apply_event
   Rows_log_event::do_hash_scan_and_update 
     Rows_log_event::do_hash_row  (add entry info of changed records)
       if (m_key_index < MAX_KEY) (index used instead of table scan)
         Rows_log_event::add_key_to_distinct_keyset ()

当一个event 中包含多个行的更改时,会首先扫描所有的更改,将结果缓存到m_hash中,如果该表有索引,则将索引的值缓存至m_distinct_key_list List 中,如果没有,则不使用这个缓存结构,而直接进行全表扫描。

执行stack如下:

#0 handler::ha_delete_row 
#1 0x0000000000a4192b in Delete_rows_log_event::do_exec_row 
#2 0x0000000000a3a9c8 in Rows_log_event::do_apply_row
#3 0x0000000000a3c1f4 in Rows_log_event::do_scan_and_update 
#4 0x0000000000a3c5ef in Rows_log_event::do_hash_scan_and_update 
#5 0x0000000000a3d7f7 in Rows_log_event::do_apply_event 
#6 0x0000000000a28e3a in Log_event::apply_event
#7 0x0000000000a8365f in apply_event_and_update_pos
#8 0x0000000000a84764 in exec_relay_log_event 
#9 0x0000000000a89e97 in handle_slave_sql
#10 0x0000000000e341c3 in pfs_spawn_thread
#11 0x0000003a00a07851 in start_thread () 
#12 0x0000003a006e767d in clone ()

执行过程说明:

Rows_log_event::do_scan_and_update

open_record_scan()
    do
      next_record_scan()
        if (m_key_index > MAX_KEY)
           ha_rnd_next();
        else
           ha_index_read_map(m_key from m_distinct_key_list)       
        entry= m_hash->get()
        m_hash->del(entry);
        do_apply_row()
    while (m_hash->size > 0);

从执行过程上可以看出,当使用hash_scan时,只会全表扫描一次,虽然会多次遍历m_hash这个hash表,但是这个扫描是O(1),所以,代价很小,因此可以降低扫描次数,提高执行效率。

hash_scan的一个bug

bug详情:http://bugs.mysql.com/bug.php?id=72788
bug原因:m_distinct_key_list 中的index key 不是唯一的,所以存在着对已经删除了的记录重复删除的问题。
bug修复:http://bazaar.launchpad.net/~mysql/mysql-server/5.7/revision/8494

问题扩展:

  • 在没有索引的情况下,是不是把 hash_scan 打开就能提高效率,降低延迟呢?不一定,如果每次更新操作只一条记录,此时仍然需要全表扫描,并且由于entry 的开销,应该会有后退的情况;

  • 一个event中能包含多少条记录的更新呢?这个和表结构以及记录的数据大小有关,一个event 的大小不会超过9000 bytes, 没有参数可以控制这个size;

  • hash_scan 有没有限制呢?hash_scan 只会对更新、删除操作有效,对于binlog_format=statement 产生的 Query_log_event 或者binlog_format=row 时产生的 Write_rows_log_event 不起作用;

[MySQL]快速解决”is marked as crashed and should be repaired”故障

具体报错如下:

Table '.Tablenameposts' is marked as crashed and should be repaired

提示说论坛的帖子表posts被标记有问题,需要修复。我记得以前也出现过类似的问题,但是只要点击Phpmyadmin上的repair按纽就自动修复了,但是这次很绝,什么都没有.于是赶快上网查找原因。最终将问题解决。解决方法如下:

找到mysql的安装目录的bin/myisamchk工具,在命令行中输入:

myisamchk -c -r ../data/tablename/posts.MYI

然后myisamchk 工具会帮助你恢复数据表的索引。好象也不用重新启动mysql,问题就解决了。

问题分析:

1、
错误产生原因,有网友说是频繁查询和更新dede_archives表造成的索引错误,因为我的页面没有静态生成,而是动态页面,因此比较同意这种说法。
还有说法为是MYSQL数据库因为某种原因而受到了损坏,如:数据库服务器突发性的断电、在提在数据库表提供服务时对表的原文件进行某种操作都有可能导致
MYSQL数据库表被损坏而无法读取数据。总之就是因为某些不可测的问题造成表的损坏。

2、问题解决办法。

当你试图修复一个被破坏的表的问题时,有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立,删除信息所指出的文件并再试一次–这通常是上一次修复操作遗留下来的。
这三种修复方法如下所示:

% myisamchk --recover --quick /path/to/tblName
% myisamchk --recover /path/to/tblName
% myisamchk --safe-recover /path/to/tblName

第一种是最快的,用来修复最普通的问题;而最后一种是最慢的,用来修复一些其它方法所不能修复的问题。

检查和修复MySQL数据文件
如果上面的方法无法修复一个被损坏的表,在你放弃之前,你还可以试试下面这两个技巧:


果你怀疑表的索引文件(.MYI)发生了不可修复的错误,甚至是丢失了这个文件,你可以使用数据文件(.MYD)和数据格式文件(*.frm)重新生
成它。首先制作一个数据文件(tblName.MYD)的拷贝。重启你的MySQL服务并连接到这个服务上,使用下面的命令删除表的内容:

mysql> DELETE FROM tblName;


删除表的内容的同时,会建立一个新的索引文件。退出登录并重新关闭服务,然后用你刚才保存的数据文件(tblName.MYD)覆盖新的(空)数据文件。
最后,使用myisamchk执行标准的修复(上面的第二种方法),根据表的数据的内容和表的格式文件重新生成索引数据。

如果你的表的
格式文件(tblName.frm)丢失了或者是发生了不可修复的错误,但是你清楚如何使用相应的CREATE
TABLE语句来重新生成这张表,你可以重新生成一个新的.frm文件并和你的数据文件和索引文件(如果索引文件有问题,使用上面的方法重建一个新的)一
起使用。首先制作一个数据和索引文件的拷贝,然后删除原来的文件(删除数据目录下有关这个表的所有记录)。

启动MySQL服务并使用当初的CREATE TABLE文件建立一个新的表。新的.frm文件应该可以正常工作了,但是最好你还是执行一下标准的修复(上面的第二种方法)。

为了不冒失修复,故采取保守做法,我们知道 MySQL 一个高效的管理工具便是 PhpMyAdmin,而在该管理软件中就包含了对表的检查、分析、修复、优化功能,比起网上提供的含糊命令行来说更安全更简便。

未分类

通过实践,在使用检查表功能后确实发现了问题,之后使用修复功能进行了修复,反馈结果每个表都已经 ok,再执行一次优化,重新测试访问网站终于恢复了正常。一场灾难就此避免……