rds内核团队秘密研发的全自动卖萌机. 追加特效: 发数据库内核月报. 月报传送: http://mysql.taobao.org/monthly/
前言 上一篇文章 提过,我们在之后的文章中会从 optimizer 的选项出发,系统的介绍 optimizer 的各个变量,包括变量的原理、作用以及源码实现等,然后再进一步的介绍优化器的工作过程(SQL 语句扁平化处理、索引选择、代价计算、多表连接顺序选择以及物理执行等内容),本期我们先看一下众所
背景 最近处理了几起线上实例表膨胀的问题。表膨胀是指表的数据和索引所占文件系统的空间,在有效数据量并未发生大的变化的情况下,不断增大。PG使用过程中需要特别关注这方面,我们来给大家解析一下表膨胀的原因。 表膨胀的直接触发因素是表上的大量更新,如全表的update操作、大量的insert+dele
前言 很久很久以前,内核君发表了一篇HA方案·TokuDB热备的文章,方法很简单: SET TOKUDB_CHECKPOINT_LOCK=ON; 开始拷贝TokuDB的数据文件(不包含日志文件); FLUSH TABLES WITH READ LOCK; 记录binlog位置,拷贝最新的b
前言 PostgreSQL standby 可以通过两种方法来激活成为主库: trigger file,配置在recovery.conf中。 pg_ctl promote发送SIGUSR1信号给postmaster进程。 同时,PostgreSQL支持快速激活(fast promote)和非
前言 很多时候,RDS用户经常会问如何调优RDS MySQL的参数,为了回答这个问题,写一篇blog来进行解释: 哪一些参数不能修改,那一些参数可以修改; 这些提供修改的参数是不是已经是最佳设置,如何才能利用好这些参数; 哪些参数可以改 细心的用户在购买RDS的时候都会看到,不同规格能够提
AliCloudDB MongoDB在开发过程中遇到一个无法正常退出的BUG,由于是Release版本的编译(-O3),debuginfo已经不能很好的展现出堆栈的情况。这时又该如何确定问题所在呢?本篇文章完整的记录了整个排查过程。 场景 kill命令正常执行,但进程迟迟没有退出。非必现场景,在
背景 在日常的数据处理中,我们经常会有这样的需求:从一个文本中寻找某个字符串(比如某个单词)。 对这个需求,我们可以用类似这样的SQL完成:SELECT * FROM tbl WHERE text LIKE ‘%rds PostgreSQL%’;(找到含有“rds PostgreSQL”的文本)
前言 在前面几期关于 InnoDB Redo 和 Undo 实现的铺垫后,本节我们从上层的角度来阐述 InnoDB 的事务子系统是如何实现的,涉及的内容包括:InnoDB的事务相关模块、如何实现MVCC及ACID、如何进行事务的并发控制、事务系统如何进行管理等相关知识。本文的目的是让读者对事务系统
问题描述 bug 触发条件如下: 优化器先选择了 where 条件中字段的索引,该索引过滤性较好; SQL 中必须有 order by limit 从而引导优化器尝试使用 order by 字段上的索引进行优化,最终因代价问题没有成功。 复现case 表结构 create table t
前言 4月份月报有篇文章《行锁(row-lock)与区间锁(range-lock)》,介绍了 TokuDB 的行锁/区间锁是如何使用的。这篇文章是其姐妹篇,介绍TokuDB行锁的实现,大家可以对照着看。 行锁申请 与 InnoDB 类似,TokuDB 也支持行级锁用来协调多个 txn 对数据库
问题描述 表结构如下所示: show create table test\G Table: test Create Table: CREATE TABLE `test` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
本文我们从一个索引选择的问题出发,来研究一下 MySQL 中 range 代价的计算过程,进而分析这种计算过程中存在的问题。 问题现象 第一种情况:situation_unique_key_id mysql> show create table cpa_order\G *********
本文我们从一个索引选择的问题出发,来研究一下 MySQL 中 range 代价的计算过程,进而分析这种计算过程中存在的问题。 问题现象 第一种情况:situation_unique_key_id mysql> show create table cpa_order\G ***********
外键约束异常现象 如下测例中,没有违反引用约束的插入失败。 create database `a-b`; use `a-b`; SET FOREIGN_KEY_CHECKS=0; create table t1(c1 int primary key, c2 int) engine=inno
PG默认每个page的大小为8K,PG数据页写入是以page为单位,但是在断电等情况下,操作系统往往不能保证单个page原子地写入磁盘,这样就极有可能导致部分数据块只写到4K(操作系统是一般以4K为单位),这些“部分写”的页面包含新旧数据的混合。在崩溃后的恢复期间,xlog 里面存储的记录变化信息.
前言 在MySQL中,DDL是不属于事务范畴的,如果事务和DDL并行执行,操作相关联的表的话,会出现各种意想不到问题,如事务特性被破坏、binlog顺序错乱等,为了解决类似这些问题,MySQL在5.5.3引入了MDL锁(Metadata Locking),关于其设计思路可以参考这两个worklog
背景 我们打开MySQL客户端,执行下面的SQL语句: drop table if exists t; create table t(id double)engine=innodb; insert into t values(1e-15),(1e-16); select * from t;
背景 我们打开MySQL客户端,执行下面的SQL语句: drop table if exists t; create table t(id double)engine=innodb; insert into t values(1e-15),(1e-16); select * from t;
binlog拉取存在的问题 MySQL 主备之间数据同步是通过binlog进行的,当主库更新产生binlog时,备库需要同步主库的数据,通过binlog协议从主库拉取binlog进行数据同步,以达到主备数据一致性的目的。但当主库tps较高时会产生大量的binlog,以致备库拉取主库产生的binlo
背景 之前的月报中我们比较了InnoDB linear read-ahead和Oracle的multiblock read,两个的性能有所差别,具体可以参考月报详情。 这两种方式之所以带来了更高的吞吐量,都基于数据存储的连续性的假设,比如MySQL使用自增字段作为pk的InnoDB索引表,或者是
背景 你是否曾为Error on rename of './test/#sql-78fd_780371' to './test/t2' (errno: 150)这样的错误而不解,如stackoverflow上的这个问题? 下面我们来复现下: drop table t2; drop table