最近这两天，处理了一个线上的TiDB问题，在处理问题的过程中，确实感受到了TiDB这个分布式数据库设计的巧妙的地方，也发现了自己在理解上的很多不足，具体的过程有时间再分享，这里不再描述，今天只讨论一个小的知识点。
TiDB作为一款分布式的数据库，面向的是大容量的数据场景，它的集群之间通过Region来保存数据，一份数据需要保存多个副本，所以比较消耗磁盘容量。
在线上实际运维的过程中，经常遇到磁盘占用80%以上的场景，通常情况下，我们需要通过动态的扩缩容来解决磁盘占用率高的问题。如果数据的容量增长比较快，而暂时没有合适的服务器来进行横向扩容，此时这个磁盘容量问题就比较棘手了。
TiDB 4.0 这个版本中引入了参数storage.reserve-space参数，默认是2GB，到TiDB 5.0 ，默认值已经变成了5G，这个参数的意思是：预留空间。由于它的存在，TiKV 启动时会用临时文件预占额外空间，这个参数值代表这个临时文件大小。临时文件名为 space_placeholder_file，位于 storage.data-dir 目录下。TiKV 磁盘空间耗尽无法正常启动需要紧急干预时，可以删除该文件，并且将 reserve-space 设置为 0MB。
可以通过连接tidb来查看当前的配置内容
show config where type='tikv' and name like 'storage.reserve%'; +------+--------------------+-----------------------+-------+ | Type | Instance | Name | Value | +------+--------------------+-----------------------+-------+ | tikv | 10.xx.xx.xx2:20151 | storage.reserve-space | 5GiB | | tikv | 10.xx.xx.xx2:20160 | storage.reserve-space | 5GiB | | tikv | 10.xx.xx.xx5:20153 | storage.reserve-space | 5GiB |
看到这里，其实可以引申一下，在那些没有部署TiKV的服务器上，其实也可以设置这么一个临时文件，一旦发现磁盘快满的时候，删除这些文件，从而释放出来一定的空间，临时解决问题。
这种未雨绸缪式的方案，可能你觉得你也能想到，但是在一个分布式数据库设计的过程中，能够考虑到这种细枝末节的运维场景，确实很难得，就这一点，让我觉得这个数据库确实很赞。后续还需要更进一步的探究，分享更多的知识点给大家。
