HowtoCeph: ajouter HEALTH_ERR Possible data damage
This commit is contained in:
parent
e017c9268a
commit
1cac36b594
55
HowtoCeph.md
55
HowtoCeph.md
|
@ -1198,3 +1198,58 @@ Jan 1 12:34:56 hostmane ceph-osd[1234567]: 2022-01-01 12:34:56.789 01234567890a
|
|||
> │ ╰──────────────────────────────────┴╴UUID présent dans le nom du LV
|
||||
> ╰╴numéro de l'OSD
|
||||
> ~~~
|
||||
|
||||
## `HEALTH_ERR` - `Possible data damage`
|
||||
|
||||
La commande `ceph -s` nous retourne une erreur de cette forme :
|
||||
|
||||
cluster:
|
||||
health: HEALTH_ERR
|
||||
24 scrub errors
|
||||
Possible data damage: 3 pgs inconsistent
|
||||
|
||||
Pour avoir les PG concernés :
|
||||
|
||||
# ceph health detail
|
||||
HEALTH_ERR 24 scrub errors; Possible data damage: 3 pgs inconsistent
|
||||
OSD_SCRUB_ERRORS 24 scrub errors
|
||||
PG_DAMAGED Possible data damage: 3 pgs inconsistent
|
||||
pg 5.13 is active+clean+inconsistent, acting [8,0]
|
||||
pg 5.99 is active+clean+inconsistent, acting [9,4]
|
||||
pg 5.b8 is active+clean+inconsistent, acting [9,1]
|
||||
|
||||
On voit qu’il s’agit des PG 5.13, 5.99 et 5.b8 hébergés respectivement sur les couples d’OSD [8,0], [9,4] et [9,1]. On peut avoir plus d’informations sur ces PG avec cette commande :
|
||||
|
||||
# rados list-inconsistent-obj 5.99 --format=json-pretty
|
||||
|
||||
Ici, la commande indique :
|
||||
|
||||
"shards": [
|
||||
{
|
||||
"osd": 4,
|
||||
"primary": false,
|
||||
"errors": [],
|
||||
"size": 4194304,
|
||||
"omap_digest": "0xffffffff",
|
||||
"data_digest": "0x242f0b48"
|
||||
},
|
||||
{
|
||||
"osd": 9,
|
||||
"primary": true,
|
||||
"errors": [
|
||||
"read_error"
|
||||
],
|
||||
"size": 4194304
|
||||
}
|
||||
]
|
||||
|
||||
L’OSD 9 retourne l’erreur `read_error`. Si on regarde la sortie de la commande `ceph osd tree`, on constate, dans ce cas, que :
|
||||
|
||||
* tous les OSD sont actifs et accessibles ;
|
||||
* tous les PG ont une machine en commun.
|
||||
|
||||
À ce stade, il faut vérifier sur la machine en question si les disques fonctionnent correctement. En l’occurrence, le fichier `/var/log/syslog` est rempli d’erreurs `blk_update_request: I/O error` pour deux disques, donc il faut les changer disques. En attendant, on peut essayer de faire réparer les PG :
|
||||
|
||||
# ceph pg repair 5.99
|
||||
|
||||
En fonction de l’état du disque physique, l’opération se déroulera correctement et le PG sera bon. Ça peut être une bonne de sortir l’OSD du _cluster_, car dans le cas d’une panne de disque, le problème va certainement se produire de nouveau.
|
||||
|
|
Loading…
Reference in a new issue