TiUPを使用したオンラインTiDBクラスターのデプロイと管理
このドキュメントでは、TiUPクラスタコンポーネントの使用方法に焦点を当てています。オンライン展開の完全な手順については、 TiUPを使用してTiDBクラスターをデプロイするを参照してください。
ローカルテスト展開に使用されるTiUPプレイグラウンドコンポーネントと同様に、TiUPクラスタコンポーネントは本番環境にTiDBを迅速に展開します。遊び場と比較して、クラスタコンポーネントは、アップグレード、スケーリング、さらには運用と監査を含む、より強力な本番クラスタ管理機能を提供します。
クラスタコンポーネントのヘルプ情報については、次のコマンドを実行してください。
tiup cluster
Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.9.0/cluster
Deploy a TiDB cluster for production
Usage:
cluster [flags]
cluster [command]
Available Commands:
check Perform preflight checks for the 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
clean Clean up cluster data
destroy Destroy a specified cluster
upgrade Upgrade a specified TiDB cluster
exec Run shell command on host in the tidb cluster
display Display information of a TiDB cluster
list List all clusters
audit Show audit log of cluster operation
import Import an exist 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:
-h, --help help for cluster
--native-ssh Use the system's native SSH client
--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'
クラスタをデプロイする
クラスタをデプロイするには、 tiup cluster deployコマンドを実行します。コマンドの使用法は次のとおりです。
tiup cluster deploy <cluster-name> <version> <topology.yaml> [flags]
このコマンドでは、クラスタ名、TiDBクラスタのバージョン、およびクラスタのトポロジーファイルを指定する必要があります。
トポロジーファイルを作成するには、 例を参照してください。次のファイルは、最も単純なトポロジの例です。
ノート：
TiUPクラスタコンポーネントが展開とスケーリングに使用するトポロジファイルは、 yamlの構文を使用して記述されているため、インデントが正しいことを確認してください。
---
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
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 v5.4.2を使用する場合で、クラスタ名がprod-clusterの場合は、次のコマンドを実行します。
tiup cluster deploy -p prod-cluster v5.4.2 /tmp/topology.yaml
実行中に、TiUPはトポロジを再度確認するように要求し、ターゲットマシンのルートパスワードを要求します（ -pフラグはパスワードの入力を意味します）。
Please confirm your topology:
TiDB Cluster: prod-cluster
TiDB Version: v5.4.2
Type Host Ports Directories
---- ---- ----- -----------
pd 172.16.5.134 2379/2380 deploy/pd-2379,data/pd-2379
pd 172.16.5.139 2379/2380 deploy/pd-2379,data/pd-2379
pd 172.16.5.140 2379/2380 deploy/pd-2379,data/pd-2379
tikv 172.16.5.134 20160/20180 deploy/tikv-20160,data/tikv-20160
tikv 172.16.5.139 20160/20180 deploy/tikv-20160,data/tikv-20160
tikv 172.16.5.140 20160/20180 deploy/tikv-20160,data/tikv-20160
tidb 172.16.5.134 4000/10080 deploy/tidb-4000
tidb 172.16.5.139 4000/10080 deploy/tidb-4000
tidb 172.16.5.140 4000/10080 deploy/tidb-4000
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.9.0/cluster list
Name User Version Path PrivateKey
---- ---- ------- ---- ----------
prod-cluster tidb v5.4.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は、クラスタの各コンポーネントのステータスを表示するためのtiup cluster displayのコマンドを提供します。このコマンドを使用すると、コンポーネントのステータスを確認するために各マシンにログインする必要はありません。コマンドの使用法は次のとおりです。
tiup cluster display prod-cluster
Starting /root/.tiup/components/cluster/v1.9.0/cluster display prod-cluster
TiDB Cluster: prod-cluster
TiDB Version: v5.4.2
ID Role Host Ports Status Data Dir Deploy Dir
-- ---- ---- ----- ------ -------- ----------
172.16.5.134:3000 grafana 172.16.5.134 3000 Up - deploy/grafana-3000
172.16.5.134:2379 pd 172.16.5.134 2379/2380 Up|L data/pd-2379 deploy/pd-2379
172.16.5.139:2379 pd 172.16.5.139 2379/2380 Up|UI data/pd-2379 deploy/pd-2379
172.16.5.140:2379 pd 172.16.5.140 2379/2380 Up data/pd-2379 deploy/pd-2379
172.16.5.134:9090 prometheus 172.16.5.134 9090 Up data/prometheus-9090 deploy/prometheus-9090
172.16.5.134:4000 tidb 172.16.5.134 4000/10080 Up - deploy/tidb-4000
172.16.5.139:4000 tidb 172.16.5.139 4000/10080 Up - deploy/tidb-4000
172.16.5.140:4000 tidb 172.16.5.140 4000/10080 Up - deploy/tidb-4000
172.16.5.134:20160 tikv 172.16.5.134 20160/20180 Up data/tikv-20160 deploy/tikv-20160
172.16.5.139:20160 tikv 172.16.5.139 20160/20180 Up data/tikv-20160 deploy/tikv-20160
172.16.5.140:20160 tikv 172.16.5.140 20160/20180 Up data/tikv-20160 deploy/tikv-20160
Status列は、サービスが正常に実行されているかどうかを示すためにUpまたはDownを使用します。
PDコンポーネントの場合、 |Lまたは|UIがUpまたはDownに追加される場合があります。 |LはPDノードがリーダーであることを示し、 |UIはTiDBダッシュボードがPDノードで実行されていることを示します。
クラスタでのスケーリング
ノート：
このセクションでは、scale-inコマンドの構文についてのみ説明します。オンラインスケーリングの詳細な手順については、 TiUPを使用してTiDBクラスターをスケーリングするを参照してください。
クラスタでのスケーリングとは、一部のノードをオフラインにすることを意味します。この操作により、特定のノードがクラスタから削除され、残りのファイルが削除されます。
TiKVおよびTiDBBinlogコンポーネントのオフラインプロセスは非同期であり（APIを介してノードを削除する必要があります）、プロセスに時間がかかるため（ノードが正常にオフラインになるかどうかを継続的に監視する必要があります）、特別な処理が行われます。 TiKVおよびTiDBBinlogコンポーネント。
TiKVおよびBinlogの場合：
TiUPクラスタは、APIを介してノードをオフラインにし、プロセスが完了するのを待たずに直接終了します。
その後、クラスタ操作に関連するコマンドが実行されると、TiUPクラスタはオフラインにされたTiKV/Binlogノードがあるかどうかを調べます。そうでない場合、TiUPクラスタは指定された操作を続行します。存在する場合、TiUPクラスタは次の手順を実行します。
- オフラインになったノードのサービスを停止します。
- ノードに関連するデータファイルをクリーンアップします。
- クラスタトポロジからノードを削除します。
その他のコンポーネントの場合：
- PDコンポーネントを停止すると、TiUPクラスタはAPIを介してクラスタから指定されたノードをすばやく削除し、指定されたPDノードのサービスを停止し、関連するデータファイルを削除します。
- 他のコンポーネントを停止すると、TiUPクラスタはノードサービスを直接停止し、関連するデータファイルを削除します。
スケールインコマンドの基本的な使用法：
tiup cluster scale-in <cluster-name> -N <node-id>
このコマンドを使用するには、クラスタ名とノードIDの少なくとも2つのフラグを指定する必要があります。ノード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.9.0/cluster display prod-cluster
TiDB Cluster: prod-cluster
TiDB Version: v5.4.2
ID Role Host Ports Status Data Dir Deploy Dir
-- ---- ---- ----- ------ -------- ----------
172.16.5.134:3000 grafana 172.16.5.134 3000 Up - deploy/grafana-3000
172.16.5.134:2379 pd 172.16.5.134 2379/2380 Up|L data/pd-2379 deploy/pd-2379
172.16.5.139:2379 pd 172.16.5.139 2379/2380 Up|UI data/pd-2379 deploy/pd-2379
172.16.5.140:2379 pd 172.16.5.140 2379/2380 Up data/pd-2379 deploy/pd-2379
172.16.5.134:9090 prometheus 172.16.5.134 9090 Up data/prometheus-9090 deploy/prometheus-9090
172.16.5.134:4000 tidb 172.16.5.134 4000/10080 Up - deploy/tidb-4000
172.16.5.139:4000 tidb 172.16.5.139 4000/10080 Up - deploy/tidb-4000
172.16.5.140:4000 tidb 172.16.5.140 4000/10080 Up - deploy/tidb-4000
172.16.5.134:20160 tikv 172.16.5.134 20160/20180 Up data/tikv-20160 deploy/tikv-20160
172.16.5.139:20160 tikv 172.16.5.139 20160/20180 Up data/tikv-20160 deploy/tikv-20160
172.16.5.140:20160 tikv 172.16.5.140 20160/20180 Offline data/tikv-20160 deploy/tikv-20160
PDがノード上のデータを他のTiKVノードにスケジュールした後、このノードは自動的に削除されます。
クラスタをスケールアウトする
ノート：
このセクションでは、scale-outコマンドの構文についてのみ説明します。オンラインスケーリングの詳細な手順については、 TiUPを使用してTiDBクラスターをスケーリングするを参照してください。
スケールアウト操作には、展開と同様の内部ロジックがあります。TiUPクラスタコンポーネントは、最初にノードのSSH接続を確認し、ターゲットノードに必要なディレクトリを作成してから、展開操作を実行し、ノードサービスを開始します。
PDをスケールアウトすると、ノードがjoinクラスタに追加され、PDに関連付けられたサービスの構成が更新されます。他のサービスをスケールアウトすると、サービスが直接開始され、クラスタに追加されます。
すべてのサービスは、スケールアウト時に正確性の検証を実行します。検証結果は、スケールアウトが成功したかどうかを示します。
tidb-testのクラスタにTiKVノードとPDノードを追加するには、次の手順を実行します。
scale.yamlのファイルを作成し、新しいTiKVおよびPDノードのIPを追加します。ノート：
トポロジファイルを作成する必要があります。このファイルには、既存のノードではなく、新しいノードの説明のみが含まれています。
--- pd_servers: - ip: 172.16.5.140 tikv_servers: - ip: 172.16.5.140スケールアウト操作を実行します。 TiUPクラスタは、ポート、ディレクトリ、および
scale.yamlで説明されているその他の情報に従って、対応するノードをクラスタに追加します。tiup cluster scale-out tidb-test scale.yamlコマンドの実行後、
tiup cluster display tidb-testを実行することで、スケールアウトされたクラスタのステータスを確認できます。
ローリングアップグレード
ノート：
このセクションでは、upgradeコマンドの構文についてのみ説明します。オンラインアップグレードの詳細な手順については、 TiUPを使用してTiDBをアップグレードするを参照してください。
ローリングアップグレード機能は、TiDBの分散機能を活用します。アップグレードプロセスは、アプリケーションに対して可能な限り透過的に行われ、ビジネスに影響を与えません。
アップグレードの前に、TiUPクラスタは各コンポーネントの構成ファイルが妥当であるかどうかをチェックします。その場合、コンポーネントはノードごとにアップグレードされます。そうでない場合、TiUPはエラーを報告して終了します。操作はノードによって異なります。
さまざまなノードの操作
PDノードをアップグレードします
- まず、非リーダーノードをアップグレードします。
- すべての非リーダーノードがアップグレードされたら、リーダーノードをアップグレードします。
- アップグレードツールは、リーダーをすでにアップグレードされたノードに移行するコマンドをPDに送信します。
- リーダーの役割が別のノードに切り替えられたら、前のリーダーノードをアップグレードします。
- アップグレード中に、異常なノードが検出された場合、ツールはこのアップグレード操作を停止して終了します。原因を手動で分析し、問題を修正して、アップグレードを再実行する必要があります。
TiKVノードをアップグレードします
- まず、このTiKVノードのリージョンリーダーを移行するスケジューリング操作をPDに追加します。これにより、アップグレードプロセスがビジネスに影響を与えないことが保証されます。
- リーダーが移行されたら、このTiKVノードをアップグレードします。
- アップグレードされたTiKVが正常に開始されたら、リーダーのスケジュールを削除します。
他のサービスをアップグレードする
- サービスを正常に停止し、ノードを更新します。
アップグレードコマンド
upgradeコマンドのフラグは次のとおりです。
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 300)
Global Flags:
--native-ssh Use the system's native SSH client
--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'
たとえば、次のコマンドはクラスタをv5.4.2にアップグレードします。
tiup cluster upgrade tidb-test v5.4.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ファイルを変更するには、最初に*.jsonのファイルすべてをGrafanaのdashboardsディレクトリからローカルディレクトリにコピーする必要があります。そうしないと、他のJSONファイルがターゲットマシンから失われます。
ノート：
grafana_serversのdashboard_dirフィールドを構成した場合は、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
--overwrite Use this package in the future scale-out operations
-R, --role strings Specify the role
--transfer-timeout int Timeout in seconds when transferring PD and TiKV store leaders (default 300)
Global Flags:
--native-ssh Use the system's native SSH client
--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ホットフィックスパッケージが/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
TiDBAnsibleクラスタをインポートする
ノート：
現在、TiSparkに対するTiUPクラスターのサポートはまだ実験的段階です。 TiSparkが有効になっているTiDBクラスタのインポートはサポートされていません。
TiUPがリリースされる前は、TiDBAnsibleを使用してTiDBクラスターをデプロイすることがよくあります。 TiUPがTiDBAnsibleによってデプロイされたクラスタを引き継ぐことができるようにするには、 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:
--native-ssh Use the system's native SSH client
--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'
次のいずれかのコマンドを使用して、TiDBAnsibleクラスタをインポートできます。
cd tidb-ansible
tiup cluster import
tiup cluster import --dir=/path/to/tidb-ansible
操作ログを表示する
操作ログを表示するには、 auditコマンドを使用します。 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.9.0/cluster audit
ID Time Command
-- ---- -------
4BLhr0 2022-07-08T13:25:09+08:00 /home/tidb/.tiup/components/cluster/v1.9.0/cluster deploy test v5.4.2 /tmp/topology.yaml
4BKWjF 2022-07-08T23:36:57+08:00 /home/tidb/.tiup/components/cluster/v1.9.0/cluster deploy test v5.4.2 /tmp/topology.yaml
4BKVwH 2022-07-08T23:02:08+08:00 /home/tidb/.tiup/components/cluster/v1.9.0/cluster deploy test v5.4.2 /tmp/topology.yaml
4BKKH1 2022-07-08T16:39:04+08:00 /home/tidb/.tiup/components/cluster/v1.9.0/cluster destroy test
4BKKDx 2022-07-08T16:36:57+08:00 /home/tidb/.tiup/components/cluster/v1.9.0/cluster deploy test v5.4.2 /tmp/topology.yaml
最初の列はaudit-idです。特定のコマンドの実行ログを表示するには、次のようにコマンドのaudit-idをフラグとして渡します。
tiup cluster audit 4BLhr0
TiDBクラスタのホストでコマンドを実行する
TiDBクラスタのホストでコマンドを実行するには、 execコマンドを使用します。 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'
クラスターコントローラー
tikv-ctlがリリースされる前は、 tidb-ctl 、およびその他のツールを使用してクラスタを制御できpd-ctl 。ツールのダウンロードと使用を容易にするために、TiUPはツールをオールインワンコンポーネントに統合しますctl 。
Usage:
tiup ctl {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 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クライアントを使用するには
次に、 --native-sshコマンドラインフラグを使用して、システムネイティブのコマンドラインツールを有効にします。
- クラスタのデプロイ：
tiup cluster deploy <cluster-name> <version> <topo> --native-ssh - クラスタを開始します：
tiup cluster start <cluster-name> --native-ssh - クラスタのアップグレード：
tiup cluster upgrade ... --native-ssh
上記のすべてのクラスタ操作コマンドに--native-sshを追加して、システムのネイティブSSHクライアントを使用できます。
すべてのコマンドにこのようなフラグが追加されないようにするには、 TIUP_NATIVE_SSHシステム変数を使用して、ローカルSSHクライアントを使用するかどうかを指定できます。
export TIUP_NATIVE_SSH=true
# or
export TIUP_NATIVE_SSH=1
# or
export TIUP_NATIVE_SSH=enable
この環境変数と--native-sshを同時に指定すると、 --native-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のディレクトリを定期的にバックアップすることをお勧めします。