ibdata1恢复数据_MySQL数据库场景中NVMe SSD的优化

Dear 丶 2023-01-10 13:09 231阅读 0赞

在DB-Engines Ranking的榜单上，虽然Oracle、MySQL和SQL Server前三的地位仍是不可撼动的。作为一家专注于NVMe SSD设计研发的厂商，Memblaze关注的是NVMe SSD在数据库中的应用及系统优化。近日召开的DTCC2019上，Memblaze产品部朱磊的演讲就围绕着MySQL的Doublewrite原理以及PBlaze5的优化方案展开。

**成为系统瓶颈的Doublewrite buffer**

关系型数据库将原子性、一致性、隔离性和持久性(ACID)作为事务的四大基本属性，数据库日志、存储引擎等等核心组件的设计都围绕着事务的四个基本属性展开，Doublewrite就是为了保障掉电等极端情况下数据一致性的。

MySQL的InnoDB的page size一般是16KB，其数据校验也是针对这16KB来计算的，MySQL数据库通常使用O\_DIRECT方式绕过文件系统cache直接写后端NVMe SSD。所以MySQL将16KB IO通过NVMe Driver发送到NVMe SSD，但是NVMe SSD在处理16KB IO时可能根据各个SSD Vendor的算法会并发拆分为4个4KB IO处理。当系统意外掉电会破坏这一操作的原子性，会有IO没有写完而造成的partial page write(部分页写入)风险。

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

![cdc4266277982f6e276b1a1aa1abf094.png][]

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进行隔离。**

具体实现如下图。

![69f039035bef651723ba4b4914f7a42a.png][]

混合介质多命名空间技术

(可以将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。

![750c7e3b11b929191b84f62a6448cd52.png][]

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 R730xdCPU: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz 8 Cores * 2Memory: DDR4 96GBMemblaze 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 filesystem3. Percona MySQL 8.0.15

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

![68aefef562913e8e352c590e1e4f7bce.png][]

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

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

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

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

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

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

![b69e5f28d750caf27909fab627b3c3a5.png][]

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

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

![448d3b8fd2636c01991bf9d1ee951e79.png][]

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的持续磨合，双方未来的配合将越来越默契。

[cdc4266277982f6e276b1a1aa1abf094.png]: /images/20221119/695bad4fc15d4fd3b6f60d52af82e15c.png
[69f039035bef651723ba4b4914f7a42a.png]: https://img-blog.csdnimg.cn/img_convert/69f039035bef651723ba4b4914f7a42a.png
[750c7e3b11b929191b84f62a6448cd52.png]: https://img-blog.csdnimg.cn/img_convert/750c7e3b11b929191b84f62a6448cd52.png
[68aefef562913e8e352c590e1e4f7bce.png]: https://img-blog.csdnimg.cn/img_convert/68aefef562913e8e352c590e1e4f7bce.png
[b69e5f28d750caf27909fab627b3c3a5.png]: https://img-blog.csdnimg.cn/img_convert/b69e5f28d750caf27909fab627b3c3a5.png
[448d3b8fd2636c01991bf9d1ee951e79.png]: https://img-blog.csdnimg.cn/img_convert/448d3b8fd2636c01991bf9d1ee951e79.png