我的挑战是在给定的 ZFS 池上存储尽可能多的 mysql 转储。
游泳池本身有已启用重复数据删除和压缩. 为了存储转储的多个版本，使用快照（每 15 分钟、每小时、每天、每周和每月）。
MySQL 服务器上各种数据库中的大多数表都在增长，并且不会经常更改。我的想法是针对每个表而不是每个数据库进行转储，以便让 zfs 有机会在块级别进行重复数据删除。
备份脚本使用 mysqldump 的输出并将其传输到文件（使用mysqldmup -u$user -p$pass $db $table > $outputfile.sql
- ZFS 重复数据删除功能能否以良好的速率对来自 stdout 的流进行重复数据删除？
- 是否应手动配置目标数据的块大小？（如果是 - 那么大小是多少？）
- 是否应该应用某种输出缓冲（除行缓冲之外）？
- 来自重定向的写入是同步的还是异步的？
编辑以确定：如果内容（几乎[例如只有最后一行不同]）相同，那么需要做什么才能使逐行写入的文件像复制的文件一样进行重复数据删除？
答案1
重复数据删除始终处于块级别（快照和压缩也是如此），上面的数据结构并不重要。因此，您可以拥有单个文件而不是数千个小文件，而这对于重复数据删除来说不会产生任何影响。
另一方面，块大小确实会产生影响，原因如下：
- 块越大，浪费就越多，因为非常小的文件的某些字节可以保留大块的大小（块大小是最小单位，不能进一步划分）
- 块越小，平均性能就越慢，因为要读取同一个文件，现在必须读取更多的块（每次读取都会有轻微的开销，并且每个块很可能位于整个磁盘上完全不同的位置）
- 重复数据删除针对块进行，因此较小的块可能会获得更好的结果
- 另一方面，这会增加内存中必须引用的块数量，并可能降低性能。有关权衡和示例计算，请参阅这篇博文- 关键在于你需要大量的内存，而且这取决于你的数据
因此，尺寸很重要，但没那么容易。看来您已经有足够的数据了，所以我只想测试一下：创建两个文件系统（如果可能的话，之后再创建，而不是同时创建，以尽量减少对彼此的影响），一个文件系统的块大小非常小（4K），另一个文件系统的块大小非常大（128K），然后复制数据并比较结果。您还可以zdb -b poolname通过比较两个块数然后计算节省量来模拟重复数据删除性能。如果这两个结果都不适合您，请尝试不同的大小，例如 16K、32K 或 64K。