一个系统如何保证 log 的高可用跟鲁棒性？

[yhvictor]

之前一阵在研究一些系统设计题。
对于数据库，突然断电的解决办法大多都是读 raw log 重做。也就是 log 是整个系统安全的基石。
但似乎从来没见到讨论如何保证 写 log 可用 跟 log 不丢失（磁盘损坏 etc ）。
我尝试找过很多材料，基本都没有讨论，遂很迷茫，求大佬解释下。

或者换个角度，这个 log 要不要放在三个不同机房的机器上（是的话如何保证写高可用，不是的话怎么容灾）？每台机器是不是要组个 raid （什么样的 raid 比较推荐）？某台机器突然坏了（断电，磁盘出错）怎么办？
再如果 log 是跟数据库的机器在一台电脑上，怎么保证分布式下的数据库的 log 们都一样呢？

[liuhan907]

分布式一致性资料烂大街，你是怎么找的能找不到的。。。

[billlee]

参考 zookeeper/etcd 的 paxos/raft 保证共识，但这种性能就很有限了。MySQL 那种异步复制，只能保证事务原子性，持久性是不能保证的，切换的时候可能会丢已提交的事务。

[yhvictor]

@liuhan907 那还是麻烦给个链接？

[Mohanson]

Write ahead log (WAL). 这是数据库的标配了, (几乎)任何数据库实现都有介绍的.

[zmal]

这个问题没啥讨论的，你担忧的问题早就被类似 HDFS 这种分布式文件存储系统给解决了。

[sha851092391]

其实需要把问题分单机和分布式来看，单机的 wal （ mysql redolog ）的刷盘方式不同，也会影响到事务是否会丢失。同步刷盘的方式也只能解决软件层面的故障，硬盘损坏这类的硬件故障就无能为力。而 RAID 也只能做到硬件冗余来保证高可用，万一火灾地震呢。

这时候可以考虑多机房通过主从复制来保证 log 的可用性。

首先单主复制，也就是同一时刻只有一个主节点进行写操作，那么这里面如果保证主从之间 log 的一致呢，不考虑延迟的话一个事务的提交就必须等所有从节点 log 复制完才提交（虽然有 semi-sync 、quorum 等手段，但本质是解决写的性能）。

那还有多主复制的问题，这里面的写冲突就更复杂了，例如 LWW 、CRDT 等，而 paxos 族的 raft 、zab 解决的是选主共识问题，还有 gossip 是解决复制的问题，这个话题有点大，OP 可以自行了解下看看。