Linux数据库环境搭建：七步落地实战指南

去年4月，我接手一个新项目——在Linux服务器上搭建MySQL 8.0集群，要求支持高并发读写和主从复制。当时团队里没人碰过MySQL 8.0，网上教程大多停留在5.7版本，连官方文档的中文翻译都滞后两个版本。我硬着头皮啃英文文档，发现新技术带来的便利远超预期——比如InnoDB Cluster的自动故障转移，比传统MHA方案少了至少30%的配置步骤。

第一步选系统时，我直接pass了CentOS 7——这老古董连MySQL官方仓库都不支持8.0。最后选了Ubuntu 20.04 LTS，不是因为它多“优雅”，而是apt源里直接有MySQL APT Repository，一行命令就能添加，比CentOS的yum仓库快三倍。安装时遇到个坑：系统自带的libnuma1版本太低，导致MySQL启动报错，手动从Ubuntu仓库下载2.0.12版本替换后才解决——这细节网上几乎没人提。

配置主从复制时，我踩了个大坑。按照某“权威”教程，在主库配置文件里加了log_bin=mysql-bin，结果从库同步时总报“Error 1236”。查了半天日志，发现是主库的binlog_format没设成ROW模式——这参数在MySQL 8.0里默认是MIXED，而从库要求必须和主库一致。更气人的是，官方文档里这行配置被藏在“高级选项”里，不仔细翻根本找不到。最后我直接在主从库的my.cnf里都加上binlog_format=ROW，问题秒解。

性能调优那步，我试了三种方法。先是用sysbench压测，发现TPS卡在1200左右，远低于硬件极限。查监控发现是InnoDB缓冲池（innodb_buffer_pool_size）设得太小，默认只有128M——这在8.0里简直离谱，直接改成物理内存的70%（64G服务器设了45G），TPS直接飙到3800。接着调连接数，max_connections从151改到500后，并发测试时连接池不再报错。最后优化查询缓存——虽然MySQL 8.0默认禁用了查询缓存，但通过performance_schema的events_statements_summary_by_digest表，还是能找出慢查询，手动加索引后，复杂查询的响应时间从2.3秒降到0.15秒。

说到新技术，MySQL 8.0的InnoDB Cluster真香——以前用MHA搞主从切换，得写脚本、配心跳、监控，现在用MySQL Router+Group Replication，主库挂了，从库自动选举，30秒内完成切换，业务几乎无感知。我特意做了故障演练：拔掉主库网线，观察从库的选举过程，发现新主库的GTID（全局事务标识符）自动同步，数据零丢失。这功能在5.7里得靠第三方工具实现，8.0直接集成，省了多少事？

但新技术也有代价——Group Replication对网络要求极高。有次测试时，从库总报“Error 1129”，查日志发现是网络延迟超过1秒，导致事务无法同步。最后把服务器从公网迁到内网，延迟降到0.2ms，问题解决。这提醒我：新技术虽好，但得先评估基础设施是否达标，不然就是给自己挖坑。

现在回头看，这七步（选系统、装软件、配主从、调性能、测高可用、验数据、写文档）里，最难的不是技术，是细节——比如那个libnuma1的版本问题，比如binlog_format的隐藏配置，比如网络延迟的坑。这些细节，不亲自踩一遍，根本记不住。所以我的建议是：别光看教程，一定要实操——哪怕先在虚拟机里搭一遍，也比看十遍文档强。

文章配图，仅供参考

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!