registry数据清理的巨坑

前言：

        最好不要做registry的数据清理，最好不要做registry的数据清理，最好不要做registry的数据清理！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

踩坑记录：

        registry后端数据大小1.2P，清理被标记delete的数据

详情：

        由于后端registry多年未做镜像的清理，倒是底层镜像的数据巨大，达到了1.2P的数据量，每月的存储费用巨高，所以想要通过镜像标记删除的方式，来清理镜像，释放磁盘空间

操作：

        操作之前，查询了网上的诸多文章，发现都千遍一律，没有什么问题，也没有任何的坑的记录，所以开始做数据的标记及清理

操作步骤：

        1）curl 127.0.0.1:5000/v2/_catalog  （查镜像）

        2）curl 127.0.0.1:5000/v2/nginx-xctest/tags/list （查标签）

        3）curl -i -sS -H 'Accept: application/vnd.docker.distribution.manifest.v2+json' 127.0.0.1:5000/v2/nginx-xctest/manifests/v4 （超sha256的值）

        4）curl -X DELETE 127.0.0.1:5000/v2/nginx-xctest/manifests/sha256:0ad4dc606173faf65f9e64fd05f74629d34d2957fdbb06996526e3006839a442 （数据标记delete）

        5）docker exec registry bin/registry garbage-collect  /etc/docker/registry/config.yml（docker私有镜像仓库垃圾回收）（这是巨坑的一步）

        6）重启registry 

registry镜像仓库垃圾回收的过程分析如下：

        1）查询所有镜像仓库的镜像层的link （我们1.2P的数据量，这一过程经过了大概10天的时间）

        2）对统计标记的delete的镜像层做数据清理

故障分析：
        registry在手动垃圾回收期间，会首先筛选并标记所有的link层，然后统一进行删除，当处于标记期间，push镜像，由于push的操作是分层push，当push完成后才会形成link记录，所以，恰巧处以标记期间的镜像，就会由于没有link信息被误认为是删除标记的镜像，从而被默认标记为删除状态，当进行到垃圾回收的第二个步骤（数据清理之后），就会对线上的部分误标记的镜像层做清理，从而导致镜像缺失或manifest不存在

数据清理的最好的方法：

        1）对于小于40个T的数据，可以在夜间通过将registry的readonly=true打开，重启registry生效后，然后做数据清理 （8个小时基本可以跑完）

        2）对于大于40个T的数据，放弃第一种方式，重新搭建registry仓库，将用的的镜像push到新的镜像仓库，并行一段时间，切换镜像仓库