On 14.05.19 10:08 vorm., Dan van der Ster wrote:
On Tue, May 14, 2019 at 10:02 AM Kevin Flöh <kevin.fl...@kit.edu> wrote:
On 13.05.19 10:51 nachm., Lionel Bouton wrote:
Le 13/05/2019 à 16:20, Kevin Flöh a écrit :
Dear ceph experts,

[...] We have 4 nodes with 24 osds each and use 3+1 erasure coding. [...]
Here is what happened: One osd daemon could not be started and
therefore we decided to mark the osd as lost and set it up from
scratch. Ceph started recovering and then we lost another osd with
the same behavior. We did the same as for the first osd.
With 3+1 you only allow a single OSD failure per pg at a given time.
You have 4096 pgs and 96 osds, having 2 OSD fail at the same time on 2
separate servers (assuming standard crush rules) is a death sentence
for the data on some pgs using both of those OSD (the ones not fully
recovered before the second failure).
OK, so the 2 OSDs (4,23) failed shortly one after the other but we think
that the recovery of the first was finished before the second failed.
Nonetheless, both problematic pgs have been on both OSDs. We think, that
we still have enough shards left. For one of the pgs, the recovery state
looks like this:

      "recovery_state": [
          {
              "name": "Started/Primary/Peering/Incomplete",
              "enter_time": "2019-05-09 16:11:48.625966",
              "comment": "not enough complete instances of this PG"
          },
          {
              "name": "Started/Primary/Peering",
              "enter_time": "2019-05-09 16:11:48.611171",
              "past_intervals": [
                  {
                      "first": "49767",
                      "last": "59313",
                      "all_participants": [
                          {
                              "osd": 2,
                              "shard": 0
                          },
                          {
                              "osd": 4,
                              "shard": 1
                          },
                          {
                              "osd": 23,
                              "shard": 2
                          },
                          {
                              "osd": 24,
                              "shard": 0
                          },
                          {
                              "osd": 72,
                              "shard": 1
                          },
                          {
                              "osd": 79,
                              "shard": 3
                          }
                      ],
                      "intervals": [
                          {
                              "first": "58860",
                              "last": "58861",
                              "acting": "4(1),24(0),79(3)"
                          },
                          {
                              "first": "58875",
                              "last": "58877",
                              "acting": "4(1),23(2),24(0)"
                          },
                          {
                              "first": "59002",
                              "last": "59009",
                              "acting": "4(1),23(2),79(3)"
                          },
                          {
                              "first": "59010",
                              "last": "59012",
                              "acting": "2(0),4(1),23(2),79(3)"
                          },
                          {
                              "first": "59197",
                              "last": "59233",
                              "acting": "23(2),24(0),79(3)"
                          },
                          {
                              "first": "59234",
                              "last": "59313",
                              "acting": "23(2),24(0),72(1),79(3)"
                          }
                      ]
                  }
              ],
              "probing_osds": [
                  "2(0)",
                  "4(1)",
                  "23(2)",
                  "24(0)",
                  "72(1)",
                  "79(3)"
              ],
              "down_osds_we_would_probe": [],
              "peering_blocked_by": [],
              "peering_blocked_by_detail": [
                  {
                      "detail": "peering_blocked_by_history_les_bound"
                  }
              ]
          },
          {
              "name": "Started",
              "enter_time": "2019-05-09 16:11:48.611121"
          }
      ],
Is there a chance to recover this pg from the shards on OSDs 2, 72, 79?
ceph pg repair/deep-scrub/scrub did not work.
repair/scrub are not related to this problem so they won't help.

How exactly did you use the osd_find_best_info_ignore_history_les option?

One correct procedure would be to set it to true in ceph.conf, then
restart each of the probing_osd's above.
(Once the PG has peered, you need to unset the option and restart
those osds again).

We executed |ceph --admin-daemon /var/run/ceph/ceph-osd.X.asok config set osd_find_best_info_ignore_history_les true|

And then we restarted the affected OSDs. I guess this is doing the same, right?

We are also worried about the behind on trimming of the mds or is this
not too problematic?
Trimming requires IO on PGs, and the mds is almost certainly stuck on
those incomplete PGs.
Solve the incomplete, and then address the MDS later if it doesn't
resolve itself.


-- dan

ok, then we don't have to worry about this for now.


Best regards,

Kevin




MDS_TRIM 1 MDSs behind on trimming
      mdsceph-node02.etp.kit.edu(mds.0): Behind on trimming (46178/128)
max_segments: 128, num_segments: 46178


Depending on the data stored (CephFS ?) you probably can recover most
of it but some of it is irremediably lost.

If you can recover the data from the failed OSD at the time they
failed you might be able to recover some of your lost data (with the
help of Ceph devs), if not there's nothing to do.

In the later case I'd add a new server to use at least 3+2 for a fresh
pool instead of 3+1 and begin moving the data to it.

The 12.2 + 13.2 mix is a potential problem in addition to the one
above but it's a different one.

Best regards,

Lionel
The idea for the future is to set up a new ceph with 3+2 with 8 servers
in total and of course with consistent versions on all nodes.


Best regards,

Kevin

_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Reply via email to