香港独服跑MySQL主从怎么选

数据库一开始只有一台，业务跑得好好的，等到读写压力上来或者某天误删了一张表，才想起该做复制和备份。主从这件事听起来像大厂才需要，其实一个日活几千的小站，配好从库之后既能分担读请求，也能在出问题时把数据捞回来。这篇不聊原理推导，只讲动手之前要想清楚的几件事：要几台机器、盘怎么分、备份放哪里、什么时候该加节点，以及预算档位怎么选。

主从复制到底要几台机器

最小可用是两台，一主一从。主库负责写入，从库通过复制日志追平数据，读请求分一部分过去。这种方式能把读压力分掉大半，但主库仍然是单点，写挂了一样停摆，这是主从最常被误解的地方，以为有两台就等于高可用。

三台是比较稳的形态，一主两从，其中一台从库兼做备份或者报表查询。写入中断时可以从从库提升一台上来，代价是切换期间有一段只读窗口，业务要能接受，只读窗口通常在几十秒到几分钟之间，取决于切换脚本做得多熟。

机器数量不等于高可用。两台机器放在同一个机房、同一条交换机上，停电或者交换机故障一样全灭，物理层面的隔离比多买一台更值钱，两台机器分在不同机柜甚至不同机房，才算真隔离。

很多人忽略复制本身的开销。主库要为每个从库保留并发送日志，从库越多，主库的磁盘写入和网络出向压力越大，加到五六个从库之后主库的写延迟会明显上升，这一步扩容的边际收益会快速变差。

起步阶段两台就够，等读请求真正压上来再加第三台。八百元档那台 6248 二十核配 128GB 内存、六 TB 机械盘，做从库兼备份很合适；一千二的 8259CL 双路二十四核四十八线程、131GB 内存、两块 SSD，做主库写密集型业务更从容。档位对比在这条渠道入口里能直接看到，两种配置的侧重差别很明显。

容易被忘掉的是仲裁或者监控机这个角色。它不存数据，但负责判断主库是不是真的挂了，避免出现两边都以为自己是主的脑裂。一台低配机器就够，占不了多少资源，但没有它，切换判断就只能靠人打电话确认，慢而且容易误判。

从库延迟大是机器不够还是配置问题

先看延迟是持续的还是偶发，这两种情况的原因和处理方式完全不同，混在一起判断容易改错方向，先把两种情况的曲线分开看，再决定是换盘还是调批处理大小。持续落后说明从库回放能力跟不上主库写入速度，偶发落后往往是大事务或者批量导入造成的短时堆积，过一段会自己追上，不用急着改配置，先看是否只在固定时间点出现，跟定时任务对一下往往能对上。

持续落后时先查从库的磁盘。回放日志是顺序写加随机读，机械盘在这种混合负载下很容易成为瓶颈，换成固态之后延迟通常立刻下来，比加内存效果更直接。判断方法是看从库的磁盘队列长度，队列长期不为零就说明盘跟不上。另一种可能是从库同时在跑报表查询，回放和查询抢盘，把报表挪到低峰时段能缓解不少，或者干脆让报表只读一个专门的从库，别和回放抢同一块盘。

偶发落后要控制单批数据量。一次导入几十万行，主库一条语句，从库要回放很久，拆成小批次写入，延迟就能压在秒级以内，业务读到的数据也更及时。写到从库的延迟控制在秒级以内，用户刷新页面看到的就是最新内容，否则会出现下单后查不到订单这种诡异现象，用户会以为是系统丢了数据，实际只是读到了落后的从库，这类问题最伤信任，读请求分流之前一定要确认复制延迟在可接受的秒级范围内。

主库和从库的硬盘怎么分

主库的盘要扛住随机写。写入密集时日志和数据文件同时写，随机 IOPS 不够会直接拉高事务响应时间，固态是主库的第一优先项，容量可以差点，随机写能力一点都不能省，一块八百 GB 的固态跑写入，比几 TB 的机械盘更合适，容量不足的补到从库上去。

从库的盘要扛住顺序回放加查询。回放是顺序的，但业务查询是随机的，两种负载混在一起，盘的压力比主库更杂，容量也要留足，因为还要放备份，容量规划要按未来一年的数据增量算，别按现在的数据量算，一年的增量通常比预期大，业务增长和日志留存都会叠加。

把日志、数据、临时文件分到不同的物理盘或者不同分区，能显著减少互相干扰。同一块盘上三种写入抢队列，峰值时延迟会翻几倍，分区之前先确认这些目录真的能分开，逻辑分区共享物理盘意义不大，得是真的不同盘位才有效果，采购时要把盘位数确认清楚，两盘位的机器上做三份分离只能是逻辑分区，效果会打折扣。

大容量机型适合放在从库位置。六 TB 机械盘那种配置可以同时承担回放、备份归档和报表查询，主库这边一块固态跑得开就行，两边分工清楚，从库的容量焦虑基本消失，主库也不用为了省空间去删日志，两边的运维动作都简单了很多，扩容的时候也只需要扩其中一边，不用整机替换。

备份和 binlog 放哪儿

备份绝不能和主库数据放在同一块盘。盘坏一次两样一起没，这种事故听起来低级，实际发生的频率并不低。

全量备份放独立的存储或者另一台机器，增量靠 binlog 补。恢复时先还原全量，再回放 binlog 到指定时间点，这套流程要定期演练，演练的时候顺便量一下恢复耗时，这个数字是容量规划里最实际的一项输入。

binlog 的保留时间按业务定。保留七天能覆盖大多数误操作的回滚需求，保留三十天占用会非常大，写满盘之后主库直接停止写入，比性能下降更严重，属于直接不可用。

给 binlog 单独设目录和配额，别和数据文件混在一起。清理策略做成定时任务，先归档再删，别一上来就删掉还没同步的日志，从库落后时删掉日志等于把复制链路切断。

备份要能验证。每天做一次抽样恢复，把备份文件在测试机上解开、启动、查一张表，才算真的备份成功。只看备份任务状态是绿色，等于什么都没验证，任务绿灯只能说明脚本跑完了，不代表文件能恢复。

异地保存也不能省。同机房两份备份遇到机房级故障一样全丢，冷备份放到另一地，成本不高但关键时刻能救命，一份冷备份的空间成本，比一次数据丢失的代价小得多。

监控 binlog 的增长速度。突然加速往往意味着有大批量写入或者某张表被反复更新，这既是容量问题也是业务异常的信号，两个角度都值得看一眼。

定期把过期的备份清理掉。保留策略写在文档里而不是记在人脑子里，换人接手时才知道哪些能删，避免误删还在有效期内的备份，这一点在换人交接时尤其重要。

什么时候该上双主或者多从

双主适合写入也要分流且能接受冲突处理成本的场景。两边都能写，就得解决自增主键冲突和数据覆盖，配置复杂度比一主多从高一个档次，没有明确的写入分流需求就别碰，配置里一个自增步长设错，排查半天都找不到原因，两边同时写入同一条记录还会互相覆盖，数据一致性很难保证，出了问题还要靠人工核对两边的差异。

多从适合读多写少的业务。内容站、报表查询、搜索索引构建这类只读需求，加从库几乎线性提升读能力，成本比升级单机低，加一台从库的钱通常远低于换一台更高配的主库，按现有读请求量估算台数就够，具体档位在这条入口里可以对照着看，按读请求的量估算需要几台，读请求占比越高，加从库的收益越明显，读请求不到一成时加从库基本是浪费钱。

写压力大到主库扛不住时，优先考虑分库分表或者换更强的机器，而不是加双主。双主解决的是写入可用性，解决不了单表写入的绝对上限。切换预案要提前写。主库挂掉之后谁来判断、谁来提升、应用怎么改连接串，这些步骤演练一次比写十页文档有用，真出事时手忙脚乱是常态，把步骤写成清单贴在旁边，按顺序逐条勾掉，比凭记忆更快也更可靠，切换时每一步都要有人确认结果再往下走，抢着往下执行往往会遗漏校验，反而把窗口拉长。

一千二和八百这两档怎么取舍

一千二那台是双路 8259CL，二十四核四十八线程，131GB 内存，两块两千 GB 固态组成的大容量，主打的是写吞吐和并发连接，适合承担写入压力大的主库角色。

八百那台是单路 6248，二十核四十线程，128GB 内存配六 TB 机械盘，优势在存储容量和单位容量成本，适合放冷数据和备份，容量优势在数据长起来之后会越来越明显。

预算只够一台时选一千二做主库，从库先用小配置或者延后。反过来先买八百做主库，写入压力上来之后迁移成本会更高，主库迁移要停机、要校验数据、要改连接串，一次至少一整天。

两台都买的话就是标准的读写分离形态，主库固态跑写入，从库大容量盘跑回放、备份和报表，两边互不打扰，扩容也有明确方向，读不够加从库，写不够换主库，不用整机重买。

决定之前先量化三个数：每秒写入事务数、单表最大容量、可接受的故障恢复时间。三个数摆出来之后，档位选择基本没有争议，剩下的就是预算和交付时间的权衡，急上线就先用一台扛，慢一点就把两台一起配齐，前期多花一份月付，后面省下的迁移和调试时间远不止这个数。

别忘了算备份的存储。数据长到几百 G 之后，备份要占的空间和主库差不多，只买单机存储不够，这笔容量预算要提前留出来，别等备份失败才发现盘不够。