ceph 分布式存储获取指定的pg分布

admin

不难看出，PG分布的比较不均匀，但总体上来说还好，osd.28上的PG数最多 257个PG，而osd.0-14上PG数最少，只有0，平均下来，如果不同OSD之间使用量差距很大就需要引起注意

admin

[root@compute03 ~]# ceph pg stat
  b. J5 u8 v4 C+ o, B& Z7 B[root@compute03 ~]# ceph pg dump_stuck
2 V: w9 M1 o; u; L$ ?/ i6 cok
[root@compute03 ~]# ceph pg dump

) Y& V0 _+ M: ]: J[root@compute03 ~]# ceph pg dump_json
4 u1 O' B5 b! x) Y- c& ?...........................
/ \# e# t$ P! A. @4 R: Z9 e
5 I, r  |0 X  Z$ _- Z; ]( Wsum 1635749 0 0 0 0 6869267547107 66904 3988 9997885 9997885
OSD_STAT USED    AVAIL   USED_RAW TOTAL   HB_PEERS                                                                       PG_SUM PRIMARY_PG_SUM
* G$ f) l& ]3 e/ z31       696 GiB 6.6 TiB  698 GiB 7.3 TiB  [0,1,3,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,30]    294            133
30       638 GiB 6.7 TiB  640 GiB 7.3 TiB [0,2,4,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,31]    273            129
/ O8 n  w: A7 O7 \0 x& n, s29       674 GiB 6.6 TiB  675 GiB 7.3 TiB    [1,3,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,30]    277            147
  l3 v8 c3 o" ^* ?0 ]. ~28       751 GiB 6.5 TiB  753 GiB 7.3 TiB    [0,2,4,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,27,29,30,31]    312            158
27       746 GiB 6.5 TiB  748 GiB 7.3 TiB [1,3,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,28,29,30,31]    308            169
26       611 GiB 6.7 TiB  613 GiB 7.3 TiB    [0,2,4,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,27,29,30,31]    271            127
3 R& H1 f( K5 N2 L( d' M! ?1 P0 r25       667 GiB 6.6 TiB  668 GiB 7.3 TiB    [1,3,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,24,26,27,28,29,30,31]    287            152
24       681 GiB 6.6 TiB  683 GiB 7.3 TiB [0,2,4,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,25,26,27,28,29,30,31]    290            137
23       681 GiB 6.6 TiB  683 GiB 7.3 TiB    [1,3,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,24,26,27,28,29,30,31]    286            138
8 W- ^/ j& }% `5 @9 ?! d# h22       614 GiB 6.7 TiB  616 GiB 7.3 TiB    [0,2,4,6,7,8,9,10,11,12,13,14,15,16,17,18,19,21,23,24,25,26,27,28,29,30,31]    261            121
; v  |, {) Y3 R  Z& ]# k9        140 GiB 418 GiB  141 GiB 559 GiB                                    [1,3,5,6,7,8,10,11,12,13,14,17,21,23,26,29]    337            155
8         21 MiB 446 GiB  1.0 GiB 447 GiB                                    [0,2,4,6,7,9,10,11,12,13,16,19,20,25,28,31]      0              0
( V+ s9 R, e2 z7         21 MiB 446 GiB  1.0 GiB 447 GiB                                    [1,3,5,6,8,9,10,11,12,13,15,18,22,24,27,30]      0              0
6 W4 N& j9 i: ?' Y; S6         21 MiB 446 GiB  1.0 GiB 447 GiB                                  [0,2,4,5,7,8,9,10,11,12,13,14,17,21,23,26,29]      0              0
' ^0 t" C" f! j$ g4 [5        6.4 GiB 887 GiB  7.4 GiB 894 GiB                              [0,1,2,3,4,6,7,8,9,10,11,12,13,16,19,20,25,28,31]     46             28
4        5.9 GiB 887 GiB  6.9 GiB 894 GiB                              [0,1,2,3,5,6,7,8,9,10,11,12,13,15,18,22,24,27,30]     44             20
' B9 a+ b4 F; S: q, R+ n0        5.9 GiB 887 GiB  6.9 GiB 894 GiB                           [1,2,3,4,5,6,7,8,9,10,11,12,13,14,17,21,23,26,29,31]     42             21
1        4.6 GiB 889 GiB  5.6 GiB 894 GiB                              [0,2,3,4,5,6,7,8,9,10,11,12,13,15,18,22,24,27,30]     33             15
* z' P1 D$ A/ u* l0 X2        4.4 GiB 889 GiB  5.4 GiB 894 GiB                              [0,1,3,4,5,6,7,8,9,10,11,12,13,16,19,20,25,28,31]     33             16
. P5 h5 [7 B* e0 E, l( J7 \5 V3        7.7 GiB 886 GiB  8.7 GiB 894 GiB                              [0,1,2,4,5,6,7,8,9,10,11,12,13,14,17,21,23,26,29]     58             28
- y0 i5 s* I3 P10       147 GiB 411 GiB  148 GiB 559 GiB                                     [0,2,4,6,7,8,9,11,12,13,15,18,22,24,27,30]    352            177
! c+ }5 O) J2 i! f11       140 GiB 418 GiB  141 GiB 559 GiB                                     [1,3,5,6,7,8,9,10,12,13,16,19,20,25,28,31]    335            180
12       110 GiB 2.1 TiB  112 GiB 2.2 TiB                                     [0,2,4,6,7,8,9,10,11,13,14,17,21,23,26,29]    512            259
/ ?. I5 u9 g# ?$ B" ~- P: Z13       110 GiB 2.1 TiB  112 GiB 2.2 TiB                                  [1,3,5,6,7,8,9,10,11,12,14,16,18,22,24,27,30]    512            253
14       709 GiB 6.6 TiB  711 GiB 7.3 TiB    [0,2,4,6,7,8,9,10,11,12,13,15,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31]    291            142
$ a% H% L& U  u' P! a8 N: i0 f, @15       662 GiB 6.6 TiB  664 GiB 7.3 TiB [1,3,5,6,7,8,9,10,11,12,13,14,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31]    288            142
% M+ ?  |! _8 P2 {9 L! D16       631 GiB 6.7 TiB  633 GiB 7.3 TiB    [0,2,4,6,7,8,9,10,11,12,13,15,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31]    280            145
17       629 GiB 6.7 TiB  630 GiB 7.3 TiB    [1,3,5,6,7,8,9,10,11,12,13,14,15,16,18,20,21,22,23,24,25,26,27,28,29,30,31]    279            141
. C3 x; Y( `$ o' p7 a18       617 GiB 6.7 TiB  619 GiB 7.3 TiB [0,2,4,6,7,8,9,10,11,12,13,14,15,16,17,19,20,21,22,23,24,25,26,27,28,29,30,31]    266            126
19       633 GiB 6.7 TiB  635 GiB 7.3 TiB    [1,3,5,6,7,8,9,10,11,12,13,14,15,16,18,20,21,22,23,24,25,26,27,28,29,30,31]    271            146
4 O3 q+ ~/ G8 a20       730 GiB 6.6 TiB  732 GiB 7.3 TiB    [0,2,4,6,7,8,9,10,11,12,13,14,15,16,17,18,19,21,23,24,25,26,27,28,29,30,31]    305            160
0 B6 |, ~% R) }  v4 k21       667 GiB 6.6 TiB  668 GiB 7.3 TiB [1,3,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,22,23,24,25,26,27,28,29,30,31]    281            147
sum       12 TiB 131 TiB   12 TiB 144 TiB                                                                                                      

! v1 `0 u" y' |% J% @: d* NOTE: Omap statistics are gathered during deep scrub and may be inaccurate soon afterwards depending on utilisation. See http://docs.ceph.com/docs/master ... up/#omap-statistics for further details.

admin

常见的PG状态：

常见的pg状态：
creating ：创建中
down ：PG处于失效状态，PG处于离线状态
1 I; g' H' r* S" ]5 b1 P# G. `
0 x- n' D/ Y* Q: ]  @ repair （修复）：PG正在被检查，被发现的任何不一致都将尽可能的被修复。
4 f  [9 c% R9 L
$ Z2 Z3 Z9 [! E2 g* L peering（等待互联）：
' Y( Y& ~0 ~/ z0 {) M1. 当ceph peering pg, ceph 将会把 pg 副本协定导入 osd, 当 ceph 完成 peering, 意味着 osd 同意当前 PG 状态, 并允许写入
2. PG处于 peering 过程中, peering 由主 osd 发起的使存放 PG 副本的所有 OSD 就 PG 的所有对象和元素数据的状态达成一致的过程,  peering 过程完成后, 主 OSD 就可以接受客户端写请求.

0 o. R5 ^! o+ S* ~" `3 I  Z active：
1. 当 ceph 完成 peering 过程, pg 将会变成 active, active 状态意味着 pg 中的数据变得可用, 主 pg 将可执行读写操作
2. PG 是活动的, 意味着 PG 中的数据可以被读写, 对该 PG 的操作请求都讲会被处理.

clean: 干净态。PG当前不存在待修复的对象， Acting Set和Up Set内容一致，并且大小等于存储池的副本数
. }3 d; X$ W3 c2 f. y
3 F6 _& q" j) \. O1 T2 l
9 d3 t3 v- Z. `, G* ]+ j replay（重做）：某OSD崩溃后，PG正在等待客户端重新发起操作。
4 Y  F2 y, j4 N1 R
degraded（降级）：
4 o3 w2 J2 X8 }8 o+ Q1. 当客户端写对象到主 osd, 主 OSD 会把数据写复制到对应复制 OSD, 在主 OSD 把对象写入存储后, PG 会显示为 degraded 状态, 直到主 osd 从复制 OSD 中接收到创建副本对象完成信息
1 X; P6 P9 ], R+ d/ d4 u7 O9 g2. PG 处于 active+degraded 原因是因为 OSD 是处于活跃, 但并没有完成所有的对象副本写入, 假如 OSD DOWN, CEPH 标记每个 PG 分配到这个相关 OSD 的
7 ~  c  _1 |. e$ N1 N, Q% e# E状态为 degraded, 当 OSD 重新上线, OSD 将会重新恢复,
  r+ f8 t( c' h+ v3. 假如 OSD DOWN 并且 degraded 状态持续, CEPH 会标记 DOWN OSD, 并会对集群迁移相关 OSD 的数据, 对应时间由 mon osd down out interval 参数决定
" w1 q& Q, A  N& ]# F4. PG 可以被北极为 degraded, 因为 ceph 在对应 PG 中无法找到一个或者多个相关的对象, 你不可以读写 unfound 对象, 你仍然可以访问标记为 degraded PG 的其他数据
2 Q* H% G2 k& ]6 ~; v5. PG 中部分对象的副本数量未达到规定的数量

inconsistent（不一致）：PG副本出现不一致, 对象大小不正确或者恢复借宿后某个副本出现对象丢失现象
, |7 Y) N" X8 D3 s' D7 q* c: d
8 m, i+ A% S; V" T2 brecoverying（恢复中）：
! z3 r8 i& G' _ceph 设备故障容忍在一定范围的软件与硬件问题, 当 OSD 变 DOWN, 那么包含该 OSD 的 PG 副本都会有问题, 当 OSD 恢复, OSD 对应的 PG 将会更新
并反映出当前状态, 在一段时间周期后, OSD 将会恢复 recoverying 状态
recovery 并非永远都有效, 因为硬件故障可能会导致多个 OSD 故障, 例如, 网络交换机故障, 可以导致集群中的多个主机及主机包含的 OSD 故障
当网络恢复之后, 每个 OSD 都必须执行恢复

& q# u* _' N% f, b6 Z/ k  U6 ^# ~
' H3 m: r+ Y6 t* s  bback filling（回填）：
当新 OSD 加入集群, CRUSH 将会为集群新添加的 OSD 重新分配 PG, 强制新的 OSD 接受重新分配的 PG 并把一定数量的负载转移到新 OSD 中,back filling OSD 会在后台处理, 当 backfilling 完成, 新的 OSD 完成后, 将开始对请求进行服务

在 backfill 操作期间, 你可以看到多种状态,
  k' H8 m2 g/ }2 F! |3 xbackfill_wait 表示 backfill 操作挂起, 但 backfill 操作还没有开始 ( PG 正在等待开始回填操作 )
9 f/ R' _7 K! Hbackfill 表示 backfill 操作正在执行
" r+ w! [* _, r( x" t# \backfill_too_full 表示在请求 backfill 操作, 由于存储能力问题, 但不可以完成,
) d( o$ p' @$ w! K' x1 R4 Pceph 提供设定管理装载重新分配 PG 关联到新的 OSD
osd_max_backfills 设定最大数量并发 backfills 到一个 OSD, 默认 10
3 z3 f* F6 ^: z. j, wosd backfill full ratio  当 osd 达到负载, 允许 OSD 拒绝 backfill 请求, 默认 85%,
; I' u- u+ }- x' n0 r1 k+ u假如 OSD 拒绝 backfill 请求,  osd backfill retry interval 将会生效, 默认 10 秒后重试
osd backfill scan min ,  osd backfill scan max 管理检测时间间隔
一个新 OSD 加入集群后, CRUSH 会把集群先有的一部分 PG 分配给他, 该过程称为回填, 回填进程完成后, 新 OSD 准备好了就可以对外提供服务。

2 l* C$ H1 m7 ]( H
3 V+ n3 I8 O- v/ Q# u- w: P
remapped（重映射）：
当 pg 改变, 数据从旧的 osd 迁移到新的 osd, 新的主 osd 应该请求将会花费一段时间, 在这段时间内, 将会继续向旧主 osd 请求服务, 直到
- y4 [& d1 V/ j" d* YPG 迁移完成, 当数据迁移完成,  mapping 将会使用新的 OSD 响应主 OSD 服务
; s1 z6 A  h; s8 m& n6 F% v7 _, {
# w6 J  W1 Z4 k' h8 n4 s$ J, N当 PG 的 action set 变化后, 数据将会从旧 acting set 迁移到新 action set, 新主 OSD 需要过一段时间后才能提供服务, 因此它会让老的主 OSD 继续提供服务, 知道 PG 迁移完成, 数据迁移完成后, PG map 将会使用新 acting set 中的主 OSD
' T0 ]# I, m7 O) s. D7 r) i
6 W0 I; B$ g+ s& G例如：
; w& n( K4 e2 t) C/ @- O, T6 r1 t[root@ ~]# ceph osd map volumes rbd_id.volume-1421625f-a9a2-41d0-8023-4cec54b33a57
. s/ J6 v# j5 Q; m7 I, B7 s5 @$ Gosdmap e5276 pool 'volumes' (1) object 'rbd_id.volume-1421625f-a9a2-41d0-8023-4cec54b33a57' -> pg 1.2cdd8028 (1.28) -> up ([32,26,41], p32) acting ([32,26,41], p32)

/ A, O( P) n' A$ |stale（旧）：
当 ceph 使用 heartbeat 确认主机与进程是否运行,  ceph osd daemon 可能由于网络临时故障, 获得一个卡住状态 (stuck state) 没有得到心跳回应
默认, osd daemon 会每 0.5 秒报告 PG, up 状态, 启动与故障分析,
4 X( G3 O2 s( K# R7 Y8 A9 C假如 PG 中主 OSD 因为故障没有回应 monitor 或者其他 OSD 报告 主 osd down, 那么 monitor 将会标记 PG stale,
当你重启集群, 通常会看到 stale 状态, 直到 peering 处理完成,
: m- k8 P- Z& P7 g4 e在集群运行一段时候, 看到 stale 状态, 表示主 osd PG DOWN 或者没有主 osd 没有报告 PG 信息到 monitor 中
PG 处于未知状态, monitors 在 PG map 改变后还没有收到过 PG 的更新, 启用一个集群后, 常常会看到主 peering 过程结束前 PG 处于该状态。


scrubbing（清理中）：
# {7 h7 x* `/ d6 }# ]+ S% DPG 在做不一至性校验
有问题的PG：
' E3 x+ B! l5 a6 u* u: t$ A9 w# m$ Rinactive ：PG 很长时间没有显示为 acitve 状态,  (不可执行读写请求), PG 不可以执行读写, 因为等待 OSD 更新数据到最新的备份状态
; m; m( J7 C2 ?
+ ?* B) w/ D- [0 k1 Dunclean：PG 很长时间都不是 clean 状态 (不可以完成之前恢复的操作),  PG 包含对象没有完成相应的复制副本数量, 通常都要执行恢复操作。

stale：PG 状态很长时间没有被 ceph-osd 更新过, 标识存储在该 GP 中的节点显示为 DOWN,  PG 处于 unknown 状态, 因为 OSD 没有报告 monitor 由 mon osd report timeout 定义超时时间
4 H9 t6 x( X$ {! bceph pg 常见问题处理：
3 P6 R8 a* L/ ~) [# h5 e
案例1:

1. 检查集群状态发现有pg  inconsistent
通过ceph health detail查看具体的PG id。
. ?4 ~2 x8 n" I, [  k
! k3 [/ J9 L: j4 [$ ceph health detail
& e. d* o' z5 L( ^, i4 i6 E2 F! uHEALTH_ERR 1 scrub errors; Possible data damage: 1 pg inconsistent
OSD_SCRUB_ERRORS 1 scrub errors
" C$ h5 {" k% ?+ b8 C" |& QPG_DAMAGED Possible data damage: 1 pg inconsistent
% d8 ?1 E7 ^% p3 z: z+ W& }& e, z: k! o    pg 3.0 is active+clean+inconsistent, acting [34,23,1]

% K7 `9 h- u7 l' N  [/ m通过上面输出可以看到当前PG3.0处于inconsistent，并且它的三副本分别在osd.34,osd.23,osd.1。

2. 修复PG 3.0
$ ceph pg repair 3.0
instructing pg 3.0 on osd.34 to repair

1 z% y6 p  g+ H: a' K  J#查看集群监控状态
5 f0 S1 |+ Y" m' J9 [/ @$ ceph health detail
HEALTH_ERR 1 scrub errors; Possible data damage: 1 pg inconsistent, 1 pg repair
OSD_SCRUB_ERRORS 1 scrub errors
PG_DAMAGED Possible data damage: 1 pg inconsistent, 1 pg repair
; }9 Z/ {' ?  J; M; f    pg 3.0 is active+clean+scrubbing+deep+inconsistent+repair, acting [34,23,1]

#集群监控状态已恢复正常
1 I' [9 _; `- d7 F$ ceph health detail
HEALTH_OK
: [: E/ Z( Q1 W$ h
# B% r$ u2 \* E4 V3. 根据以往经验，pg出现inconsistent很有可能是对应的osd磁盘上有逻辑坏道，可以去查看osd [34,23,1]的磁盘，查看对应节点上的dmesg日志。
dimes -T |grep -I err
: [9 w3 \" }+ ]0 ]# j4 S( T案例2: osd挂了

当osd短暂挂掉的时候，因为集群内还存在着两个副本，是可以正常写入的，但是 osd.34 内的数据并没有得到更新，过了一会osd.34上线了，这个时候osd.34的数据是陈旧的，就通过其他的OSD 向 osd.34 进行数据的恢复，使其数据为最新的，而这个恢复的过程中，PG的状态会从inconsistent ->recover -> clean,最终恢复正常。
+ ?$ A$ b, E/ W+ T1 g0 V  M9 N% _这是集群故障自愈一种场景。

admin

1、查看ceph集群配置信息

1 N7 Y- i$ W; p* X* ?: C, @- J5 _
8 g, x! G. V) G+ E3 _% r
ceph daemon /var/run/ceph/ceph-mon.$(hostname -s).asok config show
$ Q) B5 i- C0 ^% S2、在部署节点修改了ceph.conf文件，将新配置推送至全部的ceph节点

ceph-deploy  --overwrite-conf config push dlp node1 node2 node3
3、检查仲裁状态，查看mon添加是否成功
* g% W4 ]  I3 x1 d
ceph quorum_status --format json-pretty
4、列式pool列表
5 R% t+ Q7 h! Y5 z
ceph osd lspools
5、列示pool详细信息

3 ?0 e* q" U, R3 q0 ]. A7 D- k9 aceph osd dump | grep pool
: H/ W; p& L4 i5 L% L7 y6、检查pool的副本数

ceph osd dump|grep -i size
7、创建pool
4 t7 ]% ]% i8 w
ceph osd pool create pooltest 128
$ P8 ]2 u' o$ _/ ?4 \1 p1 x8、删除pool

ceph osd pool delete data　　#会提示确认信息（增加命令，如下）
ceph osd pool delete data data  --yes-i-really-really-mean-it
6 ~2 g" s& B3 w4 p9、设置pool副本数

ceph osd pool get data size
ceph osd pool set data size 3
10、设置pool配额

ceph osd pool set-quota data max_objects 100                              #最大100个对象
ceph osd pool set-quota data max_bytes $((10 * 1024 * 1024 * 1024))       #容量大小最大为10G
# j) {% z) u) I( Q11、重命名pool

ceph osd pool rename data date
12、PG, Placement Groups。CRUSH先将数据分解成一组对象，然后根据对象名称、复制级别和系统中的PG数等信息执行散列操作，再将结果生成PG ID。可以将PG看做一个逻辑容器，这个容器包含多个对 象，同时这个逻辑对象映射之多个OSD上。如果没有PG，在成千上万个OSD上管理和跟踪数百万计的对象的复制和传播是相当困难的。没有PG这一层，管理海量的对象所消耗的计算资源也是不可想象的。建议每个OSD上配置50~100个PG。

　　PGP是为了实现定位而设置的PG，它的值应该和PG的总数(即pg_num)保持一致。对于Ceph的一个pool而言，如果增加pg_num，还应该调整pgp_num为同样的值，这样集群才可以开始再平衡。

0 L8 b5 H0 X  _) `; W& I; p      参数pg_num定义了PG的数量，PG映射至OSD。当任意pool的PG数增加时，PG依然保持和源OSD的映射。直至目前，Ceph还未开始再平衡。此时，增加pgp_num的值，PG才开始从源OSD迁移至其他的OSD，正式开始再平衡。PGP，Placement Groups of Placement。
1 ^, q3 o4 N% d
　　计算PG数：

) n+ d* Y, Z7 n4 o
　　ceph集群中的PG总数：

- I4 X# A8 g9 V6 l$ }  d3 G$ pPG总数 = (OSD总数 * 100) / 最大副本数        ** 结果必须舍入到最接近的2的N次方幂的值
) `( ]" |! O% Z/ L　　ceph集群中每个pool中的PG总数：
5 a+ G" p4 A" l! ]7 E) I
. x! i( e% E' c$ l3 q( X( z存储池PG总数 = (OSD总数 * 100 / 最大副本数) / 池数
　　获取现有的PG数和PGP数值：

ceph osd pool get data pg_num
ceph osd pool get data pgp_num
8 U: O3 H# N) V" @  q1 _13、修改存储池的PG和PGP

' J2 U+ F. D7 d; f" pceph osd pool set data pg_num = 1
ceph osd pool set data pgp_num = 1

admin

修复方式 wanted: command to clear 'incomplete' PGs
比如：pg 1.1是incomplete，先对比pg 1.1的主副本之间 pg里面的对象数 哪个对象数多 就把哪个pg export出来
9 F$ d$ ~2 ]& d0 I' |. F6 E% U然后import到对象数少的pg里面 然后再mark complete，一定要先export pg备份。
5 S$ A: O( Z8 a7 s3 [' n; C0 I简单方式，数据可能又丢的情况
9 W2 j$ e# p3 \( ]% P& F; Q8 g
. h) E7 t* j# `/ f! o a. stop the osd that is primary for the incomplete PG;   
b. run: ceph-objectstore-tool --data-path ... --journal-path ... --pgid $PGID --op mark-complete   
3 c# t# h) d  E, K+ P7 E2 z( [2 H: d! p c. start the osd.
  @- |7 q3 |! X. l7 s6 K: s
& J) I: g. U$ ]  f保证数据完整性
1 I8 `( g, G* N5 @2 X, X3 _
#1. 查看pg 1.1主副本里面的对象数，假设主本对象数多，则到主本所在osd节点执行
$ ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0/ --journal-path /var/lib/ceph/osd/ceph-0/journal --pgid 1.1 --op export --file /home/pg1.1

6 V5 h& G& U) t1 u, G4 \#2. 然后将/home/pg1.1 scp到副本所在节点（有多个副本，每个副本都要这么操作），然后到副本所在节点执行
$ ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-1/ --journal-path /var/lib/ceph/osd/ceph-1/journal --pgid 1.1 --op import --file /home/pg1.1

#3. 然后再makr complete $ ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-1/ --journal-path /var/lib/ceph/osd/ceph-1/journal --pgid 1.1 --op mark-complete  
, @2 }7 G7 Y$ L1 p0 Y4 G' f: Q
#4. 最后启动osd $ start osd

验证方案
( F: T$ S0 P9 s6 q" ^
#1. 把状态incomplete的pg，标记为complete。建议操作前，先在测试环境验证，并熟悉ceph-objectstore-tool工具的使用。
% |3 g6 t6 F, E9 t% W& ^. B( ?PS：使用ceph-objectstore-tool之前需要停止当前操作的osd，否则会报错。  
+ X/ c$ J! W8 p4 @& p- R( i
#2. 查询pg 7.123的详细信息，在线使用查询
3 s9 o( f( ?# A; sceph pg 7.123 query > /export/pg-7.123-query.txt  

0 [; k* s" q5 S( _#3. 每个osd副本节点进行查询
1 \/ h; X5 H& s* ^; M( C% ~. R: L ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-641/ --type bluestore --pgid 7.123 --op info > /export/pg-7.123-info-osd641.txt
5 G7 d6 M  h) h如
pg 7.123 OSD 1 存在1,2,3,4,5 object
pg 7.123 OSD 2 存在1,2,3,6 object
) m: K; H9 l$ o( A9 i. L pg 7.123 OSD 2 存在1,2,3,7 object

#4. 查询对比数据
#4.1 导出pg的object清单
5 x8 A9 ?* ]* W1 E- s1 ~- g$ xceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-641/ --type bluestore --pgid 7.123 --op list > /export/pg-7.123-object-list-osd-641.txt  
, R9 o) v0 S. [8 M# }$ x" A3 N
#4.2 查询pg的object数量
" e$ Y% y" ?1 ]) _( s4 H: Zceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-641/ --type bluestore --pgid 7.123 --op list|wc -l  
$ _& o9 U$ n" W2 v
#4.3 对比所有副本的object是否一致。
+ o! h3 [- h( t- r3 {' gdiff -u /export/pg-7.123-object-list-osd-1.txt /export/pg-7.123-object-list-osd-2.txt
& C* y6 U  m4 R/ ^9 l比如：pg 7.123是incomplete，对比7.123的所有副本之间pg里面的object数量。  
- 如上述情况，diff对比后，每个副本（主从所有副本）的object list是否一致。避免有数据不一致。使用数量最多，并且diff对比后，数量最多的包含所有object的备份。  
2 I! w4 w' O* F0 ~" |% f1 W; q* J  E  v% B2 ~- 如上述情况，diff对比后，数量是不一致，最多的不包含所有的object，则需要考虑不覆盖导入，再导出。最终使用完整的所有的object进行导入。注：import是需要提前remove pg后进行导入，等于覆盖导入。  
5 e. v) }3 N( q! V" V- 如上述情况，diff对比后，数据是一致，则使用object数量最多的备份，然后import到object数量少的pg里面 然后在所有副本mark complete，一定要先在所有副本的osd节点export pg备份，避免异常后可恢复pg。  
1 ~+ P1 [, O) R  ^
#5. 导出备份
* q% ?# K8 C/ p& V) M查看pg 7.123所有副本里面的object数量，参考上述情况，假设osd-641的object数量多，数据diff对比一致后，则到object数量最多，object list一致的副本osd节点执行（最好是每个副本都进行导出备份,为0也需要导出备份）
4 Y+ x1 h( C8 p: D$ Q2 w+ }2 y ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-641/ --type bluestore --pgid 7.123 --op export --file /export/pg1.414-osd-1.obj
; M" \3 {0 W- l4 N
% Q" p! C, H, n. y& b#6. 导入备份
然后将/export/pg1.414-osd-1.obj scp到副本所在节点，在对象少的副本osd节点执行导入。（最好是每个副本都进行导出备份,为0也需要导出备份）
- r+ Q" S7 a* z& a8 l1 `将指定的pg元数据导入到当前pg,导入前需要先删除当前pg（remove之前请先export备份一下pg数据）。需要remove当前pg,否则无法导入，提示已存在。
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-57/ --type bluestore --pgid 7.123 --op remove 需要加–force才可以删除。
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-57/ --type bluestore --pgid 7.123 --op import --file /export/pg1.414-osd-1.obj  

#7. 标记pg状态，makr complete（主从所有副本执行）
, F2 E, I  o2 N2 B' R8 @# r. gceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-57/ --type bluestore --pgid 7.123

/ ?* E/ M$ [& y( I6 ^