数据库宕机恢复、事务回滚和主从复制分别依赖哪些日志？项目里怎么配置？
我的判断
redo 保证已提交页修改能崩溃恢复，undo 支持回滚和 MVCC，binlog 用于复制与时间点恢复；生产配置要围绕可接受的数据损失来定。
数据库宕机后，内存里还没刷回数据页的已提交修改靠 redo 重放；未提交事务则利用 undo 回滚。普通快照读也通过 undo 版本链看到历史版本。binlog 位于 Server 层，记录逻辑变更，副本和备份系统据此复制或做 PITR。
提交时 InnoDB 通过 redo 与 binlog 的两阶段提交保持两者一致，避免主库恢复后有数据、binlog 却缺事件，或者反过来。
核心订单库通常会选择：
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
binlog_format = ROW
这意味着每次提交更强调持久性，也要接受 fsync 成本。若业务允许极小窗口丢失才会评估放宽，而且要用故障演练量化，不会为了跑分快直接改成 0。
binlog 不是备份替代品：仍需全量备份、binlog 保留和定期恢复演练，确认真的能恢复到指定时间。