分类目录归档:系统运维

FAQ系列 | 防范SQL注入风险

0、导读

在MySQL里,如何识别并且避免发生SQL注入风险

1、关于SQL注入

互联网很危险,信息及数据安全很重要,SQL注入是最常见的入侵手段之一,其技术门槛低、成本低、收益大,颇受各层次的黑客们所青睐。

一般来说,SQL注入的手法是利用各种机会将恶意SQL代码添加到程序参数中,并最终被服务器端执行,造成不良后果。

例如,我们访问接口 http://imysql.com/user.php?userid=123 来根据userid获取用户信息,假设程序中是这么处理的:

$sql = “SELECT * FROM user WHERE userid = $_GET[userid]“;

上面这段代码看起来既low有很xx对吧,尤其是在双引号里面还可以直接引用数据类型变量,所以说php是世界上最好的语言一点不为过,哈哈(其实我早期也写过几年php的)。

这时候,如果我们传递进去的参数改成这样:http://imysql.com/user.php?userid=123 or 1=1,这就会导致SQL条件永远成立,所有的数据都会被读取出来。又或者可以传递这样的参数:http://imysql.com/user.php?userid=123 or if(now()=sysdate(),sleep(5),1),这时候不但所有的数据都会被读取到,也会让这个SQL执行完毕后再等待5秒才能返回,黑客可据此来判断这个SQL注入探测是否成功。

在上面这个例子中,其实我们只需要对用户输入的参数进行简单的类型判断和控制,即可快速避免被注入的风险,例如改成下面这样就可以了:

$userid = intval(strim($_GET[‘userid’]));

$sql = “SELECT * FROM user WHERE userid = “ . mysql_real_escape_string($userid);

可见,至少基础的SQL注入并不难防范,只要在各个层面都做足工作就可以。而简单的SQL盲注(就是乱拳打死老师傅的玩法)已经可以采用sqlmap之类的辅助工具来做了,完全不需要人工执行。

2、如何防范

上面提到过sqlmap,它既可以作为SQL盲注的工具,也可以在新项目上线前内部扫一次,提前发现潜在漏洞,及时修补,反过来为我们所用。其他可以检测sql注入漏洞的知名扫描工具有:SQLIer、SQLID、SQL Power Injector、SQLNinja

我们也可以自己通过频繁扫描当前执行的SQL列表,根据一些关键字来判断是否发生了SQL注入或潜在风险,常见的关键字有:

  • SLEEP() — 一般的SQL盲注都会伴随SLEEP()函数出现,而且一般至少SLEEP 5秒以上
  • MID()
  • CHAR()
  • ORD()
  • SYSDATE()
  • SUBSTRING()
  • DATABASES()
  • SCHEMA()
  • USER()
  • VERSION()
  • CURRENT_USER()
  • LOAD_FILE()
  • OUTFILE/DUMPFILE
  • INFORMATION_SCHEMA
  • TABLE_NAME
  • fwrite()/fopen()/file_get_contents() — 这几个是PHP文件操作函数

我们可以以较高频率检查当前的活跃SQL命令,一旦发现上述关键字,可以立即记录下来并触发告警,通知管理员及时人工确认处理,甚至也可以先直接自动杀掉这些SQL查询(可以用 pt-kill 工具来做到这点,也可以自行开发),以防万一,少给黑客留机会。

还有,我们建议把选项 safe-update/sql_safe_updates 设置为 1,防止没有任何 WHERE 条件的误操作更新,将全表数据都写错

3、其他建议

防范SQL注入只是数据安全保护工作很小的一部分,只要做好基本功就可以防住至少80%以上的SQL注入探测。

在app server层,以PHP开发语言为例,除了上面提到的规范用户输入类型外,还可以改成用 sprintf() 函数来格式化构造 SQL 语句,也可以一定程度防范SQL注入。还可以修改 php cgi 程序的运行属主为普通用户,最起码不能使用 root 用户,避免因为代码层不严谨导致被黑客上传可执行 php 程序代码文件。还可以把php中的远程文件调用权限关闭,把选项 allow_url_fopen、allow_url_include 均设置为 off,并限定php可以打开的文件目录,不允许跨区域访问敏感文件。

除了在代码层面做好数据类型判断、用户输入判断外,还可以在web server层加上过滤策略,比如在nginx上启用WAF插件。或者,也可以购买IDC运营商、云主机提供商提供的商业解决方案。对于重视数据安全的企业来说,花点钱保平安更为重要。

4、附录

下面是一些常见SQL注入参考案例:

案例1:SELECT * FROM t WHERE a LIKE ‘%xxx%’ OR (IF(NOW=SYSDATE(), SLEEP(5), 1)) OR b LIKE ‘1=1‘;

案例2:SELECT * FROM t WHERE a > 0 AND b IN(497 AND (SELECT * FROM (SELECT(SLEEP(20)))a));

案例3:SELECT * FROM t WHERE a=1 and b in (1234,(SELECT (CASE WHEN (5=5) THEN SLEEP(5) ELSE 5*(SELECT 5 FROM INFORMATION_SCHEMA.CHARACTER_SETS) END)));

 

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yejinrong.com 获得专属优惠

R620服务器idrac偶尔不可用问题解决方法

R620服务器中,比较经常出现idrac无法连接,或者连接用户数超限的问题,有几个方法可以尝试下:
1、 升级idrac卡的firmware
下载并升级最新的1.57.57版本的firmware:http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=XH6FX
该版本的bug fix中提到过一点:
– Fix for issues that cause iDRAC7 sluggish responsiveness after a prolonged period of time (approx. 45-100 days, depending on the usage). In some cases, if the iDRAC is not reset, the iDRAC may become unresponsive and requires a server AC Power on reset. This issue was introduced in firmware release 1.50.50 and fixed in 1.56.55.

该版本解决了idrac启动45-100天后可能出现无法响应的问题。

2、 杀掉超时连接会话
有2个方法:
a. 重启bmc卡
执行命令: ipmitool mc reset cold 即可,将bmc卡重启后,所有的session都会重置释放。

b. 杀掉超时会话
前提是,允许bmc卡通过网络远程连接
ipmitool lan set 1 access on

或者在下面这个地方启用
iDRAC 设置 => 服务 => VNC 服务器 => 超时

或者在idrac卡的下面这个地方设置:
iDRAC 设置 => 网络 => IPMI 设置 => 启用 LAN 上的 IPMI

同时,建议把web server及ssh服务的timeout值适当调低:
iDRAC 设置 => 服务 => Web Server => 超时
iDRAC 设置 => 服务 => SSH => 超时
iDRAC 设置 => 服务 => Telnet => 超时
iDRAC 设置 => 服务 => VNC 服务器 => 超时

利用 racadm 工具(racadm工具的安装自行搞定)关闭超时会话,首先可以查看当前的会话连接情况,例如:
[ 15:41:10-root@fzdm-10-59-xx-xx:~ ]#racadm -r 10.59.xx.xx -uroot -p”xx” getssninfo
Security Alert: Certificate is invalid – self signed certificate
Continuing execution. Use -S option for racadm to stop execution on certificate-related errors.
SSNID Type User IP Address Login Date/Time
—————————————————————————
20 SSH root 10.5.xx.xx 11/18/2014 15:38:43
25 GUI root 10.5.xx.xx 11/18/2014 15:40:27
28 RACADM root 10.59.xx.xx 11/18/2014 15:41:17
29 SSH root 10.59.xx.xx 11/18/2014 15:41:18

再执行下面的命令,关闭超时会话连接
[ 15:40:52-root@fzdm-10-59-xx-xx:~ ]#racadm -r 10.59.xx.xx -uroot -p”xx” closessn -i 25
Security Alert: Certificate is invalid – self signed certificate
Continuing execution. Use -S option for racadm to stop execution on certificate-related errors.
Session 19 closed successfully.

【荐】用iopp代替iotop

1、为什么推荐iopp

iotop对内核及python版本都有一定要求,有时候无法用上,这时候就可以使用iopp作为替代方案。在有些情况下可能无法顺利使用iotop,这时候就可以选择iopp了。它的作者是Mark Wong,用C开发,代码仅有532行,非常简洁。

iopp的项目地址:https://github.com/markwkm/iopp

2、安装iopp

下载源码到本地后,执行下面的命令即可完成安装:
cmake CMakeLists.txt
make && make install
 
#或者指定安装的目标路径到 /usr/bin 下
make install DESTDIR=/usr

3、使用iopp

iopp使用起来非常简便,用法:

iopp [-ci] [-k|-m] [delay [count]]

几个常用参数见下,比较简单,就不一一解释了:

-c, --command display full command line
-h, --help display help
-i, --idle hides idle processes
-k, --kilobytes display data in kilobytes
-m, --megabytes display data in megabytes
-u, --human-readable display data in kilo-, mega-, or giga-bytes

iopp输出的结果也比较清晰易懂,简单解释下:

pid 进程ID
rchar 预计发生磁盘读的字节数
wchar 预计发生磁盘写的字节数
syscr I/O读次数
syscw I/O写此书
rbytes 真正发生磁盘读的字节数
wbytes 真正发生磁盘写的字节数
cwbytes 因为清空页面缓存而导致没有发生操作的字节数
command 命令行名称

常用PC服务器阵列卡、硬盘健康监控

通常,我们使用的DELL/HP/IBM三家的机架式PC级服务器阵列卡是从LSI的卡OEM出来的,DELL和IBM两家的阵列卡原生程度较高,没有做太多封装,可以用原厂提供的阵列卡管理工具进行监控;而HP的阵列卡一般都做过封装了,因此需要使用自身特有的管理工具来监控。

本文以几种常用的阵列卡为例,展示其阵列卡及硬盘监控的方法。
DELL SAS 6/iR卡,全称LSI Logic SAS1068E,只支持RAID 0, RAID 1, RAID 1+0, 不支持RAID 5等高级RAID特性,不支持阵列卡电池。
DELL PERC PERC H700卡,全称LSI Logic MegaRAID SAS 2108,支持各种RAID级别及高级特性,可选配阵列卡电池。
DELL PERC H310 Mini卡 ,全称LSI Logic / Symbios Logic MegaRAID SAS 2008,支持常见RAID级别,不支持高级RAID特性,不支持阵列卡电池。
IBM ServeRAID M5014 SAS/SATA Controller卡,全称LSI Logic / Symbios Logic MegaRAID SAS 2108,支持各种RAID级别及高级特性,可选配阵列卡电池。
IBM ServeRAID-MR10i SAS/SATA Controller卡,全称LSI Logic / Symbios Logic MegaRAID SAS 1078,支持常见RAID级别,不支持高级RAID特性,可选配阵列卡电池,这个卡其实和DELL的PERC 6/i卡是一样的,都是基于LSI MegaRAID SAS 1078基础上OEM出来的。

上面是几种常见的阵列卡型号,更多的可以自行查看官方的技术手册。

下面我们要继续的是,这些阵列卡以及硬盘如何监控,阵列卡的管理也请查看官方技术手册,不在本文讨论范畴,或者查看作者的一个分享PPT:PC服务器阵列卡管理简易手册

一般地,支持RAID 5的卡,我们称其为阵列卡,都可以使用LSI官方提供的MegaCli工具来管理,而不支持RAID 5的卡,我们称其为SAS卡,使用lsiutil工具来管理。HP的服务器使用其特有的hpacucli工具来管理。

1、MegaCli工具
a) MegaCli -adpallinfo -aall — 查看阵列卡信息
-a 参数指定阵列卡的编号,一般服务器上只会配一个阵列卡,因此我们通常指定为 -a0(阵列卡适配器编号,从0开始) 即可,主要关注下面几个信息:

状态值 对应含义
Product Name : PERC H710 Mini  阵列卡名称
FW Package Build: 21.2.0-0007  阵列卡firmware版本号,版本如果太低,建议升级以提高稳定性及性能
BBU : Present  是否有配BBU电池

b) MegaCli -cfgdsply -aall — 查看阵列配置

状态值 对应含义
Memory: 512MB  阵列卡cache大小,2的N次方,如果不是,说明阵列卡有异常
Number of dedicated Hotspares: 0  阵列是否有专用/独享热备盘(如果有多个逻辑磁盘组/disk group,则可以指定一个硬盘用于全局热备,那么该disk group上的专用热备盘数量为0也不用担心),除了RAID 1/RAID 1+0一般不指定热备盘以外,其他几个阵列级别建议都要指定热备盘
State : Optimal  阵列状态,如果不是 Optimal 就要关注了
Current Cache Policy: WriteBack, ReadAheadNone, Direct, Write Cache OK if Bad BBU  阵列读写cache策略,建议写策略设置为FORCE WB,最起码是WB,预读策略可以关掉,意义不大,几乎没影响
Disk Cache Policy : Disabled  硬盘cache策略,建议关闭,防止意外时数据丢失
Current Power Savings Policy: None  节电策略,建议关闭
Media Error Count: 0  三个错误计数器,任何一个值大于100就要立刻引起关注,尤其要关注起增长速度。1T以上SATA盘,计数值不够精确,可能所有盘上该值都会大于0,一般重启就会重新清0,如果重启后还是大于0的话,赶紧报修吧。SAS盘的计数值则比较准确。
Other Error Count: 0
Predictive Failure Count: 0
Firmware state: Online, Spun Up  查看硬盘状态,如果是unconfigured表示该硬盘未分配加入到阵列中;如果是 unconfigured(bad)表示该盘不但是未分配,而且还坏了,正是“出师未捷身先死”;如果是failed,表示该盘故障无法识别;如果是rebuilding,表示该盘正在重建数据

c) MegaCli -adpbbucmd -aall — 查看阵列卡电池信息

状态值 对应含义
Temperature: 39 C  查看电池温度,如果相比上一次查看高出不少,就需要关注了,或者可以根据经验设置一个基线值
Battery State: Optimal  电池状态,如果不是为Optimal,就需要关注了
Charger Status: Complete  电池充放电状态
isSOHGood: Yes  电池状态,如果不是为Yes,需要关注
Relative State of Charge: 93 %  当前电量,当电量低于15%,或者电池坏掉时,默认都会将写策略从WB改成WT,除非设定为FORCE WB策略
Max Error = 0 %  电池是否有错误信息
Next Learn time: Tue Oct 14 22:06:50 2014  电池充放电时间,注意这是美国时间。另外,新的阵列卡电池很多改成电容式的了,也就不需要重复充放电了

d) MegaCli -fwtermlog -dsply -aALL 查看阵列卡日志,关注里面的error/fail/warn等多个关键字

2、lsiutil工具
lsiutil有交互和非交互两种方式,作为监控,我们肯定选择非交互模式。想要使用交互模式的,可以根据非交互模式自行练习。
a) lsiutil -p 1 -a 20,12,0,0 — 查看硬盘计数器
Invalid DWord Count 2,563 — 任何一个值大于0,都需要引起关注
Running Disparity Error Count 2,366
Loss of DWord Synch Count 0
Phy Reset Problem Count 0

b) lsiutil -p 1 -a 21,1,0,0,0 — 查看逻辑卷状态

状态值 对应含义
Volume State: optimal, enabled  逻辑卷健康状况
Volume draws from Hot Spare Pools: 0  是否有热备
Volume Size 139392 MB, 2 Members  由几块硬盘组成
Primary is PhysDisk 1 (Bus 0 Target 9)  物理硬盘1
Secondary is PhysDisk 0 (Bus 0 Target 3)  物理硬盘0

c) lsiutil -p 1 -a 21,2,0,0,0 — 查看物理硬盘状态

状态值 对应含义
PhysDisk 0 is Bus 0 Target 3  编号
PhysDisk State: online  状态
Error Count 13, Last Error: Command = 28h, Key = 3, ASC/ASCQ = 11h/00h  错误计数器,大于0的话,就需要引起关注

3、hpacucli工具
hpacucli工具查看阵列、硬盘、电池信息,其实就只要一条指令:
hpacucli ctrl all show config detail — 查看阵列详细信息、配置

状态值 对应含义
Controller Status: OK 阵列卡状态
Firmware Version: 1.18 firmware版本,太低了建议升级,以提高稳定性及性能
Cache Board Present: True 是否配备了cache模块
Cache Status: OK cache模块状态
Cache Ratio: 100% Read / 0% Write cache策略,此处只有读cache,不用于写cache,因为没有bbu电池,见下方结果
Drive Write Cache: Disabled 关闭磁盘cache
Total Cache Size: 256 MB cache大小
Total Cache Memory Available: 208 MB 实际可用cache大小,和理论cache大小不一样,说明cache模块可能有问题
No-Battery Write Cache: Disabled 关闭FORCEWB策略
Battery/Capacitor Count: 0 阵列卡BBU电池数量为0,也就是没有BBU模块
Battery/Capacitor Status: Failed (Replace Batteries) 阵列卡BBU电池状态,这里显示是错误状态,需要及时更换
Array: A 第一个乌列阵列,编号从A开始,依次是A、B、C
Status: OK 物理阵列状态
Logical Drive: 1 第一个逻辑卷,编号从1开始
Fault Tolerance: RAID 5 第一个逻辑卷的阵列级别
Status: OK 第一个逻辑卷状态
Caching: Enabled 第一个逻辑卷是否启用了cache策略
physicaldrive 1I:1:1 第一块物理硬盘,编号从1开始
Status: OK 第一块物理硬盘状态
Firmware Revision: HPDA 第一块物理硬盘firmware,如果太低,也需要及时升级,HP的硬盘每个批次都有不同的firmware

延伸阅读:

http://www.lsi.com/downloads/Public/Obsolete/Obsolete%20Common%20Files/mr_sas_stor_ug.pdf
http://www.hp.com/ctg/Manual/c00709035.pdf
http://www.wafl.co.uk/tag/sasadmin/
http://docs.oracle.com/cd/E19121-01/sf.x4200/819-1157-23/F_BIOS_RAID.html

迁移Zabbix数据库到TokuDB

背景介绍

线上的Zabbix数据库有几个大表数据量疯狂增长,单表已经超过500G,而且在早期也没做成分区表,后期维护非常麻烦。比如,想删除过期的历史数据,在原先的模式下,history、history_uint等几个大表是用 (itemid, clock) 两个字段做的联合主键,只用 clock 字段检索效率非常差。

TokuDB 是一个高性能、支持事务处理的 MySQL 和 MariaDB 的存储引擎。TokuDB 的主要特点是高压缩比,高 INSERT 性能,支持大多数在线修改索引、添加字段,特别适合像 Zabbix 这种高 INSERT,少 UPDATE 的应用场景。

迁移准备

欲使用 TokuDB 引擎,服务层可以选择和 MariaDB ,也可以选择 Percona ,鉴于我以往使用 Percona 的较多,因此本次也选择使用 Percona 版本集成 TokuDB 引擎。

当前最新版下载地址:http://www.percona.com/redir/downloads/Percona-Server-5.6/LATEST/binary/tarball/Percona-Server-5.6.17-rel66.0-608.TokuDB.Linux.x86_64.tar.gz

按照正常方式安装即可,配置文件中增加3行:

malloc-lib= /usr/local/mysql/lib/mysql/libjemalloc.so
plugin-dir = /usr/local/mysql/lib/mysql/plugin/
plugin-load=ha_tokudb.so

如果不加载jemalloc,启动时就会有类似下面的报错:

[ERROR] TokuDB not initialized because jemalloc is not loaded
[ERROR] Plugin 'TokuDB' init function returned error.
[ERROR] Plugin 'TokuDB' registration as a STORAGE ENGINE failed.

并且,修改内核配置,禁用transparent_hugepage,不关闭的话可能会导致TokuDB内存泄露(建议写到 /etc/rc.local 中,重启后仍可生效):

echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

如果不修改内核设置,启动时就会有类似下面的报错:

Transparent huge pages are enabled, according to /sys/kernel/mm/redhat_transparent_hugepage/enabled
Transparent huge pages are enabled, according to /sys/kernel/mm/transparent_hugepage/enabled
[ERROR] TokuDB will not run with transparent huge pages enabled.
[ERROR] Please disable them to continue.
[ERROR] (echo never > /sys/kernel/mm/transparent_hugepage/enabled)
[ERROR]
[ERROR] ************************************************************
[ERROR] Plugin 'TokuDB' init function returned error.
[ERROR] Plugin 'TokuDB' registration as a STORAGE ENGINE failed.

然后,初始化数据库,启动即可。

我的服务器配置:E5-2620 * 2,64G内存,1T可用磁盘空间(建议datadir所在分区设置为xfs文件系统),下面是我使用的相关选项,仅供参考:

#
#my.cnf
# 
# Percona-5.6.17, TokuDB-7.1.6,用于Zabbix数据库参考配置
# 我的服务器配置:E5-2620 * 2,64G内存,1T可用磁盘空间(建议datadir所在分区设置为xfs文件系统)
# TokuDB版本:Percona-5.6.17, TokuDB-7.1.6(插件加载模式)
# 
# created by yejr(http://imysql.com), 2014/06/24
# 
[client]
port            = 3306
socket          = mysql.sock
#default-character-set=utf8
 
[mysql]
prompt="\\u@\\h \\D \\R:\\m:\\s [\\d]>
#pager="less -i -n -S"
tee=/home/mysql/query.log
no-auto-rehash
 
[mysqld]
open_files_limit = 8192
max_connect_errors = 100000
 
#buffer & cache
table_open_cache = 2048
table_definition_cache = 2048
max_heap_table_size = 96M
sort_buffer_size = 2M
join_buffer_size = 2M
tmp_table_size = 96M
key_buffer_size = 8M
read_buffer_size = 2M
read_rnd_buffer_size = 16M
bulk_insert_buffer_size = 32M
 
#innodb
#只有部分小表保留InnoDB引擎,因此InnoDB Buffer Pool设置为1G基本上够了
innodb_buffer_pool_size = 1G
innodb_buffer_pool_instances = 1
innodb_data_file_path = ibdata1:1G:autoextend
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 64M
innodb_log_file_size = 256M
innodb_log_files_in_group = 2
innodb_file_per_table = 1
innodb_status_file = 1
transaction_isolation = READ-COMMITTED
innodb_flush_method = O_DIRECT

#tokudb
malloc-lib= /usr/local/mysql/lib/mysql/libjemalloc.so
plugin-dir = /usr/local/mysql/lib/mysql/plugin/
plugin-load=ha_tokudb.so
 
#把TokuDB datadir以及logdir和MySQL的datadir分开,美观点,也可以不分开,注释掉本行以及下面2行即可
tokudb-data-dir = /data/mysql/zabbix_3306/tokudbData
tokudb-log-dir = /data/mysql/zabbix_3306/tokudbLog
 
#TokuDB的行模式,建议用 FAST 就足够了,如果磁盘空间很紧张,建议用 SMALL
#tokudb_row_format = tokudb_small
tokudb_row_format = tokudb_fast
tokudb_cache_size = 44G
 
#其他大部分配置其实可以不用修改的,只需要几个关键配置即可
tokudb_commit_sync = 0
tokudb_directio = 1
tokudb_read_block_size = 128K
tokudb_read_buf_size = 128K

迁移过程

建议在一台全新的服务器上启动Percona(TokuDB)实例进程,初始化新的Zabbix数据库,直接将大表转成TokuDB引擎,并且开启分区模式。这样相比直接在线ALTER TABLE或者INSERT…SELECT导入数据都要来的快一些(我简单测试了下,差不多能快2-3倍,甚至更高)。

在做数据迁移时,建议在目标服务器上做库表结构初始化,在源服务器上采用分段方式导出,一个表导出多个备份文件,方便在恢复时可以并发导入。在导入时,并且记得临时关闭 binlog,最起码设置 sync_binlog = 0 以及 tokudb_commit_sync = 0,以提高导入速度。采用 mysqldump 增加 -w 参数即可实现根据条件分段导出,具体可参考上一次的文章:[MySQL FAQ]系列— mysqldump加-w参数备份,或者是用MySQLDumper

需要用到外键的表继续保留InnoDB引擎,其他表都可以转成TokuDB,history_str、trends、trends_uint、history、history_uint等几个大表是一定要转成TokuDB的,events由于需要用到外键,所以继续保留InnoDB引擎。

我将表结构初始化SQL脚本提供下载了,一份是没有采用分区表的,一份是采用分区表的,大家可自行选择。一般如果记录数超过1亿,就建议使用分区表,根据时间字段(clock)分区,方便后期维护,例如删除过期历史数据什么的。

收尾

剩下的基本没啥可做的了,就是观察下运行状态,是否还有个别慢查询堵塞。在我的环境中,一开始把items表也转成TokuDB了,结果有个画图的SQL执行计划不准确,非常慢。后来发现items表也需要用到外键,于是又转回InnoDB表,这个SQL也恢复正常了。

数据库初始化脚本我整理后提供下载了,大家可以直接使用。

附件1:不使用分区表附件2:使用分区表

适用版本:

Zabbix版本:Zabbix 2.2.0
TokuDB版本:Percona-5.6.17, TokuDB-7.1.6(插件加载模式)

如果还有什么问题,欢迎加入我的QQ群(272675472)讨论。

磁盘空间未释放异常案例

其实也谈不上异常,就是syslog-ng打开一个打日志文件准备传输时,该日志被logrotate给轮转了,gzip压缩后,文件被 deleted,但syslog-ng中文件句柄还在,结果导致磁盘空间一直未释放。有经验的SA发现磁盘空间实际使用和df显示的不一致时,一般都会用lsof检查是否有大文件标记为deleted,把该进程杀掉或重启下就可以了。