HEALTH_WARN Reduced data availability: 23 pgs inactive; 23 pgs not deep-scrubbed

admin

一般手动修复损坏的PG即可，使用ceph pg repair {pgid}

PG状态为inconsistent时，说明PG中存在对象不一致的情况。有可能时某个OSD磁盘损坏，或者磁盘上的数据发生静默错误。
; b/ Q2 n2 y, c: V7 C
. c6 A* g* L+ r( M0 ~0 q3 S下面手动构造一个PG数据损坏的例子，并修复它。

# 1.关闭OSD服务
$ systemctl stop ceph-osd@{id}

# 2.使用ceph-objectstore-tool 挂载 /var/lib/ceph/osd/ceph-0 到 /mnt/ceph-osd@0
0 l9 S5 k+ r3 N: Z5 v( E0 c* F[root@node-1 ceph-objectstore-tool-test]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0/ --op fuse --mountpoint /mnt/ceph-osd@0/
6 K! i8 B/ ?8 L" Imounting fuse at /mnt/ceph-osd@0/ ...

# 3.删除 /mnt/ceph-osd/@0/10.0_head/all文件夹中某个目录文件(即PG中的对象)，即破坏了10.0pg的某个对象
! l3 c; ]2 D* p/ T2 p[root@node-1 all]# rm -rf \#10\:01ec679f\:\:\:10000011eba.00000000\:head#/
rm: 无法删除"#10:01ec679f:::10000011eba.00000000:head#/bitwise_hash": 不允许的操作
rm: 无法删除"#10:01ec679f:::10000011eba.00000000:head#/omap": 不允许的操作
4 V3 C. M1 ^! f% ~* R! F0 arm: 无法删除"#10:01ec679f:::10000011eba.00000000:head#/attr": 不允许的操作

4 @# q! r7 U5 `0 Q& W8 t8 J  e# 4.卸载/mnt/ceph-osd@0，重启 OSD服务，等待集群恢复正常
! F9 P! o/ a! l" q& r, b9 C
# 5.手动对10.0 PG做scrub，命令：ceph pg scrub 10.0，等待后台scrub完成
$ A3 u' M: w1 c[root@node-1 ~]# ceph pg scrub 10.0
6 C) P" ?4 h* k- a7 E6 _" O. Binstructing pg 10.0 on osd.2 to scrub
8 s$ v" E9 a6 v# ], J
) ^" X+ @- M: Z1 w2 N$ a' S& `- A) O# 6.发现集群报错，PG id是10.0，状态为active+clean+inconsistent
  c& n! v4 q) {: k[root@node-1 ~]# ceph health detail
8 h& y! Y# C+ M6 x& uHEALTH_ERR 2 scrub errors; Possible data damage: 1 pg inconsistent
$ D9 {" _- k6 ~OSD_SCRUB_ERRORS 2 scrub errors
PG_DAMAGED Possible data damage: 1 pg inconsistent
    pg 10.0 is active+clean+inconsistent, acting [2,1,0]
! J- B! E  M' e' q4 D  d" T) ?
, {6 S" {; s8 J$ L. p# 7.执行修复操作，PG状态：active+clean+scrubbing+deep+inconsistent+repair
7 E  S/ p4 V- K  k9 P+ X$ F* t[root@node-1 ~]# ceph pg repair 10.0
instructing pg 10.0 on osd.2 to repair
! @( L0 t" C/ ~9 H[root@node-1 ~]# ceph -s
  cluster:
    id:     60e065f1-d992-4d1a-8f4e-f74419674f7e
  F# b& G2 O& Z: Z; ?6 r, M    health: HEALTH_ERR
            2 scrub errors
* o5 @+ F6 B3 S: w            Possible data damage: 1 pg inconsistent
  。。。
  data:
4 d, {' H) ?% |5 \& z% c1 M) z    pools:   9 pools, 464 pgs
3 W$ }, C/ K) Y( Y    objects: 53.99k objects, 802 MiB
    usage:   16 GiB used, 24 GiB / 40 GiB avail
    pgs:     463 active+clean
             1   active+clean+scrubbing+deep+inconsistent+repair
9 l1 {* a/ N) c- l
- n: a( n( T% u1 m' Q: Z% r) s# 8.等待集群恢复健康
/ A3 {" T: \9 c, B8 H, b. j[root@node-1 ~]# ceph health detail
, I  j  D9 U, D3 J- V6 [9 MHEALTH_OK
  o# X/ I7 M" b# k" s- V8 m. }

如果ceph pg repair {pgid}命令无法修复PG，可以使用ceph-objectstore-tool导入整个PG的方式。
9 D, B3 i& Q  L8 C
, I# h; d( i- N$ E9 |

1 A) t/ U; i- Aosd_recovery_max_single_start  #越大，OSD恢复速度越快，集群对外服务受到影响越大，默认为1
osd_recovery_max_active        #越大，OSD恢复速度越快，集群对外服务受到影响越大，默认为3
: I! h( A8 ?% J$ Uosd_recovery_op_priority       #越大，OSD恢复速度越快，集群对外服务受到影响越大，默认为3
( i/ ~* E$ w* T7 [5 R3 x% U: @osd_max_backfills              #越大，OSD恢复速度越快，集群对外服务受到影响越大，默认为1
osd_recovery_sleep             #越小，OSD恢复速度越快，集群对外服务受到影响越大，默认为0秒
4 |; v) g; t. {" g. T6 S" X. f1 M
[root@node-2 ~]# ceph config set osd osd_recovery_max_single_start 32
[root@node-2 ~]# ceph config set osd osd_max_backfills 32
[root@node-2 ~]# ceph config set osd osd_recovery_max_active 32
设置后，OSD恢复速度大大加快，注意这三个配置要同步增加，否则只增加其中一个，会由于其他短板而无法使得恢复速度加快

# ceph -s 检查恢复速度，设置上述参数前，恢复速度只有6 objects/s。

+ Q/ N1 Y$ V* d. `. ~- h
: g' {+ H% ?; k. l
一般来说，集群三副本的情况下不太可能出现PG丢失的情况，如果一旦出现了，那也就意味着这丢失的数据无法找回。
5 W( e* m2 S% w* }2 Z
# 1.查找丢失的PG
+ C- C/ {9 O% w* R: }- k% a2 u% hroot@storage01-ib:~#  ceph pg dump_stuck unclean | grep unknown
5 z0 Z5 R) ^; w# Q" j' V. K20.37                         unknown     []         -1     []             -1
5 I4 y  C/ a0 b- u/ _: W) I2 h; e6 p9 E20.29                         unknown     []         -1     []             -1
20.16                         unknown     []         -1     []             -1

# 2.创建PG
root@storage01-ib:~# ceph osd force-create-pg 20.37 --yes-i-really-mean-it
( m. e; A, b7 R3 \. Y$ o9 kpg 20.37 now creating, ok
: v; }# `4 q, t; s  M- f
注意：不要使用单副本的集群。

) R! H- V$ U; V5 A) d' a$ f  K! J7 _
- F+ h3 K2 K8 G, g# H4 S& g出现“1 pools have many more objects per pg than average”警告时，说明集群中某个pool的PG数量配置过少，其每个PG承载的对象高于集群平均PG承载对象10倍以上，最简单的解决方法就是增加pool的pg数即可。

6 q. F( ]& a9 D
# 告警：1 pools have many more objects per pg than average
% \1 [1 y: E; Q) E+ p[root@lab8106 ~]# ceph -s
cluster fa7ec1a1-662a-4ba3-b478-7cb570482b62
health HEALTH_WARN
1 pools have many more objects per pg than average


# 增加该pool的pg数，N版以后，只需要调整pg_num即可，pgp_num会自动调整。
. v) j8 [. ?  H- X4 c# ?$ lceph osd pool set  cephfs_metadata pg_num 64


6 D8 Z2 w2 t' r1 f6 u

admin

情况
5 ~* p: k; z3 \ceph 在一次掉盘恢复后, 有 pg 出现 state unknown 的状况. 运行 ceph health detail, 显示:

9 x! \5 v' L( w8 p/ f+ m3 k' X$ u[root@storage02-ib ~]# ceph health detail
9 l0 Q2 i3 J! l, S; h$ T+ WHEALTH_WARN 211801/3035471 objects misplaced (6.978%); Reduced data availability: 4 pgs inactive
OBJECT_MISPLACED 211801/3035471 objects misplaced (6.978%)
0 `/ b8 S, p) ~" LPG_AVAILABILITY Reduced data availability: 4 pgs inactive
, z/ I# ]- }4 i& Q- I9 e    pg 20.16 is stuck inactive for 12365.100778, current state unknown, last acting []
    pg 20.29 is stuck inactive for 12365.100778, current state unknown, last acting []
    pg 20.2d is stuck inactive for 12365.100778, current state unknown, last acting []
/ l& T  C" q0 M% `" y    pg 20.37 is stuck inactive for 12365.100778, current state unknown, last acting []
显示这4个 pg 卡住了.

. E1 J' @, a. q% d运行 pg query, 查看该 pg 的具体信息, 显示:
# b% V2 i! v& R) [6 H9 x
9 W2 Z: E, @5 D# g8 a% T+ Croot@storage01-ib:~# ceph pg 20.16 query
Error ENOENT: i don't have pgid 20.16
无法找到该 pg id.
0 a4 j, t! N7 t3 q% d/ ?
  U% S9 Q' H" s, U运行 pg dump_stuck unclean, 显示:
$ v( z. ^6 G6 T5 R" M
1 v8 P; V+ z+ |. E* lroot@storage01-ib:~#  ceph pg dump_stuck unclean
8 u8 v6 K3 Z9 [! ?( V* w. Lok
8 P8 ]! N* t: e, @! B2 tPG_STAT STATE                         UP     UP_PRIMARY ACTING ACTING_PRIMARY
8 ^( [& e3 L/ Q# j9 y+ X" W21.f9   active+remapped+backfill_wait  [7,4]          7  [4,9]              4
21.f7     active+remapped+backfilling  [4,8]          4  [4,2]              4
21.d9   active+remapped+backfill_wait [10,0]         10  [0,9]              0
21.c9   active+remapped+backfill_wait  [8,4]          8  [4,7]              4
( R# S( }8 y. p7 i5 W. n7 V21.b8     active+remapped+backfilling  [2,7]          2  [6,7]              6
6 U% G; i' a* g/ i  I7 D21.af   active+remapped+backfill_wait  [0,5]          0  [0,8]              0
% |4 N0 o# q5 x; y& Q21.a3   active+remapped+backfill_wait  [4,8]          4  [4,9]              4
21.9c   active+remapped+backfill_wait [9,10]          9 [5,10]              5
21.cb   active+remapped+backfill_wait  [5,3]          5  [2,3]              2
21.95     active+remapped+backfilling [10,4]         10 [10,7]             10
3 L! l' p# v. z2 ~3 C21.f3   active+remapped+backfill_wait [2,10]          2  [2,5]              2
/ V4 @/ C# @+ t  B- c5 ], \21.3f   active+remapped+backfill_wait  [4,2]          4  [2,6]              2
21.3a   active+remapped+backfill_wait  [3,6]          3  [6,9]              6
20.37                         unknown     []         -1     []             -1
21.b4   active+remapped+backfill_wait  [2,7]          2 [2,10]              2
21.56   active+remapped+backfill_wait  [8,7]          8  [8,5]              8
# ]- A' N# [  k- T# k# V21.68     active+remapped+backfilling  [7,2]          7  [0,2]              0
3 X. b3 V) q. h; f; v, k9 B1 c9 T21.2e   active+remapped+backfill_wait [10,6]         10  [5,6]              5
21.7f   active+remapped+backfill_wait  [9,8]          9  [9,7]              9
21.e9   active+remapped+backfill_wait  [4,9]          4 [9,10]              9
4 q* e2 O" I8 C8 j/ s6 P' ~21.55   active+remapped+backfill_wait  [9,4]          9  [9,6]              9
21.5e   active+remapped+backfill_wait  [0,6]          0  [0,9]              0
21.87   active+remapped+backfill_wait  [7,8]          7  [7,4]              7
4 }; h$ y6 y- N: m21.76   active+remapped+backfill_wait [10,8]         10  [4,8]              4
+ U4 U0 ~( F' V2 z9 L' H21.a1   active+remapped+backfill_wait  [2,5]          2  [5,6]              5
21.43   active+remapped+backfill_wait  [3,0]          3  [0,5]              0
21.82   active+remapped+backfill_wait  [7,3]          7  [7,9]              7
20.2d                         unknown     []         -1     []             -1
21.2d   active+remapped+backfill_wait  [4,8]          4  [4,2]              4
- n2 ]2 R+ Z6 R& C$ T. m9 J# k4 \. u. }21.1c   active+remapped+backfill_wait  [8,0]          8  [0,6]              0
21.22   active+remapped+backfill_wait  [4,9]          4  [4,7]              4
0 \" P/ c( ]  Y1 w  C! }21.79   active+remapped+backfill_wait  [4,6]          4  [4,0]              4
: a1 ^0 b/ C0 M% I% m3 M/ ~- \% o0 k21.28   active+remapped+backfill_wait  [7,4]          7  [0,4]              0
20.29                         unknown     []         -1     []             -1
20.16                         unknown     []         -1     []             -1
! ^6 ?& @( s+ G, [/ a7 a) S* b) r29.4    active+remapped+backfill_wait  [6,1]          6  [6,4]              6
21.23   active+remapped+backfill_wait [10,0]         10  [0,3]              0
21.63   active+remapped+backfill_wait  [9,0]          9  [0,2]              0
2 L" @0 s* L  i3 e! c, h- b29.5    active+remapped+backfill_wait  [1,9]          1  [0,9]              0
21.6c   active+remapped+backfill_wait  [6,5]          6  [6,8]              6
- ~/ ?& a9 i0 @$ i21.e    active+remapped+backfill_wait  [0,7]          0  [4,7]              4
分析
, ~3 j0 P7 {! A看来是这几个 pgid 彻底找不到了. 我的 osd pool 有三个, 分别叫 l1 (1副本), l2 (2副本), l3 (3副本).

估计可能是之前写入 1 副本的数据由于硬盘挂掉导致的数据丢失.

既然是1副本, 也不要求数据可靠性了. 并且本身存储的也是一些下载到一半的数据, 也没什么关系.

修正
通过阅读 CEPH 官方 PG troubleshooting 文档 , 发现了解决方案:
! n& W6 g( j7 e
' q5 z) v- {; A, x) oPOOL SIZE = 1
; B" p  z% _7 g3 c! ^
; A5 A$ Q+ X% U* T1 ^If you have the osd pool default size set to 1, you will only have one copy of the object. OSDs rely on other OSDs to tell them which objects they should have. If a first OSD has a copy of an object and there is no second copy, then no second OSD can tell the first OSD that it should have that copy. For each placement group mapped to the first OSD (see ceph pg dump), you can force the first OSD to notice the placement groups it needs by running:

2 c! g/ q% F2 L6 sceph osd force-create-pg <pgid>

4 W$ {- h* I* W8 }  x% K! A即, 多 osd 副本可以互相通知 pg 信息, 但是单副本就会丢, 为了恢复这个pg, 我们可以强行创建它.

root@storage01-ib:~# ceph osd force-create-pg 20.37
Error EPERM: This command will recreate a lost (as in data lost) PG with data in it, such that the cluster will give up ever trying to recover the lost data.  Do this only if you are certain that all copies of the PG are in fact lost and you are willing to accept that the data is permanently destroyed.  Pass --yes-i-really-mean-it to proceed.
* G0 g* `0 `3 S运行创建命令, 提示, 运行会永久的丢失该 pg 的数据, 需要加上 --yes-i-really-mean-it.

root@storage01-ib:~# ceph osd force-create-pg 20.37 --yes-i-really-mean-it
' W: w2 s$ `0 O2 z/ f7 \pg 20.37 now creating, ok
执行成功.

# Y* z4 G0 i4 R. L7 z6 G查看新创建的 pg.

root@storage01-ib:~# ceph pg 20.37 query
{
    "state": "active+clean",
1 h# }5 w+ y- F0 b5 d    "snap_trimq": "[]",
9 M- p8 \( k0 i    "snap_trimq_len": 0,
    "epoch": 814,
+ D: S; I- X; e; n5 v% X' C    "up": [
+ d$ J2 `+ j+ p- ~# _: E. {# b/ H        6
    ],
2 p; X& ^' ]" E1 [: w9 \# l) _    "acting": [
        6
4 k. O% E; [7 s! O% s    ],
" b  S4 N4 r$ W0 U! T    "acting_recovery_backfill": [
        "6"
5 h* b4 i; U" ^% n    ],
. b0 h7 {, N8 V    "info": {
% `: S; a+ Y* \$ V; \5 [        "pgid": "20.37",
        "last_update": "0'0",
4 G  C- o  R4 b* D1 u* v        "last_complete": "0'0",
! _* n: R  W, w: e% C( i        "log_tail": "0'0",
        "last_user_version": 0,
        "last_backfill": "MAX",
        "last_backfill_bitwise": 0,
        "purged_snaps": [],
9 K, V5 [6 ]8 }- f" Z8 `/ F" G        "history": {
& P; i4 _7 ?$ u            "epoch_created": 795,
            "epoch_pool_created": 795,
! |" ~4 A% I/ V- S. {3 Z9 Q            "last_epoch_started": 797,
            "last_interval_started": 795,
            "last_epoch_clean": 797,
            "last_interval_clean": 795,
            "last_epoch_split": 0,
, f, r" N( y: {2 ^1 y0 A            "last_epoch_marked_full": 0,
6 }% |6 U9 Y- Z4 B) U, Y3 i            "same_up_since": 795,
            "same_interval_since": 795,
            "same_primary_since": 795,
            "last_scrub": "0'0",
            "last_scrub_stamp": "2019-03-05 03:02:04.611341",
            "last_deep_scrub": "0'0",
            "last_deep_scrub_stamp": "2019-03-05 03:02:04.611341",
            "last_clean_scrub_stamp": "2019-03-05 03:02:04.611341"
3 K- T4 c# y3 u7 X9 a        },
        "stats": {
$ P* \4 K  H! ^1 ]# Z            "version": "0'0",
$ n& |: d9 F) S1 R1 l! |            "reported_seq": "25",
$ x1 Q2 ^" _; g- ^3 p            "reported_epoch": "814",
2 ?7 w5 r" B: F: J# w; v            "state": "active+clean",
% |- d; |6 G6 m; {/ [% R            "last_fresh": "2019-03-05 03:07:59.418140",
1 s/ k  Q- [5 \8 X3 s7 e            "last_change": "2019-03-05 03:02:06.260474",
            "last_active": "2019-03-05 03:07:59.418140",
$ g8 `- t5 }! D( s  A" E$ }! I0 Y& Q            "last_peered": "2019-03-05 03:07:59.418140",
            "last_clean": "2019-03-05 03:07:59.418140",
            "last_became_active": "2019-03-05 03:02:06.260323",
, M# @  `; f( M  n& n# m            "last_became_peered": "2019-03-05 03:02:06.260323",
% `4 k+ @) b) i) x- d/ ~            "last_unstale": "2019-03-05 03:07:59.418140",
            "last_undegraded": "2019-03-05 03:07:59.418140",
            "last_fullsized": "2019-03-05 03:07:59.418140",
            "mapping_epoch": 795,
            "log_start": "0'0",
            "ondisk_log_start": "0'0",
            "created": 795,
. Q& H9 _$ X( `8 K# z: P" V            "last_epoch_clean": 797,
            "parent": "0.0",
            "parent_split_bits": 0,
            "last_scrub": "0'0",
* [. q: m" M* V- T* j) z. U7 g% a            "last_scrub_stamp": "2019-03-05 03:02:04.611341",
; l6 ]( Q- P( o            "last_deep_scrub": "0'0",
# E! r) N9 d# r2 Z% }            "last_deep_scrub_stamp": "2019-03-05 03:02:04.611341",
( f- h  y2 ^( R7 ?( j" |6 E4 I            "last_clean_scrub_stamp": "2019-03-05 03:02:04.611341",
, T4 W. g7 h3 D) v. R9 `1 |7 ^            "log_size": 0,
            "ondisk_log_size": 0,
            "stats_invalid": false,
            "dirty_stats_invalid": false,
- K; t+ _( i' l( `& ]4 w8 H            "omap_stats_invalid": false,
            "hitset_stats_invalid": false,
' V8 {; N) `. a7 Z6 d* O, x            "hitset_bytes_stats_invalid": false,
            "pin_stats_invalid": false,
            "manifest_stats_invalid": false,
            "snaptrimq_len": 0,
            "stat_sum": {
5 h2 Y( p& m3 J& e- r+ j! `                "num_bytes": 0,
" ~, x7 q' X9 G2 j: J                "num_objects": 0,
                "num_object_clones": 0,
                "num_object_copies": 0,
                "num_objects_missing_on_primary": 0,
                "num_objects_missing": 0,
0 o7 `/ m3 g( Y/ h; k) o5 u                "num_objects_degraded": 0,
* m: ~, {8 d7 l: j8 R$ }                "num_objects_misplaced": 0,
                "num_objects_unfound": 0,
  D3 l, B; K  F. H- u8 y4 M                "num_objects_dirty": 0,
/ i& [3 z: e* ~4 c% c* p3 [                "num_whiteouts": 0,
                "num_read": 0,
" X: y; V# C( m8 D3 M4 C                "num_read_kb": 0,
, f' L0 e* ]* d, u& h                "num_write": 0,
                "num_write_kb": 0,
                "num_scrub_errors": 0,
3 Z) c/ b0 P2 O/ ~/ u* k: y4 R                "num_shallow_scrub_errors": 0,
# f6 T2 r# N' O/ e. c# E8 a, e                "num_deep_scrub_errors": 0,
                "num_objects_recovered": 0,
& @5 Y  [2 E- W                "num_bytes_recovered": 0,
3 F) }0 U1 z, ]4 T                "num_keys_recovered": 0,
                "num_objects_omap": 0,
8 \& `1 U. x; v# ]  {( F                "num_objects_hit_set_archive": 0,
; g+ O+ I  ]9 o! q" Z/ u                "num_bytes_hit_set_archive": 0,
* t- U' y- ]! _3 A, ~                "num_flush": 0,
1 s7 e4 H; l9 J, t' {, P* r                "num_flush_kb": 0,
                "num_evict": 0,
: n% ~* S" w0 k6 W4 c& b                "num_evict_kb": 0,
                "num_promote": 0,
                "num_flush_mode_high": 0,
. \* D* |+ ?) R& y! `                "num_flush_mode_low": 0,
                "num_evict_mode_some": 0,
                "num_evict_mode_full": 0,
                "num_objects_pinned": 0,
                "num_legacy_snapsets": 0,
4 I0 N6 O4 ^: G& e                "num_large_omap_objects": 0,
+ m4 o4 M+ y2 T6 j% O                "num_objects_manifest": 0
            },
            "up": [
                6
            ],
. w& }! m" X# n3 ~            "acting": [
! k) C' P, E( p                6
            ],
            "blocked_by": [],
            "up_primary": 6,
            "acting_primary": 6,
            "purged_snaps": []
. u; F2 N  N7 B$ l2 `5 H& N' Y        },
        "empty": 1,
& H, t) Q8 R5 Q7 H; j# u        "dne": 0,
8 F6 J7 k' G; y7 q% ~8 _        "incomplete": 0,
        "last_epoch_started": 797,
9 F: p( s8 Q. d/ F; C        "hit_set_history": {
            "current_last_update": "0'0",
5 s# e! |8 g/ w: h; r. Y            "history": []
        }
    },
. n1 \( r% H! V* a: M    "peer_info": [],
    "recovery_state": [
        {
            "name": "Started/Primary/Active",
2 T) i3 H2 H; Q, J            "enter_time": "2019-03-05 03:02:06.252112",
            "might_have_unfound": [],
0 C( i" S/ x7 Z            "recovery_progress": {
) y3 r( g* q1 Y4 I                "backfill_targets": [],
                "waiting_on_backfill": [],
                "last_backfill_started": "MIN",
( p$ s& M- U) u7 l' F                "backfill_info": {
. `& V6 N! G4 m& l6 |1 C                    "begin": "MIN",
) B( h1 r* \" }, P2 G. E                    "end": "MIN",
- C8 u! @# }* {                    "objects": []
                },
                "peer_backfill_info": [],
                "backfills_in_flight": [],
" G# R, `5 E: T1 S; c5 L                "recovering": [],
* q# _6 z. \% a% D                "pg_backend": {
. |$ ^4 x) k# F                    "pull_from_peer": [],
                    "pushing": []
                }
            },
, a! R# j: p" \, b' b$ i            "scrub": {
% {! R" i1 D; L' Y! V' Y* ]* z! w                "scrubber.epoch_start": "0",
1 G+ o' R& N$ @! Y                "scrubber.active": false,
                "scrubber.state": "INACTIVE",
                "scrubber.start": "MIN",
                "scrubber.end": "MIN",
, }8 ~2 P9 w6 p7 m* j+ B                "scrubber.max_end": "MIN",
; [3 P8 n5 i/ m+ z. F( o% ?                "scrubber.subset_last_update": "0'0",
                "scrubber.deep": false,
                "scrubber.waiting_on_whom": []
8 a0 d# n6 L+ m' ]2 Y            }
: K( ^' [* P, n5 y8 S$ F9 Q        },
        {
# P/ l, `7 e& n            "name": "Started",
            "enter_time": "2019-03-05 03:02:05.356513"
        }
    ],
    "agent_state": {}
- j0 z% |' y- Y}
& e- W8 d0 f" i- X" l% Q

结论
: V7 P; O4 v1 c; q至此, 修复完毕.

1 i+ Z4 h3 |1 R. s7 k2 ]7 e2 N/ }. i后续检查, 1 副本的下载文件夹丢了几个小姐姐【手动滑稽】

2 m, e0 ]3 y; v0 H建议在直到具体是什么问题的情况下才进行这样的操作. 如果是重要的数据, 请不要使用 1 副本, 并做好备份后再进行操作.

如果是2,3 副本情况下的 pg stat unknown, 建议做好心理准备... 很可能就是没了.
3 l  W, _( T/ W: Z) ?+ ]! V9 b
4 {' m8 e+ Q: g, m' B  Z6 G如果是其他 pg stuck 的情况, 建议仔细分析再进行操作.
+ v8 O0 U3 x! f( w
1 j2 j. b- e( u以上.