TiKVの配置を決めるPD: pd-serverの単一ノードからクラスタへ

Placement Driverの責務

PDはTiKVクラスタの管理とスケジューリングを担うコンポーネントです。READMEはetcdを組み込むことでfault-toleranceを支えると説明しています。SQLサービスが必要な構成ではTiDBも加えられますが、PD単体がTiDBのSQLサーバーになるわけではありません。

導入判断では、PD単体のAPI確認と、TiKVを含むクラスタの運用確認を分けます。メンバー管理やスケジューリングの責務を明確にしないまま、単一ノードの起動成功を本番クラスタの成立と扱わないことが大切です。

PDの確認では、READMEに書かれた対象を一度に広げず、1番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。PD固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。

Goとmakeが作る三つの実行ファイル

ビルドにはGo 1.25以降を用意し、make、またはmake buildを実行します。READMEによるとbinにはpd-server、pd-ctl、pd-recoverが生成されます。依存関係やOS別の性能条件はこのREADMEでは詳しくありません。

ビルド後はbinの三つのファイルを確認し、pd-server --helpとpd-ctlの接続先設定を確認します。Goの版、コミット、生成物のハッシュを保存すると、環境を変えた時の差分を追えます。

PDの確認では、READMEに書かれた対象を一度に広げず、2番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。PD固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。

単一ノードの待受とmembers API

ローカルの単一ノードはpd-serverへ--name="pd"、--data-dir="pd"、client URL、peer URL、--log-file=pd.logを渡して起動します。外部から接続する場合はHOST_IPを待受とadvertiseへ使い、2379がclient、2380がpeerのポートです。

起動後はcurl http://${HOST_IP}:2379/pd/api/v1/membersでmembersとleaderを読みます。応答のcluster_id、member_id、client_urls、peer_urls、binary_version、git_hashを記録し、指定したアドレスと一致するかを確認します。サンプルのIPを自分の環境へそのまま流用してはいけません。

PDの確認では、READMEに書かれた対象を一度に広げず、3番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。PD固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。

Docker版とローカル版の差

Dockerではdocker build -t pingcap/pd .またはdocker pull pingcap/pdでイメージを用意し、2379と2380を公開してpd-server引数を渡します。コンテナ内の0.0.0.0と外部へ広告するHOST_IPは役割が異なり、advertise URLの誤りは接続確認を難しくします。

ローカル版とDocker版でmembers APIを呼び、name、peer、clientの各URL、logの出力先を比較します。イメージのタグ、データディレクトリ、コンテナ再作成後の状態はREADMEの短い例だけでは確定しないので、使う運用条件に合わせて確認します。

PDの確認では、READMEに書かれた対象を一度に広げず、4番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。PD固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。

TiKVと一緒に成立する構成

READMEはPDがTiKVプロジェクトのコンポーネントであり、動作にはTiKVとともに実行する必要があると明記します。TiDBを含める場合はTiUPによるTiDBクラスタ、またはTiDB on Kubernetesの公式文書を参照します。PDの単一ノード例は開発・確認の入口で、クラスタ配置手順全体ではありません。

本番候補ではPDだけを先に評価せず、TiKVとの接続、leader、メンバー一覧、障害時の再起動後状態を確認します。TiUPかKubernetesかで手順が変わるため、採用する配備方式を一つに決めて公式手順へ戻します。

PDの確認では、READMEに書かれた対象を一度に広げず、5番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。PD固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。

Apache-2.0と運用上の未確定点

メタデータはApache-2.0です。READMEはコマンドラインflagsでPDを設定できるとし、詳細をPD Configuration Flagsへ案内します。一方、互換表、性能基準、サービス保証、長期サポートをこの資料だけで確定することはできません。

TiKVの配置管理を担うサービスをGoで構築・検証したい人には、ビルドとAPIの入口が明確です。単独でSQLを提供する部品、管理ポートを無条件に外部公開する部品、性能保証つきの運用製品を探している場合は用途が違います。まずmembers応答とadvertise URLを検証してください。

PDの確認では、READMEに書かれた対象を一度に広げず、6番目の論点に対応する入力、処理結果、ログまたは生成物を分けて記録します。機能が使えるという説明と、特定のOS、版、権限、データ量で期待どおりに動くという判断は同じではありません。PD固有の設定名やファイル名を残しておけば、別の環境で再確認する際にも、どの記述を根拠にした判断かを追跡できます。

編集部の結論

PDは、READMEに記載された構成と用途が自分の環境に合う人向けです。合わない人は採用すべきではありません。先にPDのREADMEにある具体的な入力、出力、設定、実行経路を小さな検証環境で確認し、未記載の保証を補って考えないでください。

公式情報源

1. Official README
2. Project repository
3. Release notes