在云环境中搭建 MySQL 主从架构，核心是利用云平台的弹性网络、高可用存储和自动化运维能力，实现数据同步、读写分离与故障快速切换。关键不在于完全复刻物理机部署逻辑，而是适配云服务特性，避免单点故障，同时控制成本。
选择云厂商提供的托管数据库服务
优先考虑阿里云 RDS、腾讯云 CDB、AWS RDS 或华为云 GaussDB(for MySQL) 等托管方案。它们默认支持一键创建主从实例（如“只读实例”），自动处理 binlog 开启、复制用户授权、GTID 配置、延迟监控和断线重连。你无需手动配置 my.cnf 或管理复制线程，运维负担大幅降低。
创建主实例时，确保“日志保留时间”设为 7 天以上，便于从库异常后追平数据 添加只读实例时，选择与主实例同可用区（低延迟）或跨可用区（高可用），但跨可用区可能产生额外网络费用 开启“延迟监控告警”，阈值建议设为 30 秒，超过即通知或触发自动重启复制若需自建 MySQL（ECS + 云盘），必须强化基础配置
在云服务器（如阿里云 ECS、AWS EC2）上自行安装 MySQL 时，不能沿用本地配置习惯。重点解决网络可达性、磁盘 I/O 稳定性和复制可靠性问题。
主从节点使用同一 VPC，安全组双向放行 3306 端口，禁用公网访问，仅通过内网 IP 复制 系统盘用高效云盘，数据目录挂载 SSD 云盘（如阿里云 ESSD），并启用多队列 IO（Linux 中设置 nr_requests 和 read_ahead_kb） 主库 my.cnf 必须启用：log-bin=mysql-bin、binlog-format=ROW、server-id=1；从库 server-id 设为唯一非零值（如 2），并开启 relay-log-recovery=ON实现可靠的数据同步与切换机制
云环境下的主从不是“搭完就完”，必须建立可观测、可验证、可干预的同步链路。
定期执行 SHOW SLAVE STATUS\G，重点关注 Seconds_Behind_Master（应为 0 或个位数）、Slave_IO_Running 和 Slave_SQL_Running（均为 Yes） 用 pt-table-checksum 工具校验主从数据一致性，每周至少一次；发现差异时用 pt-table-sync 修复，避免直接停写操作 不要依赖手动 CHANGE MASTER TO 切换主从。生产环境应接入中间件（如 MyCat、ShardingSphere）或云厂商的读写分离代理（如阿里云 RDS 的读写分离地址），由其自动识别主库状态并路由预留扩展与容灾路径
云架构的价值在于弹性。主从只是起点，后续可平滑升级为 MGR（MySQL Group Replication）或 InnoDB Cluster，支撑更高可用要求。
主从架构下，从库可作为备份源：每天凌晨用 mysqldump + xtrabackup 对从库做物理备份，存入对象存储（OSS/COS/S3） 跨地域容灾不推荐主从直连（网络延迟高、丢包率高）。应采用“主-异地异步从-本地只读集群”三级结构，或使用云厂商的跨地域备份恢复能力 当业务增长导致单主压力大，可在应用层引入分库分表，或升级为一主多从+读写分离+连接池（如 HikariCP）组合方案
