存档

文章标签 ‘MySQL’

InnoDB的IO优化

2014年5月9日 3,317 views 没有评论

    InnoDB的IO优化

突然要临处理线上数据库问题,等待的过程太久, 马马虎虎写了点对于IO的优化。

状态不佳,凌晨1点,要睡觉了。作为一个IT人,要切记充分锻炼、充分休息。

 

对于传统数据库的IO优化,一般有几个方向,如1, 减少数据库的写入。2,使用时间换空间,比如压缩。3,利用物理设备的空间时间 局部性(Locality)特征。4,把随机读写转换成顺序读写。5,缓存数据,一般传统数据库都有自己的buffer pool 。

以下简单说说具体的实现,Innodb的常用的参数、大家已知的定义、设置、作用我就不细说了。大家可以google下具体的参数作用。

减少page size    一些第三方版本早就实现了自定义的page大小,MySQL官方版本高版本才有提供此功能,低版本的话,你可以用源码编译的方式实现,如果不是追求极致的话,不建议源码编译的方式改变page size,因为可能没有经历过大规模的考验。InnoDB的压缩技术可以考虑用下,对效率和空间上取得平衡,一般16KB使用2倍压缩,8KB使用2倍压缩是可行的。

关闭 do[……]

Read more

MySQL升级到5.6

2014年4月22日 1,113 views 没有评论

开发/测试环境,建议先升级到5.6,升级到MySQL 5.6的步骤如下,以官方二进制版本为例:

假设目录路径如下

ll /usr/local/mysql
lrwxrwxrwx 1 root root 39 Oct 23 2013 /usr/local/mysql -> /usr/local/mysql-5.5.34-linux2.6-x86_64

/usr/local/mysql/里面的 数据目录/日志目录 我们都是用的符号链接,这样可以更方便升级。

以下步骤均在root下执行

1、备份下数据,可以使用mysqldump备份下;

2、关闭MySQL实例

2、下载官方二进制版本 MySQL 5.6; http://dev.mysql.com/downloads/mysql/

3、删除符号链接 /usr/local/mysql, 解压缩 mysql到/usr/local下,并建立新的符号链接 mysql指向它

4、配置相应的实例的配置文件,注意数据目录正常可访问

5、启动实例

6、确认启动成功

7、运行如下命令[……]

Read more

分类: 互联网技术 标签:

delete very large file in Linux using truncate

2013年4月27日 1,167 views 没有评论

If your OS file system is ext3, You will encounter performance problems when you delete very large files.

You can use truncate command to shrink the size of a file step by step to avoid performance problems.

For RHEL6,  truncate command is installed by default.

For RHEL5, you need to install truncate command manually.

I write a script to wrap the command truncate.

[code]

#!/bin/bash
## invoke truncate command to delete very large file(size more than several G BytesG)
# Inst[......]

Read more

分类: 互联网技术 标签: ,

MySQL网络优化 生产实践:网络层

2013年2月1日 4,331 views 没有评论

MySQL网络优化

发一篇自己的笔记…

1.需要清楚自己的网络架构.了解专线的延时对性能的影响,对应用服务器做适当调整,可能需要redirect访问;
2.使用mrtg or cacti监控流量;
3.跨idc的网络完全不能和idc内网质量相比,且速度可能成为问题,国内的网络还可能出现骨干网异常;
4.应用服务尽量避免访问外部的网络资源(特别是慢速网络);
5.跨IDC做复制,其实本质上是为了安全,就是其他机房有一份数据,而不是为了实时同步,也不能要求必须是实时同步,
6.跨IDC的复制,可以启用压缩.

可能导致Mysql服务异常的网络因素:
1. 丢包 (即使1%的丢包也会导致严重性能问题) ;
2. dns服务慢(可使用 skip_name_resolve 解决) ;
3. TCP backlog 的设置,设置大点无可厚非; os参数net.core.somaxconn,net.ipv4.tcp_max_syn_backlog适当设置;
4. 流量瓶颈 . PCIe SSD IO太强,可能网络成为瓶颈, Mysql中间层也需要留意;
5.[……]

Read more

MySQL中间件的一些思考

2013年1月30日 7,756 views 没有评论

MySQL中间件的一些思考

下午特地花2个多小时 做了一些思考. 本着分享的精神,摘录了工作邮件的部分内容发这里. 希望能帮到有同样需求的人.  我说的中间件是代理所有的请求访问,  相对于应用路由,会有一些性能上的损耗,适合流量大点的业务.

=====================
1.需以集群的思路去设计,部署和维护,所有模块的安装,部署,启动,关闭,监控,收集信息,都在一个统一的平台(界面)完成;举一些例子: 可以直观得看到某个应用的TPS,以及response time,需要关注资源的使用情况,报警…..略….
2.关于mha里日本老外实现的日志补齐功能: 要看应用是否能接受丢失少量记录,其实大部分公司大部分应用可以接受的.这个开发成本较高,而且需要权限能访问到二进制日志.  5.5的半同步复制,5.6的全局事务日志 都可以让以后的日志更安全可靠,高可用变得更简单 ,还是让MySQL来做更专业的事吧.
3. 中间件的方案引入了一定开销,相对比应用直接判断路由,效率会低些,但这个不太重要. 主要的缺陷是引入了单点, 所以中间件(Proxy)自身需要实现[……]

Read more

MySQL复制注意事项 复制生产实践:Mysql复制

2013年1月26日 4,414 views 没有评论

MySQL复制注意事项

上一次博客还是9月份, 近半年工作实在太忙, 学习计划也大半停滞, 博客也没有更新了. 计划年前补上每个月的一篇 .

基本原理:
在主库的二进制日志里记录对数据库的变更,然后在从库重放这部分日志(异步).
1. 一般用来扩展读,但对于扩展写没什么用.扩展写的办法只能是sharding(partitioning) 数据.
2. 由于目前5.1,5.5的复制是单线程的,所以很可能复制成为瓶颈. 网上有说淘宝DBA在5.1上实现了多线程复制. 但是现在ssd盘并不贵,我的建议是使用ssd来突破瓶颈,一般情况下使用ssd突破了,就不太会出现滞后了.

3. 不要使用复制的许多高级特性,,可以看看mysql的bug列表,往往都是些高级特性,非核心特性导致的,而且Mysql的复制的限制和坑比较多,一定要保持自己的简单架构, 使用普通的主-从就足够了,没有必要使用特殊的链式复制,环形复制, Blackhole引擎.  如果是主从,就全部复制,主从数据所有配置,数据,硬件都一样, 不要使用什么花哨的手法,比如主库指定复制某个些库,从库忽略某个库,这些手法往[……]

Read more

分类: 数据库 标签: , ,

配置MySQL日志服务器

2013年1月22日 3,940 views 没有评论

配置MySQL日志服务器

关于log server的配置.参考 http://mysqlsandbox.net

使用log server 利用复制来进行时间点恢复而不是用mysqlbinlog来进行,更加可靠,稳健. 如下是搭建的简单步骤:
配置步骤如下:
1. 部署安装
下载mysql二进制官方安装包 wget mysql-5.1.58-linux-x86_64-glibc23.tar.gz
下载sandbox
wget https://launchpad.net/mysql-sandbox/mysql-sandbox-3/mysql-sandbox-3/+download/MySQL-Sandbox-3.0.28.tar.gz
useradd sandbox
usermod -G mysql sandbox
解压到目录 /home/sandbox/pkgs/MySQL-Sandbox-3.0.28/
安装参考
# as normal user
export PATH=$HOME/usr/local/mysql/bin:$PATH
##export[……]

Read more

一个图,InnoDB缓冲和文件

2012年10月26日 1,137 views 没有评论

一个图,InnoDB缓冲和文件的交互。

 

2222

分类: 数据库 标签: ,

MySQL半同步导致幻读

2012年9月9日 2,048 views 没有评论

 MySQL半同步导致幻读

MySQL的半同步是个很好的特性,不过我并没有在生产环境中启用过,担心的主要是网络的延迟影响了事务吞吐。

如果我们启用半同步,肯定是有相当重要的数据,但不容忽视的情况是,半同步会导致幻读。

出现幻读的场景是:Innodb提交了事务,此时从库还没有接受二进制日志, 但另一个新的线程仍然可以读取到提交后的数据。 如果此时宕机了。那么虽然我们曾经读取到了数据,但这个数据在从库机器上并不存在。

所以,我们读取到了新的数据,但在崩溃后,这份数据就不存在了,我们管这个叫“幻读”

这种情况,由于效率和安全不可兼得, 在许多数据库产品都存在,但既然启用了半同步,肯定是希望能更稳健些。

enhanced-semi-sync-replication  这个方案就是一个更稳健的方案。

转两张图,对比下原来半同步的改进。

原来的半同步机制

1a

 

改进后的

2

 

 

 

分类: 数据库 标签: , , ,

mysql基准测试模型(4) 基准测试的不足.

2012年8月21日 3,645 views 没有评论

mysql基准测试模型(4)    基准测试的不足.

1. 不容易测试其他的系统特性:稳定性,安全性,扩展性,可用性,灾难恢复性等等 ;
2. 没有计算成本(磁盘,内存,…..) ,但即使计算了成本,也可能被厂商欺骗,厂商会使用最优的配置,以尽可能低的成本支撑更大的吞吐;
3. 没有衡量能源消耗;
4. 没有考虑到复杂的网络环境;
5. 用户考虑得是 这个产品能够满足何种服务品质协议(service-level agreement) (比如说99.99%的时间是可用的) ,而基准测试考虑的更多是能够达到的平均分数.
一般报告列出的可能是80-90%的的系统资源使用率,不考虑系统资源严重瓶颈,而现实中往往并非如此,在系统资源严重瓶颈下的的性能,安全性,稳定性可能急剧下降.

分类: 数据库 标签: ,