案例目前公司的订单中心是MySQL分片集群其有128个分片组成使用的固态硬盘是NVMe SSD。库存中SATA SSD比较富裕NVMe SSD相对紧张因而需要DBA评估用SATA SSD替代NVMe SSD的可行性和风险。直接看下两者的关键区别对比维度SATA SSDNVMe SSD本质区别使用为机械硬盘设计的旧协议 (AHCI)使用为闪存设计的专属新协议 (NVMe)通信接口SATA 接口带宽上限约 600 MB/sPCIe 接口直连CPU速度无上限速度表现顺序读写约 550 MB/s顺序读写可达 3,500 ~ 14,000 MB/s响应延迟较高约 100 微秒极低约 10-20 微秒其读/写性能差异很是很大的。二小批量验证为了减少替换带来的影响先从影响小的下手。先把其中个分片的从节点替换为了SATA SSD从节点有部分读业务观察运行两周其CPU、内存、IOait、TPS、QPS等指标运行还是平稳的也在合理的区间和 NVMe SSD 横向相比CPU、IOait指标有增加但是还可以内存、TPS、QPS的变化不明显。两周后将这4个从节点升级成了主节点。即目前 128套集群有4套运行在 SATA SSD124套 运行在了 NVMe SSD 上。切换3个月来业务系统运行还算正常。三 分析与总结如果只是从小批量试运行的效果来看是令人满意的。可是不是就可以放心的替换呢我们还做了以下分析。3.1 分析慢查询将这4个SATA SSD的服务器划为一组再随机抽取5个 NVMe SSD划为对照组分析慢查询的情况。慢查询的数据量增长了3.7倍。梳理的比较的格式如下:比较NVMe SSDSATA SSD慢查询总数慢查询执行时间的中位数6S 慢查询的数量6S 4S 慢查询的数量4S 2S 慢查询的数量3.2 分析DDL操作这个一定要分析总结但也容易被忽略。因为DDL操作是MySQL 最耗资源的一种操作当然也是运维的核心变更之一。系统使用的MySQL版本是5.7所以选择什么样的DDL语句才能说明问题是关键。知识补充OperationIn PlaceRebuilds TablePermits Concurrent DMLOnly Modifies MetadataAdding a columnYesYesYes*NoDropping a columnYesYesYesNoRenaming a columnYesNoYes*YesReordering columnsYesYesYesNoSetting a column default valueYesNoYesYesChanging the column data typeNoYesNoNoExtendingVARCHARcolumn sizeYesNoYesYesDropping the column default valueYesNoYesYesChanging the auto-increment valueYesNoYesNo*Making a columnNULLYesYes*YesNoMaking a columnNOT NULLYes*Yes*YesNoModifying the definition of anENUMorSETcolumnYesNoYesYes涉及 Rebuilds Table 的操作都是一个高消耗的操作消耗的资源比较多同时执行时间也比较长。一定要注意的是 修改字段长度不一定不 Rebuilds Table 其实它有一个零界值的。The number of length bytes required by a VARCHAR column must remain the same. For VARCHAR columns of 0 to 255 bytes in size, one length byte is required to encode the value. For VARCHAR columns of 256 bytes in size or more, two length bytes are required. As a result, in-place ALTER TABLE only supports increasing VARCHAR column size from 0 to 255 bytes, or from 256 bytes to a greater size. In-place ALTER TABLE does not support increasing the size of a VARCHAR column from less than 256 bytes to a size equal to or greater than 256 bytes. In this case, the number of required length bytes changes from 1 to 2, which is only supported by a table copy (ALGORITHMCOPY). For example, attempting to change VARCHAR column size for a single byte character set from VARCHAR(255) to VARCHAR(256) using in-place ALTER TABLE returns this error:ALTER TABLE tbl_name ALGORITHMINPLACE, CHANGE COLUMN c1 c1 VARCHAR(256); ERROR 0A000: ALGORITHMINPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHMCOPY.具体细节参照官网:https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html言归正传,聚焦最近的DDL操作。Review替换以来的所有DDL变更发现 在所有的集群中执行最慢的永远都是这4台SATA SSD的分片并且执行时间明显的比其它组长很多。以给150G左右的一张表的添加字段为例两者相比NVMe SSD 与 SATA SSD其执行时间由原来的1.5 小时增长到了3 小时以上。即DDL的执行时间增长了1.5倍是原来的2.5倍。再看添加索引操作。add index虽然无需Rebuilds Table但是涉及新建index的结构也是一个耗时操作从中也能体现两者性能差异。果然如此耗时最久的依然是SATA SSD的分片执行时间大大增加了。不利因素不仅仅是执行时间变本身。此外DDL执行时间长出问题的风险就变大。拿过往的经验举个例子添加索引OperationIn PlaceRebuilds TablePermits Concurrent DMLOnly Modifies MetadataCreating or adding a secondary indexYesNoYesNoDropping an indexYesNoYesYesRenaming an indexYesNoYesYesAdding aFULLTEXTindexYes*No*NoNoAdding aSPATIALindexYesNoNoNoChanging the index typeYesNoYesYes按照官方的说明添加索引无需Rebuilds Table允许Permits Concurrent DML。但恰恰是这种操作引发过两个故障。故障1因为add index ,会由大量的io操作导致DB Server 下降引发了大量的慢查询和事务堆积。故障2这次故障比故障1更严重读写都不可用了。堆积了大量事务正在运行的SQLThreads_running由平常的10多个快速增长到 600堆积无法处理---堆积的事务状态为【Waiting for table flush】。不得不进行killKill Add index 的事务后系统立马恢复了。故障2,难解。3.3 对主从延迟的影响类似于 慢查询 的现象通过监控数据分析发现SATA SSD 发生主从延迟的概率增加了很多并且延迟值明显比对照组的要大。主从延迟不仅会影响的业务的读写分离还会影响主从切换影响高可用。3.4 其它影响分析最近的一次OOM切换恰恰发生在SATA SSD的节点上。此外虽然orchestrator对其进行了主从切换但中间有3个事务丢失和业务确认后DBA需手动补全。OOM和数据丢失与性能的关系还需要更多的理论解析和实践说明但需留意。四. 概况总结从直观来看资源降配看似对应用系统的影响不大但对运维和高IO的操作来讲会带来很大的挑战。建议1针对慢查询请研发确认是否可以接受、是否可以优化改进SQL语句2针对DDL的耗时增加需要评估是否可以接受是否可以对MySQL版本进行升级例如升级到8.03细化监控、增加完善及时告警如有异常可以及时止损。后记这种境况让我联想到“坐船渡河”。
