TiUPを使用してオンライン TiDBクラスタをデプロイおよび管理
このドキュメントでは、 TiUPクラスタコンポーネントの使用方法に焦点を当てています。オンライン展開の詳細な手順については、 TiUPを使用して TiDBクラスタをデプロイを参照してください。
ローカルテストデプロイメントで使用されるTiUP遊び場コンポーネントと同様に、 TiUPクラスタコンポーネントは本番環境にTiDBを迅速にデプロイします。Playgroundと比較して、クラスタコンポーネントはアップグレード、スケーリング、さらには運用と監査を含む、より強力な本番クラスタ管理機能を提供します。
クラスターコンポーネントのヘルプ情報を表示するには、次のコマンドを実行します。
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.1.2など)、およびクラスターのトポロジ ファイルを指定する必要があります。
トポロジファイルを作成するには、 例を参照してください。次のファイルは最も単純なトポロジの例です。
注記：
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.1.2 を使用し、クラスター名がprod-cluster場合は、次のコマンドを実行します。
tiup cluster deploy -p prod-cluster v8.1.2 /tmp/topology.yaml
実行中に、 TiUP はトポロジーを再度確認するように要求し、ターゲット マシンのルート パスワードを要求します (フラグ-pはパスワードの入力を意味します)。
Please confirm your topology:
TiDB Cluster: prod-cluster
TiDB Version: v8.1.2
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.1.2 /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.1.2
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コンポーネントの場合、 |Lまたは|UI UpまたはDownに追加されることがあります。 |L PD ノードがLeaderであることを示し、 |UI TiDBダッシュボード PD ノードで実行されていることを示します。
クラスターのスケールイン
注記：
このセクションでは、スケールインコマンドの構文のみを説明します。オンラインスケーリングの詳細な手順については、 TiUPを使用して TiDBクラスタをスケールするを参照してください。
クラスターをスケールインするということは、一部のノードをオフラインにすることを意味します。この操作により、特定のノードがクラスターから削除され、残りのファイルも削除されます。
TiKV、 TiFlash、および TiDB Binlogコンポーネントのオフライン プロセスは非同期 (API 経由でノードを削除する必要がある) であり、プロセスに長い時間がかかる (ノードが正常にオフラインになったかどうかを継続的に監視する必要がある) ため、TiKV、 TiFlash、および TiDB Binlogコンポーネントには特別な処理が行われます。
TiKV、 TiFlash、 Binlogの場合:
TiUPクラスターは API を介してノードをオフラインにし、プロセスが完了するのを待たずにすぐに終了します。
その後、クラスタ操作に関連するコマンドが実行されると、 TiUPクラスタはオフラインになっているTiKV、 TiFlash、またはBinlogノードがあるかどうかを確認します。オフラインになっていない場合、 TiUPクラスタは指定された操作を続行します。オフラインになっている場合、 TiUPクラスタは以下の手順を実行します。
- オフラインになったノードのサービスを停止します。
- ノードに関連するデータ ファイルをクリーンアップします。
- クラスター トポロジからノードを削除します。
その他のコンポーネントの場合:
- PDコンポーネントを停止する場合、 TiUPクラスターは API を介して指定されたノードをクラスターからすばやく削除し、指定された PD ノードのサービスを停止し、関連するデータ ファイルを削除します。
- 他のコンポーネントを停止する場合、 TiUPクラスターはノード サービスを直接停止し、関連するデータ ファイルを削除します。
スケールイン コマンドの基本的な使用法:
tiup cluster scale-in <cluster-name> -N <node-id>
このコマンドを使用するには、少なくとも2つのフラグ（クラスター名とノードID）を指定する必要があります。ノードIDは、前のセクションのtiup cluster displayコマンドを使用して取得できます。
たとえば、 172.16.5.140上の TiKV ノードをオフラインにするには、次のコマンドを実行します。
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.1.2
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クラスタをスケールするを参照してください。
スケールアウト操作にはデプロイメントと同様の内部ロジックがあります。TiUPTiUPコンポーネントは、まずノードの 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スケールアウト操作を実行します。TiUPTiUPは、
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ノードをアップグレードする
- まず、PD に、この TiKV ノードのリージョンLeaderを移行するスケジュール操作を追加します。これにより、アップグレードプロセスがビジネスに影響を与えないことが保証されます。
- 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.1.2 にアップグレードします。
tiup cluster upgrade tidb-test v8.1.2
構成の更新
コンポーネント構成を動的に更新する場合、 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-26T23:55:09+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.1.2 /tmp/topology.yaml
4BKWjF 2024-12-26T23:36:57+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.1.2 /tmp/topology.yaml
4BKVwH 2024-12-26T23:02:08+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.1.2 /tmp/topology.yaml
4BKKH1 2024-12-26T16:39:04+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster destroy test
4BKKDx 2024-12-26T16:36:57+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.1.2 /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/binlog/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]
binlogctl [args] = tiup ctl bindlog [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.1.2など)、<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）に使用するメタファイルが失われると、 TiUPを使用したクラスターの管理が失敗します。以下のコマンドを実行して、メタファイルを定期的にバックアップすることをお勧めします。
tiup cluster meta backup ${cluster_name}
メタ ファイルが失われた場合は、次のコマンドを実行して復元できます。
tiup cluster meta restore ${cluster_name} ${backup_file}
注記：
復元操作により、現在のメタファイルが上書きされます。そのため、メタファイルが失われた場合にのみ復元することをお勧めします。