重要

このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

TiUP を使用してオンライン TiDBクラスタをデプロイおよび管理

このドキュメントでは、 TiUPクラスターコンポーネントの使用方法に焦点を当てています。オンライン展開の完全な手順については、 TiUP を使用して TiDBクラスタをデプロイを参照してください。

ローカルテスト展開に使用されるTiUP遊び場コンポーネントと同様に、 TiUPクラスターコンポーネントは、本番環境用に TiDB を迅速に展開します。プレイグラウンドと比較して、クラスターコンポーネントは、アップグレード、スケーリング、さらには操作と監査を含む、より強力な本番クラスター管理機能を提供します。

クラスターコンポーネントのヘルプ情報を表示するには、次のコマンドを実行します。

tiup cluster

Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.12.3/cluster
Deploy a TiDB cluster for production

Usage:
  tiup cluster [command]

Available Commands:
  check       Precheck a cluster
  deploy      Deploy a cluster for production
  start       Start a TiDB cluster
  stop        Stop a TiDB cluster
  restart     Restart a TiDB cluster
  scale-in    Scale in a TiDB cluster
  scale-out   Scale out a TiDB cluster
  destroy     Destroy a specified cluster
  clean       (Experimental) Clean up a specified cluster
  upgrade     Upgrade a specified TiDB cluster
  display     Display information of a TiDB cluster
  list        List all clusters
  audit       Show audit log of cluster operation
  import      Import an existing TiDB cluster from TiDB-Ansible
  edit-config Edit TiDB cluster config
  reload      Reload a TiDB cluster's config and restart if needed
  patch       Replace the remote package with a specified package and restart the service
  help        Help about any command

Flags:
  -c, --concurrency int     Maximum number of concurrent tasks allowed (defaults to `5`)
      --format string       (EXPERIMENTAL) The format of output, available values are [default, json] (default "default")
  -h, --help                help for tiup
      --ssh string          (Experimental) The executor type. Optional values are 'builtin', 'system', and 'none'.
      --ssh-timeout uint    Timeout in seconds to connect a host via SSH. Operations that don't need an SSH connection are ignored. (default 5)
  -v, --version            TiUP version
      --wait-timeout uint   Timeout in seconds to wait for an operation to complete. Inapplicable operations are ignored. (defaults to `120`)
  -y, --yes                 Skip all confirmations and assumes 'yes'

クラスターをデプロイ

クラスターをデプロイするには、 tiup cluster deployコマンドを実行します。コマンドの使用方法は次のとおりです。

tiup cluster deploy <cluster-name> <version> <topology.yaml> [flags]

このコマンドでは、クラスター名、TiDB クラスターバージョン ( v8.5.0など)、およびクラスターのトポロジファイルを指定する必要があります。

トポロジファイルを作成するには、例を参照してください。次のファイルは最も単純なトポロジの例です。

注記：
TiUPクラスターコンポーネントがデプロイメントとスケーリングに使用するトポロジファイルはヤムの構文を使用して記述されるため、インデントが正しいことを確認してください。

---

pd_servers:
  - host: 172.16.5.134
    name: pd-134
  - host: 172.16.5.139
    name: pd-139
  - host: 172.16.5.140
    name: pd-140

tidb_servers:
  - host: 172.16.5.134
  - host: 172.16.5.139
  - host: 172.16.5.140

tikv_servers:
  - host: 172.16.5.134
  - host: 172.16.5.139
  - host: 172.16.5.140

tiflash_servers:
  - host: 172.16.5.141
  - host: 172.16.5.142
  - host: 172.16.5.143

tiproxy_servers:
  - host: 172.16.5.144

grafana_servers:
  - host: 172.16.5.134

monitoring_servers:
  - host: 172.16.5.134

デフォルトでは、 TiUPは amd64アーキテクチャで実行されるバイナリファイルとして展開されます。ターゲットマシンが arm64アーキテクチャである場合は、トポロジファイルで構成できます。

global:
  arch: "arm64"           # Configures all machines to use the binary files of the arm64 architecture by default

tidb_servers:
  - host: 172.16.5.134
    arch: "amd64"         # Configures this machine to use the binary files of the amd64 architecture
  - host: 172.16.5.139
    arch: "arm64"         # Configures this machine to use the binary files of the arm64 architecture
  - host: 172.16.5.140    # Machines that are not configured with the arch field use the default value in the global field, which is arm64 in this case.

...

ファイルを/tmp/topology.yamlとして保存します。TiDB v8.5.0 を使用し、クラスター名がprod-cluster場合は、次のコマンドを実行します。

tiup cluster deploy -p prod-cluster v8.5.0 /tmp/topology.yaml

実行中に、 TiUP はトポロジーを再度確認するように要求し、ターゲットマシンのルートパスワードを要求します (フラグ-pはパスワードの入力を意味します)。

Please confirm your topology:
TiDB Cluster: prod-cluster
TiDB Version: v8.5.0
Type        Host          Ports                            OS/Arch       Directories
----        ----          -----                            -------       -----------
pd          172.16.5.134  2379/2380                        linux/x86_64  deploy/pd-2379,data/pd-2379
pd          172.16.5.139  2379/2380                        linux/x86_64  deploy/pd-2379,data/pd-2379
pd          172.16.5.140  2379/2380                        linux/x86_64  deploy/pd-2379,data/pd-2379
tiproxy     172.16.5.144  6000/3080                        linux/x86_64  deploy/tiproxy-6000
tikv        172.16.5.134  20160/20180                      linux/x86_64  deploy/tikv-20160,data/tikv-20160
tikv        172.16.5.139  20160/20180                      linux/x86_64  deploy/tikv-20160,data/tikv-20160
tikv        172.16.5.140  20160/20180                      linux/x86_64  deploy/tikv-20160,data/tikv-20160
tidb        172.16.5.134  4000/10080                       linux/x86_64  deploy/tidb-4000
tidb        172.16.5.139  4000/10080                       linux/x86_64  deploy/tidb-4000
tidb        172.16.5.140  4000/10080                       linux/x86_64  deploy/tidb-4000
tiflash     172.16.5.141  9000/8123/3930/20170/20292/8234  linux/x86_64  deploy/tiflash-9000,data/tiflash-9000
tiflash     172.16.5.142  9000/8123/3930/20170/20292/8234  linux/x86_64  deploy/tiflash-9000,data/tiflash-9000
tiflash     172.16.5.143  9000/8123/3930/20170/20292/8234  linux/x86_64  deploy/tiflash-9000,data/tiflash-9000
prometheus  172.16.5.134  9090         deploy/prometheus-9090,data/prometheus-9090
grafana     172.16.5.134  3000         deploy/grafana-3000
Attention:
    1. If the topology is not what you expected, check your yaml file.
    2. Please confirm there is no port/directory conflicts in same host.
Do you want to continue? [y/N]:

パスワードを入力すると、 TiUPクラスターは必要なコンポーネントをダウンロードし、対応するマシンに展開します。次のメッセージが表示されたら、展開は成功です。

Deployed cluster `prod-cluster` successfully

クラスターリストをビュー

クラスターが正常にデプロイされたら、次のコマンドを実行してクラスターリストを表示します。

tiup cluster list

Starting /root/.tiup/components/cluster/v1.12.3/cluster list
Name          User  Version    Path                                               PrivateKey
----          ----  -------    ----                                               ----------
prod-cluster  tidb  v8.5.0    /root/.tiup/storage/cluster/clusters/prod-cluster  /root/.tiup/storage/cluster/clusters/prod-cluster/ssh/id_rsa

クラスターを起動する

クラスターが正常にデプロイされたら、次のコマンドを実行してクラスターを起動します。

tiup cluster start prod-cluster

クラスターの名前を忘れた場合は、 tiup cluster list実行してクラスターリストを表示します。

TiUP はデーモンプロセスを開始するためにsystemd使用します。プロセスが予期せず終了した場合、15 秒後にプルアップされます。

クラスターのステータスを確認する

TiUP は、クラスター内の各コンポーネントのステータスを表示するためのtiup cluster displayコマンドを提供します。このコマンドを使用すると、コンポーネントのステータスを確認するために各マシンにログインする必要がなくなります。コマンドの使用方法は次のとおりです。

tiup cluster display prod-cluster

Starting /root/.tiup/components/cluster/v1.12.3/cluster display prod-cluster
TiDB Cluster: prod-cluster
TiDB Version: v8.5.0
ID                  Role        Host          Ports                            OS/Arch       Status  Data Dir              Deploy Dir
--                  ----        ----          -----                            -------       ------  --------              ----------
172.16.5.134:3000   grafana     172.16.5.134  3000                             linux/x86_64  Up      -                     deploy/grafana-3000
172.16.5.134:2379   pd          172.16.5.134  2379/2380                        linux/x86_64  Up|L    data/pd-2379          deploy/pd-2379
172.16.5.139:2379   pd          172.16.5.139  2379/2380                        linux/x86_64  Up|UI   data/pd-2379          deploy/pd-2379
172.16.5.140:2379   pd          172.16.5.140  2379/2380                        linux/x86_64  Up      data/pd-2379          deploy/pd-2379
172.16.5.134:9090   prometheus  172.16.5.134  9090                             linux/x86_64  Up      data/prometheus-9090  deploy/prometheus-9090
172.16.5.134:4000   tidb        172.16.5.134  4000/10080                       linux/x86_64  Up      -                     deploy/tidb-4000
172.16.5.139:4000   tidb        172.16.5.139  4000/10080                       linux/x86_64  Up      -                     deploy/tidb-4000
172.16.5.140:4000   tidb        172.16.5.140  4000/10080                       linux/x86_64  Up      -                     deploy/tidb-4000
172.16.5.141:9000   tiflash     172.16.5.141  9000/8123/3930/20170/20292/8234  linux/x86_64  Up      data/tiflash-9000     deploy/tiflash-9000
172.16.5.142:9000   tiflash     172.16.5.142  9000/8123/3930/20170/20292/8234  linux/x86_64  Up      data/tiflash-9000     deploy/tiflash-9000
172.16.5.143:9000   tiflash     172.16.5.143  9000/8123/3930/20170/20292/8234  linux/x86_64  Up      data/tiflash-9000     deploy/tiflash-9000
172.16.5.134:20160  tikv        172.16.5.134  20160/20180                      linux/x86_64  Up      data/tikv-20160       deploy/tikv-20160
172.16.5.139:20160  tikv        172.16.5.139  20160/20180                      linux/x86_64  Up      data/tikv-20160       deploy/tikv-20160
172.16.5.140:20160  tikv        172.16.5.140  20160/20180                      linux/x86_64  Up      data/tikv-20160       deploy/tikv-20160
172.16.5.144:6000   tiproxy     172.16.5.144  6000/3080                        linux/x86_64  Up      -                     deploy/tiproxy-6000

Status列目では、 UpまたはDown使用して、サービスが正常に実行されているかどうかを示します。

PDコンポーネントの場合、 UpまたはDownに|Lまたは|UI追加されることがあります。 |L PD ノードがLeaderであることを示し、 |UI TiDBダッシュボード PD ノードで実行されていることを示します。

クラスターのスケールイン

注記：
このセクションでは、スケールインコマンドの構文についてのみ説明します。オンラインスケーリングの詳細な手順については、 TiUP を使用して TiDBクラスタをスケールするを参照してください。

クラスターのスケーリングとは、一部のノードをオフラインにすることを意味します。この操作により、特定のノードがクラスターから削除され、残りのファイルが削除されます。

TiKV およびTiFlashコンポーネントのオフラインプロセスは非同期 (API 経由でノードを削除する必要がある) であり、プロセスに時間がかかる (ノードが正常にオフラインになったかどうかを継続的に監視する必要がある) ため、TiKV およびTiFlashコンポーネントには特別な処理が行われます。

TiKV およびTiFlashの場合:
- TiUPクラスターは API を介してノードをオフラインにし、プロセスが完了するのを待たずにすぐに終了します。
- その後、クラスター操作に関連するコマンドが実行されると、 TiUPクラスターはオフラインになった TiKV またはTiFlashノードがあるかどうかを調べます。ない場合、 TiUPクラスターは指定された操作を続行します。ある場合、 TiUPクラスターは次の手順を実行します。
  1. オフラインになったノードのサービスを停止します。
  2. ノードに関連するデータファイルをクリーンアップします。
  3. クラスタートポロジからノードを削除します。
その他のコンポーネントの場合:
- PDコンポーネントを停止する場合、 TiUPクラスターは API を介して指定されたノードをクラスターからすばやく削除し、指定された PD ノードのサービスを停止し、関連するデータファイルを削除します。
- 他のコンポーネントを停止する場合、 TiUPクラスターはノードサービスを直接停止し、関連するデータファイルを削除します。

スケールインコマンドの基本的な使用方法:

tiup cluster scale-in <cluster-name> -N <node-id>

このコマンドを使用するには、クラスター名とノード ID の少なくとも 2 つのフラグを指定する必要があります。ノード ID は、前のセクションのtiup cluster displayコマンドを使用して取得できます。

たとえば、TiKV ノード172.16.5.140をオフラインにするには、次のコマンドを実行します。

tiup cluster scale-in prod-cluster -N 172.16.5.140:20160

tiup cluster display実行すると、TiKV ノードがOfflineマークされていることがわかります。

tiup cluster display prod-cluster

Starting /root/.tiup/components/cluster/v1.12.3/cluster display prod-cluster
TiDB Cluster: prod-cluster
TiDB Version: v8.5.0
ID                  Role        Host          Ports                            OS/Arch       Status   Data Dir              Deploy Dir
--                  ----        ----          -----                            -------       ------   --------              ----------
172.16.5.134:3000   grafana     172.16.5.134  3000                             linux/x86_64  Up       -                     deploy/grafana-3000
172.16.5.134:2379   pd          172.16.5.134  2379/2380                        linux/x86_64  Up|L     data/pd-2379          deploy/pd-2379
172.16.5.139:2379   pd          172.16.5.139  2379/2380                        linux/x86_64  Up|UI    data/pd-2379          deploy/pd-2379
172.16.5.140:2379   pd          172.16.5.140  2379/2380                        linux/x86_64  Up       data/pd-2379          deploy/pd-2379
172.16.5.134:9090   prometheus  172.16.5.134  9090                             linux/x86_64  Up       data/prometheus-9090  deploy/prometheus-9090
172.16.5.134:4000   tidb        172.16.5.134  4000/10080                       linux/x86_64  Up       -                     deploy/tidb-4000
172.16.5.139:4000   tidb        172.16.5.139  4000/10080                       linux/x86_64  Up       -                     deploy/tidb-4000
172.16.5.140:4000   tidb        172.16.5.140  4000/10080                       linux/x86_64  Up       -                     deploy/tidb-4000
172.16.5.141:9000   tiflash     172.16.5.141  9000/8123/3930/20170/20292/8234  linux/x86_64  Up       data/tiflash-9000     deploy/tiflash-9000
172.16.5.142:9000   tiflash     172.16.5.142  9000/8123/3930/20170/20292/8234  linux/x86_64  Up       data/tiflash-9000     deploy/tiflash-9000
172.16.5.143:9000   tiflash     172.16.5.143  9000/8123/3930/20170/20292/8234  linux/x86_64  Up       data/tiflash-9000     deploy/tiflash-9000
172.16.5.134:20160  tikv        172.16.5.134  20160/20180                      linux/x86_64  Up       data/tikv-20160       deploy/tikv-20160
172.16.5.139:20160  tikv        172.16.5.139  20160/20180                      linux/x86_64  Up       data/tikv-20160       deploy/tikv-20160
172.16.5.140:20160  tikv        172.16.5.140  20160/20180                      linux/x86_64  Offline  data/tikv-20160       deploy/tikv-20160
172.16.5.144:6000   tiproxy     172.16.5.144  6000/3080                        linux/x86_64  Up       -                     deploy/tiproxy-6000

PD がノード上のデータを他の TiKV ノードにスケジュールすると、このノードは自動的に削除されます。

クラスターをスケールアウトする

注記：
このセクションでは、スケールアウトコマンドの構文についてのみ説明します。オンラインスケーリングの詳細な手順については、 TiUP を使用して TiDBクラスタをスケールするを参照してください。

スケールアウト操作には、TiUPと同様の内部ロジックがあります。TiUP クラスターコンポーネントは、まずノードの SSH 接続を確認し、ターゲットノードに必要なディレクトリを作成してから、デプロイメント操作を実行し、ノードサービスを開始します。

PD をスケールアウトすると、ノードがjoinクラスターに追加され、PD に関連付けられているサービスの構成が更新されます。他のサービスをスケールアウトすると、サービスが直接起動され、クラスターに追加されます。

すべてのサービスは、スケールアウト時に正確性の検証を実行します。検証結果には、スケールアウトが成功したかどうかが表示されます。

tidb-testクラスターに TiKV ノードと PD ノードを追加するには、次の手順を実行します。

scale.yamlファイルを作成し、新しい TiKV ノードと PD ノードの IP を追加します。
注記：
既存のノードではなく、新しいノードの説明のみを含むトポロジファイルを作成する必要があります。
```
---

pd_servers:
  - host: 172.16.5.140

tikv_servers:
  - host: 172.16.5.140
```
スケールアウト操作を実行します。TiUP クラスターは、 scale.yamlで説明したポート、ディレクトリ、およびその他の情報に従って、対応するノードをクラスターに追加します。
```
tiup cluster scale-out tidb-test scale.yaml
```
コマンドを実行した後、 tiup cluster display tidb-test実行してスケールアウトされたクラスターのステータスを確認できます。

ローリングアップグレード

注記：
このセクションでは、アップグレードコマンドの構文についてのみ説明します。オンラインアップグレードの詳細な手順については、 TiUP を使用して TiDB をアップグレードするを参照してください。

ローリングアップグレード機能は、TiDB の分散機能を活用します。アップグレードプロセスはアプリケーションに対して可能な限り透過的に行われるため、ビジネスには影響しません。

アップグレードの前に、 TiUPクラスターは各コンポーネントの構成ファイルが妥当かどうかを確認します。妥当であれば、コンポーネントはノードごとにアップグレードされます。妥当でない場合、 TiUP はエラーを報告して終了します。操作はノードによって異なります。

異なるノードに対する操作

PDノードをアップグレードする
- まず、リーダー以外のノードをアップグレードします。
- リーダー以外のノードがすべてアップグレードされたら、Leaderノードをアップグレードします。
  - アップグレードツールは、Leaderをすでにアップグレードされたノードに移行するコマンドを PD に送信します。
  - Leaderの役割が別のノードに切り替えられたら、以前のLeaderノードをアップグレードします。
- アップグレード中に、異常なノードが検出されると、ツールはこのアップグレード操作を停止して終了します。手動で原因を分析し、問題を修正して、アップグレードを再度実行する必要があります。
TiKVノードをアップグレードする
- まず、この TiKV ノードのリージョンLeaderを移行するスケジュール操作を PD に追加します。これにより、アップグレードプロセスがビジネスに影響を与えないことが保証されます。
- Leaderが移行されたら、この TiKV ノードをアップグレードします。
- アップグレードした TiKV が正常に起動したら、Leaderのスケジュールを削除します。
他のサービスをアップグレードする
- サービスを通常どおり停止し、ノードを更新します。

アップグレードコマンド

アップグレードコマンドのフラグは次のとおりです。

Usage:
  cluster upgrade <cluster-name> <version> [flags]

Flags:
      --force                  Force upgrade won't transfer leader
  -h, --help                   help for upgrade
      --transfer-timeout int   Timeout in seconds when transferring PD and TiKV store leaders (default 600)

Global Flags:
      --ssh string          (Experimental) The executor type. Optional values are 'builtin', 'system', and 'none'.
      --wait-timeout int  Timeout of waiting the operation
      --ssh-timeout int   Timeout in seconds to connect host via SSH, ignored for operations that don't need an SSH connection. (default 5)
  -y, --yes               Skip all confirmations and assumes 'yes'

たとえば、次のコマンドはクラスターを v8.5.0 にアップグレードします。

tiup cluster upgrade tidb-test v8.5.0

構成の更新

コンポーネント構成を動的に更新する場合、 TiUPクラスターコンポーネントは各クラスターの現在の構成を保存します。この構成を編集するには、 tiup cluster edit-config <cluster-name>コマンドを実行します。例:

tiup cluster edit-config prod-cluster

TiUPクラスターは、 vi エディターで設定ファイルを開きます。他のエディターを使用する場合は、 EDITOR環境変数を使用して、 export EDITOR=nanoなどのエディターをカスタマイズします。

ファイルを編集したら、変更を保存します。新しい構成をクラスターに適用するには、次のコマンドを実行します。

tiup cluster reload prod-cluster

このコマンドは、構成をターゲットマシンに送信し、クラスターを再起動して構成を有効にします。

注記：
監視コンポーネントの場合は、 tiup cluster edit-configコマンドを実行して対応するインスタンスにカスタム構成パスを追加し、構成をカスタマイズします。例:

---

grafana_servers:
  - host: 172.16.5.134
    dashboard_dir: /path/to/local/dashboards/dir

monitoring_servers:
  - host: 172.16.5.134
    rule_dir: /path/to/local/rules/dir

alertmanager_servers:
  - host: 172.16.5.134
    config_file: /path/to/local/alertmanager.yml

指定されたパスの下にあるファイルの内容と形式の要件は次のとおりです。

grafana_serversのdashboard_dirフィールドに指定されたフォルダーには、 *.jsonファイルがすべて含まれている必要があります。
monitoring_serversのrule_dirフィールドに指定されたフォルダーには、 *.rules.ymlファイルがすべて含まれている必要があります。
alertmanager_serversのconfig_file欄に指定するファイルの形式についてはAlertmanager 構成テンプレートを参照してください。

tiup reload実行すると、 TiUP はまずターゲットマシンの古い構成ファイルをすべて削除し、次にコントロールマシンからターゲットマシンの対応する構成ディレクトリに該当する構成をアップロードします。したがって、特定の構成ファイルを変更する場合は、すべての構成ファイル (変更されていないものも含む) が同じディレクトリにあることを確認してください。たとえば、Grafana のtidb.jsonファイルを変更するには、まず Grafana のdashboardsディレクトリから*.jsonファイルすべてをローカルディレクトリにコピーする必要があります。そうしないと、ターゲットマシンから他の JSON ファイルが失われます。

注記：
dashboard_dirフィールドをgrafana_serversに設定した場合、 tiup cluster renameコマンドを実行してクラスターの名前を変更した後、次の操作を完了する必要があります。
ローカルdashboardsディレクトリで、クラスター名を新しいクラスター名に変更します。
ローカルのdashboardsディレクトリで、 datasourceクラスター名にちなんで命名されているため、 datasource新しいクラスター名に変更します。
tiup cluster reload -R grafanaコマンドを実行します。

コンポーネントの更新

通常のアップグレードでは、 upgradeコマンドを使用できます。ただし、デバッグなどの一部のシナリオでは、現在実行中のコンポーネントを一時パッケージに置き換える必要がある場合があります。これを実現するには、 patchコマンドを使用します。

tiup cluster patch --help

Replace the remote package with a specified package and restart the service

Usage:
  cluster patch <cluster-name> <package-path> [flags]

Flags:
  -h, --help                    help for patch
  -N, --node strings            Specify the nodes
      --offline                 Patch a stopped cluster
      --overwrite               Use this package in the future scale-out operations
  -R, --role strings            Specify the roles
      --transfer-timeout uint   Timeout in seconds when transferring PD and TiKV store leaders, also for TiCDC drain one capture (default 600)

Global Flags:
  -c, --concurrency int     max number of parallel tasks allowed (default 5)
      --format string       (EXPERIMENTAL) The format of output, available values are [default, json] (default "default")
      --ssh string          (EXPERIMENTAL) The executor type: 'builtin', 'system', 'none'.
      --ssh-timeout uint    Timeout in seconds to connect host via SSH, ignored for operations that don't need an SSH connection. (default 5)
      --wait-timeout uint   Timeout in seconds to wait for an operation to complete, ignored for operations that don't fit. (default 120)
  -y, --yes                 Skip all confirmations and assumes 'yes'

TiDB ホットフィックスパッケージが/tmp/tidb-hotfix.tar.gzにあり、クラスター内のすべての TiDB パッケージを置き換える場合は、次のコマンドを実行します。

tiup cluster patch test-cluster /tmp/tidb-hotfix.tar.gz -R tidb

クラスター内の 1 つの TiDB パッケージのみを置き換えることもできます。

tiup cluster patch test-cluster /tmp/tidb-hotfix.tar.gz -N 172.16.4.5:4000

TiDB Ansible クラスターをインポートする

注記：
現在、 TiUPクラスターの TiSpark のサポートはまだ実験的です。TiSpark が有効になっている TiDB クラスターのインポートはサポートされていません。

TiUPがリリースされる前は、TiDB クラスターのデプロイに TiDB Ansible がよく使用されていました。TiDB Ansible によってデプロイされたクラスターをTiUP が引き継げるようにするには、 importコマンドを使用します。

importコマンドの使用方法は次のとおりです。

tiup cluster import --help

Import an exist TiDB cluster from TiDB-Ansible

Usage:
  cluster import [flags]

Flags:
  -d, --dir string         The path to TiDB-Ansible directory
  -h, --help               help for import
      --inventory string   The name of inventory file (default "inventory.ini")
      --no-backup          Don't backup ansible dir, useful when there're multiple inventory files
  -r, --rename NAME        Rename the imported cluster to NAME

Global Flags:
      --ssh string        (Experimental) The executor type. Optional values are 'builtin', 'system', and 'none'.
      --wait-timeout int  Timeout of waiting the operation
      --ssh-timeout int   Timeout in seconds to connect host via SSH, ignored for operations that don't need an SSH connection. (default 5)
  -y, --yes               Skip all confirmations and assumes 'yes'

次のいずれかのコマンドを使用して、TiDB Ansible クラスターをインポートできます。

cd tidb-ansible
tiup cluster import

tiup cluster import --dir=/path/to/tidb-ansible

操作ログをビュー

操作ログを表示するには、 auditコマンドを使用します。3 コマンドの使用方法は次のauditです。

Usage:
  tiup cluster audit [audit-id] [flags]

Flags:
  -h, --help   help for audit

[audit-id]フラグが指定されていない場合、コマンドは実行されたコマンドのリストを表示します。例:

tiup cluster audit

Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.12.3/cluster audit
ID      Time                       Command
--      ----                       -------
4BLhr0  2024-12-05T23:55:09+08:00  /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.5.0 /tmp/topology.yaml
4BKWjF  2024-12-05T23:36:57+08:00  /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.5.0 /tmp/topology.yaml
4BKVwH  2024-12-05T23:02:08+08:00  /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.5.0 /tmp/topology.yaml
4BKKH1  2024-12-05T16:39:04+08:00  /home/tidb/.tiup/components/cluster/v1.12.3/cluster destroy test
4BKKDx  2024-12-05T16:36:57+08:00  /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.5.0 /tmp/topology.yaml

最初の列はaudit-idです。特定のコマンドの実行ログを表示するには、次のようにコマンドのaudit-idフラグとして渡します。

tiup cluster audit 4BLhr0

TiDBクラスタ内のホストでコマンドを実行する

TiDB クラスター内のホストでコマンドを実行するには、 execコマンドを使用します。3 execの使用方法は次のとおりです。

Usage:
  cluster exec <cluster-name> [flags]

Flags:
      --command string   the command run on cluster host (default "ls")
  -h, --help             help for exec
  -N, --node strings     Only exec on host with specified nodes
  -R, --role strings     Only exec on host with specified roles
      --sudo             use root permissions (default false)

Global Flags:
      --ssh-timeout int   Timeout in seconds to connect host via SSH, ignored for operations that don't need an SSH connection. (default 5)
  -y, --yes               Skip all confirmations and assumes 'yes'

たとえば、すべての TiDB ノードでls /tmp実行するには、次のコマンドを実行します。

tiup cluster exec test-cluster --command='ls /tmp'

クラスタコントローラー

TiUPがリリースされる前は、 tidb-ctl 、 tikv-ctl 、 pd-ctlなどのツールを使用してクラスターを制御できます。ツールを簡単にダウンロードして使用できるようにするために、 TiUPそれらをオールインワンコンポーネントctlに統合しています。

Usage:
  tiup ctl:v<CLUSTER_VERSION> {tidb/pd/tikv/etcd} [flags]

Flags:
  -h, --help   help for tiup

このコマンドは、以前のツールのコマンドと対応関係があります。

tidb-ctl [args] = tiup ctl tidb [args]
pd-ctl [args] = tiup ctl pd [args]
tikv-ctl [args] = tiup ctl tikv [args]
etcdctl [args] = tiup ctl etcd [args]

たとえば、以前にpd-ctl -u http://127.0.0.1:2379 store実行してストアを表示していた場合、今度はTiUPで次のコマンドを実行できます。

tiup ctl:v<CLUSTER_VERSION> pd -u http://127.0.0.1:2379 store

対象マシンの環境チェック

checkコマンドを使用すると、ターゲットマシンの環境に対して一連のチェックを実行し、チェック結果を出力できますcheckコマンドを実行すると、よくある不合理な構成やサポートされていない状況を見つけることができます。コマンドフラグリストは次のとおりです。

Usage:
  tiup cluster check <topology.yml | cluster-name> [flags]
Flags:
      --apply                  Try to fix failed checks
      --cluster                Check existing cluster, the input is a cluster name.
      --enable-cpu             Enable CPU thread count check
      --enable-disk            Enable disk IO (fio) check
      --enable-mem             Enable memory size check
  -h, --help                   help for check
  -i, --identity_file string   The path of the SSH identity file. If specified, public key authentication will be used.
  -p, --password               Use password of target hosts. If specified, password authentication will be used.
      --user string            The user name to login via SSH. The user must has root (or sudo) privilege.

デフォルトでは、このコマンドはデプロイメント前に環境を確認するために使用されます。モードを切り替える--clusterフラグを指定すると、既存のクラスターのターゲットマシンも確認できるようになります。例:

# check deployed servers before deployment
tiup cluster check topology.yml --user tidb -p
# check deployed servers of an existing cluster
tiup cluster check <cluster-name> --cluster

CPU スレッド数チェック、メモリサイズチェック、およびディスクパフォーマンスチェックは、デフォルトでは無効になっています。本番環境では、最高のパフォーマンスを得るために、3 つのチェックを有効にして、チェックに合格することを確認することをお勧めします。

CPU: スレッド数が 16 以上の場合、チェックに合格します。
メモリ: 物理メモリの合計サイズが 32 GB 以上の場合、チェックは合格です。
ディスク: data_dirのパーティションに対してfioテストを実行し、結果を記録します。

チェックを実行するときに、フラグ--applyが指定されている場合、プログラムは失敗した項目を自動的に修復します。自動修復は、構成またはシステムパラメータを変更することで調整できる一部の項目に限定されます。修復されていないその他の項目は、実際の状況に応じて手動で処理する必要があります。

環境チェックは、クラスターのデプロイには必要ありません。本番環境では、デプロイ前に環境チェックを実行し、すべてのチェック項目に合格することをお勧めします。すべてのチェック項目に合格していない場合、クラスターはデプロイされ、正常に実行される可能性がありますが、最高のパフォーマンスが得られない可能性があります。

システムのネイティブSSHクライアントを使用してクラスタに接続する

クラスターマシンで実行される上記のすべての操作では、 TiUPに組み込まれた SSH クライアントを使用してクラスターに接続し、コマンドを実行します。ただし、シナリオによっては、このようなクラスター操作を実行するために、制御マシンシステムにネイティブの SSH クライアントも使用する必要がある場合もあります。例:

認証にSSHプラグインを使用するには
カスタマイズされたSSHクライアントを使用するには

次に、 --ssh=systemコマンドラインフラグを使用して、システムネイティブコマンドラインツールを有効にします。

クラスターをデプロイ: tiup cluster deploy <cluster-name> <version> <topo> --ssh=system <cluster-name>にクラスターの名前、 <version>にデプロイする TiDB バージョン ( v8.5.0など)、 <topo>にトポロジファイルを入力します。
クラスターを開始する: tiup cluster start <cluster-name> --ssh=system
クラスターのアップグレード: tiup cluster upgrade ... --ssh=system

上記のすべてのクラスター操作コマンドに--ssh=system追加すると、システムのネイティブ SSH クライアントを使用できます。

すべてのコマンドにこのようなフラグを追加しないようにするには、 TIUP_NATIVE_SSHシステム変数を使用して、ローカル SSH クライアントを使用するかどうかを指定します。

export TIUP_NATIVE_SSH=true
# or
export TIUP_NATIVE_SSH=1
# or
export TIUP_NATIVE_SSH=enable

この環境変数と--ssh同時に指定した場合、 --ssh優先されます。

注記：
クラスターの展開プロセス中に、接続にパスワードを使用する必要がある場合 ( -p ) またはpassphraseキーファイルに構成されている場合は、制御マシンにsshpassがインストールされていることを確認する必要があります。そうでない場合、タイムアウトエラーが報告されます。

制御マシンを移行し、 TiUPデータをバックアップする

TiUPデータは、ユーザーのホームディレクトリの.tiupディレクトリに保存されます。コントロールマシンを移行するには、次の手順を実行して、 .tiupディレクトリを対応するターゲットマシンにコピーします。

元のマシンのホームディレクトリでtar czvf tiup.tar.gz .tiup実行します。
tiup.tar.gzターゲットマシンのホームディレクトリにコピーします。
対象マシンのホームディレクトリでtar xzvf tiup.tar.gz実行します。
.tiupディレクトリをPATH環境変数に追加します。
bash使用していて、ユーザーがtidb場合、 ~/.bashrcにexport PATH=/home/tidb/.tiup/bin:$PATHを追加してsource ~/.bashrc実行します。その後、使用するシェルとユーザーに応じて対応する調整を行います。

注記：
制御マシンのディスク損傷などの異常な状況によってTiUPデータが失われるのを避けるために、 .tiupディレクトリを定期的にバックアップすることをお勧めします。

クラスタの展開とO&Mのためのメタファイルのバックアップと復元

運用および保守 (O&M) に使用されるメタファイルが失われると、 TiUP を使用したクラスターの管理が失敗します。次のコマンドを実行して、メタファイルを定期的にバックアップすることをお勧めします。

tiup cluster meta backup ${cluster_name}

メタファイルが失われた場合は、次のコマンドを実行して復元できます。

tiup cluster meta restore ${cluster_name} ${backup_file}

注記：
復元操作により、現在のメタファイルが上書きされます。したがって、メタファイルは失われた場合にのみ復元することをお勧めします。