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
|
> │ ╰──────────────────────────────────┴╴UUID présent dans le nom du LV
|
||||||
> ╰╴numéro de l'OSD
|
> ╰╴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