共计 2519 个字符，预计需要花费 7 分钟才能阅读完成。
作者：陈玉 涛思数据
WAL（Write Ahead Log），是 TDengine 的一个重要的功能模块，它能够实现数据的容错能力，保证数据的高可用。
听着简单，其实也很简略。对于关系型数据库的使用者来说，它大略就相当于 Oracle 中的 redolog，MySQL 中的 binlog 和 redolog，外面记录的是所有对于数据库的更新批改操作。
Write Ahead Log 翻译一下是“预写日志”，含意就是：在数据写入存储之前，先依照工夫程序在日志中做一下记录，这样就能够确保利用可能通过这个日志将数据库复原到任意的某个状态，即便数据库因为断电等意外事故宕机，也能防止数据的失落。
目前，TDengine 社区版尚不反对将数据回滚到指定工夫，如有须要，能够分割咱们的企业版团队来解决。
TDengine 中的 WAL 实现机制稍有非凡。它把 WAL 分为两局部，一种是 mnode 目录下的 WAL，一种是 vnode 目录下的 WAL。（为了不便本文的浏览，这里须要大家首先理解 TDengine 的基础架构：治理节点（mnode）和虚构数据节点（vnode）的概念：https://www.taosdata.com/docs…）
在 TDengine 的数据文件门路下（默认为 /var/lib/taos），就能够看到上述目录构造。
mnode 的 WAL 内容是长久化在硬盘上的，作为最重要的治理节点，它的 WAL 记录着所有对于数据库的 DDL 操作（比方创立删除操作：create dnode，create account，create mnode，create user，create table，drop dnode，drop table 等，或者批改操作：alter database，alter table，alter user 等）
而 vnode 目录下的 WAL 则次要负责记录着写入数据的操作，与此同时也记录着对表的 DDL 操作，在触发落盘后会清零。（这就是咱们在之前的文章——比方《存储老本仅为 OpenTSDB 的 1 /10，TDengine 的最大杀手锏居然是什么？》——中常常提及的局部，大家能够联合此文浏览，以加深了解。）
之后，写入 vnode 的时序数据会落盘到数据文件目录 /vnode/vnodeX/tsdb/data 上面。而对于表的 DDL 操作（也就是表的元数据）则会落盘到数据文件目录 /vnode/vnodeX/tsdb/meta 文件中，如下所示：
下面的第二张图是 vnode 的工作流程，从这里咱们能够更分明地看到时序数据和元数据是如何在写满三分之一的 buffer pool 后落地到磁盘的（一个 meta 文件，一个数据文件组：.data、.head、.last 文件）。
总结而言，mnode 通过 WAL 记录了集群、用户、数据库以及表的元数据等信息。而 vnode 通过 WAL 记录了数据和表的元数据，并且会在落盘触发后清零，而其记录的表的元数据会被写入到 meta 文件，时序数据会被写入到 data 目录。
在理解了 WAL 的作用后，接下来会衍生出细节的场景：
首先，WAL 是将数据库数据更新操作依照工夫程序追加更新的日志文件。数据库过程 taosd 在启动的时候会逐行读取 mnode 下的 WAL 文件并操作，直到最初一行，能力顺利启动服务。
这样的结构下，可能会导致这个问题呈现：
1. 当累计的 DDL 操作过多时，TDengine 的启动会变慢——那么要如何防止这种状况的产生呢？
首先，当子表数量相对大的时候，这个状况是没法防止的。然而这是一个很大的数量级，对于绝大多数用户都是达不到的。
更容易呈现的是这种状况：这个环境表数量并不是很多，然而却充斥了频繁的删库删表重建表等操作。比方，创立一个十万子表的超级表后删掉，而后再重建这个超级表。等到数据库启动加载 WAL 的时候，即使后面的 create table 和 drop table 都是有效的操作，然而还会被操作一遍，而且删表操作自身在加载的时候也会更慢一些，从而大幅拖慢 TDengine 的启动速度。
因而，为了防止这种状况，生产环境上肯定要谨慎。尤其是要尽量杜绝删库、删除超级表这些重大操作，如果是为了调试，重复重建的测试操作肯定要在测试环境进行，生产环境不可延用测试环境间接建库建表投入使用，除非该服务器的 TDengine 曾经卸载洁净。
2. 那如果是应用工夫太久，或者各种更改表构造的操作无可避免，导致 mnode 下的 WAL 过大，是不是无解了呢？
对于这种状况，在 2.1.5 版本之后，咱们提供了离线压缩 Mnode WAL 的计划来解决：
1）单机：
- systemctl stop taosd。
- taosd –compact-mnode-wal，如果执行失常的话，会在数据文件目录下生成 mnode_bak 目录，用于保留原数据。
- systemctl start taosd，这样 TDengine 就会应用压缩过的 wal 日志来启动数据库服务过程。
2）集群：
- show mnodes , 确认 mnode 节点所在的服务器，并且辨别 mnode 的 master 和 slave。
- systemctl stop taosd, 进行集群所有节点。
- 【可选】移出所有 mnode 节点上的 mnode_bak 目录。
- 在 mnode master 服务器上，以 root 权限执行 taosd –compact-mnode-wal。
- 将 mnode master 压缩后的 mnode/wal/* 文件复制到其余 slave 节点对应目录。
- 重启集群。
值得注意的是，taosd –compact-mnode-wal 命令第一次的运行工夫与压缩前集群启动工夫基本相同，要等到下次再启动的时候速度才会变快。
此外，在将来的 TDengine 3.0 版本中，这也会是咱们的重大的优化项。因为 WAL 也会变成分布式的存储，届时，即便是在亿级别表数量的状况下，TDengine 的启停速度也都不再会是问题。而且这项优化不过是 3.0 版本诸多个性的冰山一角。这项调整的背地代表着 TDengine 对于很多重要模块的优化重构，稳定性和性能都会大幅提高，多项重磅性能也会上线。
从 1.0 时代跟过去的老用户应该会对 2.0 的版本的提高深有感触，3.0 版本能够说更是后来居上。
让咱们一起期待。
想理解更多 TDengine 的具体细节，欢送大家在 GitHub 上查看相干源代码。
