数据库

混合存储中Flashcache使用的误区以及解决方案

1

Flashcache是facebook释放出来的开源的混合存储方案,用ssd来做cache提升IO设备的性能.很多硬件厂商也有类似的方案,比如说LSI raid卡. 但是这个方案是免费的软件方案,而且经过产品的考验,具体参见:
主页:https://github.com/facebook/flashcache
开源混合存储方案(Flashcache):http://blog.yufeng.info/archives/1165
Flashcache新版重大变化:http://blog.yufeng.info/archives/1429

但是flashcache在使用中很多人会有个误区,导致性能很低。首先我们看下flashcache的设计背景和适用场景:
(更多…)

RethinkDB & TokuDB调研测试报告

5

点击 这里 下载

MySQL Temporary Table相关问题的探究

12

问题的引入

让我们先来观察几条非常简单的MySQL语句:

mysql> create temporary table tmp(id int, data char(20));
Query OK, 0 rows affected (0.00 sec)

mysql> create table tmp(id int, data char(20));
Query OK, 0 rows affected (0.00 sec)

mysql> drop table tmp;
Query OK, 0 rows affected (0.00 sec)

mysql> drop table tmp;
Query OK, 0 rows affected (0.00 sec)

mysql> drop table tmp;
ERROR 1051 (42S02): Unknown table 'tmp'

这是丁奇提出的引导性的问题,几条语句看似简单,不过接下来我们提出的一连串问题与进
行的研究可都是围绕它们来的!

看到以上语句,你很容易会产生类似于以下的疑问:

1. 上述语句在一个session中先后创建了两个名为’tmp’的table,只不过一个是temporary
table,一个是normal table。问题来了:temporary table为何可以与同名的normal table
共存?

2. 上述语句成功执行了两条DROP TABLE语句,那么每一条语句操作的对象是哪个table呢?
亦即同名的temporary table与normal table之间的优先级关系是如何的?

很好,有了问题就知道了前进的方向!接下来我们就从这两个问题入手,由浅入深,开始我
们的探索之旅吧!
(更多…)

淘宝软件基础设施构建实践

4

这个PPT是在第三届中国云计算大会上讲过。主要讲目前淘宝在软件基础设施的规划、实践和一点感悟。注:我们将来在这方面开展的工作会不限于这些。

简介:

首先,简单介绍淘宝网的系统规模和增长速度,以及对软件基础设施带来的挑战;接着,回顾淘宝图片存储与CDN系统的发展历史,如何从商用系统一步一步走到完全自主的系统,描述自主系统的主要架构与设计思想、性能指标和现有的部署规模,并总结一些经验来指导系统研发;然后,描述淘宝在软件基础设施上的规划,并一一阐述当前主要项目的要点与进展状况,这包括TFS、TAIR、千亿级别的分布式表格系统OceanBase、MySQL优化、面向Java环境的专用计算平台、服务器平台、Linux内核定制与优化、组通讯夸父、CDN和低功耗服务器平台等;最后,总结一下软件基础设施研发的原则和经验。

MySQL concat + outfile的bug原因分析

0

项目中碰到一个bug,需要将MySQL表中的数据导出,字段中间用逗号隔开

1、复现 

步骤:

版本 5.1.48

a) 准备数据

CREATE TABLE `test` (   `id` int(11) DEFAULT NULL,

     `data` char(10) DEFAULT NULL

     ) ENGINE=InnoDB DEFAULT CHARSET=gbk;
(更多…)

淘宝商品库MySQL优化实践(QCon Beijing 2011)

5

在刚刚结束的Qcon 2011北京会议上我做了以下的分享:

淘宝商品库是淘宝网最核心的数据库之一,采用MySQL主备集群的架构,特点是数据量大且增长速度快,读多写少,对安全性要求高,并发请求高。

演讲内容包括淘宝商品库硬件的选型决策, 安全性和性能的平衡,特别是创新引入PCI-E Flash卡和Flashcache作为Cache提高IO性能,在保证安全性的前提下就包括MySQL、InnoDB引擎、文件系统、系统Page Cache、 IO调度算法、DM层(Flashcache)、Raid卡、设备驱动在内的整条IO路径的Cache进行优化,进一步挖掘了系统IO的潜能,重点介绍优化过程中的一些经验教训、测量手段和工具。

玩得开心!

InnoDB的log写入策略及主从同步

3

      ib_logfile是InnoDB的事务日志文件。ib_logfile与bin-log共同控制事务恢复。本文简要说明其写入时机、写入策略, 以及分析系统异常对主从数据一致性的影响。

1、              基本概念 

     a)        ib_logfile文件个数由innodb_log_files_in_group配置决定,若为2,则在datadir目录下有两个文件,命令从0开始,分别为ib_logfile0和ib_logfile1.
(更多…)

mysql的事务管理机制

1

这里mysql 事务管理机制,只讲述在mysql 是如何管理事务,不包括存储引擎的实现。当前mysql的存储引擎中只有innodb实现了事务的ACID,并且实现机制和oracle是一致的,主要使用了mvcc的实现理论。
本文主要讲述在存储引擎上,mysql公共层的事务管理机制,mysql的事务分两种,一种是标准的事务,也叫normal transaction ,还有一个叫statement transaction。其中normal transaction是标准的实现ACID的事务,而statement transaction是就是一个语句是一个事务,就是在mysql发展中一开始是支持nested transaction,后来觉得在normal transaction中假如有nested transaction,假如normal transaction rollback或者commit,其实nested transaction都是需要rollback后者commit。而statement transaction不是一种标准事务,它来自于BerkeleyDB,就是把每个statement都叫做statement transaction,其实是个nested transaction,而且statement transaction是符合”all or nothing”标准,就是说它提交了,是可见的, visible, but not durable,可见也是在parent transaction和其他的同一个parent transaction的nested transaction。
平时我们可以设置mysql autocommit为true,其实这里是只有statement transaction,没有normal transaction,就是把每个statement transaction当作一个normal transaction。 (更多…)

mysql 5.5已经发布

2

mysql5.5已经发布了,提高了很多性能,同时可用性也提高不少,就是不知道里面未修复的debug多不多.以前mysql 推出6.0 GA版,还觉得不错,增加了 falcon的存储引擎,falcon是带行缓存的,就是不知道为啥当前数据库都是page buffer,不在里面放一个record buffer,当前一些web 应用,数据其实相对离散,record buffer可能利用率更高.可惜,falcon主创人JimStarkey已经离开mysql,JimStarkey是InterBase项目的发起人,在数据库实现领域也有名气,是将多版本并发控制技术应用于数据库产品的第一人,也是BLOB数据类型的创始人,falcon项目进展很缓慢.所以oracle继续开发了5版本,发布了5.5版本
先面说下mysql5.5主要改进点:
 · 改进的性能和可扩展性:MySQL数据库和InnoDB存储引擎已得到更新,Metadata Locking (MDL) Framework替换了原来的LOCK_open mutex (lock),以在运行于最新的多CPU和多核硬件及操作系统上时,提供最佳性能和可扩展性。此外,在5.5版中,InnoDB是MySQL数据库的默认存储引擎,可提供ACID交易、参照完整性和应急恢复。
(更多…)

在改进mysql主从复制中遇到memroy leak问题

4

最近在做mysql主从复制的改进, 把单线程的SQL thread(mysql的主从复制,只有两个线程,一个是向master要日志,并写入文件,我们叫IO threa,一个线程读日志, 并进行redo,我们叫SQL thread) 改造成多线程.后来经过发现,如果对master压力比较大,slave会落后master比较多,而已性能瓶颈主要在SQL thread.
后来大家编写完成,并通过了功能测试,然后进行压力测试,经过一个晚上发现,内存会张上去, 一个晚上会增加80m,然后第二天用valgrind跑, 发现一点leak都没有,包括reachalbe,感觉奇怪,后来自己再review自己代码,发现new的地方后有对应的delete.后来看我利用的mysql自己代码地方, 发现有如下代码
class Sql_alloc
{ (更多…)

Go to Top