MySQL数据库服务器整体规划(思路与步骤)
MySQL数据库服务器整体规划(思路与步骤)
参考资料:
http://blog.51cto.com/zhilight/1630611
我们在搭建MySQL数据库服务器的开始阶段就合理的规划,可以避免以后的很多问题的产生,大大节省我们的时间和精力,在一定幅度上降低成本。当然,这会涉及到多方面。比如机器的选型、业务评估和系统规划等。
所有的设计都是跟具体的需求相关的,我们首先要做的就是对业务进行整体评估。我在下面分享一个具体的例子。
一、业务需求
要求 |
指标 |
响应时间 |
查询和操作请求ms级别返回 |
数据总量 |
1年内大约有500G的数据量 |
每秒请求量 |
每秒有3W的请求量 |
读写比 |
读写比是1:1 |
重要程度 |
核心业务,P1级别故障 |
其他说明 |
数据具有时效性,历史数据访问减少,一般处理最近7天内的数据,数据总体长度约为1K |
二、业务评估
步骤 |
结果 |
说明 |
step1 |
|
1年内数据量大约500G |
|
结果1 |
每秒产生的数据量为:500*1024*1024(365*24*60*60)=17KB |
step2 |
|
每秒3W次请求;读写比为1:1 |
|
结果2 |
每秒的读请求为15000次;每秒的写请求是15000次。 |
step3 |
|
记录的长度大约为1KB |
|
结果3 |
根据step1得出的结果,每秒insert的数据写入大约为17KB;根据step2得出的结果,每秒写入的请求为15000次,可得知14083(15000-17)次为update和delete操作之和。由于MySQL写入操作按照页来处理,页大小为16KB,假设每次操作的页都不相同,那么每秒写操作的数据量为16KB*15000=234MB。每秒读操作的数据量为16KB*15000=234MB。 |
step4 |
|
处理最近7天的数据 |
|
结果 |
热数据量为:(500/365)*7=21GB |
step5 |
|
操作ms级别返回 |
|
结果 |
操作ms级别返回,并且读写基本平衡。需要尽可能多的将数据加载到内存。按照内存命中率接近100%计算的话,那么innodb_buffer大约21G,而其他的则大约需要2-4G,因此按照30%的超配原则,操作系统内存大约需要32G(32.5G)。如果带宽也按照30%的超配原则的话,那么写带宽(wBPS)限制为304MB/s,读带宽(rBPS)限制为304MB/s。 |
三、硬盘选择
HDD类型的硬盘更善于处理一些顺序读写的内容,而SSD硬盘不管是顺序还是随机的性能都远远优于HDD的硬盘,但是SSD的硬盘价格必将昂贵。因此,我们可以通过合理的分配,降低整体拥有的成本。
例如,对于一些日志文件,这些日志文件主要是顺序IO,我们把这些文件放到HDD上,可以考虑使用RAID5S级别,提高日志系统的容错能力。对于数据文件,我们可以考虑放到SSD上,使用RAID10提高容错能力。
四、机型测试
性能对比测试:对于不同硬件设备在压力测试下数据库表现性能指标。对于硬件性能做出整体的评估。
稳定性测试:没有抖动现象,可以持续稳定的提供服务。
掉电保护测试:这个环节最好需要系统工程师配合。
内存异常测试:测试内存是否容易出现问题,能否对业务提供稳定的支持。
此外,还有IO设备和坏盘重构。
经过一系列的测试,我们可以选出2~3中候选机型,我们应当尽量避免应用和设备绑定,防止单个机型缺货,供应不足影响业务。
五、成本评估
通过前面的一些列的准备工作,我们可以选出候选的机型,考虑我们的使用成本。这包括:
设备成本
运维成本
功耗成本
特别注意:我们虽然有的时候单机使用成本会上升,但是整体的使用成本却下降了。这是因为我们提升了单个机器的性能,可以减少机器的数目。降低运维和功耗的成本,甚至也降低了整体设备的成本。
六、文件系统规划
MySQL数据库的特点:
(1) 单数据目录(单个实例不能执行多个数据库)
(2) 混合读写(日志和数据的读写方式是不一样的)
(3) 请求随机
文件系统划分:
/dev/sda1 /boot
/dev/sda2 /
/dev/sda3 /home
/dev/sda4 /tmp
/dev/sdb1 /data
/dev/sdc1 /log
根据使用经验,建议IO调度策略为deadline的方式:
echo deadline > /sys/block/sd{b,c}/queue/scheduler
MySQL数据库日志文件是顺序读写的,建议放在普通的SSD硬盘上。
-- binlog日志文件、error日志文件、slow日志文件可以放在/log日志目录中
-- tmp文件指定为系统的目录/tmp
-- 其他所有的目录指定为数据目录/data
注意:虽然日志文件是随机读写的,但是由于把几个日志文件都放在一个分区,还是可能产生随机读写的现象。
七、其他实例
业务评估需求 指标
相应时间 查询和操作要求ms级别返回
数据总量 1年内大约1T数据
美妙请求量 大约1W次请求
读写比 读写比例 4:1
重要程度 核心系统,p1级别故障,
其他说明 数据具有时效性,历史数据访问较少,一般会处理最近15天内的数据,数据记录总长度大约有1kb
一年产生的数据为1T,每秒产生的数据为
1T*1024*1024*1024/(365*24*3600)=34kB/s
每秒一万次请求 读写比里4:1(qps) 读请求的比较为8000 写请求(tqs) 2000
然后一条数据插入大约有1kb,每秒就应该是34次插入(insert),然后update delete应该该是就是1966次。然后数据库的操作是按照页来处理,页的大小为16KB,假设每次操作的页都是不相同的,那么每 秒要操作16kB×2000=32M/s 每秒的读操作应该是128MB/s。
是一个具有时效性的数据,处理近15天的数据,那么需要就需要1T/365*15=42G。
要求毫秒级返回 需要尽可能的把数据加载到内存中 那么innodb buffer 至少42G,其他大约需要3G。
按照30%的超配原则:内存大约需要60G内存,标准为64G内存的机器;写带宽因该约等于40MB/s(wbps); 读带宽(rbps)应该是166MB/s。