스마일 서브해당 트러블 슈팅에 일반적인 내용으로 나열되었으며 아래의 방법으로 찾지 못하거나 해결하지 못할 수 있다.
이는 저널링의 응급 복구 또는 스냅샷 복구 , 백업 복구의 방법을 취해야만 한다.
필자의 경우 테스팅 과정으로 백업된 내용으로의 복구 보다는 작업시작전 저널링 백업과 스냅샷을 주로 이용한다.
어떤 작업 시작전 저널링 백업과 스냅샷을 뜨는 것을 항시 유념하고 작업하길 바란다.
저널링 백업과 스냅샷에 대한 설명은 다음장에서 자세히 정리해서 올리도록 하겠으며, 정리 이후 본 해당 게시물에도
링크 첨부 하도록 하겠다.
이에 일반적으로 운용중 나올 수 있는 ceph 상태 메시지인 “unfound object” 관에 간단히 풀어 보도록 하겠다.
# ceph health detail
HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)
pg 2.4 is active+degraded, 78 unfound
— 어떤 object 가 존재하고 있음을 알지만, 해당 객체의 복사본을 못찾고 있음을 나타낸다.
첫쨰
우선 어떤 object가 miss 나는지 확인.
# ceph pg 2.4 list_missing [starting offset, in json]
{ “offset”: { “oid”: “”,
“key”: “”,
“snapid”: 0,
“hash”: 0,
“max”: 0},
“num_missing”: 0,
“num_unfound”: 0,
“objects”: [
{ “oid”: “object 1”,
“key”: “”,
“hash”: 0,
“max”: 0 },
…
],
“more”: 0}
둘째
어떤 문제가 있는 OSD 혹은 문제된 데이터를 포함하고 있는지 식별.
# ceph pg 2.4 query
“recovery_state”: [
{ “name”: “Started\/Primary\/Active”,
“enter_time”: “2012-03-06 15:15:46.713212”,
“might_have_unfound”: [
{ “osd”: 1,
“status”: “osd is down”}]},
–문제 있는 object는 osd.1 에 위치하고 있지만 작동이 중지되엇음을 확인 할 수 있다.
– 이는 osd서버를 start만 해주면된다. 이후 recovery진행.
문제의 원인을 예상.
– 이미 개선되어 처리되었을 수 있다.
– 쿼리중 상태일 수 있다.
– 문제된 osd down
– 쿼리가 되지 않아 발생된 문제일 수 있다.
여러이유와 분석을 통틀어도 발견되지 않은 문제점을 가진 Object가 있다면, 손실 된 객체는 포기해야 할 수도 있다.unfound Object를 손실 혹은 삭제로 처리 해버릴 수 있는 상황이 있을 수 있다.
(*주의 어쩔 수 없는 상황시에만 적용)
# ceph pg 2.4 mark_unfound_lost revert|delete