infobright是开源的基于mysql的数据仓库(data warehouse)
商业版叫IEE(InfoBright Enterprise Edition)
还有个免费的社区版,叫ICE(InfoBright Community Edition)
infobright的特点:
- 是列存储的(一般数据库都是行存储的)
- 拥有非常高的压缩率
- 大量数据的检索非常快
同时
社区版的infobright不支持更新数据的操作
反之,商业版的支持
这样的话
感觉社区版的infobright就非常适合用来存储备份log了
试想啊
谁会要去更新备份的log呢?
而且:
高压缩比正好节省空间;
大量数据的高速检索正好用来做日志分析
赞一个:
infobright简直就是为了日志备份而生的!
这个简单的需求来自于:
我们的服务器都是有公网地址的
而且大多跑mysql都是一些小的应用
不可能单独做一台mysql服务器
所以disable掉公网地址的方法不是完全可行的
而出于安全考虑,我不想mysql也监听公网ip的3306端口
在my.cnf里倒是可以用bind-address来帮定mysql监听的ip地址
这里可以设置成私网地址
但是除了私网ip,我还想mysql监听127.0.0.1的3306端口
人说hostname是localhost(ip是127.0.0.1)的时候缺省会通过socket来连mysql
但是这又存在一个socket设置的问题
而且,万一客户端就是要连127.0.0.1的3306口那又怎么办呢
多监听一个localhost的3306口又不费资源也不会有额外的安全性问题
为什么不一次弄好呢
所以,综上所述
我还是希望mysql能够同时监听私网ip和127.0.0.1这两个ip地址
但目前my.cnf中的bind-address显然做不到
官方明确表示bind-address只支持一个参数
或者是绑定所有ip
而且有人已经将这个需求提交到bug.mysql.com里了
我有个mysql库
里面有个server表
其存储ip地址的是一个unsigned int(10)的变态的数据类型
其存储的数据是ip地址的
((第一字节*256+第二字节)*256+第三字节)*256+第四字节
因此,表里的ip地址数据相当的不直观
程序里倒无所谓
写个自函数转一下就可以了
但我如果要在mysql控制台、直接sql语句里显示直观ip信息呢
该怎么办呢
今天终于碰到这么个问题
翻了翻mysql文档
原来mysql直接支持算术运算符+、-、*、/,甚至连取余%都支持
再结合取整函数floor()、字串连接函数concat()
问题解决了
select concat(floor(ip/(256*256*256)), “.”, floor(ip/(256*256))%256, “.”, floor(ip/256)%256, “.”, ip%256) as ip_s, product, role, contact from server
今天
把个系统从一台机器上挪到另外一台机器
由于牵涉到数据库升级
(原来的是4.1.x,中文数据编码是gbk;新的是5.0.x,中文数据编码想用utf-8)
所以就比较留心
首先把数据dump出来
mysqldump db1>db1.sql
然后传到新的服务器上
scp db1.sql xxx.xxx.xxx.xxx:/tmp/
再在新的机器上做编码转换
iconv -f gbk -t utf-8 db1.sql>db1utf8.sql
再倒入新的库
mysql db1
然后发现web页面显示需要选gbk才不乱码(跟在老机器上一样)
最后在老机器上dump时加参数指定缺省character-set
mysqldump --default-charcter-set=latin1 db1>db11.sql
这样做的数据拷到新机器上后
再
iconv -f gbk -t utf-8 db11.sql>db11utf8.sql
再倒入
就没有问题了(库里存的是utf8的数据了)
mysql_stats
需要在被检测的mysql库里添加检测机器的权限(仅需要process权限):
grant process on *.* to username@192.168.1.1 identified by ‘password’;
flush privileges;
也算是需求推动
产品那边需要在一台fc3(fedora core 3)的机器上装上php5
并且要启用pdo_mysql支持
偶,额滴神呀
幸好以前在别的机器上手工编过php5.x(具体版本5.2.5)
赶紧从那台机器上把php5.2.5拷过来
并把原来的./configure连同编译参数都调出来
再加上个–with-pdo-mysql重新configure一下
再make
make的时候出错了
不知道原因在哪儿
后来在网上搜了下
找了种折衷的办法
说是先编好php5
然后再把pdo_mysql的支持编进去
cd php5.2.5/ext/pdo_mysql
phpize
./configure
make
make install
这样居然成功了
再接着改php.ini
把编出来的pdo_mysql.so正确load进来
这样居然成功了!!
在控制台上直接执行php test.php
系统出错:
“PHP Warning: mysql_connect(): Client does not support authentication protocol requested by server”
于是就在本机控制台用命令
mysql -h 192.168.1.1 -u user -p
(这里192.168.1.1是mysql服务器ip)
再输入密码来连
这样没有问题
然后在192.168.1.1把程序拷过去
直接执行
然后又没有问题
当时就有点困惑了
这两台机器一样的php-mysql版本呀
一样的mysqlclient版本呀
可为什么一个能连一个出错呢
要说对client那台机器的权限有限制
但是在client那台机器上直接用mysql客户端程序也能连呀
于是
似乎陷入困境
mysql官网对这个错误的解释是老板本的mysql和新版本的mysql的密码格式不兼容
如果用老板本的mysql client去连新版本的mysql server
如果mysql server上的密码格式是新格式的话
就会出这个错误
显然,本例就是这样
最后问题解决后
才发现其实一开始分析问题的时候就出现了偏差
其实知道问题的原因是由于client的版本和server上存储密码的格式相关
那么就应该去确认这两台机器一台连不上一台没问题他们分别的client版本和server上的密码格式的
如果是这样
一开始就去服务器端
use mysql
select * from user where User = ‘user’;
一看就知道了
原来有条记录
Host正好是client的ip
client连过来的时候正好是匹配这条记录
但是其密码格式是新格式
而client上的mysql client版本是老板本
不出问题才怪呢!!
再看看从服务器上通过连为什么又没有问题呢
原来还有条记录
Host是’192.168.1.%’
他的密码格式是老格式的
服务器上连过来的时候正好是匹配这一条记录
自然OK
这样解决起来也就容易了
直接将写着client ip的那条记录删掉就好了
今天写了个小程序
用来监测某些机器上的某些进程是否存在
需要从mysql中查出ip和进程字串
然后从中控上一台一台ssh上去ps查进程是否存在
如果状态变化(原来标记不存在的现在有了,或是原来标记存在的现在没有了)
还需要更新mysql库中的相应状态字段
因为查询出来的数据比较多(600多条)
而且我还要一台一台ssh上机器检测进程
等我发现某台机器的某个进程状态改变要update库的时候
数据库报错:
MySQL server has gone away
查了好些资料
也没找出原因来
最后按照文档上建议的
先判断
然后再执行mysql_query
function connect(){
$db = mysql_connect(‘xxx.xxx.xxx.xxx’, ‘xxx’, ‘xxxxxx’);
mysql_select_db(‘db1′);
return $db;
}
if (!$db){
mysql_close($db);
$db = connect();
}elseif(!mysql_ping($db)){
mysql_close($db);
$db = connect();
}
mysql_query(“$sql”);
不管怎么样
这个问题算是解决了
不过说实话:为什么我还是没搞明白
:)
在mysql的官方网站上找到几个用tcpdump来抓在mysql server上跑的sql语句
# — (1.1) To capture all traffic on the interface eth0, run:
time tcpdump -i eth0 -s 1500 -w 20060427-db-traffic-01.dmp
# — (1.2) To capture traffic on the interface eth0 coming from a specific IP address, run:
time tcpdump -i eth0 -s 1500 src host 192.168.2.10 -w 20060427-db-traffic-01.dmp
# — Press Ctrl+C — do not leave tcpdump running infinitely on high traffic interfaces
# — (2) To process the results, run:
strings 20060427-db-traffic-01.dmp | grep -i ’select’ | awk ‘{printf(“%s %s %s %s\n”, $1,$2,$3, $4);}’| sort| uniq -c | awk ‘{printf(“%06ld %s %s %s %s\n”, $1,$2,$3,$4,$5);}’|sort
还有一句诗:
tcpdump -l -i eth0 -w – src or dst port 3306 | strings
今天下午用前面提到的init-connect方法把一个mysql3.23.58的库倒到了5.0.x的库里
然后领导说,怎么那个什么页面还是乱码呀
他说的那个我知道,因为是用root用户直接连库的(init-connect的设定不生效)
于是我就胸有成竹的告诉领导是连库用了root用户的原因
然后我就在程序里把用户该成了一个普通用户
再一刷页面
“怎么还是乱码呀”
一下子,我的汗都出来了
“怎么会呀,那天测试过的,没有问题的”
于是我又重新倒库的sql语句iconv折腾了几下
重新倒库
还是不行
我仔细回想了上次测试的过程
最后,灵光一现:会不会是这个普通用户也有问题呀?
因为当时我给这个用户赋权限的时候因为其要access多个库
于是我就是用grant all privileges on *.*这种方式搞的
这样比较奇怪,我一般都是指定了某个数据库,很少有这样用”*”代替数据库名赋权限的
所以我就进mysql查了下
use mysql;
select User, Super_priv from user;
果然,这个“普通用户”的Super_priv是’Y’
而相应其他的用户(除了root)都是’N’
按照文档,具有”super”权限的用户连上mysql库,是会被忽略init-connect参数的
而php程序如果不指定,却省是用的latin1来连接数据库的
所以就乱码了呀
知道了原因,再改起来就容易了
update user set Super_priv = ‘N’ where User = ……
flush privileges;
一下就好了
最近评论