今回はelasticsearchのデータが破損してしまった場合(シングルノード)の修復方法について紹介します。簡易的なデータストレージとしてelasticsearchを使用する場合、クラスター化させずにシングルノードで使用する場合があります。データが冗長化されていないため、誤って電源断をしてしまった時やストレージに障害が発生した時にインデックスがred状態となってしまう場合があります。最悪のケースとしては.kibana_*等のElasticのシステム系インデックスがred状態になるとkibanaが起動できなくなり、開発consoleでコマンド操作といったkibanaの操作が一切できません。
重要なデータでない場合はred状態のindexを丸ごと削除するということが多いと思います。一方で重要でないが可能なら残っているデータを可能な限り復元、修復したいといった場合もあると思います。障害の種類によって修復方法が異なりますが、今回はtranslogの破損による障害の修復方法を紹介します。
translogの細かい説明はここではしませんが、負荷を分散させるためにインデックス内のデータを書き込む前にデータを一時保存するファイルです。translogの破損によってred状態となっている場合、一時保存された直近のデータは消える可能性があります。ただ、red状態で該当するインデックスのすべてのデータにアクセスできない、新規データ投入できない状態から回復したいという場合に有効です。
まずはブラウザやcurlコマンドで下記を実行し、red状態のノードを確認します。修復で使用するため、red状態となったインデックス名のUUIDも合わせて確認します。
続いて、ブラウザやcurlコマンドで下記を実行し、red状態の理由を確認します。
理由として表示された内容で下記の様にTranslog関連の障害が発生している場合は今回の方法で修復できます。unassigned_infoのdetailsにTranslogCorruptedExceptionと表示されており、translog関連の障害と分かります。TranslogCorruptedException以外にもtranslog整合性が合わないといった障害も同様に今回の方法で修復できます。
破損したtranslogファイル等を削除して新規に空のtranslogファイルを生成するために下記のコマンドを実行します。なお、ファイル操作を伴うため、elastcisearchを終了させた状態で実行します。また、破損ファイルを削除するため、必要に応じてdataフォルダのバックアップをしてください。インデックスに反映される前のtranslogにのみ記録された直近のデータは削除される場合があります。コマンドラインから下記のコマンドを実行します。
Elasticsearch7以降
bin/elasticsearch-shard remove-corrupted-data --index (インデックス名) --shard-id 0
Elasticsearch6以前
bin/elasticsearch-translog truncate -d (データフォルダ)/elasticsearch/data/nodes/0/indices/(UUID)/0/translog/
elasticsearch7以降の場合は下記のように表示され、translogの破損を発見した場合、修復の有無を聞いてきます。yキーを押して修復させます。
------------------------------------------------------------------------ WARNING: Elasticsearch MUST be stopped before running this tool. ----------------------------------------------------------------------- Please make a complete backup of your index before using this tool. ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ No problems were detected with this index. Took 0.025 sec total. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Translog is corrupted at \data\nodes\0\indices\~\0\translog ----------------------------------------------------------------------- Documents inside of translog files will be lost. The following files will be DELETED at \0\translog --> translog-2＿.tlog --> translog.ckp WARNING: YOU MAY LOSE DATA. ----------------------------------------------------------------------- Continue and remove corrupted data from the shard ? Confirm [y/N] y Checking existing translog files Reading translog UUID information from Lucene commit from shard at Translog UUID : History UUID : Removing existing translog files Creating new empty checkpoint at \translog\translog.ckp] Creating new empty translog at [translog\translog-1.tlog] Marking index with the new history uuid : Changing allocation id to You should run the following command to allocate this shard: POST /_cluster/reroute { "commands" : [ { "allocate_stale_primary" : { "index" : "(インデックス名)", "shard" : 0, "node" : "(UUID)", "accept_data_loss" : false } } ] } You must accept the possibility of data loss by changing the `accept_data_loss` parameter to `true`. |
上記は一部を書き換えています。
上記のコマンドだけでは修復したインデックスはred状態のままです。続いて、elasticsearchを起動させ、下記のコマンドを実行して再割り当てを行います。先ほどの修復コマンドの最後に表示されているように、accept_data_lossをtrueにしてcurlコマンドで下記のように実行すると再割り当てが行われ、red状態から回復します。
curl -XPOST localhost:9200/_cluster/reroute --header "Content-Type: application/json" --data "{\"commands\":[{\"allocate_stale_primary\":{\"index\":\"(インデックス名)\",\"shard\" : 0,\"node\" : \"(UUID)\",\"accept_data_loss\" : true}}]}"
再度、下記のコマンドで再割り当てされたノードを確認します。red状態から回復していれば修復完了です。
今回はelasticsearchのtranslog破損時の修復方法について紹介しました。elasticsearch-shard remove-corrupted-dataコマンドはtranslogの破損以外にも対応できるようで他の障害でも使えそうです。
もし、正常な状態のバックアップデータ(スナップショット)がある場合、邪道な方法ではありますが、該当するインデックスのtranslogファイルを丸ごと置き換える方法もあります。http://localhost:9200/_cat/indices?vでインデックス名とUUIDの関係を調べ、dataフォルダ内の該当するUUIDフォルダを見つけます。その中にtranslogフォルダがあり、同じUUIDの正常なtranslogフォルダを丸ごと置き換えます。translog自体の破損は修復できますが、インデックスデータとの整合性が合わない可能性が出てきます。ただ、この方法の場合、コマンド操作が不要なため、ダメ元で修復したい場合は作業として非常に楽になります。なお、当然ではありますが異なるUUIDのtranslogフォルダを置き換えた場合は整合性が取れないため、red状態のままです。
