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 クラスターのバージョン ( v7.5.1など)、およびクラスターのトポロジー ファイルを指定する必要があります。

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

注記:

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 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 v7.5.1 を使用する場合で、クラスター名がprod-cluster場合は、次のコマンドを実行します。

tiup cluster deploy -p prod-cluster v7.5.1 /tmp/topology.yaml

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

Please confirm your topology: TiDB Cluster: prod-cluster TiDB Version: v7.5.1 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 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 v7.5.1 /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: v7.5.1 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

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

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

クラスタースケールイン

注記:

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

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

TiKV、 TiFlash、および TiDB Binlogコンポーネントのオフライン プロセスは非同期であり (API を介してノードを削除する必要がある)、プロセスに時間がかかるため (ノードが正常にオフラインになったかどうかを継続的に観察する必要がある)、特別な処理が必要になります。 TiKV、 TiFlash、TiDB Binlogコンポーネントに与えられます。

  • TiKV、 TiFlash、およびBinlogの場合:

    • TiUPクラスターは API を通じてノードをオフラインにし、プロセスの完了を待たずに直接終了します。

    • その後、クラスター操作に関連するコマンドが実行されると、 TiUPクラスターは、オフラインになった TiKV、 TiFlash、またはBinlogノードが存在するかどうかを調べます。そうでない場合、 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コマンドを使用して取得できます。

たとえば、 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: v7.5.1 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

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

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

注記:

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

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

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

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

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

  1. scale.yamlファイルを作成し、新しい TiKV ノードと PD ノードの IP を追加します。

    注記:

    トポロジ ファイルを作成する必要があります。このファイルには、既存のノードではなく、新しいノードの説明のみが含まれます。

    --- pd_servers: - host: 172.16.5.140 tikv_servers: - host: 172.16.5.140
  2. スケールアウト操作を実行します。 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'

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

tiup cluster upgrade tidb-test v7.5.1

構成を更新する

コンポーネント構成を動的に更新する場合、 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_serversdashboard_dirフィールドで指定されたフォルダーには、 *.jsonファイルがすべて含まれている必要があります。
  • monitoring_serversrule_dirフィールドで指定されたフォルダーには、 *.rules.ymlファイルがすべて含まれている必要があります。
  • alertmanager_serversconfig_fileフィールドで指定するファイルの形式については、 Alertmanager 構成テンプレートを参照してください。

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

注記:

dashboard_dirフィールドをgrafana_serversに設定した場合は、 tiup cluster renameコマンドを実行してクラスターの名前を変更した後、次の操作を完了する必要があります。

  1. ローカルdashboardsディレクトリで、クラスター名を新しいクラスター名に変更します。
  2. ローカルdashboardsディレクトリで、 datasourceはクラスター名にちなんで命名されているため、 datasourceを新しいクラスター名に変更します。
  3. 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 [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

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

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

TiDB Ansible クラスターのインポート

注記:

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

TiUPがリリースされる前は、TiDB Ansible が TiDB クラスターのデプロイによく使用されていました。 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コマンドを使用します。 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-02-29T23:55:09+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v7.5.1 /tmp/topology.yaml 4BKWjF 2024-02-29T23:36:57+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v7.5.1 /tmp/topology.yaml 4BKVwH 2024-02-29T23:02:08+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v7.5.1 /tmp/topology.yaml 4BKKH1 2024-02-29T16:39:04+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster destroy test 4BKKDx 2024-02-29T16:36:57+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v7.5.1 /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'

クラスタコントローラー

TiUPがリリースされる前は、 tidb-ctltikv-ctlpd-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 バージョン ( v7.5.1など)、 <topo>にはトポロジ ファイルを入力します。
  • クラスターを開始します: tiup cluster start <cluster-name> --ssh=system
  • クラスターのアップグレード: tiup cluster upgrade ... --ssh=system

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

すべてのコマンドにこのようなフラグを追加しないようにするには、 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対応するターゲット マシンにコピーします。

  1. 元のマシンのホーム ディレクトリでtar czvf tiup.tar.gz .tiupを実行します。

  2. tiup.tar.gzターゲット マシンのホーム ディレクトリにコピーします。

  3. ターゲットマシンのホームディレクトリでtar xzvf tiup.tar.gzを実行します。

  4. .tiupディレクトリをPATH環境変数に追加します。

    bashを使用し、あなたがtidbユーザーである場合は、 ~/.bashrcexport 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}

注記:

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

このページは役に立ちましたか?

Playground
新規
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Cloud
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.