ストレージ上にのみ存在するファイルの一覧を取得する

kamonohashiの管理データ上は削除されてるが、ストレージ上には実体が残っているファイルを一覧にする方法を説明する。

背景

kamonohashiの不具合により、管理データ上ではファイルが削除されているが、ストレージ上には実体が残っているという事象が発生している。具体的には

1. データを削除した場合、そのデータに属するファイルの実体が残る
2. 前処理履歴を削除した場合、前処理後データに属するファイルの実体が残る

という事象が発生する。

ノートブック、学習の添付ファイル、学習履歴、推論の添付ファイル、推論履歴の削除ではそのようにはならない。また、データに属するファイルを個別に削除した場合も、そのようにはならない。

この不具合は4.0及び3.2で発生している。3.1では発生していない。修正は4.0.1にて行われた。

この事象によりkamonohashiの管理からファイルが一度外れると、不具合を修正したkamonohashiに更新してもそのファイルはストレージ上に残ったままとなる。そこで、kamonohashi外での作業になるが、その一覧を取得する方法を記述する。

手順の概要

ストレージ上にのみ存在するファイルの一覧を取得する手順の概要は次のとおり

1. ストレージ上に実体が存在するファイルの一覧を作成し、作業者のローカルマシンに転送する。
2. kamonohashi上に管理データが存在するファイルの一覧を作成し、作業者のローカルマシンに転送する。
3. 作業者のローカルマシンにてこれらの差分を計算する。

これで得られた差分が、ストレージ上にのみ存在するファイルの一覧である。

詳細手順1:ストレージ上のファイル一覧取得

ストレージ上のファイル一覧を取得する手順は次のとおり

minioのサーバに接続する

sshでminioのサーバにログインし、superuserになる。

ストレージのマウントポイントを確認する

kamonohashiのデフォルト構成では、minioの/var/lib/kamonohashi/nfsにストレージがマウントされている。カスタム構成にしている場合は、mountの実行結果などからストレージのマウントポイントを確認する。

マウントポイント以下のファイルを検索する

1. マウントポイントにcdする
2. find . -type d -path './.*' -prune -o -type f -path '*/Data/*' \! -name dummyFile -print として、ストレージ上のファイルを検索する。結果は任意のファイルにリダイレクトして保存しておく。
3. 検索結果をローカルマシンにsftpなどで転送する

この手順をマウントポイントの数だけ繰り返す。

結果を確認する

検索結果は次のような行がファイル数だけ繰り返されている。

./sandbox/Data/af4ac373-f7e3-4cd3-be86-c5c3d90096ce.png

sandboxの部分は、そのファイルが属するテナントを表す。

Dataの部分は、これがkamonohashiのデータに属するファイルであることを示す。

af4ac373-f7e3-4cd3-be86-c5c3d90096ce.pngの部分は、ストレージ上でのファイル名である。

findコマンドの注釈

マウントポイント以下にはドットで始まるディレクトリが存在する場合があるが、これはminioの管理ファイルであるためfindの検索外としている。dummyFileという名前のファイルも同様にminioの管理ファイルなので除外している。

Dataの部分は、kamonohashi上での管理種別が異なるもの、例えば学習結果であれば別の名前になる。今回の事象ではkamonohashiのデータのみが対象となるので、検索はパスにDataを含むものに限定している。

詳細手順2:kamonohashi管理下のファイル一覧取得

kamonohashi管理下にあるファイルの一覧を取得する手順は次の通りである

PostgreSQLのpodに接続する

sshでkubernetesのmasterにログインし、superuserになる。続いてkubectl get pod -n kqi-systemでPostgreSQLのpodを検索する。postgres-というプレフィックスがついているのがPostgreSQLのpodである。このpodにkubectl exec -it {pod名} -n kqi-system -- /bin/bashとして接続する。

kamonohashiのdbに接続する

PostgreSQLのpodでpsql --username=platypus --password --dbname=platypusdb -t -A -F, -o /backup/kqidata.txtとしてkamonohashiのdbに接続する。-oは問い合わせ結果の出力先であり、/backup/ディレクトリの適当なファイルを指定する。

ファイル一覧を作成する

psql上でselect "Tenants"."Name", "DataFiles"."StoredPath" from "DataFiles", "Tenants" where "Tenants"."Id" = "DataFiles"."TenantId";としてファイル一覧を作成する。作成後、\qでpsqlを終了する。

kqiサーバーに接続する

sshでkqiサーバにログインし、superuserになる。

sql結果ファイルをローカルマシンに転送する

PostgreSQLのpodで/backup/に作成したファイル一覧が、kqiサーバから/var/lib/kamonohashi/postgresql/backup/にて参照できるはずである。この結果を、sftpなどでローカルマシンに転送する。転送後、その結果ファイルを削除する。

結果を確認する

検索結果は次のような行がファイル数だけ繰り返されている。

sandbox,af4ac373-f7e3-4cd3-be86-c5c3d90096ce.png

sandboxの部分は、そのファイルが属するテナントを表す。

af4ac373-f7e3-4cd3-be86-c5c3d90096ce.pngの部分は、ストレージ上でのファイル名として、kamonohashiが認識しているファイル名である。

問い合わせsqlの注釈

DataFilesテーブルには、kamonohashiのデータに属するファイルの情報が格納されている。今回の事象ではkamonohashiのデータのみが対象となるので、検索はこのテーブルに限定している。

詳細手順3:結果の差分計算

詳細手順1の結果に存在し、詳細手順2の結果に存在しないファイルが、ストレージ上にのみ存在するファイルとなる。

この差分の計算方法は、作業者に委ねる。ローカルマシン上で適当なプログラムを作成するか、excelなどで処理できるだろう。

差分の利用方法についても、作業者に委ねることにする。minioサーバのストレージマウントポイントからファイルをメンテナンスする、あるいはminioかストレージの管理機能を用いてファイルをメンテナンスすることができるだろう。

なお、ファイルをそのままにしておいても、ストレージの容量を消費する以外の弊害はない。