MySQL 部署,总结一些在各种学习和实际生产中积累的 MySQL 版本信息和推荐配置。
MySQL 版本选择
通常情况下选择一个版本的 MySQL 主要看官方是否 GA,因为只有 MySQL 官方 GA 的版本才是较为稳定的版本,且修复了大量 Bug 和使用量较大的版本。若对 MySQL 要求比较高时,可采用 GA 后 2-3 个小版本作为生产使用。
- 8.4 LTS 2032 年 4 月 EOF
- 8.0 LTS 2026 年 4 月 EOF,当前(2024 年)主流版本,推荐
- 5.7 LTS 2023 年 10 月 EOF
- 5.x MySQL 版本选择(2015 年 9 月)
下面列举几个较为稳定的 MySQL 5.5/6 的版本:
MySQL-5.1.4(稳定)
MySQL-5.5.10(GA)
MySQL-5.5.40(生产)
MySQL-5.6.15(生产)
MySQL-5.6.26(稳定)资源选择
MySQL 推荐的物理机采用 16 核 cpu2 台作为集群环境。
MySQL 修复和提高版本
有幸曾参加过杭州平民软件楼方鑫老师和王广友老师主讲的平民 MySQL 二期培训。平民软件开发的 onesql-5.6.25-all-intel-linux64.tar.gz 和 onesql-5.6.26-all-intel-linux64.tar.gz 在 MySQL 的并行运算和拆锁上做了大量优化,测试效果也很好,值得推荐。国产数据库的中流砥柱。
MariaDB 版本
-
11.4 LTS 2029 年 5 月 EOF
-
10.11 LTS 2028 年 2 月 EOF
-
10.6 LTS 2026 年 7 月 EOF
-
10.5 LTS 2025 年 6 月 EOF
相关端口
3306/TCPMySQL Classic 协议33060/TCPMySQL X 协议,由mysqlx_port配置33061/TCPInnoDB Cluster 配置期间 MySQL Shell 用于检查服务器的端口33062/TCPMySQL Classic 协议的管理端口,由admin_port配置,MySQL 8.0.14 起提供
快速部署
ubuntu
https://dev.mysql.com/get/mysql-apt-config_0.8.33-1_all.debdocker 部署
- 镜像地址:https://hub.docker.com/_/mysql
docker run -it -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=root mysql:5.7docker-compose 部署
my.cnf
[mysqld]
character-set-system=utf8mb4
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci重启
mysql 重启,如何启动/停止/重启 MySQL
- Linux
启动方式:
- 使用 service 启动:
service mysqld start - 使用 mysqld 脚本启动:
/etc/inint.d/mysqld start - 使用 safe_mysqld 启动:
safe_mysqld &
停止
- 使用 service 启动:
service mysqld stop - 使用 mysqld 脚本启动:
/etc/inint.d/mysqld stop mysqladmin shutdown
重启
- 使用 service 启动:
service mysqld restart - 使用 mysqld 脚本启动:
/etc/inint.d/mysqld restart
- Windows
- 点击
开始->运行(快捷键 Win+R) - 启动:输入
net stop mysql - 停止:输入
net start mysql
高可用方案
高可用方案 如何选择?
| 方案 | 数据一致性 | 自动切换 | 多主写入 | 复杂度 | 适用场景 |
|---|---|---|---|---|---|
| 主从复制 | 异步/半同步 | 手动 | 否 | 低 | 小型业务 |
| MHA | 异步/半同步 | 自动 | 否 | 中 | 中等规模业务 |
| Galera Cluster | 强一致 | 自动 | 是 | 高 | 多主写入、强一致性需求 |
| MySQL Group Replication | 强一致 | 自动 | 可选 | 中 | 官方方案,推荐新项目 |
| InnoDB Cluster | 强一致 | 自动 | 可选 | 高 | 云原生或容器化环境 |
| 中间件方案 | 依赖底层 | 自动 | 否 | 高 | 定制化需求 |
| 云服务商方案 | 依赖配置 | 自动 | 通常否 | 低 | 云上业务,免运维需求 |
按同步类型分:
异步复制:适合对一致性要求低、追求高性能的场景(如读写分离)。半同步复制:平衡一致性和性能,适合金融类业务。Group Replication:需要高可用和强一致的集群环境。延迟复制:用于数据恢复或测试。

异步复制 (Asynchronous Replication)
默认模式:MySQL 主从复制的默认模式。工作原理:- 主库(Master)将事务写入二进制日志(Binary Log)后立即返回成功响应给客户端。
- 从库(Slave)异步拉取并应用二进制日志,可能存在延迟。
特点:高性能:主库无需等待从库确认。弱一致性:主从数据可能存在短暂不一致(复制延迟)。风险:主库故障时可能导致数据丢失(未同步到从库的事务)。
半同步复制 (Semi-Synchronous Replication)
目标:在性能和一致性之间取得平衡。工作原理:- 主库提交事务时,至少等待一个从库确认已接收二进制日志(但不要求完全应用)。
- 如果超时未收到确认,主库会退化为异步复制。
启用方式:需安装插件(如rpl_semi_sync_master和rpl_semi_sync_slave)。特点:减少数据丢失风险:确保至少一个从库有最新数据。轻微延迟:主库需等待从库确认,但性能影响较小。不完全强一致:从库可能尚未应用日志。
全同步复制 (Fully Synchronous Replication)
目标:强一致性(所有节点数据完全一致)。实现方式:- 原生 MySQL 不直接支持全同步,需依赖第三方工具(如
Galera Cluster)或 MySQL Group Replication。 MySQL Group Replication(MGR):- 基于 Paxos 协议,实现多主或单主模式。
- 所有事务需在组内多数节点确认后才提交。
- 原生 MySQL 不直接支持全同步,需依赖第三方工具(如
特点:强一致性:所有节点数据实时一致。高可用性:自动故障转移。性能代价:网络延迟和事务冲突可能影响吞吐量。
延迟复制 (Delayed Replication)
目标:人为设置从库复制延迟(用于误操作恢复或测试)。配置方式:通过CHANGE REPLICATION SOURCE TO SOURCE_DELAY=N(N 为延迟秒数)。特点:- 从库延迟应用主库的二进制日志。
- 可用于快速回滚人为错误(如误删数据)。
多源复制 (Multi-Source Replication)
目标:一个从库同时从多个主库复制数据。适用场景:数据聚合分析或跨分片查询。配置方式:MySQL 5.7+ 支持,需为每个主库配置独立的通道(Channel)。
组复制 (Group Replication)
实现:基于 MySQL Group Replication(MGR),提供高可用集群。模式:单主模式:仅一个节点可写,其他节点自动故障切换。多主模式:所有节点可写,需处理事务冲突。
一致性:基于 Paxos 协议的强一致性。
监控
- 如何使用 Prometheus 监控 MySQL
- mysql_up
- mysql_global_status_threads_connected
mysql_up{${instance}} != 1rate(mysql_global_status_slow_queries{${instance}}[5m]) > 0