提升应用性能、降低TCO的新利器

Bertha 。 2022-09-02 14:45 167阅读 0赞

![1e6aad746cce6d2389d9a7773b001db2.gif][]

‍![3a0c4f59a0ef9ad8c9eb2e9496bd29e2.png][]‍

‍

##  ##

*  对于应用的性能提升，行之有效的方法可能有如下几种：
 *   *  直接的办法！  
        \* 砸钱堆硬件！花钱就能变得更强！但这也是最费钱的办法！
     *  折中的办法！  
        \* 最省钱的办法就是买便宜的能用的就行！但这可能满足不了性能提升的需求，如果既想要提升性能，又想要降低成本，那就可能需要花钱请牛人从硬件到软件、从单机到集群、甚至到架构层面的大量优化了，不过此法虽然可行，但大概率无法避免应用适配开销与试错时间开销，需要花较多的精力在两者之间来回取舍
     *  便捷的办法？  
        \* 有没有既能提升应用性能，又能降低TCO的更简单便捷的方法呢？  
        \* 有，来自ScaleFlux的一款采用TLC/QLC NAND闪存介质的新型NVMe SSD产品CSD 2000(CSD 英文全称 Computational Storage Drives ，即计算存储驱动器，更多信息详见"2. 什么是 CSD")，在其透明压缩/解压特性的加持下，相比不带透明压缩/解压特性的同档次普通NVMe SSD，在数据可压性较高的业务场景中，它不但能够大幅提高性能、更能够大幅降低TCO、甚至是大幅延长SSD设备的使用寿命
 *  那么CSD 2000设备究竟是怎样的高科技利器呢？它是如何做到既能提高性能、又能降低TCO、还能够延长设备使用寿命的呢？
 *  下面我们按照如下顺序依次由浅入深地进行展开介绍
 *   *  NAND 存储介质有哪些
     *  什么是 CSD
     *  CSD 价值体现
     *  CSD 应用现状
     *  CSD 未来展望

# **1.NAND 存储介质有哪些** #

*  相信接触过SSD（固态硬盘）的朋友，或多或少都听说过 SLC、MLC、TLC、QLC甚至是PLC等技术术语，那么这些技术术语都是什么意思呢？
 *  简单来说，这些技术术语其实指的是按照NAND闪存介质内单个电子单元(Cell)中可以存储的不同比特(bit)数量来对NAND闪存介质的不同分类。根据单个Cell中可以存储的不同bit数量（类似如图1-1所示，图片来自TechTarget），可将NAND闪存介质分为SLC、MLC、TLC、QLC、PLC（详见表1-1所示）
 *  时至今日，SLC和MLC已逐渐淡出主流应用场景（SLC主要应用在高速缓存等特殊场景中、MLC主要应用在于工业等特殊领域中）；TLC是时下绝对的主流（目前数据中心数据库场景中大多使用TLC NAND的SSD，例如：Intel P4510/P4610系列等）；而对于QLC，与TLC相比，有着容量更大、价格也更便宜的优势，但缺点也十分明显（例如：P/E Cycles即寿命几乎是TLC的五分之一，随机写IOPS更是比TLC低1~2个数量级，可靠性也比TLC更差），这些缺点是由QLC本身的电器特性决定的，当QLC设备中发生写放大时，其随机写性能和寿命都会有惊人的下降，因此在数据中心级的业务场景中目前使用并不多（如果此时有类似CSD这样自带透明压缩/解压特性的产品来大幅减少QLC设备中的写放大，其随机写性能和寿命不仅不会下降，反而还会有大幅的提升，详见"3. CSD 价值体现"）；至于PLC，目前大多数厂商都处于研发阶段，本文不做展开，有兴趣的朋友请自行研究。

![66e095d716f9a4668ffa8992892d73a9.png][]  
表1-1  
![8b178bb837bd4380deeb63c7c996e006.png][]  
图1-1

# **2.什么是 CSD** #

*  要能够比较准确地理解什么是CSD（计算存储驱动器）及其它的作用，我们可能需要与计算存储驱动器相关的概念一起做一个大致的了解：计算存储功能、计算存储引擎以及计算存储等
 *  根据SNIA（即全球网络存储工业协会，英文全称 Storage Networking Industry Association，缩写：SNIA）的定义：
 *   *  计算存储驱动器（英文全称 Computational Storage Drives ，缩写：CSD）是一种包含一个或多个计算存储引擎和持久数据存储的存储驱动器
     *  计算存储引擎（英文全称 Computational Storage Engines，缩写CSE）是一种能够对数据进行计算的组件，如何计算由计算存储功能定义
     *  计算存储功能（英文全称 Computational Storage Function，缩写CSF）是一种可由CSE来配置和执行的特定操作
     *  计算存储（英文全称 Computational Storage ）被定义为一种提供将计算存储功能与存储耦合的架构，该架构通过将主机与存储驱动器之间的计算资源进行集成（如图2-3的左侧部分所示）、或直接与存储驱动器内的计算资源进行集成（如图2-3的右侧部分所示），以提高应用程序性能、或优化基础设施的效率，目标是实现并行计算、或减轻对现有的计算、内存、存储和I/O设备的限制。
 *  简而言之，CSD是一款集成了计算存储引擎和持久数据存储的NVMe SSD，那么普通的NVMe SSD和CSD有什么区别呢？为直观方便起见，下面我们从普通的NVMe SSD和CSD的"盘片物理结构的区别"和"在计算存储架构内计算存储引擎的区别"这2个角度做一些简单的对比
 *   *  盘片物理结构的区别：  
        \* 通常，普通的NVMe SSD盘片内部物理结构主要包括主控芯片（大多数采用ARM处理器架构的Cortex-R系列芯片，其中主要功能包括Flash、PCIe、NVMe等控制器）、NAND闪存介质和缓存单元（部分产品可能没有缓存单元）三大组件（如图2-1所示），在这三大件中，采购成本最高的是NAND闪存介质，大约占据了整盘成本的70%。由于不同厂商对不同产品的定位问题和有些产品存在内外置缓存的区分，缓存单元一般无法统一论述，但其中最有技术含量和核心技术的则当属主控芯片  
        \* CSD也同样支持NVMe协议，本质上也是一款NVMe SSD产品，因此与普通NVMe SSD产品相比，在盘片物理结构上同样有类似的三大件（如图2-2所示），但不同的是，在CSD中，作为三大件之一的主控芯片，或将其从ARM处理器架构替换为FPGA芯片（如图2-2所示，表示ScaleFlux CSD 2000的盘片物理结构）并在盘内集成计算存储引擎（例如：透明压缩/解压引擎、透明加密/解密引擎等），或仍然使用ARM处理器架构并在盘内集成计算存储引擎（如ScaleFlux CSD 3000/5000系列产品或其他友商类似的CSD产品）。

![cc480451b2ec75b1d4439dbef20e9a9f.png][]

图2-1

![29e9c1a12bb7491c369574a6e238e1d4.png][]

图2-2

*   *  在计算存储架构内计算存储引擎的区别：  
        \* 如图2-3（图片来自SNIA）所示，左侧表示一种使用外接加速卡（可能使用FPGA芯片作为主要算力，其中包含了计算存储引擎API）来对数据进行加速的计算存储架构，在此架构中，“Compute”字样标记处代表外接加速卡（包含计算存储引擎），“SSD”字样标记处的两个长方形方框代表两块普通NVMe SSD，从图中我们可以看到每一块SSD中包含一个主控芯片("Controller"标记的方框)和N个NAND闪存介质颗粒（"Flash"标记的方框）。以压缩/解压这个算子为例，在该计算存储架构中，数据写操作时，主机先将数据拷贝到外接压缩卡中，先在外接加速卡中完成数据压缩，之后再写入普通NVMe SSD，SSD内部再经由主控芯片写入到NAND闪存介质中。数据读取操作时，先将数据从SSD中读取出来，返回给外接加速卡完成数据的解压，再返回给主机，这可能会消耗大量的主机总线带宽资源，因此这种计算存储架构可能会影响主机的整体性能。  
        \* 图2-3所示的右侧表示一种使用CSD来对数据进行加速的计算存储架构，相比左侧的架构，在此架构中我们可以看到，“Compute”字样标记挪到了"Controller"所在的位置，且"Controller"被包含在其中了（即代表在CSD设备内部，主控和计算存储引擎集成到了一起），这样一来，同样以压缩/解压这个算子为例，在该计算存储架构中，数据写操作时，主机直接将原始应用数据写到CSD中，数据经过CSD内部"Compute"位置（同时也是"Controller"位置）压缩之后直接写入CSD内部的NAND闪存介质中。数据读取操作时，CSD内部先将数据从NAND介质中读取出来，经过CSD内部"Compute"位置解压之后直接返回给主机。也就是说，写操作时数据是在写入CSD内部之后压缩的、读操作时数据是在CSD内部解压之后返回给主机的，主机完全无感知（因此通常这种压缩/解压方案也叫做"透明压缩/解压"），数据的压缩/解压也就不需要消耗大量主机总线带宽资源来回拷贝数据，所以从理论上来说能这种计算存储架构够大幅提升主机的整体性能，且应用也无需特殊的适配。

![8ec45cfd0d6c76ddd411005b58dd9902.png][]  
图2-3

# **3.CSD 价值体现** #

*  在"1. NAND 存储介质有哪些"中我们介绍QLC NAND闪存介质的缺点时，提到了通过CSD设备自带的透明压缩/解压特性能够弥补QLC本身的缺陷，甚至能够大幅提升QLC设备的性能和寿命，那么CSD究竟是如何实现逆转的呢？
 *   *  简单来说，通过在盘内集成的透明压缩/解压引擎，在数据具有较高可压性时，在IO路径上先对数据进行压缩之后再写入NAND闪存介质（本节下文统称为NAND）中，大幅降低了盘内物理空间的使用率，使得盘内空闲空间增多，空闲空间一旦增多，盘内写放大、GC以及同一个Die中的读写冲突也就能大幅降低，从而带来了性能和寿命的大幅提升。
 *  ScaleFlux作为一家计算存储厂商，目前主打的CSD 2000就是这样一款自带透明压缩/解压特性的产品，目前采用的NAND类型有TLC和QLC两种，TLC类型的裸容量(NAND容量)有4T和8T两种版本，QLC类型的裸容量有8TB、16TB、32TB三种。
 *  正是由于CSD 2000在盘内集成了透明压缩/解压引擎，使得采用QLC NAND的CSD 2000 极大地弥补了 QLC本身的缺陷，甚至能够及大地提升QLC设备的性能和寿命，使得QLC设备能够进入到数据中心级的应用领域。
 *  那么，透明压缩/解压引擎究竟为何物？CSD 2000在使用上与普通NVMe SSD有什么差异呢？CSD 2000在盘片内部集成的透明压缩/解压引擎，之所以称之为透明，是因为对于主机端（如：OS或应用）完全无感知，主机端看到的数据始终是未压缩的大小（写操作时，数据在从主机端写入盘内之后压缩；读操作时，在返回数据给主机端之前解压）。此时，物理容量（NAND的使用量）可能并不能完全写满（根据数据的可压性的不同，空闲的物理容量大小会有所不同），如需将物理容量写满，就需要在主机端写入更多的数据。
 *   *  例如：假设有一块6.4TB可用物理容量的CSD 2000，在数据有50%可压性时，在主机端中写入6.4TB的逻辑数据，数据经过压缩之后，写入到NAND中占用的实际物理空间大小只有逻辑空间占用的50%（即3.2TB），这种情况下如果要将6.4TB的可用物理容量写满，就需要将主机端的数据写入量增加到12.8TB（即需将主机端的可用逻辑容量从6.4TB扩容到12.8TB）。在CSD 2000中开创性地将LBA与PAB之间的定长映射（普通NVMe SSD采用的映射方式）变更为变长映射（如图3-1所示），同时提供了一个操作接口，可以参考数据的压缩比作为扩容的倍数，对CSD 2000在主机端可见的逻辑容量进行扩容。这就意味着使用CSD 2000时，数据的可压性越高，在主机端就能够写入更多的数据，这样一来，存储的每GB成本能够随着数据可压性的增加而下降。
     *  对于来自友商的普通 NVMe SSD，由于在盘内并未集成计算存储引擎，因此无论数据的可压性如何，并不能对数据进行压缩，也就无法减少对物理空间的占用，也就无法在数据有较高可压性的情况下降低存储的成本（当然，这种情况下可以通过运行软件级别的压缩算法来降低存储的成本，但这本质上是一种牺牲CPU宝贵算力资源来换取存储空间的解决方案，在CPU算力存在瓶颈的场景可能并不适用）。

![272cfa2e60c59e07aadd6a84e019da0b.png][]  
图3-1

*  接下来，我们采用FIO和Sysbench两种基准测试工具，对ScaleFlux CSD 2000的 TLC 7.68TB（下文简称ScaleFlux TLC）和QLC 7.68TB（下文简称ScaleFlux QLC）两个具体的产品型号进行基准性能测试，并将测得结果分别与友商 TLC 8TB NVMe SSD（下文简称友商TLC）和友商 QLC 7.68TB NVMe SSD（下文简称友商QLC） 的基准性能数据进行横向对比
 *   *  在FIO基准测试中，我们将FIO的buffer\_compress\_percentage参数值设置为0（代表数据完全不可压缩）和75（代表数据有2.9:1左右的压缩比。大多数客户生产环境数据样本的压缩比在2:1~4:1之间，因此这里我们截取中位数2.9:1左右的压缩比进行对比测试）分别进行测试，观察ScaleFlux TLC和ScaleFlux QLC两个型号的产品在能够节省65.5%（根据2.9压缩比换算得出）存储空间的同时，分别能有多大幅度的性能提升
     *  类似，在Sysbench基准测试中，我们使用Sysbench来生成具有66%左右可压性的数据进行压测，并观察ScaleFlux TLC和ScaleFlux QLC两个型号的产品在能够节省66%左右存储空间的同时，分别能有多大幅度的性能提升

## **3.1.FIO 基准测试** ##

*  通过表3-1中所示的数据（注：表中小字部分包含了详细的IO Pattern和测试环境信息）我们可以看到，相比数据完全不可压缩的场景（数据压缩比为1：1），在数据有约65.5%可压性（数据压缩比为2.9：1）的场景中，ScaleFlux TLC 在节省65.5%存储空间的同时其随机写性能比友商TLC高出204%+(差异值，后不赘述)，ScaleFlux QLC 在节省65.5%存储空间的同时其随机写性能比友商QLC高出997%+，甚至ScaleFlux QLC在节省65.5%存储空间的同时其随机写性能比友商TLC也高出198%+。这主要得益于压缩之后物理写入量显著减少，使得GC和NAND介质中相同die中的读写冲突显著减少（IO延迟显著降低），进而使得随机写性能获得显著提升。

![02cb4a062921b06d759e5ac4f0cef1db.png][]  
表3-1

## **3.2.写放大(WAF)、耐用等级(PBW)测试** ##

*  通过表3-2中所示的数据（注：表中小字部分包含了详细的IO Pattern和测试环境信息）我们可以看到，相比数据完全不可压缩的场景（数据压缩比为1：1），在数据有约50%可压性（ 数据压缩比为2：1）的场景中，以IO Pattern random\_64k\_4j\_128q为例：
 *   *  逻辑容量不扩容（与出厂可用物理容量相同，即7.68TB）、盘片进入稳态（主机端写满7.68TB的数据）时  
        \* TLC的写放大从4下降到了0.55，即降低了86.25%（差异值，后不赘述）；PBW从11.18增加到了81.23，即增加了626.57% ；假设TLC的质保期为5年，在5年质保期不变的情况下，根据DWPD计算，平均每天可写的数据量（逻辑数据）增加了625%  
        \* QLC的写放大从4.83降低到了0.55，即降低了88.61%；PBW从1.82增加到了16，即增加了779.12% ；假设QLC的质保期为3年，在3年质保期不变的情况下，根据DWPD计算，平均每天可写的数据量增加了759.09%
     *  将逻辑容量扩容2倍（是出厂可用物理容量的2倍，即可以将7.68TB的盘当做15.36TB的盘使用）、盘片进入稳态（主机端写满15.36TB的数据）时  
        \* TLC的写放大从4降低到了1.75，即降低了56.52%；PBW从11.18增加到了25.52，即增加了128.26%；在5年质保期不变的情况下，根据DWPD计算，平均每天可写的数据量增加了127.5%  
        \* QLC的写放大从4.83降低到了2.76，即降低了42.86%；PBW从1.82增加到了3.19，即增加了75.27%；在3年质保期不变的情况下，根据DWPD计算，平均每天可写的数据量增加了72.73%

![dafc06d924ac6f971a87dd53dbd5b49b.png][]  
表3-2

## **3.3.Sysbench基准测试** ##

*  MySQL 是时下最为流行的开源数据库，在MySQL中使用最为广泛的存储引擎则是InnoDB，因此在Sysbench基准测试中，我们选择“MySQL + InnoDB引擎”来作为应用的代表，对比测试如表3-3所示的应用场景（注：表中小字内容包含了详细的测试case和测试环境信息）：

![39a9bd09cebcb8a9820453a4fa0ac32c.png][]  
表3-3

提示：表3-3所示的测试场景中提及的DW，表示MySQL InnoDB引擎中的DoubleWrite双写缓冲机制，该机制是一种数据页的安全保护机制。因MySQL InnoDB的Page Size默认为16k，而文件系统的Block Size默认为4k，当刷新脏数据过程中因进程意外崩溃或主机意外宕机则可能导致数据页发生部分写（损坏）。其核心原理是将脏数据页写两遍，先写一遍到DoubleWrite中，DoubleWrite写入成功之后，再将脏数据页写入到表空间中。期间表空间中的数据页发生部分写，则可以从DoubleWrite中读取完整的页进行恢复。

*  经过长达3周的测试，我们获得了如下对比测试结论

### **3.3.1.盘对盘性能对比测试** ###

*  通过图3-2中所示的数据我们可以看到，在盘对盘性能对比中，相比基线（开DW），在32~256并发中，ScaleFlux QLC 透明压缩 (开DW) 场景的 TPS高出4.6%~30%，透明压缩+原子写(关DW) 场景的TPS高出25%~163%；ScaleFlux TLC 透明压缩 (开DW) 的 TPS高出 8.3%~47% ，透明压缩+原子写(关DW) 的TPS高出68%~216% 。随着并发线程数的增加，ScaleFlux QLC/TLC的TPS优势逐步增大 （虽然友商TLC 关DW比起基线，TPS高出18.8%~92%，但比起ScaleFlux TLC/QLC关DW场景下提高幅度都要小得多）

![9b14b9366e0184d01733298c6ccd0619.png][]  
图3-2

*  ‍通过图3-3中所示的数据我们可以看到，在盘对盘性能对比中，相比基线，在32~256并发线程写场景中，ScaleFlux QLC 透明压缩 (开DW) 的avg latency （平均延迟）降低4.4%到23.9%，透明压缩+原子写(关DW) 的 avg latency 降低20%到62%；ScaleFlux TLC 透明压缩 (开DW) 的 avg latency 降低7.7%到32%，透明压缩+原子写(关DW) 的 avg latency 降低40%到68% 。随着并发线程数的增加，ScaleFlux TLC/QLC的avg latency 降低幅度逐步增大（虽然友商TLC关DW比起基线，avg latency 降低15%~48%，但比起ScaleFlux TLC/QLC关DW场景下降低幅度都要小）

![5c39d6890846bbce0b233c33918793ce.png][]  
图3-3

### **3.3.2.压缩方案对比测试** ###

*  通过图3-4中所示的数据我们可以看到，在压缩方案对比中，相比基线，在32~256并发线程中， ScaleFlux QLC透明压缩（开DW）的TPS在写负载中高出4.6%~30% ，ScaleFlux QLC透明压缩+原子写（关DW）的TPS在写负载中高出25%~163%。随着并发线程数的增加，ScaleFlux QLC的TPS优势逐步增大。
 *   *  对于压缩率，实测结果ScaleFlux QLC的压缩比为3:1，在所有压缩方案中压缩比最高（MySQL 透明页压缩lz4算法的压缩比为1.69:1、MySQL 透明页压缩zlib算法的压缩比为2.93:1、MySQL 表压缩的压缩比为1.83:1）

![efcf9c6c37928c931a9831d65232a5ff.png][]  
图3-4

*  通过图3-5中所示的数据我们可以看到，在压缩方案对比中，相比基线，在32~256并发线程中， ScaleFlux QLC透明压缩（开DW）的avg latency（平均延迟） 降低了4.4%到23% ，ScaleFlux QLC透明压缩+原子写（关DW）的avg latency 降低了20%到62% 。随着并发线程数的增加，ScaleFlux QLC的avg latency 降低幅度逐步增大

![30884f907fcfb5eb75303724ecd08c4e.png][]  
图3-5

# **4.CSD 应用现状** #

*  关于CSD的应用场景探索与落地，在计算存储领域，ScaleFlux当属"人中翘楚"，如表4-1所示，ScaleFlux与大家耳熟能详的众多行业头部企业展开广泛深入的合作，共同探索CSD的应用场景探索与落地，取得了良好的应用成果
 *   *  在实际测试中，各大行业头部公司线上业务数据的压缩率普遍在2~3之间（甚至在部分业务场景中高达4以上），这意味着能够节省至少50%~66%的存储空间，存储空间的节省也就意味着存储TCO的降低。
     *  对于性能，无论是FIO、或Sysbench、或BenchmarkSQL等基准测试工具，或主从复制延迟，与生产环境中现有的SSD使用方案相比（普通SATA SSD或SAS SSD组成的RAID方案、或普通NVMe SSD方案），多数指标都超过了生产环境中现有的SSD使用方案，在大数据集、高并发的场景中甚至大幅领先。

![cf23e60384f493606a3073ee5b3e12b4.png][]  
表4-1

# **5.CSD 未来展望** #

*  当今时代，我们正处在一个前所未有的数字化转型的进程中，各种新兴技术的产生和使用都会面临着一个共同的问题，那就是数据产生和使用呈爆发性增长，这会给底层的计算和存储的技术带来巨大的挑战。
 *  在过去的几十年中，存储的技术从卡带、到磁盘、到固态硬盘，从容量和性能上都得到了巨大的提升，但其提升的速度远远赶不上数据增长的需求，如果我们把2020年全球存储的产能加起来，大约20ZB（相当于20亿张10TB的硬盘），这已经是比较惊人的产量，但到了2025年，数据的增长大约会达到125ZB，与此同时，存储的产能只能达到22ZB，可想而知这将是存储面临的一个巨大挑战。
 *  当传统的计算与存储的方式难以满足数据增长需求的时候，就必须通过创新来解决计算和存储的效率，要提升计算和存储的效率，最有效的解决方案就是将计算与存储分离，可以将不同的计算类型细分到不同的更加高效的计算引擎里。可计算型存储由此应运而生，将近存储的数据相关的计算（例如：数据的压缩与解压、数据的过滤、数据的加密与解密等）集成到存储设备内部，不需要主机CPU参与，不需要在系统总线中来回拷贝数据，不需要额外占用PCIe插槽与额外的供电，同时算力能够随着存储的扩容而线性扩展，甚至能够做到并行计算等等。
 *  来自ScaleFlux的CSD 2000系列正是这样的一种通过在盘内集成专有算力芯片来实现盘内压缩/解压的解决方案级产品，其主打的CSD 2000系列经过不断地和众多行业头部企业展开广泛的探索、磨合，在应用场景探索与落地上，不但取得了良好的应用成果，也使得CSD 2000系列产品变得越来越成熟、稳定、易用。在不久的将来，ScaleFlux 将会推出集成更多实用的计算存储引擎(如增加加密/解密、SSL/TLS等)、更高吞吐和性能(如支持PCIe Gen4)、更加物美价廉的CSD 3000 系列，甚至是CSD 5000系列。理论上最大支持的物理容量可达64TB，其最大可扩容的逻辑容量可达512TB。对于在数据可压性超高的场景中，如果应用QLC NAND介质的CSD 3000系列产品，相比同类型的普通NVMe SSD产品，其能够带来的性能提升以及存储TCO的降低就不言而喻了。
 *  5G时代即将到来，在万物互联、AI、区块链、自动驾驶等新兴技术中，以及在各种云存储、CDN等应用场景中，CSD无论从存储性能提升的需求来看，还是从存储成本节省的需求、甚至是近存储的特殊计算需求上来看，都可能存在着巨大的增长空间。因此，对于CSD 的应用前景，我们拭目以待！

**作者介绍：**

罗小波@ScaleFlux，《千金良方——MySQL性能优化金字塔法则》、《数据生态：MySQL复制技术与生产实践》作者之一。

熟悉MySQL体系结构，擅长数据库的整体调优，喜好专研开源技术，并热衷于开源技术的推广，在线上线下做过多次公开的数据库专题分享，发表过近100篇数据库相关的研究文章。

![e1ca505cb8d2b6d6d2173b34a750bbf8.gif][]

![28712a5ba300cab92711f961cd7b9e9b.png][]

更多视频信息，包括培训、采访和产品介绍，请关注我们的微信公众号-视频资讯频道

ScaleFlux视频资讯官网:  
http://scaleflux.com/videos.html  
ScaleFlux优酷频道：  
https://i.youku.com/scaleflux?spm=a2hzp.8244740.0.0

![ab308ec4a190d8e631136b32469d2b1e.png][]

--------------------

**文章推荐：**

*  [MGR最佳实践(MGR Best Practice)][MGR_MGR Best Practice]
 *  [万里数据库MGR Bug修复之路][MGR Bug]
 *  [ansible一键安装GreatSQL并构建MGR集群][ansible_GreatSQL_MGR]
 *  [在Docker中部署GreatSQL并构建MGR集群][Docker_GreatSQL_MGR]
 *  [将GreatSQL添加到系统systemd服务][GreatSQL_systemd]
 *  [金融应用场景下跨数据中心的MGR架构方案][MGR]  
    
 *  [InnoDB Cluster+GreatSQL快速部署MGR集群，并实现读写分离和故障自动转移][InnoDB Cluster_GreatSQL_MGR]
 *  [利用GreatSQL部署MGR集群，并完成添加新节点 、滚动升级、切主][GreatSQL_MGR_]
 *  [《叶问》33期，MGR最佳配置参考，PFS里的监测指标要全开吗，mysqld进程占用内存过高怎么排查][33_MGR_PFS_mysqld]

--------------------

扫码加入GreatSQL/MGR交流**QQ群**

![353e1bf52be6bd487cf38bcdadb5f8af.png][]

点击文末“**阅读原文**”直达老叶专栏

[1e6aad746cce6d2389d9a7773b001db2.gif]: /images/20220829/01625686344b49bfb6027e144c5b635c.png
[3a0c4f59a0ef9ad8c9eb2e9496bd29e2.png]: /images/20220829/6345685995d941348958f7d43f7cc0d2.png
[66e095d716f9a4668ffa8992892d73a9.png]: /images/20220829/5447ee6180b646979bb9b044c2e43a97.png
[8b178bb837bd4380deeb63c7c996e006.png]: /images/20220829/9f51f64e1d3341fa8c3fa337a9375ace.png
[cc480451b2ec75b1d4439dbef20e9a9f.png]: /images/20220829/01b0e454af8f4f8e9ba12e53f49da0d4.png
[29e9c1a12bb7491c369574a6e238e1d4.png]: /images/20220829/eee853d48a5047778958da74b37760f5.png
[8ec45cfd0d6c76ddd411005b58dd9902.png]: /images/20220829/373a68be90694ada8555e5fee414a347.png
[272cfa2e60c59e07aadd6a84e019da0b.png]: /images/20220829/79af2d71f5124f70b44c18b519d13082.png
[02cb4a062921b06d759e5ac4f0cef1db.png]: /images/20220829/ab2638ac2fa041ee8a14c3140264d34b.png
[dafc06d924ac6f971a87dd53dbd5b49b.png]: /images/20220829/1f4b08f4b77242e094c4341d3a2dddd5.png
[39a9bd09cebcb8a9820453a4fa0ac32c.png]: /images/20220829/5f59188f7cef48e68bf4c64bfe121afb.png
[9b14b9366e0184d01733298c6ccd0619.png]: /images/20220829/f993ad1cd0ff42dab942b565f96f1fd9.png
[5c39d6890846bbce0b233c33918793ce.png]: /images/20220829/322077b654324ccab864094d4f5272e5.png
[efcf9c6c37928c931a9831d65232a5ff.png]: /images/20220829/fb273c111f35404dbcbb83202f44b71a.png
[30884f907fcfb5eb75303724ecd08c4e.png]: /images/20220829/8e0ade0e0921488e9a0e36e9e7da6c4c.png
[cf23e60384f493606a3073ee5b3e12b4.png]: /images/20220829/b965684ea63e49c2bcf97c068fd8ccd7.png
[e1ca505cb8d2b6d6d2173b34a750bbf8.gif]: /images/20220829/22ec45a5308c4cbeb6d532131a0e3eaf.png
[28712a5ba300cab92711f961cd7b9e9b.png]: /images/20220829/cf4f4d72525546cbac8ae6b17b19c763.png
[ab308ec4a190d8e631136b32469d2b1e.png]: /images/20220829/fd59b8dca84b43088411adc6954ab3de.png
[MGR_MGR Best Practice]: http://mp.weixin.qq.com/s?__biz=MzkzMTIzMDgwMg%3D%3D&chksm=c26f6633f518ef25f19309e4b01ce5d4527d945a2a030b66a9d9bbaa598cb668eca30cb91a0f&idx=1&mid=2247484174&scene=21&sn=4f795e889e3778876b09143c4ffdc770#wechat_redirect
[MGR Bug]: http://mp.weixin.qq.com/s?__biz=MzkzMTIzMDgwMg%3D%3D&chksm=c26f64abf518edbdb278f1c21e98e39dc73b78397d01c2d583450a1da6d72a4ff32a0ec6db9c&idx=1&mid=2247483798&scene=21&sn=21fc1b1797074e002e1c684263b731e8#wechat_redirect
[ansible_GreatSQL_MGR]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b404d8a4cc95b9b429093753a7aec8fd990a6b1057646d82726d9debe0f1405477ee83031&idx=1&mid=2653936167&scene=21&sn=76420e523bec1b9399ab7e0138802bcd#wechat_redirect
[Docker_GreatSQL_MGR]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b40488a4cc95e2f4a7750a3cad05fd70d3b9b5f366ded103e66e16f2cdda6f67fa231803c&idx=1&mid=2653936162&scene=21&sn=fa76aa58c0262d6a4e43c675f305db6d#wechat_redirect
[GreatSQL_systemd]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b43ea8a4ccafc0edffe28125815e5a490370463d7f7c00436f5d58b47df58affd0afe263d&idx=1&mid=2653936000&scene=21&sn=d21f6f3a89e03c08663df5b34f6b09f8#wechat_redirect
[MGR]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b43108a4cca06841d2adf3a63dfe6af99df09b09164e8676d99cb08fc5e569bfc543a0ccf&idx=1&mid=2653935994&scene=21&sn=91c596c81944aabd396d33f4924aac26#wechat_redirect
[InnoDB Cluster_GreatSQL_MGR]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b43308a4cca26c2db9912a9ce5e2d73df1a10e7415f83538742b92e5475a0b11b88e39f4c&idx=1&mid=2653935962&scene=21&sn=38f2acfb147f16ae8daaa6a48a3102ae#wechat_redirect
[GreatSQL_MGR_]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b43258a4cca336b0260c6b9cfc363f10596c775bdd0408d89dca855f3c7949911aa50ec8f&idx=1&mid=2653935951&scene=21&sn=ec8794371cd6f7677a5355b7e7ac39ea#wechat_redirect
[33_MGR_PFS_mysqld]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b436b8a4cca7ddf138db1d2342aa19f0452bff97beb2f5015cf0eb377a7d2a6899d1c3c05&idx=1&mid=2653935873&scene=21&sn=7511853d63145b7d72ae533586b6ad81#wechat_redirect
[353e1bf52be6bd487cf38bcdadb5f8af.png]: /images/20220829/d28038f53191405584361a48dbc5c6c9.png