1. Docker复杂安装场景概述当我们需要在生产环境部署数据库集群或分布式缓存系统时Docker的优势就充分显现出来了。相比传统部署方式容器化方案能实现环境隔离、快速扩容和统一管理。但像MySQL主从复制、Redis集群这类复杂服务的容器化部署会遇到网络配置、数据持久化、服务发现等一系列特有的技术挑战。我最近在金融项目中将MySQL和Redis从物理机迁移到Docker环境期间踩了不少坑。比如Redis集群节点间通信突然中断、MySQL主从同步延迟飙升等问题都是传统单机部署不会遇到的。通过这次实践我总结出一套可靠的部署方案特别适合需要高可用架构的中大型项目。2. MySQL主从复制的容器化实现2.1 容器网络架构设计MySQL主从集群的容器部署首要解决的是网络通信问题。我推荐使用自定义bridge网络而不是默认的bridgedocker network create --driver bridge mysql-cluster-net这种方式的优势在于容器间可以通过容器名直接通信自动提供DNS解析服务可以自定义子网和网关重要提示避免使用host网络模式虽然简单但会带来端口冲突和安全风险。2.2 主库容器配置启动主库容器时需要特别注意以下参数docker run -d --name mysql-master \ --network mysql-cluster-net \ -v /data/mysql/master:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORDyourstrongpassword \ -e MYSQL_REPLICATION_USERrepl \ -e MYSQL_REPLICATION_PASSWORDreplpass \ mysql:8.0 \ --server-id1 \ --log-binmysql-bin \ --binlog-formatROW \ --gtid-modeON \ --enforce-gtid-consistencyON关键配置解析server-id必须是集群内唯一IDGTID模式能确保数据一致性数据卷挂载到宿主机防止数据丢失2.3 从库容器配置从库启动时需要连接主库docker run -d --name mysql-slave \ --network mysql-cluster-net \ -v /data/mysql/slave:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORDyourstrongpassword \ mysql:8.0 \ --server-id2 \ --log-slave-updatesON \ --gtid-modeON \ --enforce-gtid-consistencyON \ --skip-slave-start启动后需要在从库容器内执行CHANGE MASTER TO MASTER_HOSTmysql-master, MASTER_USERrepl, MASTER_PASSWORDreplpass, MASTER_AUTO_POSITION1; START SLAVE;2.4 常见问题排查同步延迟问题检查主库show processlist是否有大事务调整从库slave_parallel_workers参数增加从库容器CPU和内存资源GTID不一致错误STOP SLAVE; SET GTID_NEXTaaa-bbb-ccc-ddd:123; BEGIN; COMMIT; SET GTID_NEXTAUTOMATIC; START SLAVE;网络中断恢复使用docker network inspect检查网络状态考虑使用restart: always保证容器自动恢复3. Redis集群的容器化部署3.1 集群规划与哈希槽分配Redis集群采用哈希槽分区方案共16384个槽位。我们以6节点集群为例3主3从节点类型容器名称槽位范围从属关系主节点redis-node10-5460-主节点redis-node25461-10922-主节点redis-node310923-16383-从节点redis-node4-node1从节点redis-node5-node2从节点redis-node6-node33.2 容器启动配置使用官方redis镜像启动集群节点for port in $(seq 6379 6384); do docker run -d --name redis-node$((port-6378)) \ --net host \ -v /data/redis/node$((port-6378))/data:/data \ redis:7.0 redis-server \ --cluster-enabled yes \ --cluster-config-file nodes.conf \ --cluster-node-timeout 5000 \ --appendonly yes \ --port ${port} done注意生产环境建议使用自定义网络而非host模式这里为演示简化3.3 集群初始化进入任意容器执行集群创建命令redis-cli --cluster create \ 127.0.0.1:6379 \ 127.0.0.1:6380 \ 127.0.0.1:6381 \ 127.0.0.1:6382 \ 127.0.0.1:6383 \ 127.0.0.1:6384 \ --cluster-replicas 13.4 集群运维要点节点扩容redis-cli --cluster add-node new_node:port existing_node:port redis-cli --cluster reshard existing_node:port故障转移测试手动停止主节点容器观察从节点晋升使用cluster nodes命令查看节点角色变化数据迁移redis-cli --cluster import host:port \ --cluster-from source_host:port \ --cluster-copy4. 生产环境优化建议4.1 资源限制与监控在docker-compose.yml中配置资源限制services: redis-node: deploy: resources: limits: cpus: 2 memory: 4G reservations: cpus: 0.5 memory: 1G推荐监控指标容器内存使用率Redis集群槽位覆盖状态MySQL主从延迟秒数4.2 备份策略MySQL备份方案docker exec mysql-master \ mysqldump -uroot -p --all-databases --single-transaction backup.sqlRedis备份方案docker exec redis-node1 \ redis-cli --cluster backup /data/dump.rdb4.3 安全加固措施修改默认端口启用TLS加密通信配置合理的ACL规则定期轮换密码5. 容器化部署的深度思考在实际项目中我逐渐发现容器化数据库的几个关键点数据持久化必须使用volume不能依赖容器存储层。曾经因为没挂载volume导致升级时数据丢失教训深刻。网络时延对性能影响很大。在跨主机部署时需要确保宿主机间的网络质量。某次故障就是因为主机间网络抖动导致Redis集群脑裂。资源隔离不彻底可能引发问题。MySQL容器和Redis容器混部时曾出现内存竞争导致OOM。现在会严格限制每个容器的内存上限。监控体系需要特别设计。传统监控工具往往只监控宿主机需要补充容器内关键指标的采集。这些经验都是在生产环境踩坑后总结的希望对准备容器化改造的团队有所帮助。