Infobright出现坏表的可能及处理

rezic

1.可能出现数据损坏的情况

理论上，在Infobright进行大量写操作时，如果发生突然中断（如关闭所有Infobright进程、服务器断电等），可能发生表损坏。其中表损坏分为两类：

数据块损坏和知识网格损坏

2.Infobright数据块损坏：

由于Infobright采用高压缩算法，在存储数据时尽量避免了冗余，当数据损坏后，几乎是不可逆的。需要删除后建表，从原始数据中重新插入或导入。

但在实际测试环境进行模拟时，用多线程大量DML语句（包含Load）操作数据时，切断服务器电源。反复约20次，重启数据库，操作均成功回滚，未发生数据损坏。

且经查阅Infobright社区论坛，未发现用户有数据块损坏情况的反馈。

3.Knowledge Grid损坏：

当高频率批量进行单个update操作时，后台进程频繁更新知识网格（耗时极短），若发生中断，可能造成知识网格损坏，但不损坏实际数据，只影响Infobright查询性能。

当发生这类损坏时，为提高查询性能，可采用Infobright Consistency Manager进行修复。

语法如下：

cd /infobright_path/bin

./icm --datadir=/usr/local/infobright/data [datadir] --knfolder=/usr/local/infobright/data/BH_RSI_Repository [knfolder] #--database=test [database] --table=icmtest [table]

附：断电测试说明

基表icm ：包含随机数字和随机字母组合，数据行数：一亿两千万

并发一：insert into icm2 select* from icm;

并发二：delete from icm3 limit 50000000;

并发三：update icm4 set name=’MMMMMMM’ where id <200;

并发四：load data infile ‘/tmp/icm.dat’ into table icm5;

同时运行2min后断电，重新启动后

select count(1) from icm2;行数为未插入前行数；

select count(1) from icm3;行数为未删除前行数；

select count(1) from icm4 where name=’ MMMMMMM’;返回结果为0；

select count(1) from icm5; 行数为未导入前行数；