MySQL 部署

MySQL 部署，总结一些在各种学习和实际生产中积累的 MySQL 版本信息和推荐配置。

MySQL 版本选择

• https://en.wikipedia.org/wiki/MySQL#Release_history

通常情况下选择一个版本的 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/TCP MySQL Classic 协议
• 33060/TCP MySQL X 协议，由 mysqlx_port 配置
• 33061/TCP InnoDB Cluster 配置期间 MySQL Shell 用于检查服务器的端口
• 33062/TCP MySQL Classic 协议的管理端口，由 admin_port 配置，MySQL 8.0.14 起提供

快速部署

ubuntu

https://dev.mysql.com/get/mysql-apt-config_0.8.33-1_all.deb

docker 部署

• 镜像地址：https://hub.docker.com/_/mysql

docker run -it -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=root mysql:5.7

docker-compose 部署

• my.cnf

[mysqld]
character-set-system=utf8mb4
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci

重启

mysql 重启，如何启动/停止/重启 MySQL

1. 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

2. 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 协议，实现多主或单主模式。
    • 所有事务需在组内多数节点确认后才提交。
• 特点：
  • 强一致性：所有节点数据实时一致。
  • 高可用性：自动故障转移。
  • 性能代价：网络延迟和事务冲突可能影响吞吐量。

延迟复制 (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}} != 1
  • rate(mysql_global_status_slow_queries{${instance}}[5m]) > 0