当前位置：首页 > wzjs >正文

ii6创建网站优购物官方网站女鞋

wzjs 2025/9/19 11:47:50

ii6创建网站,优购物官方网站女鞋,郑州纯手工seo,google广告在wordpress一、核心原理篇 1. 主从同步基础流程（必考） 答： 主库：事务提交后生成binlog，由Dump线程发送给从库从库： I/O线程：接收binlog写入relay log，受slave_net_timeout控制网络超时&…

一、核心原理篇

1. 主从同步基础流程（必考）
答：

主库：事务提交后生成binlog，由Dump线程发送给从库
从库：
- I/O线程：接收binlog写入relay log，受slave_net_timeout控制网络超时（默认3600秒）
- SQL线程：解析relay log执行SQL，单线程设计是经典瓶颈
核心文件：master.info（连接信息）、relay-log.info（执行进度）

2. 异步复制 vs 半同步复制（高频）
答：

异步复制：主库提交事务后立即响应客户端，不等待从库确认（高性能，可能丢数据）
半同步复制（rpl_semi_sync_master_enabled=1）：
- 至少一个从库ACK确认收到日志后才返回客户端
- 超时退化为异步复制（rpl_semi_sync_master_timeout=1000毫秒）

二、配置与监控篇

3. 主从搭建关键步骤（实操题）
答：

-- 主库  
CREATE USER 'repl'@'%' IDENTIFIED BY 'Slave@123';  
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';  
SHOW MASTER STATUS; -- 记录File和Position  -- 从库  
CHANGE MASTER TO  
MASTER_HOST='master_ip',  
MASTER_USER='repl',  
MASTER_PASSWORD='Slave@123',  
MASTER_LOG_FILE='mysql-bin.000001',  
MASTER_LOG_POS=154;  
START SLAVE;

4. 如何监控主从延迟（监控设计题）
答：

内置指标：

SHOW SLAVE STATUS\G  
-- Seconds_Behind_Master（可能不准）  
-- Read_Master_Log_Pos vs Exec_Master_Log_Pos

外部工具：
- Percona Toolkit的pt-heartbeat：时间戳比对（需NTP同步）
- 监控中继日志堆积量：SHOW GLOBAL STATUS LIKE 'Relay_Log_Space'

三、故障排查篇

5. Slave_SQL_Running=No的排查思路（高频故障）
答：

-- 查看具体错误  
SHOW SLAVE STATUS\G  
/*  
Last_Errno: 1062  
Last_Error: Duplicate entry '1001' for key 'PRIMARY'  
*/  -- 临时跳过错误（生产慎用）  
STOP SLAVE;  
SET GLOBAL sql_slave_skip_counter = 1;  
START SLAVE;  -- 根治方案：  
1. 主从数据一致性校验（pt-table-checksum）  
2. 手动修复冲突数据  
3. 重建从库（严重不一致时）

6. 网络闪断导致主从断开如何优化？
答：

修改超时参数加速重连（默认1小时太长）：

# my.cnf  
slave_net_timeout = 10      -- 超时时间（秒）  
master-connect-retry = 5    -- 重试间隔

配合TCP Keepalive参数优化：

net.ipv4.tcp_keepalive_time = 60  
net.ipv4.tcp_keepalive_probes = 3  
net.ipv4.tcp_keepalive_intvl = 10

四、性能优化篇

7. 主从延迟的六大优化方案（架构设计题）
答：

从库层面：
1. 开启并行复制（5.7+）：slave_parallel_workers=4
2. 升级硬件：SSD替换HDD，提升IOPS
3. 调整事务提交策略：sync_binlog=0, innodb_flush_log_at_trx_commit=2
架构层面：
1. 分库分表减少单库压力
2. 使用ProxySQL实现读写分离
3. 添加缓存层减少DB查询

8. GTID复制解决了哪些痛点？（进阶考点）
答：

传统复制问题：依赖binlog文件名和position，切换主库需手动对齐
GTID优势：
- 全局唯一事务ID格式：server_uuid:事务序号
- 自动定位同步点，无需手动指定binlog位置
- 强一致性保障：通过enforce_gtid_consistency控制事务安全

五、高可用篇

9. MHA高可用方案原理（架构设计）
答：

故障转移流程：
1. 检测主库不可用（连续ping失败）
2. 选举最新从库（对比relay log进度）
3. 其他从库切换新主（通过CHANGE MASTER命令）
核心优势：
- 支持GTID和传统复制
- 自动修复数据差异（通过差异binlog）
- VIP漂移对应用透明

10. 延迟从库的应用场景（容灾设计）
答：

CHANGE MASTER TO MASTER_DELAY = 3600; -- 延迟1小时执行

核心价值：
- 误删数据快速恢复（在延迟窗口内停止同步）
- 防范逻辑错误（如错误的UPDATE全表更新）
- 应对极端数据损坏场景

六、终极压轴题

11. 设计一个主从同步监控系统（架构设计题）
答：

数据采集层：
- 从库状态：SHOW SLAVE STATUS
- 延迟检测：pt-heartbeat --check
- 错误日志监控：ELK收集分析ERROR日志
告警规则：
- 同步线程状态异常（Slave_IO/SQL_Running ≠ Yes）
- 延迟超过阈值（如 > 60秒）
- 特定错误码（1062主键冲突、1032数据不存在）
可视化展示：
- Grafana展示：延迟趋势图、线程状态矩阵
- 拓扑图：主从关系与健康状态
自动化处理：
- 邮件/钉钉通知
- 自动跳过可忽略错误（通过预定义白名单）
- 联动K8s进行Pod重建（容器化环境）