问题(如果你想先看到'状态'，请在帖子末尾看到输出)
在我的生产群集中，具有缓慢恢复的纠删码存储池，
新的擦除池不可用，因为它们的所有 PG 似乎永远保持"创建+不完整"。
我现有的池恢复将需要非常非常长的时间(几个月)，但我希望能够立即创建新的"干净"池，以弹性方式接收新数据。
我试过什么：
Ceph OSD 存储池 创建新池 128 128 擦除我的个人资料
拉多斯 --pool newpool 把一个对象文件 ==> 此块
Ceph PG ls-by-pool newpool 不完整 ==> 我所有的 PG 都列了
Ceph 第 15.1 页查询 ==>状态 ;"正在创建+未完成" "up"和"acting"仅包含OSD '1'作为第一个元素，在所有其他位置包含'null'(2147483647)。
请注意，我的平台上的 osd '1' 是加载最多的一个(它的 PG 数量几乎是其他 OSD 的两倍)
完整上下文
- 夜光 12.2.0 (Ubuntu 16.04) 从宝石迁移而来
- 现有纠删池具有非常降级的情况(所有 OSD 现在都已启动，但 83% 的对象放错了位置，13% 的对象降级了)
- 恢复时间估计为一年
- 我的擦除配置文件是 12 + 3
==> 我想开始在一个新的"干净"池中写作，而现有的池将慢慢恢复。
=======================================Ceph 状态
簇： 编号： B5ee2A02-B92C-4829-8D43-0EB17314C0F6 生命值： HEALTH_WARN 1314118857/1577308005 物体错放 (83.314%) 数据可用性降低：10 页处于非活动状态，10 页不完整 数据冗余降级：203997294/1577308005 个对象降级 (12.933%)，492 个 pgs 不干净，342 个 pgs 降级，279 pgs 尺寸不足
服务业： 星期一：28 个守护进程，法定人数 1、2、3、4、5、6、7、8、9、10、11、12、13、14、15、16、17、18、19、20、21、22、23、24、25、26、27、28 经理： 37(活动)， 备用： 38， 12， 45， 33， 29， 10， 11， 22， 31， 47， 15， 36， 40， 32， 41， 24， 44， 34， 27， 28， 43， 35， 39， 16， 25， 26， 2， 9， 3， 4， 8， 23， 19， 17， 5， 42， 6， 21， 7， 20， 30， 13， 18， 14， 46， 1 OSD：47 OSD：47 向上，47 英寸;512 重新映射的 pgs
数据： 池： 3 池， 522 pgs 对象：100M 个对象，165 TB 使用量：已使用 191 TB，466 TB/657 TB 可用 PGS：1.916% PGS 不活跃 203997294/1577308005 对象降级 (12.933%) 1314118857/1577308005 物体错放 (83.314%) 155 个活动 +尺寸不足+降级 + 重新映射+backfill_wait 140 个活动 + 重新映射 + backfill_wait 114 个活动 + 尺寸不足 + 降级 + 重新映射 63 个活动 + recovery_wait+降级 + 重新映射 30 个活动 + 清理 + 重新映射 10 创建+未完成 9 个活动 + recovery_wait + 尺寸不足 + 降级 + 重新映射 1 个活动+尺寸不足+降级+重新映射+回填
io： 客户端： 291 kB/s RD， 0 B/s wr， 14 op/s rd， 16 op/s wr 恢复：6309 kB/s，2 个对象/秒
Ceph 健康详情
HEALTH_WARN 1314114780/1577303100物体错放(83.314%);数据可用性降低：10 页处于非活动状态，10 页不完整;数据冗余降级：203992956/1577303100 个对象降级 (12.933%)，492 个 pgs 不干净，342 个 pgs 降级，279 pgs 尺寸不足 OBJECT_MISPLACED 1314114780/1577303100 物体错放 (83.314%) PG_AVAILABILITY 数据可用性降低：10 页处于非活动状态，10 页不完整 PG 15.0 正在创建+未完成，正在操作 [1,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647](将池测试器min_size从 12 减少可能会有所帮助;ceph.com/docs 搜索"不完整") PG 15.1 正在创建+未完成，正在操作 [1,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647](将池测试器min_size从 12 减少可能会有所帮助;ceph.com/docs 搜索"不完整") PG 15.2 正在创建+未完成，正在操作 [1,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647](将池测试器min_size从 12 减少可能会有所帮助;ceph.com/docs 搜索"不完整") PG 15.3 正在创建+未完成，正在操作 [1,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647](将池测试器min_size从 12 减少可能会有所帮助;ceph.com/docs 搜索"不完整") PG 15.4 正在创建+未完成，正在操作 [1,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647](将池测试器min_size从 12 减少可能会有所帮助;ceph.com/docs 搜索"不完整")PG 15.5 正在创建+未完成，正在操作 [1,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647](将池测试器min_size从 12 减少可能会有所帮助;ceph.com/docs 搜索"不完整") PG 15.6 正在创建+未完成，正在操作 [1,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647](将池测试器min_size从 12 减少可能会有所帮助;ceph.com/docs 搜索"不完整") PG 15.7 正在创建+未完成，正在操作 [1,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647](将池测试器min_size从 12 减少可能会有所帮助;ceph.com/docs 搜索"不完整") PG 15.8 正在创建+未完成，正在操作 [1,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647](将池测试器min_size从 12 减少可能会有所帮助;ceph.com/docs 搜索"不完整") PG 15.9 正在创建+未完成，正在操作 [1,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647](将池测试器min_size从 12 减少可能会有所帮助;ceph.com/docs 搜索"不完整") PG_DEGRADED 数据冗余降级：203992956/1577303100 个对象降级 (12.933%)，492 个 pgs 不干净，342 个 pgs 降级，279 pgs 尺寸不足 PG 1.e2 卡住不干净 9096318.249662，当前状态为活动+大小不足+降级+重新映射，上次作用 [1,2147483647,2147483647,5,40,8,28,47,13,12,29,10,23,2147483647,35] PG 1.e3 卡在 11585.111340 中尺寸过小，当前状态为活动 + 尺寸不足+降级 + 重新映射，上次作用 [1,3,2147483647,47,11,21,32,46,28,23,2147483647,13,2147483647,19,26] PG 1.e4 卡在 11588.194871 中尺寸过小，当前状态为活动+尺寸不足+降级+重新映射+backfill_wait，上次作用 [26,6,23,46,18,30,2147483647,25,38,29,13,45,9,35,20] PG 1.e5 卡在 11588.374341 中尺寸过小，当前状态为活动+尺寸不足+降级+重新映射+backfill_wait，上次作用 [14,40,2147483647,22,18,17,29,31,28,43,34,19,33,15,32] PG 1.e6 卡在 11584.602668 中尺寸过小，当前状态为活动 + 尺寸不足+降级 + 重新映射，上次作用 [1,38,40,2147483647,46,14,2147483647,23,7,44,15,39,8,21,28] PG 1.e7 卡在 11578.574380 中尺寸过小，当前状态为活动 + 尺寸不足 + 降级 + 重新映射，上次作用 [1,13,2147483647,37,29,33,18,2147483647,9,38,23,16,42,2147483647,3] PG 1.e8 卡在 11571.385848 中尺寸过小，当前状态为活动+尺寸不足+降级+重新映射，上次操作 [1,23,2147483647,7,36,26,6,39,38,2147483647,29,11,15,2147483647,19] PG 1.e9 卡在 11588.254477 中尺寸过小，当前状态为活动+尺寸不足+降级+重新映射+backfill_wait，上次作用 [13,44,16,11,9,2147483647,32,37,45,17,20,21,40,46,2147483647] PG 1.EA 卡在 11588.242417 中大小过小，当前状态为活动 + 大小不足 + 降级 + 重新映射+backfill_wait，上次作用 [25,19,30,33,2147483647,44,20,39,17,45,43,24,2147483647,10,21] PG 1.eb 卡在 11588.329063 中尺寸过小，当前状态为活动+尺寸不足+降级+重新映射+backfill_wait，上次作用 [29,39,2147483647,2147483647,40,18,4,33,24,38,32,36,15,47,12] PG 1.ec 卡在 11587.781353 中尺寸过小，当前状态为活动 + 尺寸不足+降级 + 重新映射 + backfill_wait，上次作用 [35,37,42,11,2147483647,2147483647,30,15,39,44,43,46,17,4,7]
[...]
pg 3.fa is stuck unclean for 11649.009911, current state active+remapped+backfill_wait, last acting [36,15,42,4,21,14,34,16,17,8,39,3,2,7,19]
pg 3.fb is stuck undersized for 11580.419670, current state active+undersized+degraded+remapped, last acting [1,7,16,9,19,39,2147483647,33,26,23,20,8,35,40,29]
pg 3.fd is stuck unclean for 11649.040651, current state active+remapped+backfill_wait, last acting [17,21,8,26,15,42,46,27,7,39,14,35,4,29,25]
pg 3.fe is active+recovery_wait+degraded+remapped, acting [22,8,45,18,10,46,33,36,16,7,17,34,43,1,23]
pg 3.ff is stuck unclean for 11649.056722, current state active+remapped+backfill_wait, last acting [33,46,47,17,37,4,40,34,28,43,3,44,13,2,11]
在宝石到发光的迁移集群大小增加后，我遇到了同样的问题。在此过程中的某个地方，粉碎图权重已损坏(不是通过"重新加权"命令定位的权重)并归零。这导致我的集群做出了奇怪的放置决策(其中一个节点溢出了太多的 pg)，并且无法分配新的 pg(至少当这个节点不负责时)。
当我们编辑 crushmap(提取、反编译、手动版、重新编译、放置)并重新启动我们的集群时，问题得到了解决。我们只需手动重置所有设备的重量为 1.0(因为我们所有的磁盘都相同)。
重新启动后，可以分配新的 pg/pool，并且分配行为似乎恢复正常(很好地重新平衡)。
希望有帮助，
索尔蒂斯。