Une courte note, plutôt pour moi, sur les petites astuces pour la récupération de données dans Elasticsearch. Comment réparer l'index rouge s'il n'y a pas de sauvegarde, que faire si j'ai supprimé les documents et qu'il n'en reste aucune copie - malheureusement dans la documentation officielle, ils ne disent rien de ces fonctionnalités.
Sauvegardes
La première chose à faire est de configurer des sauvegardes de données importantes. La procédure à suivre est décrite dans la
documentation officielle .
Dans l'ensemble, rien de compliqué. Dans la version la plus simple, créez une boule sur un autre serveur, montez-la sur tous les nœuds élastiques de n'importe quelle manière (nfs, smbfs, peu importe). Ensuite, utilisez cron, votre application ou quoi que ce soit pour envoyer des demandes d'instantanés périodiques.
Le premier instantané sera long, les suivants ne contiendront que le delta entre les états de l'index. Notez que si vous effectuez périodiquement une
émergence forcée , le delta sera énorme et, par conséquent, le temps
nécessaire pour créer un instantané sera comme la première fois.
À considérer:
- VĂ©rifiez l'Ă©tat des sauvegardes, par exemple en utilisant _cat:
curl localhost:9200/_cat/snapshots/ yourbackuprepo / . Les instantanés partiels ou ayant échoué ne sont pas votre frère. - À partir de ES 6.x, l'élastique est très exigeant sur les en-têtes de demande. Si vous les faites manuellement (pas via l'API), vérifiez que vous avez
Content-Type: application/json , sinon toutes vos demandes s'arrêteront simplement et la sauvegarde n'aura pas lieu - L'instantané ne peut pas être restauré dans un index ouvert. Il doit être fermé ou retiré en premier. Cependant, vous pouvez restaurer le cliché côte à côte à l'aide de rename_pattern, rename_replacement ( voir l'exemple dans le dock ). En outre, lorsqu'un instantané est restauré, ses paramètres sont également restaurés, y compris les alias, le nombre de répliques, etc. Si vous n'en avez pas besoin, ajoutez index_settings ( voir le dock pour un exemple ) avec les modifications nécessaires à la demande de restauration.
- Les dépôts (boule) avec des instantanés peuvent être connectés à plusieurs clusters et restaurer des instantanés d'un cluster à un autre. L'essentiel est que les versions élastiques soient compatibles.
En général, regardez la documentation, là ce sujet est plus ou moins dévoilé.
Elasticdump
Un petit utilitaire sur nodejs qui vous permet de copier des données d'un index vers un autre index, cluster, fichier, stdout.
Soit dit en passant, la sortie vers un fichier ou une sortie standard peut être utilisée comme méthode de sauvegarde alternative - la sortie est un json valide normal (quelque chose comme le vidage sql), qui peut être réutilisé comme vous le souhaitez. Par exemple, vous pouvez coller la sortie dans un canal, où votre script transformera en quelque sorte les données et les enverra à un autre référentiel, tel que clickhouse. Les conversions js les plus simples peuvent être effectuées directement par elasticdump lui-même, il existe une clé correspondante
--transform . En général, un vol de fantaisie.
Des pièges:
- En tant que méthode de sauvegarde, elle est beaucoup plus lente que les instantanés. De plus, la sauvegarde est étendue au fil du temps, de sorte que le résultat sur un index changeant fréquemment peut être incohérent. Gardez à l'esprit.
- N'utilisez pas nodejs du référentiel debian, il y a une version trop ancienne qui affecte négativement la stabilité des outils.
- La stabilité peut varier, surtout si l'une des parties est surchargée. N'essayez pas de sauvegarder d'un serveur à un autre en exécutant l'outil sur la machine de bureau - tout le trafic y circulera.
- Fig copier des mappages. Si vous avez quelque chose de compliqué là -bas, créez manuellement l'index, puis remplissez-y uniquement les données.
- Parfois, il est logique de changer la taille du morceau (paramètre --limit). Cette option affecte directement la vitesse de copie.
Pour fusionner un grand nombre d'indices en même temps, il existe un vidage multi-élastique avec un ensemble d'options simplifié, mais tous les indices fusionnent en parallèle.
Remarque! L'auteur de l'utilitaire a déclaré qu'il n'avait plus le temps de prendre en charge, donc le
programme recherche un nouveau responsable .
De l'expérience personnelle: utilitaire utile, sauvé plus d'une fois. La vitesse et la stabilité sont telles, je voudrais un remplacement adéquat, mais jusqu'à présent, rien n'est à l'horizon.
Checkindex
Donc, nous commençons à approcher le côté obscur. Situation: l'indice est devenu rouge. Dans les journaux - quelque chose s'est mal passé, le chèque ne correspond pas au montant, vous avez probablement une mémoire ou un disque:
org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?)Bien sûr, cela ne se produit jamais avec les mères-administrateurs, car elles disposent d'un matériel haut de gamme avec triple réplication, d'une mémoire superECC avec correction de tous les niveaux d'erreur à la volée et généralement des instantanés sont configurés chaque seconde.
Mais la réalité invite malheureusement parfois de telles options, lorsque la sauvegarde était relativement longue (si vous avez des gigaoctets par heure indexés, la sauvegarde est-elle trop ancienne il y a 2 heures?), Il n'y a pas de place pour restaurer les données, la réplication n'a pas eu le temps et tout le reste.
Bien sûr, s'il y a un instantané, une sauvegarde ou similaire. - Excellent, déployez-vous et ne vous inquiétez pas. Et sinon? Heureusement, au moins certaines des données peuvent encore être enregistrées.
Tout d'abord, fermez l'index et / ou désactivez l'élastique, faites une copie de sauvegarde du fragment défaillant.
Lucene (à savoir, il fonctionne comme un backend dans elasticsearch) a une merveilleuse méthode CheckIndex. Nous avons juste besoin de l'invoquer sur un éclat brisé. Lucene vérifiera tous ses segments et supprimera ceux endommagés. Oui, les données seront perdues, mais au moins pas tout. Bien qu'il y ait de la chance.
Il y a au moins 2 façons.
MĂ©thode 1: directement sur le site
Un script aussi simple nous aidera.
En l'appelant sans paramètres, nous obtenons quelque chose comme ceci:
ERROR: index path not specified Usage: java org.apache.lucene.index.CheckIndex pathToIndex [-exorcise] [-crossCheckTermVectors] [-segment X] [-segment Y] [-dir-impl X] -exorcise: actually write a new segments_N file, removing any problematic segments -fast: just verify file checksums, omitting logical integrity checks -crossCheckTermVectors: verifies that term vectors match postings; THIS IS VERY SLOW! -codec X: when exorcising, codec to write the new segments_N file with -verbose: print additional details -segment X: only check the specified segments. This can be specified multiple times, to check more than one segment, eg '-segment _2 -segment _a'. You can't use this with the -exorcise option -dir-impl X: use a specific FSDirectory implementation. If no package is specified the org.apache.lucene.store package will be used. **WARNING**: -exorcise *LOSES DATA*. This should only be used on an emergency basis as it will cause documents (perhaps many) to be permanently removed from the index. Always make a backup copy of your index before running this! Do not run this tool on an index that is actively being written to. You have been warned! Run without -exorcise, this tool will open the index, report version information and report any exceptions it hits and what action it would take if -exorcise were specified. With -exorcise, this tool will remove any segments that have issues and write a new segments_N file. This means all documents contained in the affected segments will be removed. This tool exits with exit code 1 if the index cannot be opened or has any corruption, else 0.
En fait, nous pouvons soit simplement exécuter le test d'index, soit faire en sorte que CheckIndex le «corrige», supprimant tout ce qui est endommagé.
L'index Lutsen vit de la même manière: / var / lib / elasticsearch / nodes / 0 / indices / str4ngEHashVa1uE / 0 / index /, où 0 et 0 sont le numéro de nœud sur le serveur et le numéro du fragment sur le nœud. La valeur effrayante entre eux - le nom interne de l'index - peut être obtenue à partir de la sortie de curl localhost: 9200 / _cat / indices.
Je fais généralement une copie dans un autre répertoire et répare sur place. Ensuite, je redémarre elasticsearch. En règle générale, tout est ramassé, mais avec une perte de données. Parfois, l'index ne veut toujours pas être lu en raison des fichiers * corrompus * dans le dossier des fragments. Déplacez-les dans un endroit sûr pendant un certain temps.
MĂ©thode 2: Luke
(photo d'Internet)
Il existe un grand utilitaire pour travailler avec Lucene
appelé Luke .
C'est encore plus simple ici. DĂ©couvrez la version Lucene de votre elasticsearch:
$ curl localhost:9200 { "name" : "node00", "cluster_name" : "main", "cluster_uuid" : "UCbEivvLTcyWSQElOipgTQ", "version" : { "number" : "6.2.4", "build_hash" : "ccec39f", "build_date" : "2018-04-12T20:37:28.497551Z", "build_snapshot" : false, "lucene_version" : "7.2.1", "minimum_wire_compatibility_version" : "5.6.0", "minimum_index_compatibility_version" : "5.0.0" }, "tagline" : "You Know, for Search" }
Prenez la même version de Luke. Nous y ouvrons un index (copie bien sûr) avec un daw
Ne pas ouvrir IndexReader (lors de l'ouverture d'un index corrompu) . Ensuite, cliquez sur Outils / Vérifier l'index. Je recommande d'abord de fonctionner à sec, puis seulement en mode de réparation. D'autres actions sont similaires - recopiez l'élastique, redémarrez / ouvrez l'index.
Récupérer des documents supprimés
Situation: vous avez effectué une requête destructrice qui a supprimé beaucoup / toutes les données dont vous avez besoin. Et nulle part où restaurer, ou très cher. Eh bien, bien sûr, SSZB qu'il n'y a pas de sauvegardes, mais cela se produit également.
Malheureusement ou heureusement, Lucene n'enlève jamais rien directement. Sa philosophie est plus proche de CoW, donc les données supprimées ne sont pas réellement supprimées, mais uniquement marquées comme supprimées. La suppression elle-même se produit pendant l'optimisation d'index - les données en direct des segments sont copiées dans les segments nouvellement créés, les anciens segments sont simplement supprimés. En général, bien que l'état de l'index supprimé ne soit pas 0, il y a des chances de le sortir.
$ curl localhost:9200/_cat/indices?v health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open data.0 R0fgvfPnTUaoI2KKyQsgdg 5 1 7238685 1291566 45.1gb 22.6gb
Après l'émergence, il n'y a aucune chance.
Donc, tout d'abord, fermez l'index, arrêtez l'élastique, copiez l'index (fichiers) dans un endroit sûr.
Il n'est pas possible d'extraire un document supprimé individuel. Vous ne pouvez récupérer que tous les documents supprimés dans le segment spécifié.
Pour les versions Lucene inférieures à 4, tout est très simple. L'API Lucene a une fonction appelée undeleteAll. Vous pouvez l'appeler directement depuis
Luke dans le paragraphe précédent.
Pour les versions plus récentes, hélas, la fonctionnalité a été réduite. Mais il reste encore un moyen. Les informations sur les documents actifs sont stockées dans des fichiers * .liv. Cependant, leur simple suppression rendra l'index illisible. Il est nécessaire de corriger le fichier segments_N pour qu'il oublie complètement leur existence.
Ouvrez le fichier segments_N (N est un entier) dans votre éditeur Hex préféré. La
documentation officielle nous aidera Ă y naviguer:
segments_N: Header, LuceneVersion, Version, NameCounter, SegCount, MinSegmentLuceneVersion, <SegName, SegID, SegCodec, DelGen, DeletionCount, FieldInfosGen, DocValuesGen, UpdatesFiles>SegCount, CommitUserData, Footer
De tout cela, nous avons besoin des valeurs de DelGen (Int64) et DeletionCount (Int32). Le premier doit ĂŞtre Ă©gal Ă -1 et le second Ă 0.
Ce n'est pas difficile de les trouver, ils sont juste derrière SegCodec, qui est une chaîne très visible comme Lucene62. Dans cette capture d'écran, vous pouvez voir que DelGen a une valeur de 3 et DeletionCount - 184614. Remplacez le premier par 0xFFFFFFFFFFFFFFFF et le second par 0x00000000. Répétez pour tous les segments nécessaires, enregistrez.
Cependant, l'index fixe ne voudra pas se charger, citant une erreur de somme de contrôle. C'est encore plus simple ici. Prenez Luke, chargez l'index avec le IndexReader désactivé, Tools / Check Index. Nous effectuons un test et constatons immédiatement que segments_N est endommagé. Tel ou tel chèque est attendu, mais tel ou tel est reçu.
Caused by: org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?) : expected=51fbdb5c actual=6e964d17
Un non-sens! Nous prenons la somme de contrĂ´le attendue et la saisissons dans les 4 derniers octets du fichier.
Enregistrez. Nous réexécutons CheckIndex pour nous assurer que tout va bien et que l'index se charge.
Et voilĂ !