mysql datadir nvme_MySQL数据库场景中NVMe SSD的优化

当开启Doublewrite buffer，MySQL会将内存中Doublewrite buffer的数据先写到共享表空间中，然后再写到磁盘上的数据文件。当系统掉电时，即使数据库的一个page没有完整的写入磁盘，InnoDB也可以从共享表空间的doublewrite space中找到该页的一个最近的副本，将其复制到数据page，再应用redo log，完成数据恢复操作。

InnoDB存储引擎Doublewrite实现原理

从Doublewrite原理可以直观的发现这一技术带来了近2倍的写操作，以此降低数据不一致的风险，但也会降低系统性能，另一方面，传统的doublewrite buffer被所有buffer pool instances和flusher threads所共享，这也会导致的性能瓶颈问题。

但是由于磁盘性能低，所以基于磁盘的数据库系统对于Doublewrite buffer带来的性能下降并不敏感，而且磁盘寿命也不会因此受到严重影响。但对于SSD而言，这个延迟造成的系统性能瓶颈效应十分明显，并且会降低SSD的使用寿命，Memblaze给出了相应的解决方案。本文接下来就会重点以Percona数据库场景为例解读Memblaze的混合介质的多命名空间管理技术。

混合介质的多命名空间管理

多命名空间是NVMe SSD一项基础而重要的技术，双端口等功能都高阶功能都需要基于多命名空间实现。在DTCC2019大会上，朱磊介绍了Memblaze的混合介质的多命名空间管理解决方案，通过拓展多命名空间(Multi-namespace)的功能，NVMe SSD可以实现对 DRAM/NAND 等不同存储介质的统一管理。如此便可将将MySQL的共享表空间放置在SSD内速度较高的内存(或者其他高寿命高性能的介质)中，而数据文件(.ibd)还仍然存在NAND上。而两个区域通过不同的namespace进行隔离。

具体实现如下图。

混合介质多命名空间技术

(可以将Doublewrite space或者整个ibdata1放在高寿命高性能介质中，建议UNDO SPACE从ibdata1中分离出来单独存储在NAND NS空间)

当前DRAM介质Namespace和NAND介质Namespace被SSD统一的FTL管理,同样提供Block接口给Host端, 这个方案最大程度了简化了应用对DRAM Namespace的使用,方便用户对不同应用使用不同介质的Namespace。

Percona：改良后的Doublewrite buffer技术

在验证测试之前，需要介绍一下MySQL数据库发行版Percona对传统Doublewrite buffer进行改良形成的Parallel Doublewrite Buffer。Percona给每一个buffer pool instance私有的doublewrite buffers，1个buffer pool instances会分配2个 doublewrite shards, 每个shards近1MB。

8个buffer pool instances分配16个doublewrite shards,近32MB

一个flusher线程只能访问一个shard，shard完成flush是独立的,这样消除了锁,并且可以并发的flush,此时瓶颈只在于异步IO完成的速度。Percona Doublewrite space已经被单独分离为一个文件(非tablespace)，这个文件包含所有buffer pool instances对应的shards，每个shards有不同的offsets。

在下一步的测试中也会基于Percona的Parallel Doublewrite Buffer进行配置。

TPCC测试验证混合介质管理方案的收益

在我们的验证测试中，共创建了了28000个数据仓库(对应测试数据量为3TB)，并分别获取4、8、16、32、64个并发进程下的结果。

测试环境及基本配置

Server：PowerEdge R730xd

CPU: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz 8 Cores * 2

Memory: DDR4 96GB

Memblaze PBlaze5 910 NVMe SSDs:

SSD配置1：3.84TB U.2 SSD with 3.84TB namespace * 1 (nvme0n1)

(Percona配置1：datadir=/data1, innodb_doublewrite=on, innodb_parallel_doublewrite_path=/data1/xb_doublewrite)

SSD配置2：3.84TB U.2 SSD with 3.80TB namespace * 1 (nvme3n1) and 64MB DRAM Namespace *1 (nvme3n2)

(Percona配置2：datadir=/data1, innodb_doublewrite=on, innodb_parallel_doublewrite_path=/DWB/doublewrite.file)

2. Centos 7.4 with NVMe driver 1.0, ext4 filesystem

3. Percona MySQL 8.0.15

从环境配置信息可以看到，测试使用了两块PBlaze5 910 NVMe SSD，其中一块有1个namespace，另一块有两个namespace(其中一个是64MB的DRAM)，Percona的配置也与SSD配置匹配起来。与预期一样，当Doublewrite被放在DRAM的命名空间上时，系统性能得到了提升、同时NAND的数据写入量有了大幅下降。下面是测试结果的展示和解读。

将Innodb parallel double write file放置在DRAM Nanmespace, 性能在64并发下提升35.49%。

我们进一步得到了SSD性能提升的数据。如下：

SSD平均随机读IOPS和随机读带宽提升38.3%;

SSD平均随机写带宽提升37.1%;

SSD平均随机读延迟减少7.4%;

SSD平均随机写延迟减少52.6%。

64线程下两种SSD配置测试结果对比

不仅性能提升效果明显，NAND的数据写入量也得到了30%的降低，写放大直降46%。这对于NVMe SSD的寿命和性能都是一个好消息。

HOST写数据量与NAND写数据量以及写放大对比

在Memblaze的这一混合介质的多命名空间管理的方案中，DRAM介质Namespace和NAND介质Namespace被SSD统一的FTL管理,同样提供Block接口给Host端, 这个方案最大程度了简化了应用对DRAM Namespace的使用，方便用户对不同应用使用不同介质的Namespace。

总结

当前Memblaze PBlaze5系列产品NAND Namespace的写性能在小压力下已经优化到近DRAM的性能，但是在大压力下NAND介质的性能瓶颈开始凸显。DRAM Namespace可以解决NAND Namespace的性能瓶颈，所以在大压力下TPCC MySQL将double write file放在DRAM Namespace后的性能表现极大的优化了。

就其方案实现而言，对不同介质的管理以及保证SSD的可靠性是难点。需要深入理解DRAM、NAND(未来还会有PCM等新存储介质)的特性，并结合大规模的验证测试。数据库往往是一个企业最为关键的应用，任何数据丢失和不可靠因素都是不能忍受的。

现在这一方案还并不完美，这里我们总结了方案的限制以及下一步优化方向：

1. 由于使用了DRAM NS，所以掉电保护需要更多的电容，但当前DWB MB级别的容量需求对增加电容容量的要求不大；

2. DRAM为易失性介质，并且价格较贵，所以SSD一般使用较小容量的DRAM。可以考虑在SSD中使用PCM等其他非易失性介质代替DRAM, SSD统一管理PCM Namespace和NAND Namespace, 由PCM承载MySQL的ibdata1(含Double Write Buffer File,但需要剔除较大的undo log)；

3. 对于不支持innodb_parallel_doublewrite_path设置的MySQL,需要设置datadir、innodb_log_group_home_dir、innodb_undo_directory、log_bin等目录在NAND Namespace，而放置ibdata1在DRAM或者 PCM Namespace。

关系型数据库历经数十年发展演进，已经有非常成熟的技术保障数据一致性和系统可靠性，Doublewrite buffer就是其中的代表。NVMe SSD作为新一代主流的高性能存储设备，正处于快速普及的阶段，应当针对数据库的读写机制进行深入研究，给出相应的解决方案，而非改变数据库本身的运转机制。另一方面，数据库还在不断发展，随着数据库与NVMe SSD的持续磨合，双方未来的配合将越来越默契。