搭建MySQL主从复制环境时服务器硬件有什么要求？

搭建 MySQL 主从复制（Master-Slave Replication）环境，硬件配置并不是“越贵越好”，而是要根据业务场景、数据量级和并发需求来定。很多初学者容易陷入一个误区：认为从库只要比主库配置高就行，或者随便找个低配机器凑合。其实，主从架构对硬件的要求有着非常明确的侧重点差异。

我们可以把主库和从库分开来看，因为它们在集群中的角色完全不同。

一、 主库（Master）：重在 IOPS 和低延迟

主库是写入数据的唯一入口（除非用了 MGR 或 ProxySQL 等复杂架构），它承受着所有的 DML（增删改）操作以及部分高频查询压力。因此，主库的硬件核心指标是 IOPS（每秒读写次数） 和 CPU 单核性能。

1. 存储（最关键）

   • 必须使用 SSD：这是底线。机械硬盘（HDD）的随机读写能力太弱，MySQL 的 InnoDB 引擎高度依赖随机 IO（尤其是 undo log、redo log 和 buffer pool 的刷新）。如果预算允许，优先选择 NVMe SSD；如果是云环境，选择高 IOPS 的云盘类型（如阿里云的 ESSD PL1/PL2，AWS 的 io2 等）。
   • 独立日志磁盘：理想情况下，将 redo log 和 binlog 放在独立的物理磁盘或高性能卷上，避免与数据文件争抢 IO。虽然现代 SSD 速度很快，但在高并发下隔离日志依然能显著降低延迟抖动。

2. 内存（Buffer Pool）

   • 主库需要尽可能大的内存来缓存热点数据。InnoDB 的 innodb_buffer_pool_size 建议设置为服务器总内存的 50%-70%。内存越大，命中率高，磁盘 IO 就越少，响应越快。
   • 注意：不要为了追求大内存而忽略 CPU 核心数，否则会出现“内存换 CPU”的瓶颈。

3. CPU

   • 主库的 SQL 执行、事务管理、锁竞争都消耗 CPU。建议选择高主频的核心（High Frequency Cores），因为很多数据库操作是单线程或强依赖串行化的。对于极高并发场景，多核并行处理也是必要的，但单核性能往往决定了长尾延迟。

二、 从库（Slave）：重在吞吐量和读取分离

从库的主要任务是接收主库发来的 binlog，重放（Apply）到本地，并对外提供只读查询服务。从库的压力主要来自两个方面：网络带宽（接收 binlog）和 CPU/IO（重放 SQL 和响应查询）。

1. 网络带宽

   • 这是最容易被忽视的点。如果主从之间通过公网传输，带宽会成为最大瓶颈。务必保证主从在同一 VPC（虚拟私有云）内，并使用内网通信。
   • 如果数据量极大（TB 级别），主库产生的 binlog 流量可能非常大，确保网卡带宽足够（如万兆网卡），避免网络拥塞导致主从延迟（Replication Lag）飙升。

2. CPU 与 多线程复制

   • MySQL 5.7 之前，从库默认是单线程重放 binlog，这会导致严重的延迟。MySQL 5.7+ 引入了基于组提交的多线程复制（MTS, Multi-Threaded Slave）。
   • 因此，从库需要更多的 CPU 核心来并行重放不同 schema 或表的事务。从库的 CPU 核心数可以适当多于主库，以应对重放压力。

3. 存储：顺序写优势

   • 从库的重放过程主要是顺序写入（Append-only），相比主库的随机写入，对 SSD 的要求稍低一些。但如果从库也承担大量报表查询或 OLAP 分析任务，那么同样需要高性能 SSD 和大内存。
   • 注意：如果从库仅用于灾备，不提供服务，可以使用成本更低的 HDD + 快照机制，但这不适用于生产环境的读写分离场景。

4. 内存

   • 从库也需要较大的 Buffer Pool，尤其是当从库分担了大量读请求时。内存不足会导致频繁的磁盘交换，严重影响查询性能。

三、 通用建议与避坑指南

1. 操作系统优化

   • Linux 内核参数需要调整，例如 vm.swappiness 设为 1 或 0，防止系统过度使用 Swap 分区；关闭透明大页（Transparent Huge Pages, THP），它会严重干扰数据库的内存分配，导致延迟抖动。这些在 CentOS 7/8、Ubuntu 20.04+ 上都有相应的优化脚本。

2. 时钟同步

   • 主从复制依赖时间戳进行 GTID 管理和冲突检测。务必确保所有节点的时间严格同步（NTP/Chrony），误差最好控制在毫秒级以内，否则可能出现主从不一致或复制中断。

3. 云厂商产品选型技巧

   • 如果你用的是阿里云 RDS、腾讯云 CDB 或华为云 GaussDB 等托管数据库服务，通常不需要自己操心底层硬件。但你需要理解它们的实例规格命名规则：
     • 通用型：CPU 和内存比例均衡，适合大多数 Web 应用。
     • 计算型：高 CPU 频率，适合 CPU 密集型负载。
     • 内存型：大内存配比，适合大数据量、高缓存命中率场景。
   • 在主从架构中，主库可选用“通用型”或“计算型”，从库若用于高并发读，可考虑“内存型”。

4. 不要盲目追求对称配置

   • 有些团队喜欢主从配置完全一样，这在初期没问题。但随着业务增长，主库可能因为写入压力大需要升级 CPU，而从库可能因为查询量大需要升级内存。灵活调整各节点配置才是正道。

5. 监控先行

   • 硬件再好，没有监控也是盲飞。部署 Prometheus + Grafana 或 Zabbix，重点监控：
     • iowait：等待 IO 的时间占比，超过 20% 说明存储成为瓶颈。
     • replication_lag：主从延迟秒数。
     • QPS/TPS：每秒查询/事务数。
     • CPU User/System：区分是用户态 SQL 执行慢，还是内核态上下文切换频繁。

总结

• 主库：选高 IOPS 的 SSD，大内存，高主频 CPU。目标是“快”，减少写入延迟。
• 从库：保证内网高速带宽，多核 CPU 支持多线程复制，大内存支撑读缓存。目标是“稳”，减少复制延迟和查询阻塞。
• 共同点：关闭 THP，优化 OS 内核，保持时钟同步。

最后提醒一句：硬件只是基础，MySQL 的配置参数（如 innodb_flush_log_at_trx_commit, sync_binlog）对性能和稳定性的影响甚至大于硬件差异。在生产环境上线前，务必进行充分的压测，找到你特定业务场景下的最佳平衡点。