怎么用思维导图做网站结构图品牌策划与推广实训报告

怎么用思维导图做网站结构图,品牌策划与推广实训报告,电工培训课程,ui设计的工作流程一、主从复制的核心价值#xff1a;从业务场景看技术必要性当单库 QPS 突破 1 万、数据量达到 TB 级时#xff0c;单节点 MySQL 会面临 写入瓶颈、数据丢失风险、读请求拥堵 三重挑战。主从复制并非单纯的备份工具#xff0c;而是围绕业…一、主从复制的核心价值从业务场景看技术必要性当单库 QPS 突破 1 万、数据量达到 TB 级时单节点 MySQL 会面临 写入瓶颈、数据丢失风险、读请求拥堵 三重挑战。主从复制并非单纯的备份工具而是围绕业务需求设计的复合型解决方案核心价值落地于四类场景核心价值 业务场景案例 技术收益读写分离 电商商品详情页读多写少QPS 峰值 10 万 读压力分散到多从库单库读能力提升 3-5 倍数据安全 金融交易系统不允许数据丢失 RPO恢复点目标控制在秒级避免单点丢失高可用 支付核心系统需 7×24 小时运行 RTO恢复时间目标控制在分钟级无业务中断业务隔离 报表统计系统需全量数据耗资源 避免统计任务占用主库 CPU/IO不影响线上业务二、深度拆解主从复制的底层原理MySQL 主从复制依赖二进制日志binlog 为数据载体通过 3 个核心进程主库 binlog dump 线程、从库 IO 线程、从库 SQL 线程协同实现 主库数据变更→从库数据重放 的完整链路。2.1 核心载体二进制日志binlog的工作机制binlog 是主库记录 数据变更 的二进制文件其特性直接决定复制稳定性记录时机事务提交时写入先写 redo log再写 binlog通过 二阶段提交 确保一致性事件类型Query_event记录非事务性 SQL如 CREATE TABLE、ALTER TABLERow_event记录行级数据变更INSERT/UPDATE/DELETE含 变更前后数据binlog_formatROW 模式核心Xid_event标记事务提交帮助从库 SQL 线程识别事务边界文件特性按 max_binlog_size默认 1GB轮转MySQL 5.6 支持 binlog_checksumCRC32 校验避免传输篡改2.2 进程协同主从数据同步的完整链路1主库binlog dump 线程从库 IO 线程发起同步请求时主库为该从库创建独立的 binlog dump 线程读取主库 binlog 的 指定位置从库通过 MASTER_LOG_FILE/MASTER_LOG_POS 指定实时推送 binlog 事件到从库 IO 线程无新事件时进入休眠有新事务提交时被唤醒2从库IO 线程与主库建立 TCP 连接发送 复制账号密码 同步起始位置接收主库推送的 binlog 事件写入本地中继日志relay log更新 master.info/relay-log.info 文件记录同步进度避免从库重启后中断3从库SQL 线程独立于 IO 线程按 主库事务提交顺序 重放中继日志事件binlog_formatROW 模式下直接操作数据行无需解析 SQL 语法避免主从 SQL_mode 不一致导致的重放失败遇错误如主键冲突时停止需人工修复或工具跳过2.3 复制模式异步、半同步与全同步的差异复制模式 核心逻辑 优点 缺点 适用场景异步复制默认 主库提交事务后立即返回不等待从库同步 主库性能高无延迟 主库崩溃可能丢失数据 非核心业务如日志存储半同步复制 主库提交后等待至少 1 个从库确认 接收 binlog 数据安全性高避免丢失 主库响应延迟增加10-50ms 核心业务如用户中心全同步复制 主库提交后等待所有从库确认 重放完成 数据绝对一致 主库性能差延迟高 金融级业务如交易支付注半同步复制需安装插件INSTALL PLUGIN rpl_semi_sync_master SONAME semisync_master.so;并启用 set global rpl_semi_sync_master_enabled1;三、复制形态对比如何选择适合的架构根据业务规模与高可用需求主从复制分为四类典型形态需从 延迟、复杂度、可用性 三维度选型3.1 基础形态一主一从Master-Slave架构逻辑[主库写] → [从库读备份]主库处理所有写请求从库承接读请求 数据备份从库仅单向同步主库数据不反向同步核心优劣势✅ 优势架构简单运维成本低支持快速读写分离ProxySQL/MyCat❌ 劣势从库故障后读压力回退主库主库故障需手动切换RTO 高适用场景中小业务QPS≤5000测试环境或非核心业务如后台管理系统3.2 扩展形态一主多从Master-Multi Slave架构逻辑[主库写] → [从库1线上读]→ [从库2报表统计]→ [从库3数据备份]主库 1 台从库 N 台N≥2按业务拆分从库用途核心优劣势✅ 优势读压力分散支撑高读 QPS如 10 万从库故障不影响整体❌ 劣势主库需维护 N 个 binlog dump 线程网络压力大从库数量越多延迟越高适用场景读多写少业务如电商商品页、资讯 APP单主库 QPS≤1 万从库数量≤5 台3.3 高可用形态双主互备Master-Master架构逻辑[主库A默认写] ↔ [主库B备用写]↑ ↑[业务层虚拟IP]两台服务器互为主从默认业务访问主库 AA 故障后通过 Keepalived 切换虚拟 IP 到 BB 成为新主库关键配置解决冲突主键冲突auto_increment_offset1A、auto_increment_offset2Bauto_increment_increment2两者均设循环复制通过 server-id 过滤主库不同步自身生成的 binlog适用场景核心业务如订单系统对主库可用性要求高RTO≤5 分钟的场景3.4 大规模形态级联复制Master-Slave-Slave架构逻辑[主库写] → [中间从库转发] → [二级从库1读]→ [二级从库2读]→ [二级从库3读]主库仅同步到 中间从库中间从库开启 log_slave_updates1再同步到二级从库核心优劣势✅ 优势主库仅维护 1 个 binlog dump 线程网络压力低二级从库故障不影响主库❌ 劣势延迟叠加主→中间→二级中间从库故障导致所有二级从库中断适用场景大规模业务从库数量≥6 台跨地域场景如主库北京中间从库上海二级从库广州四、实操主从复制部署全流程基于 MySQL 5.7以 一主一从 架构为例从环境准备到验证拆解每一步落地操作4.1 环境准备节点 IP 地址 角色 MySQL 版本 核心配置要求主库M 192.168.1.10 Master 5.7.40 内存≥4GBSSD 磁盘≥100GB从库S 192.168.1.11 Slave 5.7.40 配置与主库一致避免性能差前置操作关闭防火墙 禁用 SELinux# 关闭防火墙systemctl stop firewalld systemctl disable firewalld# 禁用SELinuxsetenforce 0 sed -i s/SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config4.2 主库配置关键步骤步骤 1修改 MySQL 配置文件/etc/my.cnf[mysqld]# 核心复制参数server-id 10 # 全局唯一建议用IP后两位log_bin /var/lib/mysql/mysql-bin # 开启binlog指定路径binlog_format ROW # 行级格式避免跨库同步问题binlog_row_image FULL # 记录完整行数据便于恢复sync_binlog 1 # 事务提交强制刷盘确保binlog不丢失expire_logs_days 7 # binlog保留7天避免磁盘占满# 性能优化参数innodb_flush_log_at_trx_commit 1 # redo log实时刷盘max_binlog_size 1G # 单个binlog最大1GB步骤 2重启 MySQL 并验证配置# 重启MySQLsystemctl restart mysqld# 登录MySQL验证mysql -u root -pmysql show variables like log_bin; # 结果ValueON表示开启mysql show variables like binlog_format; # 结果ValueROW步骤 3创建复制专用账号并授权# 创建账号仅允许从库IP访问CREATE USER repl192.168.1.11 IDENTIFIED BY Repl123;# 授予最小复制权限遵循最小权限原则GRANT REPLICATION SLAVE ON *.* TO repl192.168.1.11;# 刷新权限FLUSH PRIVILEGES;步骤 4锁表备份主库数据# 登录主库锁表仅禁止写允许读mysql FLUSH TABLES WITH READ LOCK;# 查看binlog同步起始位置记录File和Positionmysql show master status;# 示例结果# ------------------------------------------------------------# | File | Position | Binlog_Do_DB | Binlog_Ignore_DB |# ------------------------------------------------------------# | mysql-bin.000001 | 154 | | |# ------------------------------------------------------------# 备份主库数据InnoDB支持--single-transaction无锁备份mysqldump -u root -p --all-databases --master-data2 --single-transaction master_backup.sql# 解锁主库备份完成后mysql UNLOCK TABLES;4.3 从库配置关键步骤步骤 1修改 MySQL 配置文件/etc/my.cnf[mysqld]# 核心复制参数server-id 11 # 与主库不同全局唯一relay_log /var/lib/mysql/relay-bin # 开启中继日志必须log_slave_updates 0 # 一主一从无需开启级联复制设为1read_only 1 # 普通用户只读super_read_only 1 # super权限用户只读MySQL 5.7slave_sql_verify_checksum 1 # 验证中继日志校验和# 性能优化参数slave_parallel_workers 4 # 4个SQL线程并行重放加速同步步骤 2重启 MySQL 并恢复主库备份# 重启MySQLsystemctl restart mysqld# 恢复主库备份确保从库初始数据与主库一致mysql -u root -p master_backup.sql步骤 3关联主库并启动复制# 登录从库停止现有复制首次部署可跳过mysql STOP SLAVE;# 关联主库信息替换为实际主库参数mysql CHANGE MASTER TOMASTER_HOST192.168.1.10,MASTER_USERrepl,MASTER_PASSWORDRepl123,MASTER_LOG_FILEmysql-bin.000001, # 主库show master status的FileMASTER_LOG_POS154, # 主库show master status的PositionMASTER_CONNECT_RETRY30; # 连接失败重试间隔秒# 启动复制mysql START SLAVE;步骤 4验证复制状态核心mysql SHOW SLAVE STATUS\G;需确保以下参数为 YesSlave_IO_Running: YesIO 线程正常Slave_SQL_Running: YesSQL 线程正常Seconds_Behind_Master: 0从库无延迟4.4 读写分离验证可选# 主库执行写入测试数据mysql use test;mysql create table user(id int primary key auto_increment, name varchar(20));mysql insert into user(name) values(test1);# 从库执行查询验证应返回test1mysql use test;mysql select * from user;# 结果-----------# | id | name |# -----------# | 1 | test1 |# -----------五、Percona Toolkit复制运维的 利器 原理与实操Percona Toolkit 是 MySQL 运维开源工具集以下 4 个工具专为复制设计需理解原理避免误用5.1 pt-table-checksum主从数据一致性校验核心原理分块校验将大表按 主键范围 拆分为 chunk默认 1000 行/块避免锁表哈希计算主库对每个 chunk 计算 CRC32 哈希写入 replicate 指定的校验表如 demo.checksums从库同步校验表后对比主从哈希值DIFFS0 为一致实操命令pt-table-checksum \--nocheck-replication-filters \ # 不忽略任何表--replicatedemo.checksums \ # 校验结果存储表--no-check-binlog-format \ # 不检查binlog格式ROW兼容--databasesdemo \ # 待校验数据库h192.168.1.10, uroot, pRoot123, P3306 # 主库信息结果解读列名 含义 关键值TS 校验时间 -ERRORS 错误数 0无错误DIFFS 不一致数 0一致1不一致ROWS 表行数 -TABLE 表名 -5.2 pt-table-sync主从数据不一致修复核心原理定位不一致读取 pt-table-checksum 的校验表找到 DIFFS1 的 chunk生成修复 SQL从主库读取正确数据生成 REPLACE补数据或 DELETE删多余数据语句原子执行修复时加行级锁InnoDB避免数据篡改实操命令# 1. 生成修复SQL仅打印不执行pt-table-sync \--print \ # 打印SQL--sync-to-master \ # 以主库为基准h192.168.1.11, uroot, pRoot123 \ # 从库信息--databasesdemo \--tablesuser# 2. 执行修复确认SQL正确后pt-table-sync \--execute \ # 执行修复--sync-to-master \h192.168.1.11, uroot, pRoot123 \--databasesdemo \--tablesuser5.3 pt-online-schema-change在线修改表结构无锁核心原理解决大表 DDL 锁表问题创建临时表复制原表结构如 demo.user为 demo._user_new在临时表执行 ALTER创建触发器原表添加 INSERT/UPDATE/DELETE 触发器确保写操作同步到临时表增量同步数据分批次复制原表数据到临时表默认 1000 行/批原子切换RENAME TABLE demo.user TO demo._user_old, demo._user_new TO demo.user清理残留删除原表与触发器实操命令修改字段长度pt-online-schema-change \h192.168.1.10, uroot, pRoot123, Ddemo, tuser \ # 主库表--alterCHANGE COLUMN name name varchar(50) NOT NULL \ # DDL语句--execute \ # 执行操作--dry-run仅测试--print \ # 打印过程--chunk-size2000 # 每批复制2000行5.4 pt-heartbeat主从延迟精准监测核心原理解决 Seconds_Behind_Master 不准问题主库写入心跳每秒更新 心跳表如 demo.heartbeat记录 server_id 和 ts微秒级时间戳从库计算延迟同步心跳表后用 从库当前时间 - 心跳ts 计算延迟避免 SQL 线程堵塞误判实操命令# 1. 主库后台运行每秒更新心跳pt-heartbeat \uroot, pRoot123, h192.168.1.10 \--create-table \ # 自动创建心跳表-D demo \ # 数据库--interval1 \ # 1秒更新一次--update \ # 更新现有记录--daemonize \ # 后台运行# 2. 从库监测延迟pt-heartbeat \uroot, pRoot123, h192.168.1.11 \-D demo \--monitor \ # 持续监测--tableheartbeat结果解读0.00s [0.00s, 0.00s, 0.00s]前值实时延迟括号内1 分钟/5 分钟/15 分钟平均延迟六、常见问题与排查方案主从复制故障集中在 同步中断、延迟过高 两类需按 日志→进程→配置 顺序排查6.1 同步中断Slave_IO_Running/Slave_SQL_RunningNo1IO 线程中断Slave_IO_RunningNo排查步骤查看从库错误日志cat /var/log/mysqld.log | grep Slave IO thread aborted常见原因主从网络不通ping 192.168.1.10 telnet 192.168.1.10 3306复制账号密码错误重新执行 CHANGE MASTER TO 核对参数主库 binlog 文件不存在主库已删除 binlog需重新备份主库数据解决方案# 重新关联主库用新的show master status结果mysql STOP SLAVE IO_THREAD;mysql CHANGE MASTER TO MASTER_LOG_FILEmysql-bin.000002, MASTER_LOG_POS154;mysql START SLAVE IO_THREAD;2SQL 线程中断Slave_SQL_RunningNo排查步骤查看错误信息SHOW SLAVE STATUS\G 中的 Last_Errno如 1062 主键冲突1032 记录不存在定位错误 SQL# 查看主库binlog中对应位置的SQLmysqlbinlog --no-defaults -v -v --base64-outputdecode-rows /var/lib/mysql/mysql-bin.000002 | grep -A 10 154解决方案主键冲突1062# 方法1删除从库重复记录后重启mysql delete from demo.user where id1;mysql START SLAVE SQL_THREAD;# 方法2用pt-slave-restart跳过错误pt-slave-restart -u root -p Root123 -h 192.168.1.11 --error-numbers1062记录不存在1032# 主库查询数据mysql select * from demo.user where id1;# 从库补全数据mysql insert into demo.user(id, name) values(1, test1);# 重启SQL线程mysql START SLAVE SQL_THREAD;6.2 主从延迟过高Seconds_Behind_Master30原因 排查方法 解决方案从库 SQL 线程并行度不足 查看 slave_parallel_workers默认 0 设为 CPU 核心数如 4 核设为 4主库写压力过大 主库 show processlist 看慢 SQL 分库分表如 ShardingSphere 增加从库从库硬件性能差 iostat -x 1 看磁盘 IO% util≥90% 为满 升级 SSD 增加内存避免 IO 瓶颈大事务如批量插入 10 万行 主库 show engine innodb status 看长事务 拆分为小事务如每次插入 1000 行从库存在慢查询 从库 show slow logs 看慢查询 优化索引如添加联合索引七、总结与最佳实践核心原则优先使用 binlog_formatROW避免跨库同步问题从库必须开启 read_onlysuper_read_only防止误写主从 server-id 必须唯一避免循环复制运维工具链一致性校验pt-table-checksum数据修复pt-table-sync延迟监测pt-heartbeat在线 DDLpt-online-schema-change高可用进阶中小业务一主多从 Keepalived中大型业务MGRMySQL Group Replication金融级业务全同步复制 异地多活