-
Notifications
You must be signed in to change notification settings - Fork 13
db_006
目录
[MySQL manual 参数说明] https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html
[Percona MySQL配置文件生成工具]https://tools.percona.com/dashboard
- 方法1: 可以在mysql中用
show variables;
来查看启动时默认的参数。 - 方法2: 打印变量到一个文本文件。
(bash) $~ mysql -u root -pXXXXX -e "show variables;" > XXXXX.txt
配置文件存在/etc/my.cnf
, /etc/mysql/my.cnf
, ~/.my.cnf
中。
要在参数前面写一行,e.g.
[mysqld]
innodb_buffer_pool_chunk_size = 128M
innodb_buffer_pool_size = 512M
innodb_flush_method = O_DIRECT
- 数据存在哪了
决定于datadir参数、innodb_data_home_dir参数和innodb_data_file_path参数。对于InnoDB来说,如果第二个为空,则按第一个datadir存储。在我用编译安装的MySQL5.5中,datadir默认在/usr/local/mysql/data
, 在我用包管理器安装的MySQL 5.7中,datadir默认为/var/lib/mysql
。注意改变datadir重启前要运行下面的命令减弱SELINUX的干扰:sudo setenforce 0
- 数据刷盘策略
关于log和data文件的buffer缓存刷新方式的参数innodb_flush_log_at_trx_commit和innodb_flush_method,详见:关于InnoDB bufferpool的flush method
- InnoDB buffer pool的大小设置
innodb_buffer_pool_size 是bufferpool总大小, innodb_buffer_pool_chunk_size 是一个bufferpool块的大小,官方文档中innodb_buffer_pool_size的说明:
Buffer pool size must always be equal to or a multiple of innodb_buffer_pool_chunk_size
* innodb_buffer_pool_instances
. If you alter the buffer pool size to a value that is not equal to or a multiple of innodb_buffer_pool_chunk_size
* innodb_buffer_pool_instances
, buffer pool size is automatically adjusted to a value that is equal to or a multiple of innodb_buffer_pool_chunk_size
* innodb_buffer_pool_instances
that is not less than the specified buffer pool size.
- 最大连接数
max_connections
可以设定mysql的最大连接数,这里在sysbench测试线程开得太大时就会遇到受到限制的情况,因为默认为151,所以sysbench测mysql oltp性能的时候,如果thread数大于151会测试失败,对于怎么改参见以下网页:详情
https://dev.mysql.com/doc/refman/5.7/en/innodb-raw-devices.html
以下为copy (http://www.aichengxu.com/mysql/51853.htm )
[置顶]
MYSQL高性能IO之日志裸设备+数据裸设备+SSD cache,有需要的朋友可以参考下。
目前,数据库公认的最快的IO方式是读写裸设备,ORACLE数据库一般配置,日志和数据全部存放到裸设备上。
MYSQL目前支持数据存放到裸设备,本身不支持日志文件的裸设备,但是只需要简单的步骤就可以实现全裸设备,如下:
初次使用裸设备要先初始化:
sudo service mysql stop;
sudo nano /etc/mysql/my.cfg
//修改my.cfg的内容innodb_data_file_path=raw1:1837455Mnewraw, 其中配置数据的大小一定要比空间的实际大小少1M,以便存放数据块结束标志
//其中newraw表示将初始化raw设备。
// 修改innodb_log_file_size=16G, 其中配置数据的大小等于日志文件或者分区的大小
sudo rm /var/lib/mysql/ib_data1 // 删除默认数据文件
sudo ls -l /dev/bcache0 // 显示裸设备节点号, 这里是使用了带bcache的硬盘分区,用户应根据自己的实际选择
sudo mknod /var/lib/mysql/ib_data1 b 251 0
sudo chown mysql:mysql /var/lib/mysql/ib_data1
sudo chmod 660 /var/lib/mysql/ib_data1
sudo service mysql start; // 开始初始化裸设备数据块,以及日志数据文件
sudo cat /var/log/mysql/error.log // 显示数据,观察初始化进行情况,直到执行完毕
// 将初始化/var/lib/mysql/ib_data1对应的分区,并且生成 /var/lib/mysql/ib_logfile0, /var/lib/mysql/ib_logfile1 这2个文件
sudo service mysql stop;
sudo nano /etc/mysql/my.cfg
//修改my.cfg的内容innodb_file_path=raw1:1837455Mraw,
MYSQL本身不支持日志文件的裸设备,
但是通过linux命令mknod指定硬链接后,就可以支持裸设备,将提供最高的IO性能, 具体的方法就是:
分一个与日志文件同样大小的分区, 然后用dd拷贝日志文件内容, 通过linux命令mknod指定硬链接后,就可以支持裸设备
sudo dd if=/var/lib/mysql/ib_logfile0 of=/dev/md1p2 bs=1M; // 拷贝日志文件到分区
sudo dd if=/var/lib/mysql/ib_logfile1 of=/dev/md1p3 bs=1M;
ls -l /dev/md1p2; // 显示设备的节点号,后面mknod用
ls -l /dev/md1p3;
sudo rm /var/lib/mysql/ib_logfile0; // 删除日志文件
sudo rm /var/lib/mysql/ib_logfile1;
sudo mknod /var/lib/mysql/ib_logfile0 b 259 1; // 做裸设备分区的硬链接,把分区内容作为文件的内容
sudo mknod /var/lib/mysql/ib_logfile1 b 259 2;
sudo chown mysql:mysql /var/lib/mysql/ib_logfile0
sudo chown mysql:mysql /var/lib/mysql/ib_logfile1
sudo chmod 660 /var/lib/mysql/ib_logfile0
sudo chmod 660 /var/lib/mysql/ib_logfile1
sudo service mysql start;
sudo cat /var/log/mysql/error.log // 显示数据,观察数据库系统启动情况,将发现系统完全正常。
这样就实现了日志裸设备+数据裸设备的高性能IO配置, 比文件方式快很多。
我目前的MYSQL数据库linux系统,习惯上分区方式,一个/根分区,分配SSD1的12G, 1个backup分区做系统的备份,分配SSD2的12G, 2块SSD剩余的几百兆空间做soft raid1,做硬盘磁盘阵列的ssd cache, 使用的软件是bcache或者flahcache。
bcache不支持LVM2分区加速,支持soft RAID,bcache安装使用中遇到的问题比较多,默认的参数比较保守,仔细规划使用后,绕过几个挖坑的故障点,是基本可用的,虽然bcache目前的用户不多,由于性能突出,未来的前景本人更看好。
bcache目前只做一个cache主数据分区,使用中发现如果多个cache,每次启动每个cache名称对应的物理设备会随机变化,为了绕过这个坑,只做一个cache或者使用UUID目录,也可以解决这个问题。
bcache以桶的方式分配空间,一般要求设置桶大小为擦除块的大小,目前最新intel SSD存储芯片的擦除块是8M(16KB*512), bcache只能支持到4M, 超过4M的参数将出错。我只好先用4M的桶对付着用。
bcache虽然支持指定数据块的大小,默认是512字节,但是实际测试发现指定数据库的16Kbyte,内部还是会出错的,因此,就采用默认的512字节吧,这样就又绕过一个坑。
bcache有大量的参数,比flashcache要多很多,并且参数的默认参数比较保守,优化中修改的数量比较大,并且修改后重新启动,下次需要重新设置,为了方便,将修改命令全部放到启动sh中,保证下次启动参数重新加载。
bcache也支持write back, 但是参数当中,默认启动拥塞控制,最好关闭;否则,将可能在大并发下切换为write through方式。
bcache的部分参数,虽然能够修改,但是随时被bcache自动修改,例如:write_back的后台回写量。
bcache总体比较复杂,性能比较高,但是各类资料稀少,并且存在一些明显的BUG, 使用中需要注意, 今后我将单独写一篇博客具体写bcache的优化。
flashcache比较可靠,目前很多重量级用户都在使用,例如阿里巴巴等,几乎不会遇到什么问题,并且支持LVM2分区的加速,flashcache性能不够好,对SSD的磨损大。
一个RAID1+0磁盘阵列分出一个/var分区,大小是36G,用于存放数据(本人的习惯是分配为内存大小+4G),其余空间分为3个裸分区,分别为16G(本人的习惯是分配为内存大小一半),16G, 其余全部空间做数据的裸设备。2个16G的分区是MYSQL的日志文件ib_logfile0与ib_logfile1的裸设备,最后一个分区是ib_data1的裸设备。
目前 ubuntu系统已经内置了 bcache和flashcache, 这足以说明SSD cache是大势所趋, 使用将越来越广泛。
ubuntu下的安装命令是:
flashcache : sudo apt-get install flashcache-utils;
bcache : sudo apt-get install bcache-tools;
以上,总结了一下, MYSQL的服务器高性能IO的分区方式,希望能够给大家帮助。
- ZFS
[MySQL Innodb ZFS Best Practices]https://blogs.oracle.com/realneel/entry/mysql_innodb_zfs_best_practices
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
Wiki: wiki.jcix.top ~聚沙成塔~ Blog: blog.jcix.top