dedecms更改网站logo成都自动seo

dedecms更改网站logo,成都自动seo,网站网上预定功能怎么做,小学最好的网站建设MySQL 主从同步是如何实现的#xff1f;关键词#xff1a;binlog、I/O 线程、SQL 线程、relay log、GTID、半同步复制。 目标#xff1a;搞清楚“主库做了什么#xff0c;从库做了什么#xff0c;中间又传了什么”。一、先用一张逻辑图概括一下 逻辑流程可以概括成 4 步关键词binlog、I/O 线程、SQL 线程、relay log、GTID、半同步复制。目标搞清楚“主库做了什么从库做了什么中间又传了什么”。一、先用一张逻辑图概括一下逻辑流程可以概括成 4 步应用 - 写主库 主库 - 写 binlog 从库 - 拉取主库 binlogI/O 线程 从库 - 回放 relay logSQL 线程更具体一点主库接收写请求执行事务把变更写入 binlog从库的 I/O 线程从主库拉取 binlog写到自己的 relay log中继日志从库的 SQL 线程读取 relay log在从库重放这些变更从而保证主从之间数据尽量一致有复制延迟。二、主从复制的核心binlog2.1 binlog 是什么binlog二进制日志是 MySQL Server 层的日志记录“数据变更的逻辑事件”比如INSERT ...UPDATE ...DELETE ...ALTER TABLE ...作用主从复制从库通过读取主库的 binlog 来重放变更数据恢复配合全量备份用 binlog 回放增量数据审计/数据同步一些中间件也会基于 binlog 做数据同步。2.2 binlog 的格式Statement / Row / Mixedbinlog 有 3 种格式STATEMENT基于语句记录执行的 SQL 语句本身优点日志体积小缺点某些不确定性语句可能导致主从执行结果不一致如NOW()、RAND()等。ROW基于行记录每一行数据变更前后的值优点复制更精确不会受函数、副作用影响缺点日志量大。MIXED混合MySQL 自动在 STATEMENT 和 ROW 之间选择一般不确定是否安全时采用 ROW。生产环境中很多场景会选择ROW 格式更安全日志量问题可以用压缩、拆分等方式处理。三、主从复制的基本流程经典异步复制3.1 主库端写 binlog当你在主库执行一个事务BEGIN;UPDATEaccountSETbalancebalance-100WHEREid1;UPDATEaccountSETbalancebalance100WHEREid2;COMMIT;内部流程大致是InnoDB 写 undo log / redo log完成事务更新MySQL Server 层生成对应的 binlog 事件根据 binlog_format 格式事务提交时redo log binlog 两阶段提交确保事务成功提交 ⇒ binlog 一定写成功防止主从之间出现“主库有数据但 binlog 丢了”的情况。3.2 从库端I/O 线程拉 binlog在从库上配置CHANGE MASTERTOMASTER_HOST主库IP,MASTER_PORT3306,MASTER_USERrepl_user,MASTER_PASSWORDrepl_pwd,MASTER_LOG_FILEmysql-bin.000001,MASTER_LOG_POS4;STARTSLAVE;从库会启动两个线程I/O 线程连接到主库发起复制请求主库为其开启一个binlog dump 线程主库将后续 binlog 事件源源不断发给从库从库 I/O 线程接收后将其顺序写入本地的relay log中继日志。SQL 线程从 relay log 中依次读取事件将其“回放”到从库上等价于在从库执行同样的变更最终效果主库执行完的事务经过 binlog 流转到从库从库重放这些事务数据达到“最终一致”存在时间延迟。3.3 relay log中继日志从库本地维护的一个日志文件结构类似于主库的 binlog优点I/O 线程和 SQL 线程解耦即使主库短暂不可用已有的 relay log 仍可继续重放。四、复制模式异步 / 半同步 / 全同步4.1 异步复制默认主库提交事务后不关心从库有没有同步成功只要本地事务和 binlog 写成功就算成功。优点延迟低性能好对主库的压力小。缺点如果主库故障而从库尚未完全同步可能丢失部分已经“对外提交”的事务也就是“主库事务提交成功但从库没有”。4.2 半同步复制Semi-Synchronous Replication需要在主库开启插件或配置rpl_semi_sync_master_enabled 1 rpl_semi_sync_slave_enabled 1半同步大致逻辑主库在事务提交时必须等至少一个从库确认已收到该事务的 binlog才向客户端返回“提交成功”如果等不到从库确认会自动退回异步模式。优点降低了“主库提交成功但 binlog 未到从库”的风险在主从切换时数据更安全。缺点提交延迟会略有增加需要等待从库 ack如果网络抖动或从库压力大会影响主库提交时延。4.3 全同步复制强一致实际很少用要求所有从库都确认收到并应用该事务后才算提交成功对性能和可用性影响非常大任一从库慢/挂都会拖累整体很少在 MySQL 生产直接这样玩一般通过分布式协议如 Paxos/Raft框架上实现强一致。五、主从复制中的位置标识File/Pos 与 GTID5.1 传统方式binlog 文件名 偏移量File/PosMASTER_LOG_FILEbinlog 文件名MASTER_LOG_POS在该文件中的偏移量。问题切换主库或发生主从链路变更时需要手工管理 file/pos容易出错。5.2 GTIDGlobal Transaction ID全局事务 IDGTID 形式一般是server_uuid:transaction_id特点每个事务一个全球唯一的 ID从库可以根据 GTID 判断哪些事务已经执行哪些还没有主从切换时从节点不再用 file/pos 来定位复制位置而是根据 GTID 集合自动“对齐”。开启 GTID 的配置示例MySQL 5.7gtid_mode ON enforce_gtid_consistency ON log_slave_updates ON优点简化主从切换、容灾、级联复制真·按事务维度追踪复制状态。六、主从架构在业务中的常见用法6.1 读写分离典型架构主库负责写INSERT/UPDATE/DELETE从库负责读SELECT通过中间件或应用层路由写请求 → 主库读请求 → 多个从库做负载均衡。好处分担主库读压力提升整体吞吐。注意存在复制延迟写完立即读若读走从库可能读到旧数据对“强一致读”的请求可以强制走主库。6.2 高可用与故障切换常见模式一主多从 判断主库健康主库挂了时从库中选一个提升为新主库其他从库指向新主库继续复制。依赖心跳检测MHA、Orchestrator 等工具GTID 能显著简化切换过程。七、主从复制的延迟与一致性问题7.1 复制延迟的原因从库性能较差CPU、磁盘、IO导致 SQL 线程重放慢从库执行了复杂查询占用大量资源网络延迟或带宽限制主库写入量突增。7.2 应对策略提升从库硬件、参数调优避免在从库上执行超重查询或跑大报表使用多从库分担读压力对于需要强一致读的场景例如刚写完马上要读优先路由到主库或采用“读写都在主库” 从库主要做备份/降级用途。八、主从复制的配置步骤简要版以经典非 GTID 异步复制为例主库开启 binlog[mysqld] server-id 1 log-bin mysql-bin binlog_format ROW创建复制用户在主库CREATEUSERrepl%IDENTIFIEDBYrepl_pwd;GRANTREPLICATIONSLAVEON*.*TOrepl%;FLUSHPRIVILEGES;从库配置 server-id[mysqld] server-id 2 relay-log relay-bin在从库上指定主库信息并开启复制CHANGE MASTERTOMASTER_HOST主库IP,MASTER_USERrepl,MASTER_PASSWORDrepl_pwd,MASTER_LOG_FILEmysql-bin.000001,MASTER_LOG_POS4;STARTSLAVE;检查复制状态SHOWSLAVESTATUS\G;关注Slave_IO_Running: YesSlave_SQL_Running: Yes延迟相关字段。GTID 模式下配置稍有不同但原理类似。九、总结核心机制主库写binlog从库 I/O 线程从主库拉 binlog 写入relay log从库 SQL 线程从 relay log 中重放事件。复制模式默认是异步复制主库不等从库可配置半同步复制提高数据安全理论上的全同步复制通常不用。位置识别传统binlog 文件名 pos现代GTID按事务 ID 维度管理复制。典型用法读写分离主写从读高可用 故障切换主挂从顶上。问题与处理复制延迟不可避免只能尽量优化对强一致读写后读走主库监控SHOW SLAVE STATUS确保复制线程健康。理解了“主库写 binlog → 从库拉 binlog → 重放到自身”这条链路再加上对异步/半同步、GTID 的认识你基本就把 MySQL 主从同步的底层逻辑吃透了。