TiDBをローカルでオンラインDDLと共にスケールさせる方法

※このブログは2025年11月6日に公開された英語ブログ ｢How to Scale TiDB Locally with Online DDL｣ の拙訳です。

データ集約型アプリケーションは、プロダクトマーケットフィットが ｢完了｣ する前に、単一ノードのMySQLでは対応しきれなくなります。ホットパーティション、スキーマ変更の時間調整、手動シャーディングによりチームの作業は遅くなります。しかしTiDBは、MySQL互換の分散SQLアーキテクチャにより、ストレージとコンピュートを独立してスケールさせ、構成変更中もアプリケーションをオンラインのまま維持します。

この短いチュートリアルでは、TiUP Playgroundを使ってローカルでTiDBを起動し、ベースラインを確立した上で、再起動やダウンタイムなしでライブスケーリングを行います。その過程で、リージョンの再バランスを観察し、レプリケーション設定を確認し、負荷下でも安全にDDLを実行します。最終的には、ラップトップ上から本番環境までTiDBの柔軟性がどのように適用されるかの実践的なイメージを持つことができます。

前提条件

まず、TiUPをインストールします。もしまだTiUPをお持ちでなければ、tiup.ioからインストールしてください。

curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh

その後、ミラーを設定し、最新バージョンにアップデートします：

tiup mirror set https://tiup-mirrors.pingcap.com
tiup update --self && tiup update --all

ステップ1：小さく始める

最小構成のクラスタから始めましょう：TiDB1台、TiKV1台、PD1台。

tiup playground --db 1 --pd 1 --kv 1 --tag democluster

このターミナルは開いたままにしておきます。TiDBは通常ポート4000で動作します。

小規模データセットの読み込み

次に、別のターミナルで下記コマンドを実行します：

tiup bench tpcc --host 127.0.0.1 --port 4000 -D test --dropdata --warehouses 5 prepare

ベースラインワークロードの実行

tiup bench tpcc --host 127.0.0.1 --port 4000 -D test --warehouses 5 --time 120s --threads 32 run

リアルタイムでDDLを確認することもできます。それでは、MySQLクライアントを使ってログインしましょう：

mysql -h 127.0.0.1 -P 4000 -u root 

Use test;
CREATE INDEX idx_qty ON stock (s_w_id);
SHOW INDEXES FROM stock;
ALTER TABLE stock DROP INDEX idx_qty;
ADMIN SHOW DDL JOBS 3;
SHOW INDEXES FROM stock;

これで、単一TiKVノードでのベースラインのTPSとレイテンシプロファイルが得られます。

ベースラインが確認できたので、次はTiDBがストレージをどのようにライブでスケールするかを見てみましょう。

ステップ2：ストレージのスケール

ここからが楽しい部分です。ワークロードを実行中に、TiKVノードを2台追加(1台→3台)してみましょう。

tiup playground scale-out --kv 2 --tag democluster
tiup playground display --tag democluster

デフォルトでは、TiUP Playgroundはreplication=1 (フォールトトレランスなし) で起動します。これを3に設定すると、各リージョンに3つのコピーを持つ、実際の本番に近いクラスタをシミュレーションできます。

次に、MySQLクライアントで現在のレプリケーション係数を確認します：

SELECT type, instance, `key`, value
FROM information_schema.cluster_config
WHERE type = 'pd' AND `key` LIKE '%max-replicas%';

次に、レプリケーション係数を3に戻します。これにより、TiDBのメタデータ管理を担当するPlacement Driver (PD) が、各リージョンに3つのレプリカを維持するようになります：

SET CONFIG pd replication.max-replicas = 3;

では、確認してみましょう：

SELECT type, instance, `key`, value
  -> FROM information_schema.cluster_config
  -> WHERE type = 'pd' AND `key` LIKE '%max-replicas%';

SQLで、クラスタが拡張される様子を確認します：

-- New stores appear in minutes
SELECT store_id, address, store_state_name
FROM information_schema.tikv_store_status;

-- Region distribution across stores
SELECT store_id,
      COUNT(*) AS peer_regions,
      SUM(CASE WHEN is_leader = 1 THEN 1 ELSE 0 END) AS leader_regions
FROM information_schema.tikv_region_peers
GROUP BY store_id;

これで、PDが3台のTiKVノード全体にリージョンとリーダーを再バランスする様子を、ダウンタイムなしで確認できます。

スケールできるのはストレージだけではありません。TiDBのSQLレイヤーはステートレスなので、コンピュートも追加してみましょう。

ステップ3：コンピュートのスケール

TiDBサーバーはステートレスなSQLフロントエンドであるため、コンピュートのスケールが即座に行えます。

2台目のTiDBノードを追加します：

tiup playground scale-out --db 1 --tag democluster
tiup playground display --tag democluster

Find their ports (in the SQL Shell):

SELECT instance AS sql_addr, status_address
FROM information_schema.cluster_info
WHERE type="tidb";

次に、両方のノードにトラフィックを流します。

ターミナルA→TiDB#1 (例：ポート4000)

tiup bench tpcc --host 127.0.0.1 --port 4000 -D test --warehouses 5 --time 120s --threads 32 run

ターミナルB→TiDB#2 (もし2台目のTiDBサーバーのSQLポートが50861の場合)

tiup bench tpcc --host 127.0.0.1 --port 50861 -D test --warehouses 5 --time 120s --threads 32 run

ロードバランサーを使えば、トラフィックはTiDBサーバー間でシームレスに分散されます。

ここまででOLTPのスケーリングは完了しました。次にTiFlashを用いて分析ワークロードを組み込みましょう。

ステップ4：TiFlashによる混合ワークロード処理

TiFlashは、分析ワークロード向けのTiDBのカラム型エンジンです。ここで1つのノードを追加してみましょう:

tiup playground scale-out --tiflash 1 --tag democlustertiup playground display --tag democluster

次に、テーブルをTiFlashにレプリケートします：

USE test;
ALTER TABLE stock SET TIFLASH REPLICA 1;

-- Check replication progress
SELECT * FROM information_schema.tiflash_replica
WHERE TABLE_SCHEMA='test' AND TABLE_NAME='stock';

次に、分析クエリを意図的に実行してみましょう：

EXPLAIN ANALYZE
SELECT s_i_id, SUM(s_quantity) AS qty
FROM stock
GROUP BY s_i_id
ORDER BY qty DESC
LIMIT 10;

OLTP (オンライントランザクション処理) は引き続きTiKVで実行される一方、分析処理はTiFlashで実行されることが確認できます。これにより、重いスキャン処理をトランザクションから分離できます。

ステップ5：オブザーバビリティ

いくつかのクエリを実行して、リアルタイムの動作を確認してみましょう：

-- Connections per TiDB server
SELECT instance, COUNT(*) AS connections
FROM information_schema.cluster_processlist
GROUP BY instance;

-- Regions/Leaders per TiKV store
SELECT store_id,
      COUNT(*) AS peer_regions,
      SUM(CASE WHEN is_leader = 1 THEN 1 ELSE 0 END) AS leader_regions
FROM information_schema.tikv_region_peers
GROUP BY store_id;

このワークロードが実行されると、PD (Placement Driver) がTiKVストア間でリージョンを再バランスする様子を確認できます。TiFlashノードは通常、ほんの少数のピアリージョンしか持たず、Raftの学習者 (Learner) として動作するため、リーダーの役割は持ちません。

ステップ6：クリーンアップ

作業が完了したら、TiUP Playgroundのターミナルを閉じるだけで、クラスタは停止します。残ったデータを消去する場合は、以下のいずれかを使用できます：

tiup clean --all

Or manually remove the demo data:

rm -rf ~/.tiup/data/*democluster*

結論：TiDBをローカルでスケーリングする

私たちは小規模に始め、TiDBをライブでスケールさせました。ストレージと耐障害性を拡張するためにTiKVを追加し、ステートレスなSQLスケールアウトのためにTiDBサーバを追加し、さらにOLTPから分析処理を分離するためにTiFlashを有効化しました。その間、オンラインDDLによって、負荷がかかった状態でも変更は安全に保たれました。
その最終的な効果は、TiDBの中核となる価値を凝縮したものです：柔軟性のあるキャパシティ、運用のシンプルさ、そしてゼロダウンタイムでの進化です。

次に試せることはこちらです：

• より大きなデータセットや高スレッド数でデモを繰り返し、リーダーやリージョンの動的な挙動を確認する
• 異なるレプリケーション設定を試し、フェイルオーバーやp95レイテンシへの影響を観察する
• TiDBサーバ間での負荷分散を検証し、追加のホットテーブルにTiFlashレプリカを有効化する
• Playgroundからマネージド環境または本番デプロイへ移行し、目標とするSLOを検証する。

テスト環境でさらに多くのTiDB機能を試してみたい場合は、無料のhands-on lab coursesをチェックしてください。