MySQL数据库服务器整体规划(思路与步骤)

参考资料：

http://blog.51cto.com/zhilight/1630611

我们在搭建MySQL数据库服务器的开始阶段就合理的规划，可以避免以后的很多问题的产生，大大节省我们的时间和精力，在一定幅度上降低成本。当然，这会涉及到多方面。比如机器的选型、业务评估和系统规划等。

所有的设计都是跟具体的需求相关的，我们首先要做的就是对业务进行整体评估。我在下面分享一个具体的例子。

一、业务需求

要求	指标
响应时间	查询和操作请求ms级别返回
数据总量	1年内大约有500G的数据量
每秒请求量	每秒有3W的请求量
读写比	读写比是1:1
重要程度	核心业务，P1级别故障
其他说明	数据具有时效性，历史数据访问减少，一般处理最近7天内的数据，数据总体长度约为1K

二、业务评估

步骤	结果	说明
step1		1年内数据量大约500G
	结果1	每秒产生的数据量为：50010241024(3652460*60)=17KB
step2		每秒3W次请求；读写比为1:1
	结果2	每秒的读请求为15000次；每秒的写请求是15000次。
step3		记录的长度大约为1KB
	结果3	根据step1得出的结果，每秒insert的数据写入大约为17KB；根据step2得出的结果，每秒写入的请求为15000次，可得知14083(15000-17)次为update和delete操作之和。由于MySQL写入操作按照页来处理，页大小为16KB，假设每次操作的页都不相同，那么每秒写操作的数据量为16KB15000=234MB。每秒读操作的数据量为16KB15000=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。