RHEL中基于OS来统计某进程使用的IO;
今天在安装和使用STAP时碰到一个问题。 # stap disktop.stp semantic error: libdwfl failure (missing x86_64 kernel/module debuginfo under '/lib/modules/2.6.18-164.11.1.el5/build'): No such file or directory while resolving probe point kernel.function("vfs_read").return[@more@]semantic error: no match while resolving probe point vfs.read.return semantic error: no match while resolving probe point kernel.function("vfs_write").return semantic error: no match while resolving probe po
DML对QUERY CACHE 处理过程之源码分析
问题: 当一个大的SELECT查询在运行时,会把UPDATE堵住; SHOW INNODB STATUS看,UPDATE的状态是:invalidating query cache entries SELECT结束,现象消失。 版本号:mysql 5.1.40 首先说明一下,QUERY CACHE 只有一把全局锁。private: Cache_lock_status m_cache_lock_status;下面说到的锁,就是这个全局独占锁。[@more@]MYSQL在处理SELECT过程中,对QUERY CACHE会有两个操作:High.Performance.MySQL.Second.Edition.pdf -- P1611) 在SQL PARSE 之前,就会先到QUERY CACHE里去找,是否有这个SQL的CACHE;如果有,就把结果前直
xtrabackup 全量与增量备份恢复
今天简单介绍一下 MYSQL 免费热备工具 XtraBackup , 特别是几个使用时值得注意的地方。这里首先代表所有使用者感谢PERCONA的无私贡献。 1. 下载XtraBackup并安装 当前最新的版本是1.6 ,从这里可以选择不同OS的相应版本: http://www.percona.com/downloads/XtraBackup/XtraBackup-1.6/[@more@] 在LINUX下你可以直接运行:wget http://www.percona.com/redir/downloads/XtraBackup/XtraBackup-1.6/RPM/rhel5/x86_64/xtrabackup-1.6-245.rhel5.x86_64.rpmrpm -ivh xtrabackup-1.6-245.rhel5.x86_64.rpm2. 数据库中建立备份账号 GRAN
让drop table更快
曾经发文介绍过,DROP table XXX ,特别是碰到大表时,http://www.mysqlops.com/2011/02/18/mysql-drop-table-%e5%a4%84%e7%90%86%e8%bf%87%e7%a8%8b.html在DROP TABLE 过程中,所有操作都会被HANG住。这是因为INNODB会维护一个全局独占锁(在table cache上面),直到DROP TABLE完成才释放。在我们常用的ext3,ext4,ntfs文件系统,要删除一个大文件(几十G,甚至几百G)还是需要点时间的。 下面我们介绍一个快速DROP table 的方法; 不管多大的表,INNODB 都可以很快返回,表删除完成;[@more@]实现:巧用LINK(硬链接)实测:root@127.0.0.