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

公司网站域名到期了去哪里缴费百度竞价关键词出价技巧

wzjs 2025/8/3 15:19:48

公司网站域名到期了去哪里缴费,百度竞价关键词出价技巧,河南今天刚刚发生的新闻事件,网站集约整合建设交流在启用二进制日志（binlog）的情况下，MySQL通过两阶段提交（2PC）机制确保redo log与binlog的一致性，避免因崩溃导致数据不一致。 1. 两阶段提交（2PC）的核心目标原子性：确保…

在启用二进制日志（binlog）的情况下，MySQL通过两阶段提交（2PC）机制确保redo log与binlog的一致性，避免因崩溃导致数据不一致。

1. 两阶段提交（2PC）的核心目标

原子性：确保事务在redo log和binlog中要么全部提交，要么全部回滚。
一致性：主库与从库的数据一致（依赖binlog的可靠性）。
持久性：崩溃恢复后，已提交事务的数据不丢失。

2. 两阶段提交的详细流程

阶段1：Prepare（准备阶段）

InnoDB Prepare：
- 将事务的修改写入redo log，并标记为PREPARE状态。
- 调用fsync将redo log刷盘（由innodb_flush_log_at_trx_commit=1控制）。
- 此时事务尚未提交，但已保证redo log的持久性。

阶段2：Commit（提交阶段）

Write Binlog：
- 将事务的SQL语句按事件格式写入binlog。
- 调用fsync将binlog刷盘（由sync_binlog=1控制）。
InnoDB Commit：
- 将事务的COMMIT标记写入redo log，并再次刷盘。
- 释放行锁，清理undo log（若不再被其他事务依赖）。

3. 崩溃恢复机制

若在提交过程中发生崩溃，MySQL重启后按以下逻辑恢复：

扫描redo log：
- 查找所有处于PREPARE状态的事务（未提交的事务）。
检查binlog：
- 如果binlog中存在对应事务的完整记录（XID匹配），说明事务已成功写入binlog，提交该事务。
- 如果binlog中无对应事务记录，说明事务未完成binlog写入，回滚该事务。

4. 关键参数与配置

sync_binlog：
- =0：依赖操作系统刷盘，性能高但可能丢失事务。
- =1：每次提交刷盘，保证binlog不丢失（推荐主从复制场景）。
- =N：每N次提交刷盘，平衡性能与可靠性。
innodb_flush_log_at_trx_commit：
- =1：每次提交刷redo log，保证持久性（默认）。
- =0：每秒刷盘，可能丢失1秒数据。
- =2：写入OS缓存，不立即刷盘。
binlog_order_commits：
- 控制是否按binlog写入顺序提交事务（默认开启，保证主从一致性）。

5. 示例：事务提交与崩溃恢复场景

场景1：InnoDB Prepare后，写binlog前崩溃

现象：redo log有PREPARE记录，binlog无事务记录。
恢复：回滚事务（因binlog未写入，主从不一致风险）。

场景2：binlog写入后，InnoDB Commit前崩溃

现象：redo log有PREPARE记录，binlog有完整事务。
恢复：提交事务（重做COMMIT标记到redo log）。

6. 性能优化策略

组提交（Group Commit）：
- 合并多个事务的redo log和binlog刷盘操作，减少I/O次数。
- binlog组提交：通过binlog_group_commit_sync_delay参数延迟刷盘，批量处理。
调整刷盘参数：
- 非严格一致性场景可设置sync_binlog=0或innodb_flush_log_at_trx_commit=2。
并行复制：
- 从库使用多线程应用binlog事件，提升主从同步速度。