1. 双主模式高可用架构设计解析双主模式Dual-Master作为高可用架构的核心方案其本质是通过在两个节点间建立双向数据同步机制使任意节点都能同时承担读写流量。这种架构相比传统主从模式具有三个显著优势首先它彻底消除了单点故障风险其次读写负载可以均匀分布最后故障切换时无需重新选举主节点。在HTTP服务场景中我们通常采用Nginx/HAProxy作为前端负载均衡器配合Keepalived实现VIP漂移。当主节点故障时VIP能在秒级自动迁移到备用节点。而对于MySQL的双主配置则需要特别注意以下技术要点必须启用GTID全局事务标识符来确保事务同步的准确性需要配置auto_increment_increment和auto_increment_offset避免主键冲突建议设置slave_parallel_workers提升同步性能关键提示双主架构最危险的场景是脑裂Split-Brain即两个节点同时认为自己是主节点。必须通过至少三种机制来预防网络心跳检测、磁盘锁仲裁和第三方仲裁服务。2. HTTP服务双主实现详解2.1 负载均衡层配置以Nginx为例其核心配置需要包含健康检查机制upstream backend { server 192.168.1.10:80 max_fails3 fail_timeout30s; server 192.168.1.11:80 max_fails3 fail_timeout30s; keepalive 32; } server { listen 80; location / { proxy_pass http://backend; proxy_next_upstream error timeout http_502 http_503; } }配合Keepalived的VRRP配置vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.1.100/24 dev eth0 } }2.2 会话保持方案对于需要会话保持的应用可采用以下三种方案Cookie插入在负载均衡层注入路由标识共享存储使用Redis集中存储会话数据数据库持久化将会话数据写入后端数据库实测表明基于Redis的共享会话方案在5000并发连接下延迟仅增加8-12ms是性能最优的选择。3. MySQL双主部署实战3.1 基础配置步骤在两台服务器安装相同版本的MySQL建议5.7修改my.cnf关键参数[mysqld] server-id 1 # 另一台设置为2 log_bin mysql-bin binlog_format ROW binlog_row_image FULL gtid_mode ON enforce_gtid_consistency ON log_slave_updates ON auto_increment_increment 2 auto_increment_offset 1 # 另一台设置为2建立复制账户并配置主从关系CHANGE MASTER TO MASTER_HOST192.168.1.11, MASTER_USERrepl, MASTER_PASSWORDSecurePass123, MASTER_AUTO_POSITION1; START SLAVE;3.2 数据一致性验证推荐使用pt-table-checksum工具进行周期性校验pt-table-checksum --replicatetest.checksums \ --create-replicate-table \ --empty-replicate-table \ --recursion-methoddsnh192.168.1.10,Dtest,tdsns当检测到差异时使用pt-table-sync进行修复pt-table-sync --replicatetest.checksums \ h192.168.1.10,uadmin,ppassword \ --print4. 典型故障处理手册4.1 502 Bad Gateway排查当出现502 Bad Gateway错误时按以下步骤排查检查后端服务进程状态systemctl status nginx ps aux | grep mysql验证网络连通性telnet 192.168.1.10 3306 curl -I http://localhost/health分析日志线索tail -n 100 /var/log/nginx/error.log grep -i error /var/log/mysql/error.log4.2 主从同步中断处理当出现复制错误时典型修复流程查看复制状态SHOW SLAVE STATUS\G常见错误处理1062错误主键冲突通过pt-slave-restart跳过1032错误行不存在使用pt-table-sync修复1236错误binlog问题重建复制关系安全跳过错误慎用STOP SLAVE; SET GLOBAL sql_slave_skip_counter1; START SLAVE;5. 性能优化关键参数5.1 MySQL调优建议innodb_buffer_pool_size 12G # 物理内存的70-80% innodb_log_file_size 2G innodb_flush_method O_DIRECT sync_binlog 1 innodb_io_capacity 2000 innodb_io_capacity_max 40005.2 Nginx优化参数worker_processes auto; worker_rlimit_nofile 100000; events { worker_connections 4096; multi_accept on; use epoll; } http { keepalive_timeout 30; keepalive_requests 10000; sendfile on; tcp_nopush on; }6. 监控体系搭建方案完整的监控应包含三个维度基础设施层服务器CPU/内存/磁盘/网络进程Nginx/MySQL进程存活VIP状态arping检测服务层HTTP响应时间、状态码分布MySQL活跃连接数、QPS、复制延迟业务层关键事务成功率核心接口响应时间推荐使用PrometheusGranfana组合关键指标示例- name: mysql_status rules: - alert: MySQLReplicationLag expr: mysql_slave_status_seconds_behind_master 30 for: 5m - alert: MySQLDown expr: up{jobmysql} 0 for: 1m7. 安全加固要点网络隔离数据库节点置于内网配置安全组仅允许应用服务器访问3306端口使用SSL加密复制通道访问控制CREATE USER appuser192.168.1.% IDENTIFIED BY ComplexPass123; GRANT SELECT,INSERT,UPDATE,DELETE ON appdb.* TO appuser192.168.1.%;审计日志plugin-load audit_log.so audit_log_format JSON audit_log_policy ALL8. 灾备演练方案定期执行以下演练流程计划内切换测试# 在备用节点 mysqladmin -uroot -p shutdown # 观察VIP是否漂移应用是否自动重连数据一致性验证mysqldump --single-transaction -h192.168.1.10 -uroot -p db1 primary.sql mysqldump --single-transaction -h192.168.1.11 -uroot -p db1 standby.sql diff (sha256sum primary.sql) (sha256sum standby.sql)网络分区模拟iptables -A INPUT -s 192.168.1.11 -j DROP # 观察集群行为是否符合预期
