直接回答：redo log（InnoDB 引擎层，物理日志，保证崩溃不丢已提交数据）与 binlog（Server 层，逻辑日志，用于复制与点位恢复）是两套日志——若不协调，崩溃可能出现在“redo 已持久化而 binlog 未写”的中间态，从库就此与主库分叉。两阶段提交：redo 先写 prepare，再写 binlog，最后 redo 写 commit——任一时刻崩溃都能据此判定事务该提交还是回滚。
展开解析：崩溃恢复的对齐规则：启动时扫描 redo 里处于 prepare 的事务——若 binlog 中存在对应完整事务（按 XID 匹配）则补 commit（binlog 已发可能已同步从库，必须提交保持一致）；若 binlog 没有则回滚（从库没收到，主库也不能生效）。这组规则保证了“binlog 与 InnoDB 数据的最终一致”，是主从复制正确性的基石。参数与正确性的关联：sync_binlog=1（每次提交 fsync binlog）加 innodb_flush_log_at_trx_commit=1（每次提交 fsync redo）的“双 1”才是不丢数据配置——任一放宽，断电窗口内已确认的事务可能丢失，主从切换即丢数；组提交（group commit）把多个事务的 fsync 合并摊薄了双 1 的代价，是高并发的关键优化。扩展到认知体系：XA 事务（跨资源两阶段提交）复用了同一思想；分布式数据库的 Percolator/2PC+Raft 是它在更大尺度上的重演——“协调多个持久化位置的提交原子性”是存储系统的通用难题。排障关联：主从延迟排查时理解 binlog 写入与 dump 线程的流水线位置；点位恢复（binlog replay 到指定 GTID）依赖 binlog 完整性，sync_binlog 非 1 的实例点位恢复不可信。
追问方向：组提交如何把 prepare/commit 阶段流水线化？GTID 相对 file+position 复制解决了什么？
（约 490 字）