分布式存储的读修复和周期性静默修复的原理

                                                             分布式存储的读修复和周期性静默修复的原理

    什么是静默错误？简单来说，就是磁盘写入数据返回成功，或者当时写入是正确的，放置一段时间后，由于硬件错误、固件 BUG 或者软件 BUG、供电问题、介质损坏等等各种原因，数据被改变了。正常来讲，分布式存储内部都会在读取数据时，或者后台周期性地对数据和数据校验码进行校验，以保证数据的有效性，当发现静默错误时，分布式存储会将有效的副本复制过来，重新覆盖写入，保证数据的有效性。分布式存储的读修复和周期性静默修复的原理，如下图所示：

 

所以，总体来说分布式存储都能够保证数据在静默错误下的数据安全。

 

下面给出OceanBase的处理方法：

OceanBase的应对和处理

OceanBase作为分布式数据库，同样也使用了三副本的容灾模式，由于应用于金融场景，事实上对于数据安全性的要求会更加苛刻。那么对于静默错误，OceanBase是如何从容应对和处理的呢？

和传统数据库不同，OceanBase的存储引擎是基于LSM-Tree架构的，数据被分为两部分：动态数据（MemTable）和静态数据（SSTable）。所有的数据修改（插入、更新、删除）都会先写入MemTable，并通过Paxos协议将Redo Log同步到三副本；MemTable中的数据会在合适的时候通过合并的方式转入SSTable，SSTable是只读的。在整个过程中，数据会有多次落盘，写Redo Log时每个副本都需要将Redo Log落盘；在合并时，每个副本都需要将合并后的SSTable落盘。

Redo Log是如何应对静默错误的？

在每条Redo Log的头部，我们都会记录这条RedoLog的校验和，在做网络传输和日志回放时，都会强制对每条日志的校验和进行校验。这样我们保证了三副本同步到的内存数据至少是不会错的，如果一条日志中的数据出现了静默错误，那么这条日志一定不会被同步到其他副本。

比较麻烦的是进程重启，在进程重启时，如果之前落盘的Redo Log出现了静默错误，校验和仍然可以帮助我们将错误识别出来，但是整个进程会重启失败。考虑到三台服务器同时出现静默错误的概率不是特别大，另外两个副本的Redo Log仍然可以帮助我们把数据补齐。

SSTable是如何应对静默错误的？

在数据结构上，一个SSTable是由很多宏块组成的，宏块是定长的，大小是2M，类似于MySQL或者Oracle的Extent，宏块是最小的写IO单位；一个宏块又由很多微块组成，微块是变长的，默认大小大约是16K，类似于MySQL或者Oracle的Page，微块是最小的读IO单位。

首先对于每个微块，我们都会在微块头部记录整个微块的校验和，在每次数据读取时，我们都会对微块根据校验和进行校验，这样我们就保证用户读到的数据一定是正确的。其次对于宏块，我们会在宏块头记录整个宏块的校验和，用于数据的复制迁移。当服务器出现故障或者需要做负载均衡时，系统会自动做数据副本的复制迁移，在目的端写入数据之前，会对每个宏块的校验和进行校验，保证写入的数据是正确的，这样我们就保证静默错误不会扩散。

出了静默错误后能够处理当然还是不够的，我们还需要能够将静默错误尽早识别出来，因此我们在后台会有个定期巡检的任务，定期读取磁盘上的宏块来做校验，一旦发现有数据错误就会进行预警。发生静默错误后，我们可以把错误的数据副本删除掉，再通过复制迁移的方式从其他服务器将副本拷贝过来补齐。