mysql同步时提示 the table is full

发表于2015/08/31由pm

内部有个产品本身是和mysql绑定在一起的。近期同步时出现”the table is full”。
在网上搜了一下是一些参数设置问题，修改后重启mysql解决。
[bash]
tmp_table_size = 2048M
max_heap_table_size = 2048M
[/bash]

发表在 Admin | 留下评论

bind主备同步的关键配置

发表于2015/08/01由pm

DNS系统中，在大家的直观印象下bind主备的同步都是“实时”的。实际上主备同步的速度有诸多的瓶颈。
对于master而言：
1. 是否有delay notify消息，这个配置是 notify-delay,默认是5s，有必要的话是需要缩短的。
2. transfers-out 限制同时允许区传输的数量，默认是10，如果slave多，zone多需要调大。
3. serial-query-rate 对于master而言会限制master给slave发送notify的速度，默认是20,需要调大。
对于slave而言：
1. transfers-per-ns限制了从单个master同步的并发，默认也是10,需要调大。
2. transfers-in 限制了同时从master（可能有多个）同步的总数，默认是10,需要调大。
3. serial-query-rate 在slave中会限制slave向mastetr做SOA查询的频率。默认是20,需要调大。

最近在排查主备同步延迟的case上，发现bind 9.9.x，9,10.2都存在bug，serial-query-rate的配置不能生效。主要的原因就是 lib/dns/zone.c内
dns_zonemgr_setserialqueryrate这个函数里写死了notifyrate。

void
dns_zonemgr_setserialqueryrate(dns_zonemgr_t *zmgr, unsigned int value) {

    REQUIRE(DNS_ZONEMGR_VALID(zmgr));

    setrl(zmgr->refreshrl, &zmgr->serialqueryrate, value);

    /* Seperately controlled in BIND 9.11.x */
    /*XXXX*/
    setrl(zmgr->notifyrl, &zmgr->notifyrate, 20);
    setrl(zmgr->startupnotifyrl, &zmgr->startupnotifyrate, 20);                                                                                            

    /* XXXMPA seperate out once we have the code to support this. */
    setrl(zmgr->startuprefreshrl, &zmgr->startupserialqueryrate, value);
}

fix的方案就是把这2个地方的20改成value即可。

void
dns_zonemgr_setserialqueryrate(dns_zonemgr_t *zmgr, unsigned int value) {

    REQUIRE(DNS_ZONEMGR_VALID(zmgr));

    setrl(zmgr->refreshrl, &zmgr->serialqueryrate, value);

    /* Seperately controlled in BIND 9.11.x */
    /*XXXX*/
    setrl(zmgr->notifyrl, &zmgr->notifyrate, value);
    setrl(zmgr->startupnotifyrl, &zmgr->startupnotifyrate, value);                                                                                            

    /* XXXMPA seperate out once we have the code to support this. */
    setrl(zmgr->startuprefreshrl, &zmgr->startupserialqueryrate, value);
}

对于单个同步的case，可以从master域名更新、master触发notify，slave收到notify，slave开始同步，slave完成同步几个关键的时间点，查看时间到底消耗到哪里。

发表在 dns | 留下评论

mac下安装iprouet2

发表于2015/05/12由pm

习惯了linux下的ip命令，在mac下非常不方便。mac下有个python包装的版本可以直接安装使用



brew tap brona/iproute2mac 

brew install iproute2mac
发表在 OS | 留下评论

linux下Wireless-N 2200网卡不稳定

发表于2015/05/11由pm

也忘记从什么时候开始，在linux下连无线路由器变得非常不稳定。
当前内核版本：3.16.0-4-amd64
无线网卡：intel Wireless-N 2200
driver: iwlwifi
version: 3.16.0-4-amd64
firmware-version: 18.168.6.1
网上查了一圈，可能是驱动的问题，只能通过屏蔽11n来解决。



pm@debian:~$ cat /etc/modprobe.d/iwlwifi.conf 

options iwlwifi 11n_disable=1
发表在 OS | 留下评论

quagga路由进程连接限制

发表于2015/04/29由pm

quagga套件内的每个路由进程，都会起1个独立的端口。日常的管理我们可以通过直接telnet 端口登录到相应的路由进程做操作。
出于安全的考虑，我们需要对连接到这些路由进程的ip做限制。以只允许本地连接为例，zebra.conf/ospfpd.conf的配置如下



access-list allowed permit 127.0.0.1/32

access-list allowed deny any

!

line vty

 access-class allowed

!
发表在 OSPF | 留下评论

vtysh批量执行命令

发表于2015/03/15由pm

在使用quagga的过程中，实际有很多非交互式的场景，比如想批量做路由撤销的操作。从一个系统管理员的角度上看，希望对软路由的控制像直接在linux里写脚本一样简单方便。之前在vtysh里行执行路由撤销命令我是用expect实现的

  /usr/bin/expect -c "
    set timeout 2
    spawn $vtysh
    expect "*#*"        { send "conf t \r" }
    expect "*(config)#*" { send "router ospf \r" }
    expect "*(config-router)#*" { send "no network  $network area $area \r" }
    expect "*(config-router)#*" { send "exit  \r" }
    expect "*(config)#*" { send "exit  \r" }
    expect "*#*" { send "write memory  \r" }
    expect "*#*" { send "exit\r" }
  "

实际有更简单的方式

sudo vtysh  -c "configure terminal" -c "router ospf" -c "network  $network area $area "  -c "exit"  -c "exit" -c "write file"

这样可以简单对expect的依赖，脚本编写也更简洁。

发表在 OSPF | 留下评论

使用netem模拟弱网络环境

发表于2015/01/31由pm

前段时间为了测试bind递归时的SRTT算法效果,使用netem模拟了一下到几个NS的任意延迟.简单的脚本如下



tc qdisc add dev eth1 handle 1: root htb

tc class add dev eth1 parent 1: classid 1:1 htb rate 100Mbps  quantum 40000

tc class add dev eth1 parent 1:1 classid 1:11 htb rate 100Mbps  quantum 40000

tc class add dev eth1 parent 1:1 classid 1:12 htb rate 100Mbps  quantum 40000

tc class add dev eth1 parent 1:1 classid 1:13 htb rate 100Mbps   quantum 40000

tc class add dev eth1 parent 1:1 classid 1:14 htb rate 100Mbps   quantum 40000 



tc qdisc add dev eth1 parent 1:11 handle 10: netem delay 100ms

tc qdisc add dev eth1 parent 1:12 handle 20: netem delay 200ms

tc qdisc add dev eth1 parent 1:13 handle 30: netem delay 300ms

tc qdisc add dev eth1 parent 1:14 handle 40: netem delay 400ms



tc filter add dev eth1 protocol ip parent 1: prio 3 u32  match ip dst xx.xx.1.19/32  flowid 1:11

tc filter add dev eth1 protocol ip parent 1: prio 3 u32  match ip dst xx.xx.3.19/32  flowid 1:12

tc filter add dev eth1 protocol ip parent 1: prio 3 u32  match ip dst xx.xx.5.19/32  flowid 1:13

tc filter add dev eth1 protocol ip parent 1: prio 3 u32  match ip dst xx.xx.7.19/32  flowid 1:14

通过在本机设置到几个NS的不同延迟,对本地的bind发请求,抓包查看Bind到不同NS的请求量,可以对比出不同版本的bind的SRTT行为差异.

发表在 dns, net | 留下评论

dns缓存投毒的防范措施

发表于2015/01/31由pm

dns投毒是指攻击者伪造权威DNS的回包,向递归DNS发送查询应答包.因为UDP本身是无状态的.递归dns在发送请求时会随机产生1个ID做标识,当自己发送出去请求包后,如果伪造满足下列条件一个UDP包就可以让递归DNS缓存到自己设置的一个记录:
1. 目标IP/端口为递归dns发请求时使用的源IP/端口一致
2. 报文里的TXID一致
3. 查询的记录一致
为了尽量减少缓存投毒可以使用的方案:
1. 递归出去的IP和自己的服务IP分开,递归使用一个网段出去,并且把递归源端口范围设置的尽量大.
2. 校验权威DNS的TTL(指的是IP包里的TTL,到自己需要经过多少跳路由)
3. 递归DNS发请求的时候把查询的记录大小写随机,校验response报文里是否和请求的一致.

发表在 dns | 留下评论

ixfr-from-differences的功效

发表于2014/12/03由pm

常规情况下bind的主备同步是自动增量同步的。但是有些场景下是全量同步，比如自己手动改的zone文件，重新加载进去。
一般内部的反解信息是根据所有的zone自动生成的，就会存在PTR记录每次全量同步的量非常大。测试了可以通过打开ixfr-from-differences，在master上自动计算差异，slave就可以做增量同步了。



ixfr-from-differences yes;

ptr
上图中可以看到之前没有打开ixfr-from-differences时同步1.9W条记录需要2.6s，开启之后每次增量同步只需要0.02s。开启ixfr-from-differences 时会增加master的CPU、内存开销，所以需要根据实际的情况衡量是否需要打开。

发表在 dns | 留下评论

checksum error的原因

发表于2014/12/02由pm

今天有同事反馈dig @223.5.5.5的时候看到本地发出去的包是提示“bad udp cksum”



xxx > 223.5.5.5.53: [bad udp cksum 0x85e1 -> 0xc2e3!] 8250+ A? www.baidu.com.

实际这个是因为网卡开启了tx checksum，开启之后这个checksum的计算是由网卡硬件自己完成，tcpdump抓包的时候实际还没有去结算checksum，所以一直是bad upd cksum



#ethtool -k  eth1

Offload parameters for eth1:

rx-checksumming: on

tx-checksumming: on

scatter-gather: on

tcp-segmentation-offload: on

udp-fragmentation-offload: off

generic-segmentation-offload: on

generic-receive-offload: on

large-receive-offload: off

rx-vlan-offload: off

tx-vlan-offload: off

ntuple-filters: off

receive-hashing: off

只能在目标机器进行抓包才能发现是否发出的包checkum是否真的有错误。
另外可以选择本地把tx checksum关闭掉



#ethtool -K  eth1 tx off

再测试的时候可以看到是OK的了



xxx. > 223.5.5.5.53: [udp sum ok] 44024+ A? www.baidu.com. (31)

实际利用网卡计算checksum显然更好，所以不用太在意这个。

发表在 net | 留下评论