关于数据库快照, 有没有必要停机保证数据一致性?

[kyonn]

NAS 用的 btrfs 快照功能, 需要定期备份 docker 挂载的 volume, 其中一部分 docker 用了数据库, 快照这部分数据时是否需要先停止服务(docker)?

根据 COW 的原理, 快照是能保证快照瞬间数据一致性的, 但是对于数据库来说, 它的数据一致性没办法保证. 但数据库本身有事务机制, 是否可以保证从任意一个快照状态下恢复? 顶多丢失最近操作的数据?

网上看到各种做法都有, 有直接快照的, 有用命令冻结数据库再快照的, 有用数据库原生命令导出数据库文件再快照的.

以上都是猜测, 有没有对数据库比较熟悉的人提供下建议.

[loading]

看你强迫症在哪一边了，你 NAS 的数据库就每秒都在写导致数据库都没空给你写到硬盘？还是数据库服务一下都不能停？

定时到晚上备份，停几个小时都没事吧。

生产服务器就不用管这些了。

[kyonn]

@loading 只是请教下各种方法下的优劣势, 实际使用可以停机的. 比较关心 快照正在使用(正在向硬盘写数据)的数据库, 然后再用这份快照恢复会怎么样. 个人样本比较少, 不太容易测试得到可靠的结论.

[seers]

你多虑了，还原备份时候会用日志前滚到最新状态的，所以备份时候停不停都无所谓

[mikewang]

其实不仅是数据库，其他正在进行中的程序也有类似问题：因为 Btrfs / ZFS 等文件系统快照一般只对写到磁盘的文件做快照，而不去管内存的数据。
恢复到某个快照，相当于快照时间强制断电时的状态（丢失了内存数据）。对于数据库来说，就当作异常断电恢复时的场景处理就行了。

[mikewang]

这里补充一篇文章，挺有意思的：
《崩溃一致性：你的程序真的正确保存了数据吗？》 https://zhuanlan.zhihu.com/p/2518892

[kyonn]

@mikewang 是的, 我认为核心问题其实在 ext4 的 data=journal, writeback 设计里就已经涉及了, 无非是 btrfs 的文件系统具体实现机制不同. 拜读了下提到的文章, 还真挺有意思, 原来也不是所有数据库都能处理崩溃一致性.


*其实我想问的问题本质上应该就是数据库软件能否正确处理崩溃一致性问题. *系统中其他的程序大部分只是写个日志, 损坏关系也不大. 提这个问题的原因是我把数据库相关的目录都关闭了 COW 属性, 如果不考虑碎片直接基于 btrfs 做快照, 会比 ext4 data=order 挂载安全, 因为 metadata 和 data 都有"日志", 虽然仍然保证不了崩溃瞬间业务的一致性.
当然, 还一个问题就是提到的内存数据没有刷回硬盘, 甚至硬盘缓存没有刷回存储介质.

[kyonn]

@seers 是的, 其实我想问的就是这个回滚靠不靠谱.

[julyclyde]

innodb 的话，对这事倒是要求不太高
重新打开这个“半死”文件的时候，会执行 recovery 吧