infinidb 出现导入错误:ERROR 122

ERROR 122 (HY000): PM1 : Bulkload Read (thread 0) Failed for Table cdn. Terminating this job.

#perror 122
OS error code 122: Disk quota exceeded
MySQL error code 122: Internal (unspecified) error in handler

内部错误,没有特别好处理的办法,查了下,有日本文档介绍通过取消batchinsert设置来定位问题的,不过我测试失败
调试过程中发现取消了infinidb_use_import_for_batchinsert则可以正常导入,另外通过笨办法分割导入定位到了出错数据,原来是原始数据的某一列中包含了”\r\n”的内容,而我的导入方式是以\n 作为结尾的

附上日本文档地址和方法:
mysql> SELECT @@infinidb_use_import_for_batchinsert; — これがONだとLOAD DATA INFILEを/usr/local/Calpont/bin/cpimportにマップしてくれるので無効にする。
+—————————————+
| @@infinidb_use_import_for_batchinsert |
+—————————————+
| 1 |
+—————————————+
1 row in set (0.00 sec)

mysql> SET SESSION infinidb_use_import_for_batchinsert= 0;
Query OK, 0 rows affected (0.00 sec)

mysql> LOAD DATA INFILE ‘/data/tmp/fifo’ INTO TABLE vegelog;
Query OK, 17208325 rows affected, 2076 warnings (5 min 35.09 sec)
Records: 17208325 Deleted: 0 Skipped: 0 Warnings: 2050

edns 与 8.8.8.8 DNS Cache

发表评论

测试bind-9.8.1-P1 的edns的时候发现,google DNS解析的结果一直在跳,有时候在电信区,有时候在us区

于是给它打了第一个patch,让query log 支持edns的client subnet显示,便于排查

筛选下日志,发现很多edns请求不在我们的ecs ACL范围内,最终落到了google DNS IP 所在的us区域,推测应该是这个造成了google DNS 的错误缓存

于是,把ecs的default区域加入拦截

view "default_ecs" { match-clients { ecs 0.0.0.0/0; ecs ::/0;}; ... ... };

这样一来,的确是响应了edns请求,结果却是更多的出现了default 区的结果(热数据),或者在client所属区域和default区结果之间跳动(冷数据)

听包,发现google DNS发送过来的请求Scope Netmask 都是0,如果ecs ACL拦截不成功到了default_ecs区域,最终被ecs 0.0.0.0/0; ecs ::/0; 拦截成功,导致返回的Scope Netmask变成了0

Scope Netmask 变为0意味着什么? 意味着这个结果集有效并且范围最大,从而污染所有的subnet client结果集

目前来看,只能给它打个patch

让client subnet 到了default区域的结果集Scope Netmask 为起address netmask长度,控制结果集的有效范围

测试下,把某个网段故意从ecs ACL挪走,让default ecs拦截看看响应是否是我们期待的

正常网段的请求,返回我们ecs ACL的Netmask

上线测试,目前服务正常

附上edns 文档,非常重要:
https://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-01
http://noops.me/?p=653

以上的显示EDNS 的代码存在bug, 需要初始化

char edbuf[ISC_NETADDR_FORMATSIZE] = { 0 };

这里需要特别解释下为什么char数组初始化使用 {0}, 这里有个解释

it’s a C-style cast. That is, it converts 0 (which is a literal of type int) to char (the \0 character). That cast could have been avoided entirely by simply using the ‘\0’ literal.

测试char = 0; 的时候打印出来直接是null, 从stackoverflow的解释看是这么回事

https://stackoverflow.com/questions/10004297/what-does-char0-mean-in-c

win7 一直在检查更新的问题

发表评论

最近新装win7后,发现windows更新一直显示在检查更新,cpu很高,即使等待非常长的时间后也无法获取更新

这是因为微软升级了windows update的更新机制,如果是全新安装的win7,或者长时间未更新的win7系统,则需要先打两个补丁来获取更新

KB3020369 April 2015 servicing stack update for Windows 7 and Windows Server 2008 R2
KB3172605 July 2016 update rollup for Windows 7 SP1 and Windows Server 2008 R2 SP1

详情可以查看微软的官方链接,补丁也建议只从微软官方下载:
https://support.microsoft.com/en-us/kb/3200747

macOS sierra QQ 4.x 解决截图失败问题

由于MAC QQ团队众所周知的反人类设计团队问题,我一贯是坚持使用旧的4.2.5版本

升级到macOS sierra,也就是mac 10.12版本之后,4.2.5的macQQ截图功能就失效了

解决办法比较简单: 从官网下载最新版的macQQ,当前是5.2.0
下载后双击,点击同意协议,直到出现这个界面,但不要继续拖动图标进行安装

打开finder,找到设备->QQ,对着QQ.app右键->显示包内容,进入 Contents/Library/LoginItems

拷贝文件:JietuMac.app和QQPlatform.app到应用程序-QQ 的/Contents/Library/LoginItems 目录(进入目录方法也是类似),拷贝过去后把JietuMac.app改名为ScreenCapture.app(原来的文件直接删除或者改名)

到这一步后打开QQ程序,左上角菜单,QQ-偏好设置-截屏设置-开启设置面板,会提示你进入刚才拷贝的目录

这个时候依次双击拷贝进来的文件QQPlatform.app和ScreenCapture.app(从JietuMac.app改名而来),会提示让你确认是否打开

执行完这一步,macQQ截图功能就正式可用了

nginx proxy模式下502 bad gateway 问题

并发测试的时候发现nginx 502 bad gateway 了,看了下日志发现很多upstream Cannot assign requested address的记录
connect() to 192.168.89.170:80 failed (99: Cannot assign requested address) while connecting to upstream

正常判断应该是端口不够用了
不过,我确实开启了: net.ipv4.tcp_tw_recycle = 1 和 net.ipv4.tcp_tw_reuse = 1两个参数
理论上应该可以把timewait 端口重用,查了下这个参数跟tcp_timestamps有关(http://blog.sina.com.cn/s/blog_781b0c850100znjd.html)

if (tmp_opt.saw_tstamp &&
tcp_death_row.sysctl_tw_recycle &&
(dst = inet_csk_route_req(sk, req)) != NULL &&
(peer = rt_get_peer((struct rtable *)dst)) != NULL &&
peer->v4daddr == saddr) {
if (get_seconds() < peer->tcp_ts_stamp + TCP_PAWS_MSL &&
(s32)(peer->tcp_ts – req->ts_recent) >
TCP_PAWS_WINDOW) {
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSPASSIVEREJECTED);
goto drop_and_release;
}
}

tmp_opt.saw_tstamp：该socket支持tcp_timestamp
sysctl_tw_recycle：本机系统开启tcp_tw_recycle选项
TCP_PAWS_MSL：60s，该条件判断表示该源ip的上次tcp通讯发生在60s内
TCP_PAWS_WINDOW：1，该条件判断表示该源ip的上次tcp通讯的timestamp 大于本次tcp

因此: 应该在proxy端和后端都开启net.ipv4.tcp_timestamps=1

网卡LACP聚合配置

本文主要介绍多网卡lacp 聚合模式配置,即mode=4模式下RHEL6 bonding 和 RHEL7 team的配置

此模式需要在交换机做配置LACP聚合,具体参考交换机设置
配置范例以双网卡eth0 eth1为例,多网卡类推

RHEL6 配置

1.新增配置文件/etc/modprobe.d/bonding.conf,内容如下

alias bond0 bonding
options bond0 miimon=100 mode=4 lacp_rate=1 xmit_hash_policy=layer3+4

2.更改网卡配置

#/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

#/etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

#/etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
USERCTL=no
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.1.233
NETMASK=255.255.255.0
NETWORK=192.168.1.0
GATEWAY=192.168.1.254

3.重启网络

service network restart

4.注意点: 参见最后附录

RHEL7 配置

1. 修改网卡配置

# /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=”eth0″
ONBOOT=yes
UUID=”原来的UUID”
DEVICETYPE=TeamPort
TEAM_MASTER=team1

#/etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
DEVICETYPE=TeamPort
UUID=”原来的UUID”
ONBOOT=yes
TEAM_MASTER=team1

新增配置: /etc/sysconfig/network-scripts/ifcfg-team1
DEVICE=team1
DEVICETYPE=Team
ONBOOT=yes
BOOTPROTO=none
IPADDR=192.168.1.23
PREFIX=24
DEFROUTE=no
TEAM_CONFIG='{“runner”: {“name”:”lacp”, “active”:true, “fast_rate”:true, “tx_hash”:[“ipv4”], “ports”:{“eth0”:{}, “eth1”:{}}}}’
MTU=1476

2. 重新启动机器,是的,重新启动机器

问题研究

1. RHEL6网卡in能分摊到不同网卡,但是out只走一个网卡
检查/proc/net/bonding/bond0 文件,看看 Transmit Hash Policy 是否正确,一般layer2 在内网测试可能会有问题
需要配置xmit_hash_policy=layer3+4 或者 xmit_hash_policy=layer2+3

2. RHEL7 systetemctl restart network 网卡不通
恩,是的,重启机器吧