Etcd数据恢复机制

最新推荐文章于 2024-06-29 14:47:59 发布

萌兰三太子

最新推荐文章于 2024-06-29 14:47:59 发布

阅读量1.5k

点赞数

文章标签： etcd 数据库

本文链接：https://blog.csdn.net/m0_47495420/article/details/131266696

版权

本文介绍了Etcd的WAL（预写日志）机制，解释了为何需要WAL以提高写入性能和确保灾难恢复。在数据恢复方面，文章详细阐述了从快照和WAL进行恢复的过程，包括检查数据目录、恢复最新快照、以及根据快照数据恢复db内容。

摘要由CSDN通过智能技术生成

WAL简介

使用过存储软件的都知道，为了应对写入性能和灾难恢复，各个存储软件都有相关的机制来保障，比如：

mysql的redo log 和undo log
zookeeper的事务日志
etcd的wal日志

等等，那为啥都需要额外写入这样一种日志呢？

因为离散写的场景下会造成过多的随机写，更合理的方式是顺序 io 写到一个日志文件里，然后等待时机把数据进行合并后变更数据文件，这个日志就是 wal ( write ahead log) 预写日志.
另外还有一点，直接修改数据文件的话，如果写到一半发生了 crash，那么该页就损坏了.
如果 DB 关了或者挂了，但还有部分数据在内存和 wal 日志中，还未变更到 db 文件中. 那没关系，只需在启动后从 wal 日志中重放日志做还原即可.

源码地址：https://github.com/etcd-io/etcd

数据恢复

入口函数：mian -> StartEtcd -> etcdserver.NewServer -> bootstrap

查看bootstrap方法：

func bootstrap(cfg config.ServerConfig) (b *bootstrappedServer, err error) {
   if cfg.MaxRequestBytes > recommendedMaxRequestBytes {
      cfg.Logger.Warn(
         "exceeded recommended request limit",
         zap.Uint("max-request-bytes", cfg.MaxRequestBytes),
         zap.String("max-request-size", humanize.Bytes(uint64(cfg.MaxRequestBytes))),
         zap.Int("recommended-request-bytes", recommendedMaxRequestBytes),
         zap.String("recommended-request-size", recommendedMaxRequestBytesString),
      )
   }

   if terr := fileutil.TouchDirAll(cfg.Logger, cfg.DataDir); terr != nil {
      return nil, fmt.Errorf("cannot access data directory: %v", terr)
   }

   if terr := fileutil.TouchDirAll(cfg.Logger, cfg.MemberDir()); terr != nil {
      return nil, fmt