ZFS 相当于 lvdisplay snap_percent

Joe*_*Joe 6 mysql linux zfs lvm performance-tuning

我一直在使用 LVM 快照来备份 MySQL 数据库。

FLUSH TABLES WITH READ LOCK发布然后lvcreate --snapshot --size 4G等等。由于数据库在快照处于活动状态时处于活动状态,因此snap_percent(用于跟踪快照时文件系统原始状态的增量的快照存储量)开始增加。这snap_percent会受到日复一日的监控,并且在--size达到 80% 时会增加。

我的问题是ZFS 中是否有等效的统计信息或属性来确定快照消耗的空间占池中剩余空间的百分比?显然,我不需要将--size参数传递给,zfs snapshot但如何确定基于该快照的克隆是否接近池的限制。

希望这是有道理的,现在我读到它确实听起来像是一个令人费解的问题。

eww*_*ite 4

ZFS 快照空间反映在文件系统的消耗中。您可以通过监控下面最合适的字段来得出您所要求的内容。

最后,您将观察文件系统的“可用”空间...看看“已使用”+“可用”如何小于“大小”?:

root@deore:~# df -h /volumes/vol1/LA_Specialty
Filesystem             size   used  avail capacity  Mounted on
vol1/LA_Specialty      800G   391G   254G    61%    /volumes/vol1/LA_Specialty
Run Code Online (Sandbox Code Playgroud)

我已经过滤了下面的输出zfs get all pool/filesystem以显示相关属性。下面,我有一个 800GB 的文件系统(配额),其中使用了 545GB。引用了391GB ,这意味着这是真实数据的大小。154GB 用于快照。

root@deore:/volumes# zfs get all vol1/LA_Specialty
NAME               PROPERTY              VALUE                       SOURCE
vol1/LA_Specialty  type                  filesystem                  -
vol1/LA_Specialty  creation              Sat Sep 24 18:44 2011       -
vol1/LA_Specialty  used                  545G                        -
vol1/LA_Specialty  available             255G                        -
vol1/LA_Specialty  referenced            391G                        -
vol1/LA_Specialty  compressratio         2.96x                       -
vol1/LA_Specialty  quota                 800G                        local
vol1/LA_Specialty  reservation           none                        default
vol1/LA_Specialty  recordsize            16K                         local
vol1/LA_Specialty  mountpoint            /volumes/vol1/LA_Specialty  inherited from vol1
vol1/LA_Specialty  usedbysnapshots       154G                        -
vol1/LA_Specialty  usedbydataset         391G                        -
vol1/LA_Specialty  usedbychildren        0                           -
vol1/LA_Specialty  usedbyrefreservation  0                           -
Run Code Online (Sandbox Code Playgroud)

然后查看快照...可以看到快照的单个大小以及它们引用的总数据大小。

root@deore:/volumes# zfs list -t snapshot      
NAME                                               USED  AVAIL  REFER  MOUNTPOINT
vol1/LA_Specialty@snap-daily-1-2013-09-07-020003  57.6G      -   389G  -
vol1/LA_Specialty@snap-daily-1-2013-09-08-020003  1.95G      -   391G  -
vol1/LA_Specialty@snap-daily-1-2013-09-09-020008  3.42G      -   392G  -
vol1/LA_Specialty@snap-daily-1-2013-09-10-020003  3.05G      -   391G  -
vol1/LA_Specialty@snap-daily-1-2013-09-11-020003  2.81G      -   391G  -
vol1/LA_Specialty@snap-daily-1-2013-09-12-020004  2.65G      -   391G  -
vol1/LA_Specialty@snap-daily-1-2013-09-13-020003  2.70G      -   391G  -
vol1/LA_Specialty@snap-daily-1-2013-09-14-020003    25K      -   391G  -
vol1/LA_Specialty@snap-daily-1-latest               25K      -   391G  -
Run Code Online (Sandbox Code Playgroud)

以及du快照目录的列表......

root@deore:/volumes/vol1/LA_Specialty/.zfs/snapshot# du -skh *
 389G   snap-daily-1-2013-09-07-020003
 391G   snap-daily-1-2013-09-08-020003
 392G   snap-daily-1-2013-09-09-020008
 391G   snap-daily-1-2013-09-10-020003
 391G   snap-daily-1-2013-09-11-020003
 391G   snap-daily-1-2013-09-12-020004
 391G   snap-daily-1-2013-09-13-020003
 391G   snap-daily-1-2013-09-14-020003
 391G   snap-daily-1-latest
Run Code Online (Sandbox Code Playgroud)

  • @ewwhite 的答案是关于监视快照增量/磁盘使用情况的问题。ZFS 中的快照不是克隆。ZFS 中的快照的行为也与 LVM 中的快照不同,并且不应以相同的方式进行思考。至于监控,是的,您应该关注池的整体使用情况。如果您的原始数据集有很多增量,则在其上创建的快照将容纳更多的块,从而占用更多的空间。如果您开始发现池容量接近 80%,请开始销毁快照。如果可以的话,不要让 zpool 的使用率超过 80%。 (2认同)