Chinaunix首页 | 论坛 | 博客
  • 博客访问: 14256
  • 博文数量: 10
  • 博客积分: 210
  • 博客等级: 二等列兵
  • 技术积分: 115
  • 用 户 组: 普通用户
  • 注册时间: 2011-04-24 11:33
文章分类
文章存档

2011年(10)

我的朋友
最近访客

分类: Mysql/postgreSQL

2011-09-13 17:44:16

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; 行数为未导入前行数;

阅读(1074) | 评论(0) | 转发(0) |
0

上一篇:Infobright数据仓库需注意的SQL数据类型

下一篇:没有了

给主人留下些什么吧!~~