ITPub博客

今天在安装和使用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

问题： 当一个大的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；如果有，就把结果前直

今天简单介绍一下 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 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.

记得以前，当出现：ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction，要解决是一件麻烦的事情 ；特别是当一个SQL执行完了，但未COMMIT，后面的SQL想要执行就是被锁，超时结束； DBA光从数据库无法着手找出源头是哪个SQL锁住了； 有时候看看show engine innodb status , 并结合 show full processlist; 能暂时解决问题；但一直不能精确定位；在5.5中，information_schema 库中增加了三个关于锁的表（MEMORY引擎）；innodb_trx ## 当前运行的所有事务innodb_locks ## 当前出现的锁innodb_lock_w

在以前的版本中，一个事务请求表的“元数据锁”直到“语句”执行完毕；（这个时候整个事务没有完成）；这个时候，如果有人执行了DDL语句（如DROP table，可以马上执行）；那么在BINLOG日志中，会先记录drop table ,再记录事务的相关语句（因为事务后COMMIT）；这时候到SLAVE上面去应用就会报错；[@more@]在5.5中，这个表的“元数据锁”一直到整个"事务"全部完成后才会释放 ；这也意味着当一个表被一个事务使用（哪怕只有SELECT），在事务结束前就不对这个表作DDL；这样也就可以避免上面说到的日志顺序错误的问题；以下是原文：I

在之前版本，碎片回收操作是主线程的一部分，这经定期调度的方式运行，但会阻塞数据库的其他操作；[@more@]到5.5以后，可以将这个线程独立出来 ；方法：innodb_purge_threads =1 这个应该能让碎片回收得更及时而且不影响其他线程的操作；Improved Purge Scheduling - The InnoDB purge operation is a type of garbage collection that runsperiodically. In previous versions, the purge was part of the master thread, meaning that it couldblock other database operations when running. In MySQL 5.5 this operation can run in

1) 用正式表达式 regexp "[u0391-uFFE5]" 2) 用length和char_length[@more@] drop table t1; create table t1 ( id varchar(200)) default charset=utf8 ; insert into t1 values ('中文'),('sdalfkj'); 1)用正式表达式 regexp "[u0391-uFFE5]"root@127.0.0.1 : test 21:55:33> select id ,id regexp "[u0391-uFFE5][u0391-uFFE5]" from t1;+---------+--------------------------------------------+| id | id regexp "[u0391-uFFE5][u0391-uFFE5]" |+---------+---------------------

昨天鹰眼需求从一个大表（27G）删除47026788数据；用存储过程通过主键删除实现；用了1个小时50分钟； QPS=47026788/(60*110)=7125.2709这个速度已经满快了，都是随机读；[@more@]当时我在想，MASTER用近两个小时，是不是SLAVE也用这么长时间么；到SLAVE一看，根本没有SQL在跑；而且表里数据已经被清空；通过测试，我们发现MASTER在应用存过时，在BINLOG里记录的是真正最后执行的DML操作；比如： #101202 13:58:43 server id 2 end_log_pos 15842 Query thread_id=4058 exec_time=0 error_code=0SET TIMESTAMP=129126952

InnoDB buffer pool 被设为两个SUBLIST：一个是存放大部分查询所需用到的块；另一个是存放小量查询所需用到的块；并可以被回收；[@more@]The InnoDB buffer pool is divided into two sublists: A new sublist containing blocks that are heavily used by queries,and an old sublist containing less-used blocks and from which candidates for eviction are taken. InnoDB buffer pool 被设为两个SUBLIST：一个是存放大部分查询所需用到的块；另一个是存放小量查询所需用到的块；并可以被回收； In the default operation of the buff

Mysql半同步SLAVE，类似于ORACLE安全模式的DATAGUARD（但不完全是）；为什么是半同步呢，因为MYSQL只保证“至少一个”SLAVE接收到日志后返回； 虽然可能不会有太多的人去用这个东西（因为对网络的要求和机器的稳定性很高）；但MYSQL还是补全了这一块的功能缺失[@more@] A commit performed on the master side blocks before returning to the session that performed the transaction until at least one slave acknowledges that it has received and logged the events for the transaction. Semisynchronous replication is

在5.1版本中，slave 从MASTER拿到日志后，写到relay-log,并进行SQL应用；在这里注意，写到RELAY-LOG，指的是先写到 “OS cache”的relay-log，而不是马上刷新到磁盘上；什么时候刷新还依赖于操作系统的CACHE刷新时间；[@more@]如果在这期间，一个日志刚同步到"relay-log @os cache ",而没有被刷新到"relay-log @disk", OS CRASH, 那么这个日志将丢失；（这个问题不用担心：MYSQL会在重启后重新从MASTER获取日志）同样存在一致问题的相关SLAVE文件还有：relay-log.info ; master.info; 如果这两个文件发生不一致，问题

# 在5.1版本上，这FILE_IO这一块MYSQL只用了4个线程来处理IO；# 但在5.5上，随着对多线程的更强支持；INNODB也加强了对IO读写线程的支持；更多发挥多线程的优势 ；# IO线程默认增加到了10个；（配太多也没用，因为IO能力有限，需要配合特殊机型）# 其实这个在5.5.0就已经增强了，不过在这里讲也不晚；[@more@]### 5.1# innodb_file_io_threads# The number of file I/O threads in InnoDB. # Normally, this should be left at the default value of 4, but disk I/O on Windows may benefit from a larger number.# On Unix, increasing

MYSQL 5.0.68 on RHEL 5u4 本实验主要是想看一下，INNODB 页何时被回收，何时被重新利用； 数据文件何时扩展，按多少比例扩展等；[@more@]MYSQL 5.0.68 on RHEL 5u4 Innodb Record 组成 ：--------------------------- Field Start Offsets ：(F*1) or (F*2) bytes ，F=字段个数Extra Bytes ：6 bytes Field Contents ：三个系统字段（ROWID,TXID（6B）,PID（7B） ） + 数据内容； 如果有主键，ROWID=PK；Innodb PAGE 组成 (16K)： ---------------------------Fil Header ： 38BPage Header：

If you want to Import data from dat file to Mysql , May be you will choose : Load Data infile; Normally, you will create a table without index (include primary key) ,then load the data , then create the index ; But ,I found after load data and create primary key , "select count(*) from T" is so slowly. [@more@]#### ENV OS:RHEL 5U4 MYSQL: 5140 Engine: Innodb #### Create Table ; CREATE TABLE `http_auth1` ( `username` varchar(64) NOT NULL, `pass` varchar(200) DEFAULT NULL, `co

# Mysql 5140 @ RHEL 5u4 X86_64 [@more@]# 先提供一些表的信息:===================================================================root@127.0.0.1 : trac_apsara 17:18:46> show create table wiki G*************************** 1. row *************************** Table: wikiCreate Table: CREATE TABLE `wiki` ( `name` longtext COLLATE utf8_bin, `version` int(11) DEFAULT NULL, `time` bigint(20) DEFAULT NULL, `author` longtext COLLATE utf8_bin, `ipnr` longtext COLLATE utf8_bin, `text` longtext

接同事需求，要求从SQLITE的数据转到MYSQL，这东西以前也没接触过。这里搜搜，那里试试，下面把过程列一下。 主要过程分三步：1，把SQLITE表结构导出来，作一定的格式调整2，把SQLITE数据导出来，作特殊字符的处理3，导出MYSQL（注意字符集）[@more@]下面是我操作的过程， 有两个部分：单表操作和批量处理（含脚本） ########### 单表操作 ##################### 打开SQLITE DBroot> sqlite3 mig.db # 查看表,可用用".help"获得帮助sqlite>.tables # 导出数据表结构sqlite>.output /tmp/heyf/createtable.sqlsqlite&gt

TEST STEP6：用"constraints_parser"试着从一个PAGE（找到INDEX_ID相对应的文件夹）中找出你的数据TEST STEP7: 如果你觉得你的数据没有问题，那么你可以将所有的表连接起来（cat *.page > table.page），用此方法恢复所有的数据.把数据导回表中[@more@]TEST STEP6：用"constraints_parser"试着从一个PAGE（找到INDEX_ID相对应的文件夹）中找出你的数据---------------------- || cd /opt/percona-innodb-recovery-tool || [root@localhost percona-innodb-recovery-tool]# ./constraints_parser -5 -U -f pages-

TEST STEP3：得到表定义文件：table_defs.hTEST STEP4：编译percona-innodb-recovery-tool，makeTEST STEP5：将数据表空间拆分成N个16K大小的PAGE[@more@]TEST STEP3：得到表定义文件：table_defs.h （可以用create_defs.pl自动产生），并替换include/table_defs.h.---------------------- || [root@localhost percona-innodb-recovery-tool]# perl create_defs.pl --table=recover1 || #ifndef table_defs_h || #define table_defs_h || || // Table definitions || table_def_t table_definitions[] = { || { ||

下面我们来看一个实例，用来恢复被TRUNCATE的数据----------------------------------------------[@more@]TEST STEP 0：创建测试环境：----------------------MYSQL 5140 at RHEL 5u4 X86_64use test;create table recover1 (id int auto_increment , c1 varchar(50), c2 varchar(100) ,primary key (id) ) engine=innodb;insert into recover1(c1,c2) values ('aaaaaa','bbbbbb');insert into recover1(c1,c2) select c1,c2 from recover1 ;insert into recover1(c1,c2) select c1,c2 from recover1 ;insert into recover1(c1,c2) selec