Hi Wido,
thanks for your response.
Have you tried to dump the historic slow ops on the OSDs involved to see
what is going on?
$ ceph daemon osd.X dump_historic_slow_ops
Good question, I don't recall doing that. Maybe my colleague did but
he's on vacation right now. ;-)
But to be clear,
On 7/18/19 12:21 PM, Eugen Block wrote:
> Hi list,
>
> we're facing an unexpected recovery behavior of an upgraded cluster
> (Luminous -> Nautilus).
>
> We added new servers with Nautilus to the existing Luminous cluster, so
> we could first replace the MONs step by step. Then we moved the old
Hi list,
we're facing an unexpected recovery behavior of an upgraded cluster
(Luminous -> Nautilus).
We added new servers with Nautilus to the existing Luminous cluster,
so we could first replace the MONs step by step. Then we moved the old
servers to a new root in the crush map and then
I am fairly new to ceph and so far things are going great. That said, when
I try to replace a failed OSD, I can't seem to get it to use the same OSD
id#. I have gotten it to point which a ceph osd create does use the
correct id# but when I try to use ceph-deploy to instantiate the
replacement, I
Vikhyat,
I went through the steps as I did yesterday but with one small change. I
was putting the --zap-disk option before the host:disk option. Now it
works as expected. I'll try it again with the wrong syntax to see if
that's really the problem but it's the only difference between working and
Hi,
I hope you are following this :
http://ceph.com/docs/master/rados/operations/add-or-rm-osds/#removing-osds-manual
After removing the osd successfully run the following command :
# ceph-deploy --overwrite-conf osd create osd-host:device-path
--zap-disk
It will give you the same osd id
