bench_wiki の論理ダンプ退避と削除（TiFlash は blog 検索依存のため存続）

起票理由

PLaMo Embedding による Wikipedia データ投入検証（2026-07-17 実施、DB 名 bench_wiki）がひと段落したため、bench_wiki を論理ダンプで node1:~/work/20260717/ に退避してから DROP し、クラスタのストレージを解放する。ダンプさえ残せば再現（リストア）はすぐできる、という判断。

当初は TiFlash コンポーネント自体の撤去も対象だったが見送った。 TiFlash は wiki 検証より前（2026-07-15）にブログ本体のベクトル検索用に追加したもので、blog_dev / blog_prd 両方の article_embedding_chunks が TiFlash replica + HNSW インデックスを持ち、blog-api の検索（検索のみモード = HNSW / タグ併用モード = TiFlash exact）が依存している。撤去すると blog の検索が止まるため、本タスクでは bench_wiki の削除のみ を行う。

2026-07-27 の information_schema.tiflash_replica 実測。上 2 行が今回の削除対象。

table_schema

table_name

replica_count

available

bench_wiki

wiki_embedding_chunks

1

1

bench_wiki

vec_lesson

1

1

blog_dev

article_embedding_chunks

1

1

blog_prd

article_embedding_chunks

1

1

スコープ

対象

扱い

bench_wiki（テーブル・TiFlash replica・vector index を含む）

ダンプ退避後に DROP DATABASE

TiFlash コンポーネント（basic-tiflash-0）

残す（blog_dev / blog_prd の HNSW が依存）

blog_dev / blog_prd

触らない

plamo-embedding Deployment

触らない（blog の embedding 生成でも使うため）

手順（ユーザー実行）

コマンドはすべて Mac（Tailnet 接続済み）で実行する。root にパスワードを設定している場合は mysql / mysqldump に -p を付ける。

export TAILNET=$(tailscale status --json | jq -r '.MagicDNSSuffix')

1. 現状確認（サイズと TiFlash replica）

ダンプ前に規模と replica の状態を把握する。

# テーブル一覧とサイズ
mysql -h "tidb.${TAILNET}" -P 4000 -u root -e "
  SELECT table_name, table_rows,
         ROUND(data_length/1024/1024)  AS data_mb,
         ROUND(index_length/1024/1024) AS index_mb
  FROM information_schema.tables
  WHERE table_schema = 'bench_wiki';"

# TiFlash replica の全量（bench_wiki 以外に blog_dev / blog_prd の article_embedding_chunks がいるはず）
mysql -h "tidb.${TAILNET}" -P 4000 -u root -e "
  SELECT table_schema, table_name, replica_count, available
  FROM information_schema.tiflash_replica;"

2. ダンプ取得（node1 へ直接ストリーム保存）

mysqldump のフラグは 2026-07-05 の手順と同じ（TiDB では --single-transaction が使えないため --skip-lock-tables 構成）。DB 名は位置引数で渡すので、ダンプに CREATE DATABASE / USE は入らない（リストア先スキーマを -D で選べる）。

zstd がない場合は Mac は brew install zstd、node1 は sudo apt-get install -y zstd。

--init-command で読み取りエンジンを TiKV に固定している。これがないと TiFlash OOM で失敗する（後述のハマりどころ参照）。

TS=$(date +%Y%m%d-%H%M%S)
mysqldump -h "tidb.${TAILNET}" -P 4000 -u root \
  --init-command="SET SESSION tidb_isolation_read_engines='tikv,tidb'" \
  --skip-lock-tables --skip-add-locks --no-tablespaces --set-gtid-purged=OFF \
  bench_wiki \
  | zstd -T0 \
  | ssh shuntaka@node1 "mkdir -p ~/work/20260717 && cat > ~/work/20260717/bench_wiki-${TS}.sql.zst"

ハマりどころ: TiFlash replica を持つテーブルの全件ダンプが TiFlash OOM で落ちる

--init-command なしで実行すると以下で失敗した（2026-07-27 実測）。

mysqldump: Error 1105: other error for mpp stream: Code: 0, e.displayText() = DB::TiFlashException:
Memory limit (total) exceeded caused by 'RSS(Resident Set Size) much larger than limit' :
process memory size would be 7.49 GiB

mysqldump の全件 SELECT * は「全行 × 全列」の読み出しだが、TiFlash replica を持つテーブルではオプティマイザがフルスキャンを TiFlash (MPP) に振ることがある。wiki_embedding_chunks は 100k 行 × VECTOR(2048) で、TiFlash Pod のメモリ limit 8Gi（tidb-cluster.yaml）を超えて OOM した。tidb_isolation_read_engines='tikv,tidb' をセッションに設定すると TiKV 読みに固定できる（tidb は information_schema 等のメモリテーブル用に残す）。--init-command は mysqldump 8.0.32+ / 8.4 で使える（手元は 8.4.10）。GLOBAL で切り替えると blog-api の検索（TiFlash 依存）に影響するため、必ずセッション単位で行う。

3. ダンプ検証

DROP 前に必ず実施する。Dump completed の行が末尾にあれば mysqldump が正常終了している。

ssh shuntaka@node1 "ls -lh ~/work/20260717/ && zstd -t ~/work/20260717/bench_wiki-${TS}.sql.zst"
ssh shuntaka@node1 "zstd -dc ~/work/20260717/bench_wiki-${TS}.sql.zst | tail -3"
# 期待値: -- Dump completed on ...

4. DROP DATABASE

mysql -h "tidb.${TAILNET}" -P 4000 -u root -e "DROP DATABASE bench_wiki;"

5. 事後確認

# bench_wiki が消えていること
mysql -h "tidb.${TAILNET}" -P 4000 -u root -e "SHOW DATABASES;"

# tiflash_replica から bench_wiki 系が消え、blog_dev / blog_prd の article_embedding_chunks が available=1 で残っていること
mysql -h "tidb.${TAILNET}" -P 4000 -u root -e "
  SELECT table_schema, table_name, replica_count, available
  FROM information_schema.tiflash_replica;"

ディスクの実解放は GC（既定 10 分）+ compaction 待ちで非同期に進む（2026-07-03 の調査参照）。直後に減っていなくてよい。気になる場合は後日確認する。

export KUBECONFIG=~/.kube/config-mycluster
kubectl -n tidb-cluster exec basic-tiflash-0 -c tiflash -- df -h /data0

リストア（再現）手順

ダンプに CREATE DATABASE / USE が入っていないため、DB 作成 → -D 指定で流し込む。bench_wiki 側に VECTOR INDEX があった場合も、vector index の作成時に TiFlash replica が自動追加されるため（クラスタに TiFlash がある限り）そのまま流せる。リストア後は replica の同期と HNSW のビルド完了（tiflash_replica.available = 1）を待ってから検索クエリを打つ。

mysql -h "tidb.${TAILNET}" -P 4000 -u root -e "CREATE DATABASE bench_wiki;"
ssh shuntaka@node1 "zstd -dc ~/work/20260717/bench_wiki-<timestamp>.sql.zst" \
  | mysql -h "tidb.${TAILNET}" -P 4000 -u root -D bench_wiki

完了条件

  • [x] node1:~/work/20260717/bench_wiki-<timestamp>.sql.zst が存在し zstd -t を通過する

  • [x] ダンプ末尾に Dump completed 行がある

  • [x] DROP DATABASE bench_wiki 実行後、SHOW DATABASES から消えている

  • [x] information_schema.tiflash_replica に blog_dev / blog_prd の article_embedding_chunks（available=1）が残っている

  • [ ] blog の検索（ローカル dev）が引き続き動作する

作業ログ

2026-07-27

  • wiki 検証の片付けとして手順書を作成。当初 TiFlash コンポーネントの撤去も対象だったが、article_embedding_chunks（HNSW ベクトル検索）が TiFlash に依存しているため撤去は見送り、wiki DB の退避 + DROP のみに確定

  • 手順実行時に判明: 検証 DB の実名は wiki_db ではなく bench_wiki（テーブルは wiki_embedding_chunks / vec_lesson / tag_lesson）。手順書を実名に修正

  • あわせて blog_prd.article_embedding_chunks にも TiFlash replica が付いている（本番適用済み）ことを実測で確認。TiFlash 存続の判断を補強

Step 1: 現状確認（実行結果）

サイズは合計約 270MB。vec_lesson / tag_lesson は vector 教材の残置分で、tag_lesson は TiFlash replica なし。3 テーブルとも DB ごとダンプ・削除対象とする。

+-----------------------+------------+---------+----------+
| table_name            | table_rows | data_mb | index_mb |
+-----------------------+------------+---------+----------+
| wiki_embedding_chunks |     100000 |     264 |        6 |
| vec_lesson            |          8 |       0 |        0 |
| tag_lesson            |          7 |       0 |        0 |
+-----------------------+------------+---------+----------+

+--------------+--------------------------+---------------+-----------+
| table_schema | table_name               | replica_count | available |
+--------------+--------------------------+---------------+-----------+
| blog_dev     | article_embedding_chunks |             1 |         1 |
| blog_prd     | article_embedding_chunks |             1 |         1 |
| bench_wiki   | wiki_embedding_chunks    |             1 |         1 |
| bench_wiki   | vec_lesson               |             1 |         1 |
+--------------+--------------------------+---------------+-----------+

Step 2: ダンプ取得（実行結果）

初回は TiFlash OOM（Error 1105）で失敗（ハマりどころ参照）。node1 の中途ファイルを rm してから --init-command 付きで再実行し、約 1 分で成功。

$ ssh shuntaka@node1 "ls -lh ~/work/20260717/"
-rw-rw-r-- 1 shuntaka shuntaka 1.1G Jul 27 00:44 bench_wiki-20260727-094334.sql.zst
-rw-rw-r-- 1 shuntaka shuntaka 556K Jul 21 21:08 ingest-100k.log
-rw-rw-r-- 1 shuntaka shuntaka  61K Jul 17 13:45 ingest-10k.log
-rw-r--r-- 1 shuntaka shuntaka 9.7K Jul 18 03:25 ingest_wiki.py
-rw-rw-r-- 1 shuntaka shuntaka 611M Jul 17 04:03 jawiki_content-20260712-00000.json.bz2

information_schema の data_mb 264MB は TiKV 圧縮後サイズで、VECTOR(2048) をテキスト展開する論理ダンプは zstd 圧縮後でも 1.1GiB になる。退避先ディレクトリには投入スクリプト ingest_wiki.py・投入ログ・元データ jawiki_content-20260712-00000.json.bz2 が既存で置かれており、ダンプと合わせて再現一式が揃う。

Step 3: ダンプ検証（実行結果）

展開後 2,433,172,649 bytes ≒ 2.3GiB。Dump completed 行を確認し、バックアップ健全と判断。

$ ssh shuntaka@node1 "zstd -t ~/work/20260717/bench_wiki-20260727-094334.sql.zst"
/home/shuntaka/work/20260717/bench_wiki-20260727-094334.sql.zst: 2433172649 bytes

$ ssh shuntaka@node1 "zstd -dc ~/work/20260717/bench_wiki-20260727-094334.sql.zst | tail -3"
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

-- Dump completed on 2026-07-27  9:44:45

Step 4 / 5: DROP DATABASE と事後確認（実行結果）

DROP DATABASE bench_wiki を実行。SHOW DATABASES から消え、tiflash_replica は blog_dev / blog_prd の article_embedding_chunks（available=1）のみが残った。blog 検索への影響なしを確認。

$ mysql -h "tidb.${TAILNET}" -P 4000 -u root -e "SHOW DATABASES;"
+--------------------+
| Database           |
+--------------------+
| INFORMATION_SCHEMA |
| METRICS_SCHEMA     |
| PERFORMANCE_SCHEMA |
| blog_dev           |
| blog_prd           |
| mysql              |
| sys                |
| test               |
+--------------------+

$ mysql -h "tidb.${TAILNET}" -P 4000 -u root -e "
  SELECT table_schema, table_name, replica_count, available
  FROM information_schema.tiflash_replica;"
+--------------+--------------------------+---------------+-----------+
| table_schema | table_name               | replica_count | available |
+--------------+--------------------------+---------------+-----------+
| blog_dev     | article_embedding_chunks |             1 |         1 |
| blog_prd     | article_embedding_chunks |             1 |         1 |
+--------------+--------------------------+---------------+-----------+

ディスクの実解放は GC + compaction 待ちで非同期（手順 5 の注意どおり）。急ぎでなければ後日 df -h /data0 で確認する。