数据库部署与运维 - 运维技术服务中心

← 返回主页

案例 01

MySQL 主从复制 + MHA 高可用架构搭建

背景描述

某电商平台数据库为单机 MySQL 5.7，一次主库硬件故障导致宕机 4 小时，直接损失超百万。需搭建高可用架构，实现自动故障切换，RTO < 30 秒。

解决方案

搭建 1 主 2 从 + MHA（Master High Availability）Manager 架构。MHA 监控主库状态，故障时自动选最优从库提升为主库，VIP 自动漂移。同时配置半同步复制减少数据丢失风险。

技术要点

半同步复制：rpl_semi_sync_master_wait_for_slave_count=1，至少一个从库确认
MHA Manager 部署在独立服务器，通过 SSH 免密管理所有 MySQL 节点
VIP 漂移：MHA 脚本自动调用 keepalived 或 ifconfig 切换 VIP
故障切换流程：检测主库不可达 → 选最新从库 → 补差异日志 → 提升为新主 → VIP 漂移

# 主库配置 my.cnf
[mysqld]
server-id = 1
log-bin = mysql-bin
binlog_format = ROW
sync_binlog = 1                  # 每次事务刷盘
innodb_flush_log_at_trx_commit = 1
rpl_semi_sync_master_enabled = 1
rpl_semi_sync_master_timeout = 10000  # 10s 超时降级为异步

# 从库配置
server-id = 2
relay-log = relay-bin
read_only = 1
rpl_semi_sync_slave_enabled = 1

# 建立主从复制
CHANGE MASTER TO
  MASTER_HOST='192.168.1.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='repl_password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=154;
START SLAVE;
SHOW SLAVE STATUS\G  # 确认 Slave_IO_Running=Yes, Slave_SQL_Running=Yes

# MHA 检查 SSH 连通性
masterha_check_ssh --conf=/etc/mha/app1.cnf
masterha_check_repl --conf=/etc/mha/app1.cnf
# 启动 MHA Manager
nohup masterha_manager --conf=/etc/mha/app1.cnf &

案例 02

Redis Cluster 集群搭建与扩容

背景描述

某社交 APP 缓存层原来使用单机 Redis（32GB 内存），随着用户增长，内存即将写满且单机 QPS 已达瓶颈（8 万 QPS）。需要搭建 Redis Cluster 实现水平扩容。

解决方案

搭建 6 节点 Redis Cluster（3 主 3 从），每节点 16GB 内存，总容量 48GB。数据按 16384 个 Slot 均匀分布。后续业务增长时在线添加节点、迁移 Slot，无需停服。

技术要点

Redis Cluster 内部使用 Gossip 协议维护节点状态，无需额外组件
Slot 迁移使用 redis-cli --cluster reshard，在线完成，不影响读写
内存策略：maxmemory-policy volatile-lru（仅淘汰有过期时间的 Key）
客户端需支持 Cluster 模式（JedisCluster / Lettuce / redis-py-cluster）

# 每个节点 redis.conf 配置
port 6379
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
maxmemory 16gb
maxmemory-policy volatile-lru
save 900 1
save 300 10
appendonly yes

# 创建集群（6 节点：3 主 3 从）
redis-cli --cluster create \
  192.168.1.11:6379 192.168.1.12:6379 192.168.1.13:6379 \
  192.168.1.14:6379 192.168.1.15:6379 192.168.1.16:6379 \
  --cluster-replicas 1

# 查看集群状态
redis-cli -c -h 192.168.1.11 -p 6379 cluster info
redis-cli -c -h 192.168.1.11 -p 6379 cluster nodes

# 在线扩容：添加新节点并迁移 Slot
redis-cli --cluster add-node 192.168.1.17:6379 192.168.1.11:6379
redis-cli --cluster reshard 192.168.1.11:6379 \
  --cluster-from all --cluster-to  \
  --cluster-slots 4096

案例 03

MySQL 慢查询治理与索引优化实战

背景描述

某订单系统的订单列表查询接口响应时间从 200ms 逐渐恶化到 8s，监控显示数据库 CPU 长期 >85%。慢查询日志显示一个关联 4 张表的查询扫描了 200 万行。

解决方案

开启 slow_query_log 定位慢 SQL → 使用 EXPLAIN 分析执行计划 → 发现缺失复合索引导致全表扫描 → 创建覆盖索引 → 优化 SQL 避免 SELECT * → 响应时间降至 80ms。

技术要点

慢查询阈值：long_query_time=0.5（500ms），超过记录到 slow.log
EXPLAIN 分析：关注 type（ALL=全表扫描, index=全索引扫描, ref=索引查找）和 rows
复合索引最左前缀原则：WHERE 条件顺序要与索引列顺序匹配
定期分析：pt-query-digest 汇总慢查询 TOP 10，每月专项治理

# 开启慢查询日志
SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 0.5;
SET GLOBAL log_queries_not_using_indexes = 1;

# 分析慢查询
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log
# 或使用 Percona Toolkit
pt-query-digest /var/log/mysql/slow.log --limit=10

# EXPLAIN 分析执行计划
EXPLAIN SELECT o.*, u.name FROM orders o
LEFT JOIN users u ON o.user_id = u.id
WHERE o.status = 'paid' AND o.created_at > '2026-01-01'
ORDER BY o.created_at DESC;

# 创建优化索引
ALTER TABLE orders ADD INDEX idx_status_created (status, created_at);
# 覆盖索引（避免回表）
ALTER TABLE orders ADD INDEX idx_cover (status, created_at, id, user_id, amount);

# 查看索引使用情况
SELECT * FROM sys.schema_unused_indexes;     # 未使用的冗余索引
SELECT * FROM sys.schema_redundant_indexes;  # 重复索引