生产数据库架构改造方案

生产数据库性能优化方案（初稿）

1.背景

生产数据库上线一段时间后由于数据量远大于预期，导致数据库性能低下而影响正常业务，故需要对数据库进行性能优化。

2.现状

当前数据库结构如下图所示：

图2-1 系统结构示意图

上游三个数据源通过DI工具以定时任务的方式将上游数据抽取到基础数据库中（红色部分），从基础库到下游目标库则是通过用户操作应用程序将基础数据库中的数据调度到目标数据库中。根据目前对数据量的统计基础库约为400GB+的数据总量。

目前基础数据库的性能低下，主要表现于定时抽取任务执行时间过长，任务间的时间间隔变短；应用执行数据调度时间过长，导致应用长时间处于无响应状态。

3.分析

基础数据库获取上游数据时，数据传输量较大，数据库写操作频繁，操作系统层表现于数据文件所在磁盘写IO高，并持续时间长。

由于基础库放数据到下游数据库是人为操作，数据库读操作频繁，操作系统层表现于数据文件所在磁盘读IO高，且经常会与DI定时任务同时执行，通过系统监控发现磁盘出现大量IO等待状态。

图 3-1 磁盘IO状态

图 3-2 磁盘等待状态

由于基础库保存原始数据并不对数据进行处理，所以CPU消耗很低，从监控看CPU不视为性能瓶颈点。

图3-3 CPU使用率

从以上分析可以判断数据库操作性能低下主要在高磁盘IO时造成IO挣用较大导致拖慢整体性能。故本次优化将重点放在解决磁盘IO挣用问题和提高磁盘IOPS上。

4.优化方案

本着应用层变动最小的原则，为解决基础库磁盘IO性能低下问题，我们将从三个方面着手进行，即：优化数据库物理架构、优化DI任务执行时间

和优化数据库数据文件所在Path的磁盘VG结构。

4.1.优化数据库物理架构

根据基础库的业务特点，这里将对基础库的读写操作进行分离（即：读、写分离）。这样做的好处在于可以最大限度规避数据库读、写同时操作

所带来的磁盘IO挣用问题。调整后的架构如下图：

数据库采用主/从模式，使用binlog复制方式实现数据同步。由于考虑

到大数据量复制可能带来的同步延迟问题，实现时需要注意优化复制线程参数。

4.2.优化DI任务执行时间

为了避免多任务同时写一个数据库产生磁盘写IO过高的问题，需要对每

一个DI任务的执行时间进行估算，并根据磁盘性能合理编排任务并行度。同时还需要考虑数据单位时间内的数据增长量对任务执行时间的影响，避免由于数据量的增加延长任务执行时间而导致的任务并行执行。

4.3.优化磁盘VG

提高磁盘IOPS最有效的方法就是增加通过增加物理磁盘数量并实现条带化来提高整体的IOPS。但随之带来的硬件投资成本也会增加。这里我们可以通过将现有磁盘更换成等容量的小磁盘，目的是为了增加磁盘数量从而提高整体磁盘IOPS性能。如：当前一块磁盘容量为600GB，我们可以将其拆解成6块100GB Raid5磁盘或者12块50GB Raid5磁盘进行VG条带化处理。

5.实现

5.1.资源规划

硬件资源：

服务器2台

数据磁盘12块50GB Raid5磁盘（每台服务器）

软件资源：

CentOS 7.1 x86_64 (mini installed)

MySQL 5.7 x86_64

5.2.磁盘配置

分别将两台服务器的各12块Raid5磁盘初始化并创建VG。在创建LV时特别注意要制定LV所跨PV的数量从而实现VG条带化。

指定磁盘文件系统为xfs。

5.3.数据库部署配置

安装MySQL数据库并配置两台服务器的主从模式，将从库定义为Read_only模式。

配置binlog复制线程数。

优化数据库内存模型。

导入数据

5.4.应用配置

将用于数据调度的应用程序数据源从原来的数据库服务器IP地址改为只

读数据库服务器IP地址。

6.测试

实施完成后为保证最终优化效果，将对系统各个关键环节进行性能测试。测试将分为如下三个阶段。

6.1.磁盘性能测试

VG创建好后，确保磁盘可写的前提下使用dd命令对磁盘的读、写分

别进行性能测试。读、写测试将各进行5次从而选出最合适的磁盘块大小。使用10GB文件大小，每次创建块大小分别为4k、8k、16k、

32k和64k，并记录每次测试的时间结果。

6.2.数据库性能测试

数据库性能测试可以使用tpcc-mysql等其他第三方性能测试工具进行，

并生成测试报告。

6.3.业务测试

最后在实际业务中测试DI运行的时间和数据调度的响应时间，通过模拟真是业务操作对系统性能进行测试评估。