diff --git a/TOC.md b/TOC.md index 8263d50441982..a0fb9847c551a 100644 --- a/TOC.md +++ b/TOC.md @@ -479,20 +479,20 @@ - [日々のチェック](/dm/dm-daily-check.md) - 参照 - アーキテクチャ - - [DMワーカー](/dm/dm-worker-intro.md) + - [DM-worker](/dm/dm-worker-intro.md) - [セーフモード](/dm/dm-safe-mode.md) - [リレーログ](/dm/relay-log.md) - [DDL処理](/dm/dm-ddl-compatible.md) - 機構 - [DML複製メカニズム](/dm/dm-replication-logic.md) - コマンドライン - - [DMマスター＆DMワーカー](/dm/dm-command-line-flags.md) + - [DM-master＆DM-worker](/dm/dm-command-line-flags.md) - コンフィグレーションファイル - [概要](/dm/dm-config-overview.md) - [上流データベース構成](/dm/dm-source-configuration-file.md) - [タスク構成](/dm/task-configuration-file-full.md) - - [DMマスターコンフィグレーション](/dm/dm-master-configuration-file.md) - - [DMワーカーのコンフィグレーション](/dm/dm-worker-configuration-file.md) + - [DM-masterコンフィグレーション](/dm/dm-master-configuration-file.md) + - [DM-workerのコンフィグレーション](/dm/dm-worker-configuration-file.md) - [テーブルセレクター](/dm/table-selector.md) - [OpenAPI](/dm/dm-open-api.md) - [互換性カタログ](/dm/dm-compatibility-catalog.md) diff --git a/api/_index.md b/api/_index.md index 8ff06db31e9f5..a98b400e8d651 100644 --- a/api/_index.md +++ b/api/_index.md @@ -24,7 +24,7 @@ TiDB Self-Managedは、TiDBツール用のさまざまなAPIを提供し、ク | API | 説明 | | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | [TiProxy API](/tiproxy/tiproxy-api.md) | TiProxyの設定、稼働状況、および監視データにアクセスできます。 | -| [データ移行API](/dm/dm-open-api.md) | DMマスターノードとDMワーカーノード、データソース、およびデータレプリケーションタスクを管理します。 | +| [データ移行API](/dm/dm-open-api.md) | DM-masterノードとDM-workerノード、データソース、およびデータレプリケーションタスクを管理します。 | | [モニタリングAPI](/tidb-monitoring-api.md) | TiDBサーバーの実行状況、テーブルストレージ情報、およびTiKVクラスタの詳細を取得します。 | | [TiCDC API](/ticdc/ticdc-open-api-v2.md) | TiCDCノードの状態を照会し、レプリケーションタスク（作成、一時停止、再開、更新操作など）を管理します。 | | [TiDB Operator API](https://github.com/pingcap/tidb-operator/blob/%7B%7B%7B.tidb-operator-version%7D%7D%7D/docs/api-references/docs.md) | Kubernetes 上で TiDB クラスタを管理します。これには、デプロイ、アップグレード、スケーリング、バックアップ、フェイルオーバーなどが含まれます。 | diff --git a/api/dm-api-overview.md b/api/dm-api-overview.md index 30968c3614fe3..795a4bcafa954 100644 --- a/api/dm-api-overview.md +++ b/api/dm-api-overview.md @@ -11,8 +11,8 @@ DM は、 [dmctlツール](/dm/dmctl-introduction.md)と同様に、DM クラス DM API を使用して、DM クラスターで次のメンテナンス操作を実行できます。 -- [クラスタ管理](/dm/dm-open-api.md#apis-for-managing-clusters) : DM マスターノードと DM ワーカーノードに関する情報を取得したり、停止したりします。 -- [データソース管理](/dm/dm-open-api.md#apis-for-managing-data-sources) : データソースを作成、更新、削除、有効化、無効化し、リレーログ機能を管理し、データソースと DM ワーカー間のバインディングを変更します。 +- [クラスタ管理](/dm/dm-open-api.md#apis-for-managing-clusters) : DM-masterノードと DM-workerノードに関する情報を取得したり、停止したりします。 +- [データソース管理](/dm/dm-open-api.md#apis-for-managing-data-sources) : データソースを作成、更新、削除、有効化、無効化し、リレーログ機能を管理し、データソースと DM-worker間のバインディングを変更します。 - [レプリケーションタスク管理](/dm/dm-open-api.md#apis-for-managing-replication-tasks) : レプリケーションタスクを作成、更新、削除、開始、または停止し、スキーマと移行ルールを管理します。 リクエストパラメータ、レスポンス例、使用方法など、各 API の詳細については、 [OpenAPI を使用して DM クラスターを管理](/dm/dm-open-api.md)を参照してください。 diff --git a/best-practices-for-security-configuration.md b/best-practices-for-security-configuration.md index cdcabc8a72a6c..bbff15c4a68da 100644 --- a/best-practices-for-security-configuration.md +++ b/best-practices-for-security-configuration.md @@ -78,9 +78,9 @@ TiDBのインストールには、デフォルトでコンポーネント間通 | TiFlash | 20170 | プロトコル | | TiFlash | 20292 | HTTP | | TiFlash | 8234 | HTTP | -| DMマスター | 8261 | HTTP | -| DMマスター | 8291 | HTTP | -| DMワーカー | 8262 | HTTP | +| DM-master | 8261 | HTTP | +| DM-master | 8291 | HTTP | +| DM-worker | 8262 | HTTP | | TiCDC | 8300 | HTTP | | TiDB Lightning | 8289 | HTTP | | TiDB Operator | 6060 | HTTP | diff --git a/dm/deploy-a-dm-cluster-using-binary.md b/dm/deploy-a-dm-cluster-using-binary.md index ea35cd93dc03e..de1695c27c163 100644 --- a/dm/deploy-a-dm-cluster-using-binary.md +++ b/dm/deploy-a-dm-cluster-using-binary.md @@ -19,40 +19,40 @@ DMバイナリはTiDB Toolkitに含まれています。TiDB Toolkitをダウン 次のサンプル シナリオに基づいて DM クラスターを展開するとします。 -2 つの DM ワーカーノードと 3つの DM マスターノードが 5台のサーバーに展開されます。 +2 つの DM-workerノードと 3つの DM-masterノードが 5台のサーバーに展開されます。 各ノードのアドレスは次のとおりです。 | インスタンス | サーバーアドレス | ポート | | :------ | :---------- | :--- | -| DMマスター1 | 192.168.0.4 | 8261 | -| DMマスター2 | 192.168.0.5 | 8261 | -| DMマスター3 | 192.168.0.6 | 8261 | -| DMワーカー1 | 192.168.0.7 | 8262 | -| DMワーカー2 | 192.168.0.8 | 8262 | +| DM-master1 | 192.168.0.4 | 8261 | +| DM-master2 | 192.168.0.5 | 8261 | +| DM-master3 | 192.168.0.6 | 8261 | +| DM-worker1 | 192.168.0.7 | 8262 | +| DM-worker2 | 192.168.0.8 | 8262 | このシナリオに基づいて、次のセクションでは DM クラスターを展開する方法について説明します。 > **Note:** > -> - 単一のサーバーに複数の DM マスターまたは DM ワーカーインスタンスを展開する場合、各インスタンスのポートと作業ディレクトリは一意である必要があります。 +> - 単一のサーバーに複数の DM-masterまたは DM-workerインスタンスを展開する場合、各インスタンスのポートと作業ディレクトリは一意である必要があります。 > -> - DM クラスターの高可用性を確保する必要がない場合は、DM マスターノードを 1つだけデプロイし、デプロイされる DM ワーカーノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数以上である必要があります。 +> - DM クラスターの高可用性を確保する必要がない場合は、DM-masterノードを 1つだけデプロイし、デプロイされる DM-workerノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数以上である必要があります。 > -> - DM クラスターの高可用性を確保するには、3つの DM マスターノードを展開することをお勧めします。また、展開する DM ワーカーノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数より多くする必要があります (たとえば、DM ワーカーノードの数は、アップストリーム インスタンスの数より 2つ多くなります)。 +> - DM クラスターの高可用性を確保するには、3つの DM-masterノードを展開することをお勧めします。また、展開する DM-workerノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数より多くする必要があります (たとえば、DM-workerノードの数は、アップストリーム インスタンスの数より 2つ多くなります)。 > > - 次のコンポーネント間のポートが相互接続されていることを確認します。 -> - DM マスターノード間の`8291`ポートは相互接続されています。 -> - 各 DM マスターノードは、すべての DM ワーカーノードの`8262`ポートに接続できます。 -> - 各 DM ワーカーノードは、すべての DM マスターノードの`8261`ポートに接続できます。 +> - DM-masterノード間の`8291`ポートは相互接続されています。 +> - 各 DM-masterノードは、すべての DM-workerノードの`8262`ポートに接続できます。 +> - 各 DM-workerノードは、すべての DM-masterノードの`8261`ポートに接続できます。 -### DMマスターをデプロイ {#deploy-dm-master} +### DM-masterをデプロイ {#deploy-dm-master} -[コマンドラインパラメータ](#dm-master-command-line-parameters)または[設定ファイル](#dm-master-configuration-file)を使用して DM マスターを設定できます。 +[コマンドラインパラメータ](#dm-master-command-line-parameters)または[設定ファイル](#dm-master-configuration-file)を使用して DM-masterを設定できます。 -#### DMマスターのコマンドラインパラメータ {#dm-master-command-line-parameters} +#### DM-masterのコマンドラインパラメータ {#dm-master-command-line-parameters} -DM マスターのコマンドラインパラメータの説明は次のとおりです。 +DM-masterのコマンドラインパラメータの説明は次のとおりです。 ```bash ./dm-master --help @@ -89,9 +89,9 @@ Usage of dm-master: > **Note:** > -> 一部の設定がコマンドラインから参照できないため、上記の方法でDMマスターを設定できない場合があります。そのような場合は、代わりに設定ファイルを使用してください。 +> 一部の設定がコマンドラインから参照できないため、上記の方法でDM-masterを設定できない場合があります。そのような場合は、代わりに設定ファイルを使用してください。 -#### DMマスター構成ファイル {#dm-master-configuration-file} +#### DM-master構成ファイル {#dm-master-configuration-file} 以下はDM-masterの設定ファイルです。この方法でDM-masterを設定することをお勧めします。 @@ -166,7 +166,7 @@ Usage of worker: > > 一部の設定がコマンドラインから参照できないため、上記の方法でDM-workerを設定できない場合があります。そのような場合は、代わりに設定ファイルを使用してください。 -#### DMワーカー構成ファイル {#dm-worker-configuration-file} +#### DM-worker構成ファイル {#dm-worker-configuration-file} 以下はDM-workerの設定ファイルです。この方法でDM-workerを設定することをお勧めします。 diff --git a/dm/deploy-a-dm-cluster-using-tiup-offline.md b/dm/deploy-a-dm-cluster-using-tiup-offline.md index c038227c3cc5e..fa8a0a7676eaa 100644 --- a/dm/deploy-a-dm-cluster-using-tiup-offline.md +++ b/dm/deploy-a-dm-cluster-using-tiup-offline.md @@ -72,7 +72,7 @@ source /home/tidb/.bash_profile 完全な構成テンプレートについては、「 [TiUP構成パラメータ テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml) . 構成ファイルを作成する」 `topology.yaml`を参照してください。その他の複合シナリオでは、テンプレートに従って必要に応じて構成ファイルを編集します。 -3 つの DM マスター、3つの DM ワーカー、および 1つの監視コンポーネントインスタンスを展開する構成は次のとおりです。 +3 つの DM-master、3つの DM-worker、および 1つの監視コンポーネントインスタンスを展開する構成は次のとおりです。 ```yaml --- @@ -105,9 +105,9 @@ alertmanager_servers: > **Note:** > -> - DM クラスターの高可用性を確保する必要がない場合は、DM マスターノードを 1つだけデプロイし、デプロイされた DM ワーカーノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数以上である必要があります。 +> - DM クラスターの高可用性を確保する必要がない場合は、DM-masterノードを 1つだけデプロイし、デプロイされた DM-workerノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数以上である必要があります。 > -> - DM クラスターの高可用性を確保するには、3つの DM マスターノードを展開することをお勧めします。また、展開する DM ワーカーノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数より多くする必要があります (たとえば、DM ワーカーノードの数は、アップストリーム インスタンスの数より 2つ多くなります)。 +> - DM クラスターの高可用性を確保するには、3つの DM-masterノードを展開することをお勧めします。また、展開する DM-workerノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数より多くする必要があります (たとえば、DM-workerノードの数は、アップストリーム インスタンスの数より 2つ多くなります)。 > > - グローバルに有効にする必要があるパラメータについては、構成ファイルの`server_configs`セクションで対応するコンポーネントのこれらのパラメータを構成します。 > @@ -118,11 +118,11 @@ alertmanager_servers: > - 詳細なパラメータの説明については、 [マスター`config.toml.example`](https://github.com/pingcap/tiflow/blob/release-8.5/dm/master/dm-master.toml)と[ワーカー`config.toml.example`](https://github.com/pingcap/tiflow/blob/release-8.5/dm/worker/dm-worker.toml)を参照してください。 > > - 次のコンポーネント間のポートが相互接続されていることを確認します。 -> - DM マスターノードのうち`peer_port` (デフォルトでは`8291` ) が相互接続されています。 -> - 各 DM マスターノードは、すべての DM ワーカーノードの`port` (デフォルトでは`8262` ) に接続できます。 -> - 各 DM ワーカーノードは、すべての DM マスターノードの`port` (デフォルトでは`8261` ) に接続できます。 -> - TiUPノードは、すべての DM マスターノードの`port` (デフォルトでは`8261` ) に接続できます。 -> - TiUPノードは、すべての DM ワーカーノードの`port` (デフォルトでは`8262` ) に接続できます。 +> - DM-masterノードのうち`peer_port` (デフォルトでは`8291` ) が相互接続されています。 +> - 各 DM-masterノードは、すべての DM-workerノードの`port` (デフォルトでは`8262` ) に接続できます。 +> - 各 DM-workerノードは、すべての DM-masterノードの`port` (デフォルトでは`8261` ) に接続できます。 +> - TiUPノードは、すべての DM-masterノードの`port` (デフォルトでは`8261` ) に接続できます。 +> - TiUPノードは、すべての DM-workerノードの`port` (デフォルトでは`8262` ) に接続できます。 ## ステップ4: デプロイメントコマンドを実行する {#step-4-execute-the-deployment-command} diff --git a/dm/deploy-a-dm-cluster-using-tiup.md b/dm/deploy-a-dm-cluster-using-tiup.md index afdb55f5c07c9..5839a3cb3f182 100644 --- a/dm/deploy-a-dm-cluster-using-tiup.md +++ b/dm/deploy-a-dm-cluster-using-tiup.md @@ -15,11 +15,11 @@ TiUPはDM v2.0以降のバージョンの導入をサポートしています。 ## 前提条件 {#prerequisites} -- DMが完全なデータレプリケーションタスクを実行する場合、DMワーカーは1つの上流データベースのみにバインドされます。DMワーカーはまずローカルで全データをエクスポートし、その後、下流データベースにインポートします。そのため、ワーカーのホスト領域には、エクスポートするすべての上流テーブルを保存できる十分な大きさが必要です。ストレージパスは、タスク作成時に後で指定します。 +- DMが完全なデータレプリケーションタスクを実行する場合、DM-workerは1つの上流データベースのみにバインドされます。DM-workerはまずローカルで全データをエクスポートし、その後、下流データベースにインポートします。そのため、ワーカーのホスト領域には、エクスポートするすべての上流テーブルを保存できる十分な大きさが必要です。ストレージパスは、タスク作成時に後で指定します。 - DM クラスターを展開する場合は、 [ハードウェアとソフトウェアの要件](/dm/dm-hardware-and-software-requirements.md)を満たす必要があります。 -- v8.0.0 以降、 [データベースのパスワードを暗号化する](/dm/dm-manage-source.md#encrypt-the-database-password)必要な場合は、事前に[データベースのパスワードを暗号化および復号化するために使用されるキーファイル](/dm/dm-customized-secret-key.md)を DM マスターに保存し、 `dmctl encrypt`コマンドを使用する前に[`secret-key-path`](/dm/dm-master-configuration-file.md)を DM マスターに設定する必要があります。 +- v8.0.0 以降、 [データベースのパスワードを暗号化する](/dm/dm-manage-source.md#encrypt-the-database-password)必要な場合は、事前に[データベースのパスワードを暗号化および復号化するために使用されるキーファイル](/dm/dm-customized-secret-key.md)を DM-masterに保存し、 `dmctl encrypt`コマンドを使用する前に[`secret-key-path`](/dm/dm-master-configuration-file.md)を DM-masterに設定する必要があります。 ## ステップ1: 制御マシンにTiUPをインストールする {#step-1-install-tiup-on-the-control-machine} @@ -47,7 +47,7 @@ TiUPはDM v2.0以降のバージョンの導入をサポートしています。 コマンド`tiup dm template > topology.yaml`を使用すると、構成ファイル テンプレートをすばやく生成できます。 -3 つの DM マスター、3つの DM ワーカー、および 1つの監視コンポーネントインスタンスを展開する構成は次のとおりです。 +3 つの DM-master、3つの DM-worker、および 1つの監視コンポーネントインスタンスを展開する構成は次のとおりです。 ```yaml # The global variables apply to all other components in the configuration. If one specific value is missing in the component instance, the corresponding global variable serves as the default value. @@ -132,14 +132,14 @@ alertmanager_servers: > **Note:** > -> - 1台のホストで多数のDMワーカーを実行することは推奨されません。各DMワーカーには、少なくとも2コアのCPUと4GiBのメモリを割り当てる必要があります。 +> - 1台のホストで多数のDM-workerを実行することは推奨されません。各DM-workerには、少なくとも2コアのCPUと4GiBのメモリを割り当てる必要があります。 > > - 次のコンポーネント間のポートが相互接続されていることを確認します。 -> - DM マスターノードのうち`peer_port` (デフォルトでは`8291` ) が相互接続されています。 -> - 各 DM マスターノードは、すべての DM ワーカーノードの`port` (デフォルトでは`8262` ) に接続できます。 -> - 各 DM ワーカーノードは、すべての DM マスターノードの`port` (デフォルトでは`8261` ) に接続できます。 -> - TiUPノードは、すべての DM マスターノードの`port` (デフォルトでは`8261` ) に接続できます。 -> - TiUPノードは、すべての DM ワーカーノードの`port` (デフォルトでは`8262` ) に接続できます。 +> - DM-masterノードのうち`peer_port` (デフォルトでは`8291` ) が相互接続されています。 +> - 各 DM-masterノードは、すべての DM-workerノードの`port` (デフォルトでは`8262` ) に接続できます。 +> - 各 DM-workerノードは、すべての DM-masterノードの`port` (デフォルトでは`8261` ) に接続できます。 +> - TiUPノードは、すべての DM-masterノードの`port` (デフォルトでは`8261` ) に接続できます。 +> - TiUPノードは、すべての DM-workerノードの`port` (デフォルトでは`8262` ) に接続できます。 `master_servers.host.config`パラメータの詳細については[マスターパラメータ](https://github.com/pingcap/tiflow/blob/release-8.5/dm/master/dm-master.toml)を参照してください。`worker_servers.host.config`のパラメータの詳細については[ワーカーパラメータ](https://github.com/pingcap/tiflow/blob/release-8.5/dm/worker/dm-worker.toml)を参照してください。 diff --git a/dm/dm-arch.md b/dm/dm-arch.md index b0270e514e1a5..72eded7237125 100644 --- a/dm/dm-arch.md +++ b/dm/dm-arch.md @@ -1,29 +1,29 @@ --- title: Data Migration Architecture -summary: データ移行（DM）アーキテクチャは、DMマスター、DMワーカー、dmctlの3つのコンポーネントで構成されています。DMマスターはデータ移行タスクを管理し、DMワーカーは特定のタスクを実行し、dmctlはクラスタ制御用のコマンドラインツールです。高可用性は、複数のDMマスターノードと自動タスクスケジューリングによって実現されます。MySQLとDMワーカーの制限により、完全なエクスポートおよびインポートタスクは高可用性をサポートしません。 +summary: データ移行（DM）アーキテクチャは、DM-master、DM-worker、dmctlの3つのコンポーネントで構成されています。DM-masterはデータ移行タスクを管理し、DM-workerは特定のタスクを実行し、dmctlはクラスタ制御用のコマンドラインツールです。高可用性は、複数のDM-masterノードと自動タスクスケジューリングによって実現されます。MySQLとDM-workerの制限により、完全なエクスポートおよびインポートタスクは高可用性をサポートしません。 --- # データ移行アーキテクチャ {#data-migration-architecture} このドキュメントでは、データ移行 (DM) のアーキテクチャについて説明します。 -DM は、DM マスター、DM ワーカー、dmctl の 3つのコンポーネントで構成されます。 +DM は、DM-master、DM-worker、dmctl の 3つのコンポーネントで構成されます。 ![Data Migration architecture](/media/dm/dm-architecture-2.0.png) ## アーキテクチャコンポーネント {#architecture-components} -### DMマスター {#dm-master} +### DM-master {#dm-master} DM-master は、データ移行タスクの操作を管理およびスケジュールします。 - DMクラスタのトポロジ情報の保存 -- DMワーカープロセスの実行状態の監視 +- DM-workerプロセスの実行状態の監視 - データ移行タスクの実行状態の監視 - データ移行タスクを管理するための統合ポータルを提供する - シャーディングシナリオにおける各インスタンスのシャーディングされたテーブルの DDL 移行の調整 -### DMワーカー {#dm-worker} +### DM-worker {#dm-worker} DM-worker は特定のデータ移行タスクを実行します。 @@ -32,7 +32,7 @@ DM-worker は特定のデータ移行タスクを実行します。 - データ移行サブタスクの操作のオーケストレーション - データ移行サブタスクの実行状態の監視 -DM-workerの詳細については[DMワーカー紹介](/dm/dm-worker-intro.md)を参照してください。 +DM-workerの詳細については[DM-worker紹介](/dm/dm-worker-intro.md)を参照してください。 ### dmctl {#dmctl} @@ -47,9 +47,9 @@ dmctl は、DM クラスターを制御するために使用されるコマン ### 高可用性 {#high-availability} -複数のDMマスターノードをデプロイする場合、すべてのDMマスターノードは組み込みのetcdを使用してクラスタを形成します。DMマスタークラスタは、クラスタノード情報やタスク設定などのメタデータを保存するために使用されます。etcdによって選出されたリーダーノードは、クラスタ管理やデータ移行タスク管理などのサービスを提供します。したがって、利用可能なDMマスターノードの数がデプロイされたノードの半数を超えても、DMクラスタは正常にサービスを提供できます。 +複数のDM-masterノードをデプロイする場合、すべてのDM-masterノードは組み込みのetcdを使用してクラスタを形成します。DM-masterクラスタは、クラスタノード情報やタスク設定などのメタデータを保存するために使用されます。etcdによって選出されたリーダーノードは、クラスタ管理やデータ移行タスク管理などのサービスを提供します。したがって、利用可能なDM-masterノードの数がデプロイされたノードの半数を超えても、DMクラスタは正常にサービスを提供できます。 -デプロイされた DM ワーカーノードの数が上流の MySQL/MariaDB ノードの数を超える場合、超過した DM ワーカーノードはデフォルトでアイドル状態になります。DM ワーカーノードがオフラインになったり、DM マスターリーダーから分離したりした場合、DM マスターは元の DM ワーカーノードのデータ移行タスクを他のアイドル状態の DM ワーカーノードに自動的にスケジュールします。（DM ワーカーノードが分離されると、そのノード上のデータ移行タスクが自動的に停止されます。）利用可能なアイドル状態の DM ワーカーノードがない場合、元の DM ワーカーのデータ移行タスクは、1つの DM ワーカーノードがアイドル状態になるまで一時的に停止され、その後タスクが自動的に再開されます。 +デプロイされた DM-workerノードの数が上流の MySQL/MariaDB ノードの数を超える場合、超過した DM-workerノードはデフォルトでアイドル状態になります。DM-workerノードがオフラインになったり、DM-masterリーダーから分離したりした場合、DM-masterは元の DM-workerノードのデータ移行タスクを他のアイドル状態の DM-workerノードに自動的にスケジュールします。（DM-workerノードが分離されると、そのノード上のデータ移行タスクが自動的に停止されます。）利用可能なアイドル状態の DM-workerノードがない場合、元の DM-workerのデータ移行タスクは、1つの DM-workerノードがアイドル状態になるまで一時的に停止され、その後タスクが自動的に再開されます。 > **Note:** > diff --git a/dm/dm-best-practices.md b/dm/dm-best-practices.md index 591c99ba9ae7f..4625a49348002 100644 --- a/dm/dm-best-practices.md +++ b/dm/dm-best-practices.md @@ -27,7 +27,7 @@ DM は次のシナリオで使用できます。 - DMは1000台のワークノードの同時管理をサポートし、タスクの最大数は600です。ワークノードの高可用性を確保するには、一部のワークノードをスタンバイノードとして確保する必要があります。スタンバイノードの推奨数は、移行タスクが実行中のワークノード数の20%～50%です。 - 単一のワークノードは、理論上、ワーカーあたり最大30K QPSのレプリケーションQPSをサポートできます。これはスキーマやワークロードによって異なります。アップストリームのバイナリログ処理能力は、ワーカーあたり最大20MB/秒です。 -- DMをデータレプリケーションミドルウェアとして長期的に使用する場合は、DMコンポーネントのデプロイメントアーキテクチャを慎重に設計する必要があります。詳細については、 [DMマスターとDMワーカーをデプロイ](#deploy-dm-master-and-dm-worker)を参照してください。 +- DMをデータレプリケーションミドルウェアとして長期的に使用する場合は、DMコンポーネントのデプロイメントアーキテクチャを慎重に設計する必要があります。詳細については、 [DM-masterとDM-workerをデプロイ](#deploy-dm-master-and-dm-worker)を参照してください。 ## データ移行前 {#before-data-migration} @@ -121,13 +121,13 @@ TiDB v6.0.0以降、GBKがサポートされています。詳細については ### 展開のベストプラクティス {#best-practices-for-deployment} -#### DMマスターとDMワーカーをデプロイ {#deploy-dm-master-and-dm-worker} +#### DM-masterとDM-workerをデプロイ {#deploy-dm-master-and-dm-worker} -DM は DM マスターノードと DM ワーカーノードで構成されます。 +DM は DM-masterノードと DM-workerノードで構成されます。 -- DMマスターは、移行タスクのメタデータを管理し、DMワーカーノードのスケジュールを管理します。これはDMプラットフォーム全体の中核です。そのため、DMマスターをクラスターとして展開することで、DMプラットフォームの高可用性を確保できます。 +- DM-masterは、移行タスクのメタデータを管理し、DM-workerノードのスケジュールを管理します。これはDMプラットフォーム全体の中核です。そのため、DM-masterをクラスターとして展開することで、DMプラットフォームの高可用性を確保できます。 -- DMワーカーは、上流および下流の移行タスクを実行します。DMワーカーノードはステートレスです。最大1000個のDMワーカーノードをデプロイできます。DMを使用する場合は、高可用性を確保するために、アイドル状態のDMワーカーをいくつか確保することをお勧めします。 +- DM-workerは、上流および下流の移行タスクを実行します。DM-workerノードはステートレスです。最大1000個のDM-workerノードをデプロイできます。DMを使用する場合は、高可用性を確保するために、アイドル状態のDM-workerをいくつか確保することをお勧めします。 #### 移行タスクを計画する {#plan-the-migration-tasks} @@ -141,17 +141,17 @@ MySQLシャードの移行とマージを行う際、上流のシャードの種 移行タスクを分割することで保証されるのは、最終的なデータの整合性のみであることにご注意ください。リアルタイムの整合性は、様々な理由により大きく変動する可能性があります。 -次の表は、さまざまなシナリオにおける DM マスターと DM ワーカーの推奨される展開計画を示しています。 +次の表は、さまざまなシナリオにおける DM-masterと DM-workerの推奨される展開計画を示しています。 -| シナリオ | DMマスターの展開 | DMワーカーの展開 | +| シナリオ | DM-masterの展開 | DM-workerの展開 | | :-------------------------------------------------------------------- | :----------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------- | -|
  • 小さなデータセット（1 TiB 未満）
  • 一度限りのデータ移行
    • | 1つのDMマスターノードをデプロイ | 上流データソースの数に応じて、1～N 台の DM ワーカーノードをデプロイ。通常は 1台の DM ワーカーノードを推奨します。 | -|
  • 大規模なデータセット（1 TiB 以上）と MySQL シャードの移行およびマージ
  • 一度限りのデータ移行
    • | 長時間のデータ移行中に DM クラスターの可用性を確保するために、3つの DM マスターノードを展開することをお勧めします。 | データソースまたは移行タスクの数に応じて、DMワーカーノードをデプロイ。稼働中のDMワーカーノードに加えて、アイドル状態のDMワーカーノードを1～3台展開することをお勧めします。 | -| 長期データ複製 | DMマスターノードは3台必要です。クラウド上にDMマスターノードをデプロイする場合は、異なるアベイラビリティゾーン（AZ）にデプロイするようにしてください。 | データソース数や移行タスク数に応じて、DMワーカーノードをデプロイ。実際に必要なDMワーカーノード数の1.5～2倍を配置する必要があります。 | +|
  • 小さなデータセット（1 TiB 未満）
  • 一度限りのデータ移行
    • | 1つのDM-masterノードをデプロイ | 上流データソースの数に応じて、1～N 台の DM-workerノードをデプロイ。通常は 1台の DM-workerノードを推奨します。 | +|
  • 大規模なデータセット（1 TiB 以上）と MySQL シャードの移行およびマージ
  • 一度限りのデータ移行
    • | 長時間のデータ移行中に DM クラスターの可用性を確保するために、3つの DM-masterノードを展開することをお勧めします。 | データソースまたは移行タスクの数に応じて、DM-workerノードをデプロイ。稼働中のDM-workerノードに加えて、アイドル状態のDM-workerノードを1～3台展開することをお勧めします。 | +| 長期データ複製 | DM-masterノードは3台必要です。クラウド上にDM-masterノードをデプロイする場合は、異なるアベイラビリティゾーン（AZ）にデプロイするようにしてください。 | データソース数や移行タスク数に応じて、DM-workerノードをデプロイ。実際に必要なDM-workerノード数の1.5～2倍を配置する必要があります。 | #### アップストリームデータソースを選択して構成する {#choose-and-configure-the-upstream-data-source} -DM は、フルデータ移行を実行する際にデータベース全体のデータをバックアップし、並列論理バックアップ方式を採用しています。MySQL のバックアップ中に、グローバル読み取りロック[`FLUSH TABLES WITH READ LOCK`](https://dev.mysql.com/doc/refman/8.0/en/flush.html#flush-tables-with-read-lock)が追加されます。上流データベースの DML および DDL 操作は短時間ブロックされます。そのため、上流のバックアップデータベースを使用してフルデータバックアップを実行し、データソースの GTID 機能を有効にすることを強くお勧めします ( `enable-gtid: true` )。これにより、上流からの影響を回避し、上流のマスターノードに切り替えて増分移行中のレイテンシーを削減できます。上流の MySQL データソースを切り替える手順については、 [アップストリーム MySQL インスタンス間の DM ワーカー接続を切り替える](/dm/usage-scenario-master-slave-switch.md#switch-dm-worker-connection-via-virtual-ip)を参照してください。 +DM は、フルデータ移行を実行する際にデータベース全体のデータをバックアップし、並列論理バックアップ方式を採用しています。MySQL のバックアップ中に、グローバル読み取りロック[`FLUSH TABLES WITH READ LOCK`](https://dev.mysql.com/doc/refman/8.0/en/flush.html#flush-tables-with-read-lock)が追加されます。上流データベースの DML および DDL 操作は短時間ブロックされます。そのため、上流のバックアップデータベースを使用してフルデータバックアップを実行し、データソースの GTID 機能を有効にすることを強くお勧めします ( `enable-gtid: true` )。これにより、上流からの影響を回避し、上流のマスターノードに切り替えて増分移行中のレイテンシーを削減できます。上流の MySQL データソースを切り替える手順については、 [アップストリーム MySQL インスタンス間の DM-worker接続を切り替える](/dm/usage-scenario-master-slave-switch.md#switch-dm-worker-connection-via-virtual-ip)を参照してください。 次の点に注意してください。 @@ -186,13 +186,13 @@ TiDBスキーマ名はデフォルトでは大文字と小文字を区別しま #### リレーログを使用する {#use-the-relay-log} -MySQLのマスター/スタンバイメカニズムでは、非同期レプリケーションの信頼性と効率性を確保するために、スタンバイノードがリレーログのコピーを保存します。DMは、DMワーカーへのリレーログのコピーの保存もサポートしています。ストレージの場所や有効期限などの情報を設定できます。この機能は、以下のシナリオに適用されます。 +MySQLのマスター/スタンバイメカニズムでは、非同期レプリケーションの信頼性と効率性を確保するために、スタンバイノードがリレーログのコピーを保存します。DMは、DM-workerへのリレーログのコピーの保存もサポートしています。ストレージの場所や有効期限などの情報を設定できます。この機能は、以下のシナリオに適用されます。 - 完全データ移行および増分データ移行において、完全データの量が多い場合、上流のバイナリログのアーカイブにかかる時間よりも、全体の処理に時間がかかります。その結果、増分レプリケーションタスクが正常に開始されないことがあります。リレーログを有効にすると、完全移行の開始時にDM-workerがリレーログの受信を開始します。これにより、増分タスクの失敗を回避できます。 - DMを使用して長時間のデータレプリケーションを実行する場合、様々な理由により移行タスクが長時間ブロックされることがあります。リレーログを有効にすると、移行タスクのブロックによって上流のバイナリログが再利用される問題を効果的に解決できます。 -リレーログの使用にはいくつかの制限があります。DMは高可用性をサポートしています。DMワーカーに障害が発生すると、アイドル状態のDMワーカーインスタンスを稼働中のインスタンスに昇格させようとします。アップストリームのバイナリログに必要な移行ログが含まれていない場合、中断が発生する可能性があります。リレーログを新しいDMワーカーノードにできるだけ早く手動でコピーし、対応するリレーメタファイルを変更する必要があります。詳細については、 [トラブルシューティング](/dm/dm-error-handling.md#the-relay-unit-throws-error-event-from--in--diff-from-passed-in-event--or-a-migration-task-is-interrupted-with-failing-to-get-or-parse-binlog-errors-like-get-binlog-error-error-1236-hy000-and-binlog-checksum-mismatch-data-may-be-corrupted-returned)を参照してください。 +リレーログの使用にはいくつかの制限があります。DMは高可用性をサポートしています。DM-workerに障害が発生すると、アイドル状態のDM-workerインスタンスを稼働中のインスタンスに昇格させようとします。アップストリームのバイナリログに必要な移行ログが含まれていない場合、中断が発生する可能性があります。リレーログを新しいDM-workerノードにできるだけ早く手動でコピーし、対応するリレーメタファイルを変更する必要があります。詳細については、 [トラブルシューティング](/dm/dm-error-handling.md#the-relay-unit-throws-error-event-from--in--diff-from-passed-in-event--or-a-migration-task-is-interrupted-with-failing-to-get-or-parse-binlog-errors-like-get-binlog-error-error-1236-hy000-and-binlog-checksum-mismatch-data-may-be-corrupted-returned)を参照してください。 #### アップストリームでpt-osc/gh-ostを使用する {#use-pt-osc-gh-ost-in-upstream} diff --git a/dm/dm-command-line-flags.md b/dm/dm-command-line-flags.md index 8d1ac77f71575..f0ed7a1968182 100644 --- a/dm/dm-command-line-flags.md +++ b/dm/dm-command-line-flags.md @@ -7,41 +7,41 @@ summary: DM のコマンドラインフラグについて学習します。 このドキュメントでは、DM のコマンドラインフラグについて説明します。 -## DMマスター {#dm-master} +## DM-master {#dm-master} ### `--advertise-addr` {#advertise-addr} -- クライアントのリクエストを受信するために使用されるDMマスターの外部アドレス +- クライアントのリクエストを受信するために使用されるDM-masterの外部アドレス - デフォルト値は`"{master-addr}"`です - オプションフラグ。`"domain-name:port"`の形式をとることができます。 ### `--advertise-peer-urls` {#advertise-peer-urls} -- DMマスターノード間の通信用の外部アドレス +- DM-masterノード間の通信用の外部アドレス - デフォルト値は`"{peer-urls}"`です - オプションフラグ。`"http(s)://domain-name:port"`の形式をとることができます。 ### `--config` {#config} -- DMマスターの設定ファイルパス +- DM-masterの設定ファイルパス - デフォルト値は`""`です - オプションフラグ ### `--data-dir` {#data-dir} -- DMマスターのデータを保存するディレクトリ +- DM-masterのデータを保存するディレクトリ - デフォルト値は`"default.{name}"`です - オプションフラグ ### `--initial-cluster` {#initial-cluster} -- DMマスタークラスタのブートストラップに使用される`"{node name}={external address}"`リスト +- DM-masterクラスタのブートストラップに使用される`"{node name}={external address}"`リスト - デフォルト値は`"{name}={advertise-peer-urls}"`です - `join`フラグが指定されていない場合は、このフラグを指定する必要があります。3ノードクラスタの構成例は`"dm-master-1=http://172.16.15.11:8291,dm-master-2=http://172.16.15.12:8291,dm-master-3=http://172.16.15.13:8291"`です。 ### `--join` {#join} -- DMマスターノードがこのクラスタに参加したときの既存のクラスタの`advertise-addr`リスト +- DM-masterノードがこのクラスタに参加したときの既存のクラスタの`advertise-addr`リスト - デフォルト値は`""`です - `initial-cluster`フラグが指定されていない場合は、このフラグを指定する必要があります。2ノードのクラスタに新しいノードが参加する場合、設定例は`"172.16.15.11:8261,172.16.15.12:8261"`です。 @@ -59,19 +59,19 @@ summary: DM のコマンドラインフラグについて学習します。 ### `--master-addr` {#master-addr} -- DMマスターがクライアントのリクエストをリッスンするアドレス +- DM-masterがクライアントのリクエストをリッスンするアドレス - デフォルト値は`""`です - 必須フラグ ### `--name` {#name} -- DMマスターノードの名前 +- DM-masterノードの名前 - デフォルト値は`"dm-master-{hostname}"`です - 必須フラグ ### `--peer-urls` {#peer-urls} -- DMマスターノード間の通信のリスニングアドレス +- DM-masterノード間の通信のリスニングアドレス - デフォルト値は`"http://127.0.0.1:8291"`です - 必須フラグ @@ -81,11 +81,11 @@ summary: DM のコマンドラインフラグについて学習します。 - デフォルト値は`""`です - オプションフラグ -## DMワーカー {#dm-worker} +## DM-worker {#dm-worker} ### `--advertise-addr` {#advertise-addr} -- クライアントのリクエストを受信するために使用されるDMワーカーの外部アドレス +- クライアントのリクエストを受信するために使用されるDM-workerの外部アドレス - デフォルト値は`"{worker-addr}"`です - オプションフラグ。`"domain-name:port"`の形式をとることができます。 @@ -97,9 +97,9 @@ summary: DM のコマンドラインフラグについて学習します。 ### `--join` {#join} -- DMワーカーがこのクラスタに登録したときのクラスタ内のDMマスターノードの`{advertise-addr}`のリスト +- DM-workerがこのクラスタに登録したときのクラスタ内のDM-masterノードの`{advertise-addr}`のリスト - デフォルト値は`""`です -- 必須フラグ。3ノード（DMマスターノード）クラスタの構成例は`"172.16.15.11:8261,172.16.15.12:8261,172.16.15.13:8261"`です。 +- 必須フラグ。3ノード（DM-masterノード）クラスタの構成例は`"172.16.15.11:8261,172.16.15.12:8261,172.16.15.13:8261"`です。 ### `--log-file` {#log-file} @@ -115,13 +115,13 @@ summary: DM のコマンドラインフラグについて学習します。 ### `--name` {#name} -- DMワーカーノードの名前 +- DM-workerノードの名前 - デフォルト値は`"{advertise-addr}"`です - 必須フラグ ### `--worker-addr` {#worker-addr} -- DMワーカーがクライアントのリクエストをリッスンするアドレス +- DM-workerがクライアントのリクエストをリッスンするアドレス - デフォルト値は`""`です - 必須フラグ @@ -135,6 +135,6 @@ summary: DM のコマンドラインフラグについて学習します。 ### `--master-addr` {#master-addr} -- dmctlによって接続されるクラスタ内の任意のDMマスターノードの`{advertise-addr}` +- dmctlによって接続されるクラスタ内の任意のDM-masterノードの`{advertise-addr}` - デフォルト値は`""`です -- これは、dmctlがDMマスターと対話するときに必要なフラグです。 +- これは、dmctlがDM-masterと対話するときに必要なフラグです。 diff --git a/dm/dm-config-overview.md b/dm/dm-config-overview.md index bd5a89e6d5108..8cd0bdd250bf3 100644 --- a/dm/dm-config-overview.md +++ b/dm/dm-config-overview.md @@ -9,8 +9,8 @@ summary: このドキュメントでは、データ移行構成ファイルの ## DMプロセス構成ファイル {#dm-process-configuration-files} -- `dm-master.toml` : DMマスタープロセスの実行に関する設定ファイル。DMマスターのトポロジ情報とログが含まれます。詳細については、 [DMマスターコンフィグレーションファイル](/dm/dm-master-configuration-file.md)を参照してください。 -- `dm-worker.toml` : DMワーカープロセスの実行に関する設定ファイル。DMワーカーのトポロジ情報とログが含まれます。詳細は[DMワーカーコンフィグレーションファイル](/dm/dm-worker-configuration-file.md)を参照してください。 +- `dm-master.toml` : DM-masterプロセスの実行に関する設定ファイル。DM-masterのトポロジ情報とログが含まれます。詳細については、 [DM-masterコンフィグレーションファイル](/dm/dm-master-configuration-file.md)を参照してください。 +- `dm-worker.toml` : DM-workerプロセスの実行に関する設定ファイル。DM-workerのトポロジ情報とログが含まれます。詳細は[DM-workerコンフィグレーションファイル](/dm/dm-worker-configuration-file.md)を参照してください。 - `source.yaml` : MySQLやMariaDBなどの上流データベースの設定。詳細は[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)を参照してください。 ## DM移行タスクの構成 {#dm-migration-task-configuration} @@ -30,5 +30,5 @@ summary: このドキュメントでは、データ移行構成ファイルの | 概念 | 説明 | コンフィグレーションファイル | | :---------- | :-------------------------------------------------------------------------- | :--------------------------------------------------------- | | `source-id` | MySQLまたはMariaDBインスタンス、あるいはプライマリ/セカンダリ構造の移行グループを一意に表します。`source-id`の最大長は32です。 | `source_id` / `source.yaml` ;
    `task.yaml`中`source-id` | -| DMマスターID | DMマスターを一意に表す（ `dm-master.toml`の`master-addr`パラメータによって） | `master-addr` / `dm-master.toml` | -| DMワーカーID | DMワーカーを一意に表す（ `dm-worker.toml`の`worker-addr`のパラメータによって） | `worker-addr` / `dm-worker.toml` | +| DM-masterID | DM-masterを一意に表す（ `dm-master.toml`の`master-addr`パラメータによって） | `master-addr` / `dm-master.toml` | +| DM-workerID | DM-workerを一意に表す（ `dm-worker.toml`の`worker-addr`のパラメータによって） | `worker-addr` / `dm-worker.toml` | diff --git a/dm/dm-customized-secret-key.md b/dm/dm-customized-secret-key.md index ccaea1801b4e4..2e9e20eeda2a7 100644 --- a/dm/dm-customized-secret-key.md +++ b/dm/dm-customized-secret-key.md @@ -18,20 +18,20 @@ DM はバージョン 8.0.0 以降では固定秘密キーを使用しなくな - [データソース構成](/dm/dm-source-configuration-file.md)と[移行タスクの構成](/dm/task-configuration-file-full.md)両方でプレーンテキスト パスワードが使用されている場合、アップグレードに追加の手順は必要ありません。 - [データソース構成](/dm/dm-source-configuration-file.md)と[移行タスクの構成](/dm/task-configuration-file-full.md)で暗号化されたパスワードが使用されている場合、または将来的に暗号化されたパスワードを使用する場合は、次の手順を実行する必要があります。 - 1. [DMマスター構成ファイル](/dm/dm-master-configuration-file.md)に`secret-key-path`パラメータを追加し、カスタムキーファイルのパスを指定します。ファイルには、64 文字の 16 進数 AES-256 キーが含まれている必要があります。アップグレード前に[固定AES-256秘密鍵](https://github.com/pingcap/tiflow/blob/1252979421fc83ffa2a1548d981e505f7fc0b909/dm/pkg/encrypt/encrypt.go#L27)を使用して暗号化していた場合は、この秘密鍵をキーファイルにコピーできます。すべての DM マスターノードで同じ秘密鍵設定が使用されていることを確認してください。 - 2. まずDMマスターのローリングアップグレードを実行し、次にDMワーカーのローリングアップグレードを実行します。詳細については、 [ローリングアップグレード](/dm/maintain-dm-using-tiup.md#rolling-upgrade)を参照してください。 + 1. [DM-master構成ファイル](/dm/dm-master-configuration-file.md)に`secret-key-path`パラメータを追加し、カスタムキーファイルのパスを指定します。ファイルには、64 文字の 16 進数 AES-256 キーが含まれている必要があります。アップグレード前に[固定AES-256秘密鍵](https://github.com/pingcap/tiflow/blob/1252979421fc83ffa2a1548d981e505f7fc0b909/dm/pkg/encrypt/encrypt.go#L27)を使用して暗号化していた場合は、この秘密鍵をキーファイルにコピーできます。すべての DM-masterノードで同じ秘密鍵設定が使用されていることを確認してください。 + 2. まずDM-masterのローリングアップグレードを実行し、次にDM-workerのローリングアップグレードを実行します。詳細については、 [ローリングアップグレード](/dm/maintain-dm-using-tiup.md#rolling-upgrade)を参照してください。 ## 暗号化と復号化の秘密鍵を更新する {#update-the-secret-key-for-encryption-and-decryption} 暗号化と復号化に使用される秘密キーを更新するには、次の手順を実行します。 -1. [DMマスター構成ファイル](/dm/dm-master-configuration-file.md)のアップデート`secret-key-path` 。 +1. [DM-master構成ファイル](/dm/dm-master-configuration-file.md)のアップデート`secret-key-path` 。 > **Note:** > - > - すべての DM マスターノードが同じ秘密キー構成に更新されていることを確認します。 + > - すべての DM-masterノードが同じ秘密キー構成に更新されていることを確認します。 > - 秘密鍵の更新中は、新しい[データソース構成ファイル](/dm/dm-source-configuration-file.md)または[移行タスク構成ファイル](/dm/task-configuration-file-full.md)を作成しないでください。 -2. DM マスターのローリング再起動を実行します。 +2. DM-masterのローリング再起動を実行します。 3. 新しい[データソース構成ファイル](/dm/dm-source-configuration-file.md)と[移行タスク構成ファイル](/dm/task-configuration-file-full.md)を作成するときは、 `tiup dmctl encrypt` (dmctl バージョン >= v8.0.0) で暗号化されたパスワードを使用します。 diff --git a/dm/dm-daily-check.md b/dm/dm-daily-check.md index dcf76a2d01b86..4206f13de44a6 100644 --- a/dm/dm-daily-check.md +++ b/dm/dm-daily-check.md @@ -13,5 +13,5 @@ summary: TiDB Data Migration (DM) の毎日のチェックについて説明し - 方法 3: ログファイルを使用して、DM の実行状態とエラー (ある場合) を確認します。 - - DMマスターログディレクトリ：DMマスタープロセスパラメータ`--log-file`で指定します。DMがTiUPを使用してデプロイされている場合、DMマスターノードのログディレクトリは`{log_dir}`になります。 - - DMワーカーのログディレクトリ：DMワーカープロセスパラメータ`--log-file`で指定します。DMがTiUPを使用してデプロイされている場合、ログディレクトリはDMワーカーノードの`{log_dir}`になります。 + - DM-masterログディレクトリ：DM-masterプロセスパラメータ`--log-file`で指定します。DMがTiUPを使用してデプロイされている場合、DM-masterノードのログディレクトリは`{log_dir}`になります。 + - DM-workerのログディレクトリ：DM-workerプロセスパラメータ`--log-file`で指定します。DMがTiUPを使用してデプロイされている場合、ログディレクトリはDM-workerノードの`{log_dir}`になります。 diff --git a/dm/dm-enable-tls.md b/dm/dm-enable-tls.md index afc7e541d730e..251429316b8c8 100644 --- a/dm/dm-enable-tls.md +++ b/dm/dm-enable-tls.md @@ -5,17 +5,17 @@ summary: DM 接続で TLS を有効にする方法を学習します。 # DM接続にTLSを有効にする {#enable-tls-for-dm-connections} -このドキュメントでは、DM マスター、DM ワーカー、dmctl コンポーネント間の接続、および DM と上流または下流データベース間の接続を含む、DM 接続の暗号化されたデータ転送を有効にする方法について説明します。 +このドキュメントでは、DM-master、DM-worker、dmctl コンポーネント間の接続、および DM と上流または下流データベース間の接続を含む、DM 接続の暗号化されたデータ転送を有効にする方法について説明します。 -## DMマスター、DMワーカー、dmctl間の暗号化されたデータ転送を有効にする {#enable-encrypted-data-transmission-between-dm-master-dm-worker-and-dmctl} +## DM-master、DM-worker、dmctl間の暗号化されたデータ転送を有効にする {#enable-encrypted-data-transmission-between-dm-master-dm-worker-and-dmctl} -このセクションでは、DM マスター、DM ワーカー、dmctl 間の暗号化されたデータ転送を有効にする方法を紹介します。 +このセクションでは、DM-master、DM-worker、dmctl 間の暗号化されたデータ転送を有効にする方法を紹介します。 ### 暗号化されたデータ転送を設定して有効にする {#configure-and-enable-encrypted-data-transmission} 1. 証明書を準備します。 - DMマスターとDMワーカーそれぞれにサーバー証明書を別々に用意することをお勧めします。2つのコンポーネントが相互に認証できることを確認してください。dmctlでは1つのクライアント証明書を共有することもできます。 + DM-masterとDM-workerそれぞれにサーバー証明書を別々に用意することをお勧めします。2つのコンポーネントが相互に認証できることを確認してください。dmctlでは1つのクライアント証明書を共有することもできます。 自己署名証明書を生成するには、 `openssl` 、 `cfssl` 、および`easy-rsa`などの`openssl`に基づいたその他のツールを使用できます。 @@ -27,7 +27,7 @@ summary: DM 接続で TLS を有効にする方法を学習します。 > > DM-master、DM-worker、および dmctl が同じ証明書セットを使用するように構成できます。 - - DMマスター + - DM-master 設定ファイルまたはコマンドライン引数で設定します。 @@ -37,7 +37,7 @@ summary: DM 接続で TLS を有効にする方法を学習します。 ssl-key = "/path/to/master-key.pem" ``` - - DMワーカー + - DM-worker 設定ファイルまたはコマンドライン引数で設定します。 @@ -61,7 +61,7 @@ summary: DM 接続で TLS を有効にする方法を学習します。 コンポーネントの呼び出し元の ID を確認するには、証明書を生成するときに`Common Name` (CN) を使用して証明書のユーザー ID をマークし、呼び出し先の`Common Name`リストを構成して呼び出し元の ID を確認する必要があります。 -- DMマスター +- DM-master 設定ファイルまたはコマンドライン引数で設定します。 @@ -69,7 +69,7 @@ summary: DM 接続で TLS を有効にする方法を学習します。 cert-allowed-cn = ["dm"] ``` -- DMワーカー +- DM-worker 設定ファイルまたはコマンドライン引数で設定します。 @@ -95,7 +95,7 @@ summary: DM 接続で TLS を有効にする方法を学習します。 > **Note:** > - > すべての DM マスターおよび DM ワーカー コンポーネントが指定されたパスを介して証明書とキー ファイルを読み取ることができることを確認します。 + > すべての DM-masterおよび DM-worker コンポーネントが指定されたパスを介して証明書とキー ファイルを読み取ることができることを確認します。 ```yaml from: @@ -113,7 +113,7 @@ summary: DM 接続で TLS を有効にする方法を学習します。 > **Note:** > - > すべての DM マスターおよび DM ワーカー コンポーネントが指定されたパスを介して証明書とキー ファイルを読み取ることができることを確認します。 + > すべての DM-masterおよび DM-worker コンポーネントが指定されたパスを介して証明書とキー ファイルを読み取ることができることを確認します。 ```yaml target-database: diff --git a/dm/dm-error-handling.md b/dm/dm-error-handling.md index c9452a005d877..91708c7f6e597 100644 --- a/dm/dm-error-handling.md +++ b/dm/dm-error-handling.md @@ -36,8 +36,8 @@ summary: DM を使用する際のエラー システムと一般的なエラー | `dump-unit` | ダンプ処理装置 | `[code=32001:class=dump-unit:scope=internal:level=high] mydumper runs with error: CRITICAL **: 15:12:17.559: Error connecting to database: Access denied for user 'root'@'172.17.0.1' (using password: NO)` | | `load-unit` | 負荷処理装置 | `[code=34002:class=load-unit:scope=internal:level=high] corresponding ending of sql: ')' not found` | | `sync-unit` | 同期処理ユニット | `[code=36027:class=sync-unit:scope=internal:level=high] Column count doesn't match value count: 9 (columns) vs 10 (values)` | - | `dm-master` | DMマスターサービス | `[code=38008:class=dm-master:scope=internal:level=high] grpc request error: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp 172.17.0.2:8262: connect: connection refused"` | - | `dm-worker` | DMワーカーサービス | `[code=40066:class=dm-worker:scope=internal:level=high] ExecuteDDL timeout, try use query-status to query whether the DDL is still blocking` | + | `dm-master` | DM-masterサービス | `[code=38008:class=dm-master:scope=internal:level=high] grpc request error: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp 172.17.0.2:8262: connect: connection refused"` | + | `dm-worker` | DM-workerサービス | `[code=40066:class=dm-worker:scope=internal:level=high] ExecuteDDL timeout, try use query-status to query whether the DDL is still blocking` | | `dm-tracer` | DMトレーサーサービス | `[code=42004:class=dm-tracer:scope=internal:level=medium] trace event test.1 not found` | | `schema-tracker` | スキーマトラッカー（増分データレプリケーション中） | `[code=44006:class=schema-tracker:scope=internal:level=high],"cannot track DDL: ALTER TABLE test DROP COLUMN col1"` | | `scheduler` | 操作のスケジュール設定（データ移行タスク） | `[code=46001:class=scheduler:scope=internal:level=high],"the scheduler has not started"` | @@ -77,7 +77,7 @@ DM の実行中にエラーが発生した場合は、次の手順に従って 1. `query-status`コマンドを実行して、タスクの実行ステータスとエラー出力を確認します。 -2. エラーに関連するログファイルを確認してください。ログファイルはDMマスターノードとDMワーカーノードにあります。エラーに関する重要な情報を取得するには、 [エラーシステム](#error-system)を参照してください。その後、 [よくあるエラーの処理](#handle-common-errors)セクションを参照して解決策を見つけてください。 +2. エラーに関連するログファイルを確認してください。ログファイルはDM-masterノードとDM-workerノードにあります。エラーに関する重要な情報を取得するには、 [エラーシステム](#error-system)を参照してください。その後、 [よくあるエラーの処理](#handle-common-errors)セクションを参照して解決策を見つけてください。 3. このドキュメントにエラーが記載されておらず、ログを確認したりメトリックを監視したりしても問題を解決できない場合は、PingCAP またはコミュニティから[サポートを受けて](/support.md)ください。 @@ -101,7 +101,7 @@ DM の実行中にエラーが発生した場合は、次の手順に従って | | | | | `code=11006` | DM の組み込みパーサーが互換性のない DDL ステートメントを解析するときに発生します。 | 解決策については[データ移行 - 互換性のない DDL ステートメント](/dm/dm-faq.md#how-to-handle-incompatible-ddl-statements)を参照してください。 | | `code=20010` | タスク構成で指定されたデータベース パスワードを復号化するときに発生します。 | 構成タスクで指定されたダウンストリームデータベース パスワードが[dmctlを使用して正しく暗号化されました](/dm/dm-manage-source.md#encrypt-the-database-password)あるかどうかを確認します。 | -| `code=26002` | タスクチェックでデータベース接続を確立できませんでした。詳細なエラー情報については、エラーメッセージを確認してください。エラーメッセージには通常、データベース操作で返されたエラーコードとエラー情報が含まれています。 | DM マスターが配置されているマシンにアップストリームにアクセスする権限があるかどうかを確認します。 | +| `code=26002` | タスクチェックでデータベース接続を確立できませんでした。詳細なエラー情報については、エラーメッセージを確認してください。エラーメッセージには通常、データベース操作で返されたエラーコードとエラー情報が含まれています。 | DM-masterが配置されているマシンにアップストリームにアクセスする権限があるかどうかを確認します。 | | `code=32001` | 異常ダンプ処理装置 | エラーメッセージに`mydumper: argument list too long.`が含まれている場合は、ブロック/許可リストに従って、 `task.yaml`ファイルの Mydumper 引数`extra-args`に`--regex`正規表現を手動で追加して、エクスポートするテーブルを設定します。例えば、 `hello`という名前のテーブルをすべてエクスポートするには`--regex '.*\\.hello$'`を追加し、すべてのテーブルをエクスポートするには`--regex '.*'`を追加します。 | | `code=38008` | DM コンポーネント間の gRPC 通信でエラーが発生します。 | チェック`class` ：どのコンポーネントの相互作用でエラーが発生しているかを確認します。通信エラーの種類を特定します。gRPC接続の確立時にエラーが発生する場合は、通信サーバーが正常に動作しているかどうかを確認します。 | @@ -142,15 +142,15 @@ DMは移行タスクにおいてデータを下流へ並行して移行する機 1. エラーが発生したときに、対応するbinlogファイルのサイズが 4GB を超えたことをアップストリームで特定します。 -2. DM ワーカーを停止します。 +2. DM-workerを停止します。 3. アップストリーム内の対応するbinlogファイルをリレーログファイルとしてリレーログディレクトリにコピーします。 -4. リレーログディレクトリ内の対応する`relay.meta`のファイルを更新し、次のbinlogファイルから取得します。DMワーカーに`enable_gtid`を`true`に指定した場合は、 `relay.meta`ファイルを更新するときに、次のbinlogファイルに対応するGTIDを変更する必要があります。それ以外の場合は、GTIDを変更する必要はありません。 +4. リレーログディレクトリ内の対応する`relay.meta`のファイルを更新し、次のbinlogファイルから取得します。DM-workerに`enable_gtid`を`true`に指定した場合は、 `relay.meta`ファイルを更新するときに、次のbinlogファイルに対応するGTIDを変更する必要があります。それ以外の場合は、GTIDを変更する必要はありません。 例: エラーが発生した場合、 `binlog-name = "mysql-bin.004451"`と`binlog-pos = 2453`をそれぞれ`binlog-name = "mysql-bin.004452"`と`binlog-pos = 4`に更新し、 `binlog-gtid`を`f0e914ef-54cf-11e7-813d-6c92bf2fa791:1-138218058`に更新します。 -5. DM ワーカーを再起動します。 +5. DM-workerを再起動します。 binlogレプリケーション処理ユニットの場合は、次のソリューションを使用して手動で移行を回復します。 diff --git a/dm/dm-faq.md b/dm/dm-faq.md index 6e0233e41d03b..085670dda3b95 100644 --- a/dm/dm-faq.md +++ b/dm/dm-faq.md @@ -64,7 +64,7 @@ TiDBでサポートされていないDDL文に遭遇した場合は、dmctlを ただし、メモリ内の DDL 情報は、次の2つの方法のいずれかで取得されます。 - DM [`alter ghost_table`操作中に gh-ost テーブルを処理する](/dm/feature-online-ddl.md#online-schema-change-gh-ost)および`ghost_table`の DDL 情報を記録します。 -- DM ワーカーが再起動されてタスクが開始されると、DM は`dm_meta.{task_name}_onlineddl`から DDL を読み取ります。 +- DM-workerが再起動されてタスクが開始されると、DM は`dm_meta.{task_name}_onlineddl`から DDL を読み取ります。 そのため、増分レプリケーションのプロセスにおいて、指定されたPosが`alter ghost_table` DDLをスキップしたにもかかわらず、そのPosがgh-ostのオンラインDDLプロセス中である場合、ghost_tableはメモリまたは`dm_meta.{task_name}_onlineddl`に正しく書き込まれません。このような場合、上記のエラーが返されます。 @@ -201,7 +201,7 @@ DM-worker のログファイルを確認し、 `change count`を含む行を探 ## DM v2.0 では、タスク中に DM が再起動すると、完全インポートタスクが失敗するのはなぜですか? {#in-dm-v20-why-does-the-full-import-task-fail-if-dm-restarts-during-the-task} -DM v2.0.1 以前のバージョンでは、完全インポートが完了する前に DM が再起動すると、上流のデータソースと DM ワーカーノード間のバインディングが変更される可能性があります。例えば、ダンプユニットの中間データが DM ワーカーノード A にあるにもかかわらず、ロードユニットが DM ワーカーノード B で実行されている場合、操作が失敗する可能性があります。 +DM v2.0.1 以前のバージョンでは、完全インポートが完了する前に DM が再起動すると、上流のデータソースと DM-workerノード間のバインディングが変更される可能性があります。例えば、ダンプユニットの中間データが DM-workerノード A にあるにもかかわらず、ロードユニットが DM-workerノード B で実行されている場合、操作が失敗する可能性があります。 この問題に対する解決策は次の2つです。 @@ -211,12 +211,12 @@ DM v2.0.1 以前のバージョンでは、完全インポートが完了する 2. エクスポートされたデータのディレクトリ内のすべてのファイルを削除します。 3. dmctl を使用してタスクを削除し、コマンド`start-task --remove-meta`を実行して新しいタスクを作成します。 - 新しいタスクが開始したら、冗長な DM ワーカーノードが存在しないことを確認し、完全インポート中に DM クラスターの再起動やアップグレードを行わないようにすることをお勧めします。 + 新しいタスクが開始したら、冗長な DM-workerノードが存在しないことを確認し、完全インポート中に DM クラスターの再起動やアップグレードを行わないようにすることをお勧めします。 - データ量が大きい場合 (1 TB を超える場合) は、次の手順を実行します。 1. ダウンストリームデータベースにインポートされたデータをクリーンアップします。 - 2. データを処理する DM ワーカーノードに TiDB-Lightningをデプロイします。 + 2. データを処理する DM-workerノードに TiDB-Lightningをデプロイします。 3. DM ダンプユニットがエクスポートするデータをインポートするには、TiDB-Lightning のローカルバックエンド モードを使用します。 4. 完全インポートが完了したら、次の方法でタスク構成ファイルを編集し、タスクを再起動します。 - `task-mode`を`incremental`に変更します。 @@ -352,19 +352,19 @@ query-status test 上記の 1 番目と 2 番目のソリューションで正常にレプリケートできるデータソース (上記の例の`mysql2`など) の場合は、増分タスクを設定するときに、 `subTaskStatus.sync`の`syncerBinlog`と`syncerBinlogGtid`情報を使用して関連する`mysql-instances.meta`を構成します。 -## DM v2.0 では、 `heartbeat`機能が有効になっている仮想 IP 環境で DM ワーカーと MySQL インスタンス間の接続を切り替えるときに、「ハートビート構成が以前使用したものと異なります: serverID が等しくありません」というエラーをどのように処理すればよいですか? {#in-dm-v20-how-do-i-handle-the-error-heartbeat-config-is-different-from-previous-used-serverid-not-equal-when-switching-the-connection-between-dm-workers-and-mysql-instances-in-a-virtual-ip-environment-with-the-heartbeat-feature-enabled} +## DM v2.0 では、 `heartbeat`機能が有効になっている仮想 IP 環境で DM-workerと MySQL インスタンス間の接続を切り替えるときに、「ハートビート構成が以前使用したものと異なります: serverID が等しくありません」というエラーをどのように処理すればよいですか? {#in-dm-v20-how-do-i-handle-the-error-heartbeat-config-is-different-from-previous-used-serverid-not-equal-when-switching-the-connection-between-dm-workers-and-mysql-instances-in-a-virtual-ip-environment-with-the-heartbeat-feature-enabled} DM v2.0以降のバージョンでは、 `heartbeat`機能はデフォルトで無効になっています。タスク設定ファイルでこの機能を有効にすると、高可用性機能に支障をきたします。この問題を解決するには、タスク設定ファイルで`enable-heartbeat`を`false`に設定して`heartbeat`機能を無効にし、その後タスク設定ファイルをリロードしてください。DMは、以降のリリースで`heartbeat`機能を強制的に無効にします。 -## DM マスターが再起動後にクラスターに参加できず、DM が「埋め込み etcd の開始に失敗しました。RawCause: メンバー xxx はすでにブートストラップされています」というエラーを報告するのはなぜですか? {#why-does-a-dm-master-fail-to-join-the-cluster-after-it-restarts-and-dm-reports-the-error-fail-to-start-embed-etcd-rawcause-member-xxx-has-already-been-bootstrapped} +## DM-masterが再起動後にクラスターに参加できず、DM が「埋め込み etcd の開始に失敗しました。RawCause: メンバー xxx はすでにブートストラップされています」というエラーを報告するのはなぜですか? {#why-does-a-dm-master-fail-to-join-the-cluster-after-it-restarts-and-dm-reports-the-error-fail-to-start-embed-etcd-rawcause-member-xxx-has-already-been-bootstrapped} -DMマスターが起動すると、DMはetcd情報をカレントディレクトリに記録します。DMマスターの再起動後にディレクトリが変更されると、DMはetcd情報にアクセスできなくなり、再起動に失敗します。 +DM-masterが起動すると、DMはetcd情報をカレントディレクトリに記録します。DM-masterの再起動後にディレクトリが変更されると、DMはetcd情報にアクセスできなくなり、再起動に失敗します。 -この問題を解決するには、 TiUPを使用して DM クラスターをメンテナンスすることをお勧めします。バイナリファイルを使用してデプロイする必要がある場合は、DM マスターの設定ファイルで`data-dir`を絶対パスで設定するか、コマンドを実行する現在のディレクトリに注意してください。 +この問題を解決するには、 TiUPを使用して DM クラスターをメンテナンスすることをお勧めします。バイナリファイルを使用してデプロイする必要がある場合は、DM-masterの設定ファイルで`data-dir`を絶対パスで設定するか、コマンドを実行する現在のディレクトリに注意してください。 -## dmctl を使用してコマンドを実行すると、DM マスターに接続できないのはなぜですか? {#why-dm-master-cannot-be-connected-when-i-use-dmctl-to-execute-commands} +## dmctl を使用してコマンドを実行すると、DM-masterに接続できないのはなぜですか? {#why-dm-master-cannot-be-connected-when-i-use-dmctl-to-execute-commands} -dmctl execute コマンドを使用すると、DM マスターへの接続に失敗し（コマンドでパラメータ値`--master-addr`を指定している場合でも）、エラーメッセージ`RawCause: context deadline exceeded, Workaround: please check your network connection.`が表示される場合があります。ただし、コマンド`telnet `などを使用してネットワーク接続を確認すると、例外は見つかりません。 +dmctl execute コマンドを使用すると、DM-masterへの接続に失敗し（コマンドでパラメータ値`--master-addr`を指定している場合でも）、エラーメッセージ`RawCause: context deadline exceeded, Workaround: please check your network connection.`が表示される場合があります。ただし、コマンド`telnet `などを使用してネットワーク接続を確認すると、例外は見つかりません。 この場合、環境変数`https_proxy` （ **https** ）を確認してください。この変数が設定されている場合、dmctl は`https_proxy`で指定されたホストとポートに自動的に接続します。ホストに対応する`proxy`転送サービスがない場合、接続は失敗します。 diff --git a/dm/dm-generate-self-signed-certificates.md b/dm/dm-generate-self-signed-certificates.md index 3a80cfb115fa5..74cfa6785c177 100644 --- a/dm/dm-generate-self-signed-certificates.md +++ b/dm/dm-generate-self-signed-certificates.md @@ -11,12 +11,12 @@ summary: openssl` を使用して自己署名証明書を生成します。 | 名前 | ホストIP | サービス | | ---- | ------------ | ------- | -| ノード1 | 172.16.10.11 | DMマスター1 | -| ノード2 | 172.16.10.12 | DMマスター2 | -| ノード3 | 172.16.10.13 | DMマスター3 | -| ノード4 | 172.16.10.14 | DMワーカー1 | -| ノード5 | 172.16.10.15 | DMワーカー2 | -| ノード6 | 172.16.10.16 | DMワーカー3 | +| ノード1 | 172.16.10.11 | DM-master1 | +| ノード2 | 172.16.10.12 | DM-master2 | +| ノード3 | 172.16.10.13 | DM-master3 | +| ノード4 | 172.16.10.14 | DM-worker1 | +| ノード5 | 172.16.10.15 | DM-worker2 | +| ノード6 | 172.16.10.16 | DM-worker3 | ## OpenSSLをインストールする {#install-openssl} @@ -62,11 +62,11 @@ summary: openssl` を使用して自己署名証明書を生成します。 - DM-master が他のコンポーネントに対して DM-master を認証するために使用する`master`証明書。 - DM-worker が他のコンポーネントに対して DM-worker を認証するために使用する`worker`証明書。 -- DM マスターと DM ワーカーのクライアントを認証するために dmctl によって使用される`client`証明書。 +- DM-masterと DM-workerのクライアントを認証するために dmctl によって使用される`client`証明書。 -### DMマスターの証明書を発行する {#issue-certificates-for-dm-master} +### DM-masterの証明書を発行する {#issue-certificates-for-dm-master} -DM マスター インスタンスに証明書を発行するには、次の手順を実行します。 +DM-master インスタンスに証明書を発行するには、次の手順を実行します。 1. 証明書に対応する秘密鍵を生成します。 @@ -136,7 +136,7 @@ DM マスター インスタンスに証明書を発行するには、次の手 > **Note:** > -> DM ワーカーインスタンスの証明書を発行するプロセスも同様であるため、このドキュメントでは繰り返しません。 +> DM-workerインスタンスの証明書を発行するプロセスも同様であるため、このドキュメントでは繰り返しません。 ### クライアントの証明書を発行する (dmctl) {#issue-certificates-for-the-client-dmctl} diff --git a/dm/dm-glossary.md b/dm/dm-glossary.md index aade8ee202dc1..d00a173425f59 100644 --- a/dm/dm-glossary.md +++ b/dm/dm-glossary.md @@ -117,7 +117,7 @@ TiDB データ移行ツールを使用して、上流データベースの**増 ### サブタスク {#subtask} -サブタスクは、各 DM ワーカーインスタンスで実行されるデータ移行タスクの一部です。タスク構成によっては、1つのデータ移行タスクに 1つのサブタスクが含まれる場合もあれば、複数のサブタスクが含まれる場合もあります。 +サブタスクは、各 DM-workerインスタンスで実行されるデータ移行タスクの一部です。タスク構成によっては、1つのデータ移行タスクに 1つのサブタスクが含まれる場合もあれば、複数のサブタスクが含まれる場合もあります。 ### サブタスクのステータス {#subtask-status} @@ -131,7 +131,7 @@ TiDB データ移行ツールを使用して、上流データベースの**増 ### タスク {#task} -データ移行タスクは、コマンド`start-task`の実行に成功した後に開始されます。タスク構成によっては、単一の移行タスクを単一のDMワーカーインスタンスで実行することも、複数のDMワーカーインスタンスで同時に実行することもできます。 +データ移行タスクは、コマンド`start-task`の実行に成功した後に開始されます。タスク構成によっては、単一の移行タスクを単一のDM-workerインスタンスで実行することも、複数のDM-workerインスタンスで同時に実行することもできます。 ### タスクのステータス {#task-status} diff --git a/dm/dm-handle-alerts.md b/dm/dm-handle-alerts.md index 3b63c07ee602f..5f2aa6ca4dedb 100644 --- a/dm/dm-handle-alerts.md +++ b/dm/dm-handle-alerts.md @@ -13,26 +13,26 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - すべての DM マスターノードがオフラインの場合、このアラートがトリガーされます。 + すべての DM-masterノードがオフラインの場合、このアラートがトリガーされます。 - 解決： アラートを処理するには、次の手順を実行できます。 1. クラスターの環境を確認します。 - 2. トラブルシューティングのために、すべての DM マスターノードのログを確認してください。 + 2. トラブルシューティングのために、すべての DM-masterノードのログを確認してください。 ### `DM_worker_offline` {#dm-worker-offline} - 説明： - DMワーカーノードが1時間以上オフラインの場合、このアラートがトリガーされます。高可用性アーキテクチャでは、このアラートによってタスクが直接中断されることはないかもしれませんが、中断のリスクが高まります。 + DM-workerノードが1時間以上オフラインの場合、このアラートがトリガーされます。高可用性アーキテクチャでは、このアラートによってタスクが直接中断されることはないかもしれませんが、中断のリスクが高まります。 - 解決： アラートを処理するには、次の手順を実行できます。 - 1. 対応する DM ワーカーノードの動作ステータスを確認する。 + 1. 対応する DM-workerノードの動作ステータスを確認する。 2. ノードが接続されているかどうかを確認します。 3. ログを通じてエラーをトラブルシューティングします。 @@ -62,7 +62,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - DM ワーカーのサブタスクが 20分以上`Paused`状態にある場合、アラートがトリガーされます。 + DM-workerのサブタスクが 20分以上`Paused`状態にある場合、アラートがトリガーされます。 - 解決： diff --git a/dm/dm-handle-performance-issues.md b/dm/dm-handle-performance-issues.md index 96da29d04cbdd..db62703aa3fb6 100644 --- a/dm/dm-handle-performance-issues.md +++ b/dm/dm-handle-performance-issues.md @@ -25,11 +25,11 @@ summary: DM に存在する可能性のある一般的なパフォーマンス ### binlogデータを読み取る {#read-binlog-data} -`read binlog event duration` 、リレーログが上流データベース（MySQL/MariaDB）からbinlogを読み取る時間を表します。理想的には、このメトリックは DM ワーカーと MySQL/MariaDB インスタンス間のネットワークレイテンシーに近い値になります。 +`read binlog event duration` 、リレーログが上流データベース（MySQL/MariaDB）からbinlogを読み取る時間を表します。理想的には、このメトリックは DM-workerと MySQL/MariaDB インスタンス間のネットワークレイテンシーに近い値になります。 - 単一データセンター内でのデータ移行では、 binlogデータの読み取りはパフォーマンスのボトルネックにはなりません。値が`read binlog event duration`に設定されている場合は、DM-workerとMySQL/MariaDB間のネットワーク接続を確認してください。 -- 地理的に分散された環境でのデータ移行では、DM ワーカーと MySQL/MariaDB を 1つのデータセンターにデプロイし、TiDB クラスターをターゲット データセンターにデプロイするようにしてください。 +- 地理的に分散された環境でのデータ移行では、DM-workerと MySQL/MariaDB を 1つのデータセンターにデプロイし、TiDB クラスターをターゲット データセンターにデプロイするようにしてください。 アップストリーム データベースからbinlogデータを読み取るプロセスには、次のサブプロセスが含まれます。 @@ -47,7 +47,7 @@ DMのリレー処理ユニットは、binlogイベントをDMメモリに読み ### リレーログファイルを書き込む {#write-relay-log-files} -binlogイベントをリレーログファイルに書き込む場合、関連するパフォーマンスメトリックは`write relay log duration`です。`binlog event size`が大きすぎない場合は、この値はマイクロ秒単位にする必要があります。`write relay log duration`が大きすぎる場合は、ディスクの書き込みパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DMワーカーにローカルSSDを使用してください。 +binlogイベントをリレーログファイルに書き込む場合、関連するパフォーマンスメトリックは`write relay log duration`です。`binlog event size`が大きすぎない場合は、この値はマイクロ秒単位にする必要があります。`write relay log duration`が大きすぎる場合は、ディスクの書き込みパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DM-workerにローカルSSDを使用してください。 ## 負荷ユニット {#load-unit} @@ -68,7 +68,7 @@ Binlogレプリケーションユニットは、設定に応じて、上流のMy - DM のBinlogレプリケーション処理ユニットがアップストリーム MySQL/MariaDB からbinlogイベントを読み取る場合、問題を特定して解決するには、「リレーログユニット」セクションの[binlogデータを読み取る](#read-binlog-data)を参照してください。 -- DMのBinlogレプリケーション処理ユニットがリレーログファイルからbinlogイベントを読み取る場合、 `binlog event size`が大きすぎない場合、 `read binlog event duration`の値はマイクロ秒単位にする必要があります。`read binlog event duration`が大きすぎる場合は、ディスクの読み取りパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DMワーカーにローカルSSDを使用してください。 +- DMのBinlogレプリケーション処理ユニットがリレーログファイルからbinlogイベントを読み取る場合、 `binlog event size`が大きすぎない場合、 `read binlog event duration`の値はマイクロ秒単位にする必要があります。`read binlog event duration`が大きすぎる場合は、ディスクの読み取りパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DM-workerにローカルSSDを使用してください。 ### binlogイベント変換 {#binlog-event-conversion} diff --git a/dm/dm-hardware-and-software-requirements.md b/dm/dm-hardware-and-software-requirements.md index 1b0d523a3e0b3..90219aa28791b 100644 --- a/dm/dm-hardware-and-software-requirements.md +++ b/dm/dm-hardware-and-software-requirements.md @@ -24,22 +24,22 @@ DMは、64ビット汎用ハードウェアサーバープラットフォーム | コンポーネント | CPU | メモリ | ローカルストレージ | ネットワーク | インスタンス数（最小要件） | | ------ | ----- | ------ | ---------------------------- | -------------- | --------------------- | -| DMマスター | 4コア以上 | 8GB以上 | SAS、200 GB以上 | ギガビットネットワークカード | 1 | -| DMワーカー | 8コア以上 | 16GB以上 | SAS、200 GB以上（移行データのサイズより大きい） | ギガビットネットワークカード | アップストリームMySQLインスタンスの数 | +| DM-master | 4コア以上 | 8GB以上 | SAS、200 GB以上 | ギガビットネットワークカード | 1 | +| DM-worker | 8コア以上 | 16GB以上 | SAS、200 GB以上（移行データのサイズより大きい） | ギガビットネットワークカード | アップストリームMySQLインスタンスの数 | > **Note:** > > - テスト環境では、機能検証に使用する DM-master と DM-worker を同じサーバー上に配置できます。 > - パフォーマンス テスト結果の精度を損なわないようにするために、低パフォーマンスのストレージおよびネットワーク ハードウェア構成を使用することは**お勧めしません**。 -> - 機能の検証のみが必要な場合は、DMマスターを1台のマシンにデプロイできます。デプロイするDMワーカーの数は、上流のMySQLインスタンスの数以上である必要があります。高可用性を確保するには、より多くのDMワーカーをデプロイすることをお勧めします。 +> - 機能の検証のみが必要な場合は、DM-masterを1台のマシンにデプロイできます。デプロイするDM-workerの数は、上流のMySQLインスタンスの数以上である必要があります。高可用性を確保するには、より多くのDM-workerをデプロイすることをお勧めします。 > - DM-workerはフェーズ`dump`とフェーズ`load`で全データを保存します。そのため、DM-workerのディスク容量は、移行するデータの総量よりも大きくする必要があります。移行タスクでリレーログが有効になっている場合、DM-workerは上流のbinlogデータを保存するために追加のディスク容量を必要とします。 ### 本番環境 {#production-environment} | コンポーネント | CPU | メモリ | ハードディスクの種類 | ネットワーク | インスタンス数（最小要件） | | ------ | ------ | ------- | ---------------------------- | ---------------- | --------------------------- | -| DMマスター | 4コア以上 | 8GB以上 | SAS、200 GB以上 | ギガビットネットワークカード | 3 | -| DMワーカー | 16コア以上 | 32 GB以上 | SSD、200 GB以上（移行データのサイズより大きい） | 10ギガビットネットワークカード | アップストリームのMySQLインスタンスの数より大きい | +| DM-master | 4コア以上 | 8GB以上 | SAS、200 GB以上 | ギガビットネットワークカード | 3 | +| DM-worker | 16コア以上 | 32 GB以上 | SSD、200 GB以上（移行データのサイズより大きい） | 10ギガビットネットワークカード | アップストリームのMySQLインスタンスの数より大きい | | モニター | 8コア以上 | 16GB以上 | SAS、200 GB以上 | ギガビットネットワークカード | 1 | > **Note:** diff --git a/dm/dm-manage-source.md b/dm/dm-manage-source.md index 415bfe8d722db..339cfb7dc86bd 100644 --- a/dm/dm-manage-source.md +++ b/dm/dm-manage-source.md @@ -5,7 +5,7 @@ summary: TiDB データ移行でアップストリーム MySQL インスタン # TiDB データ移行におけるデータソース構成の管理 {#manage-data-source-configurations-in-tidb-data-migration} -このドキュメントでは、MySQL パスワードの暗号化、データソースの操作、 [dmctl](/dm/dmctl-introduction.md)を使用したアップストリーム MySQL インスタンスと DM ワーカー間のバインディングの変更など、データソース構成を管理する方法について説明します。 +このドキュメントでは、MySQL パスワードの暗号化、データソースの操作、 [dmctl](/dm/dmctl-introduction.md)を使用したアップストリーム MySQL インスタンスと DM-worker間のバインディングの変更など、データソース構成を管理する方法について説明します。 ## データベースのパスワードを暗号化する {#encrypt-the-database-password} @@ -51,7 +51,7 @@ Global Flags: - `stop` : 1つ以上の上流データベースソースを停止します。複数のデータソースの停止に失敗した場合、一部のデータソースが停止される可能性があります。 -- `show` : 追加されたデータソースと対応する DM ワーカーを表示します。 +- `show` : 追加されたデータソースと対応する DM-workerを表示します。 - `config-file` : `source.yaml`のファイルパスを指定し、複数のファイルパスを渡すことができます。 @@ -138,9 +138,9 @@ operate-source show } ``` -## アップストリームのMySQLインスタンスとDMワーカー間のバインディングを変更する {#change-the-bindings-between-upstream-mysql-instances-and-dm-workers} +## アップストリームのMySQLインスタンスとDM-worker間のバインディングを変更する {#change-the-bindings-between-upstream-mysql-instances-and-dm-workers} -`transfer-source`コマンドを使用して、アップストリーム MySQL インスタンスと DM ワーカー間のバインディングを変更できます。 +`transfer-source`コマンドを使用して、アップストリーム MySQL インスタンスと DM-worker間のバインディングを変更できます。 ```bash help transfer-source @@ -160,7 +160,7 @@ Global Flags: ### 使用例 {#usage-example} -DM ワーカーのバインディングがわからない場合は、 `dmctl --master-addr list-member --worker`を実行して、すべてのワーカーの現在のバインディングを一覧表示できます。 +DM-workerのバインディングがわからない場合は、 `dmctl --master-addr list-member --worker`を実行して、すべてのワーカーの現在のバインディングを一覧表示できます。 ```bash list-member --worker diff --git a/dm/dm-master-configuration-file.md b/dm/dm-master-configuration-file.md index b5a9d91f15533..64365c3b71e2d 100644 --- a/dm/dm-master-configuration-file.md +++ b/dm/dm-master-configuration-file.md @@ -3,7 +3,7 @@ title: DM-master Configuration File summary: DM-master の設定ファイルについて説明します。 --- -# DMマスターコンフィグレーションファイル {#dm-master-configuration-file} +# DM-masterコンフィグレーションファイル {#dm-master-configuration-file} このドキュメントでは、構成ファイル テンプレートと、このファイル内の各構成パラメータの説明を含む、DM-master の構成について説明します。 @@ -40,13 +40,13 @@ secret-key-path = "/path/to/secret/key" ## コンフィグレーションパラメータ {#configuration-parameters} -このセクションでは、DM マスターの構成パラメータについて説明します。 +このセクションでは、DM-masterの構成パラメータについて説明します。 ### グローバル構成 {#global-configuration} #### `name` {#name} -- DM マスターの名前。 +- DM-masterの名前。 #### `log-level` {#log-level} @@ -60,39 +60,39 @@ secret-key-path = "/path/to/secret/key" #### `master-addr` {#master-addr} -- サービスを提供するDMマスターのアドレスを指定します。IPアドレスを省略し、ポート番号のみ（例： `":8261"` ）を指定することもできます。 +- サービスを提供するDM-masterのアドレスを指定します。IPアドレスを省略し、ポート番号のみ（例： `":8261"` ）を指定することもできます。 #### `advertise-addr` {#advertise-addr} -- DM マスターが外部に通知するアドレスを指定します。 +- DM-masterが外部に通知するアドレスを指定します。 #### `peer-urls` {#peer-urls} -- DM マスターノードのピア URL を指定します。 +- DM-masterノードのピア URL を指定します。 #### `advertise-peer-urls` {#advertise-peer-urls} -- DMマスターが外部にアドバタイズするピアURLを指定します。デフォルト値は`advertise-peer-urls`で、 [`peer-urls`](#peer-urls)と同じです。 +- DM-masterが外部にアドバタイズするピアURLを指定します。デフォルト値は`advertise-peer-urls`で、 [`peer-urls`](#peer-urls)と同じです。 #### `initial-cluster` {#initial-cluster} -- 値`initial-cluster`は、初期クラスター内のすべての DM マスターノードの[`advertise-peer-urls`](#advertise-peer-urls)値の組み合わせです。 +- 値`initial-cluster`は、初期クラスター内のすべての DM-masterノードの[`advertise-peer-urls`](#advertise-peer-urls)値の組み合わせです。 #### `join` {#join} -- `join`の値は、クラスター内の既存の DM マスターノードの[`advertise-peer-urls`](#advertise-peer-urls)値を組み合わせたものです。DM マスターノードを新たに追加する場合は、 `initial-cluster` `join`に置き換えてください。 +- `join`の値は、クラスター内の既存の DM-masterノードの[`advertise-peer-urls`](#advertise-peer-urls)値を組み合わせたものです。DM-masterノードを新たに追加する場合は、 `initial-cluster` `join`に置き換えてください。 #### `ssl-ca` {#ssl-ca} -- DM マスターが他のコンポーネントに接続するための信頼できる SSL CA のリストが含まれるファイルのパス。 +- DM-masterが他のコンポーネントに接続するための信頼できる SSL CA のリストが含まれるファイルのパス。 #### `ssl-cert` {#ssl-cert} -- DM マスターが他のコンポーネントに接続するための PEM 形式の X509 証明書を含むファイルのパス。 +- DM-masterが他のコンポーネントに接続するための PEM 形式の X509 証明書を含むファイルのパス。 #### `ssl-key` {#ssl-key} -- DM マスターが他のコンポーネントに接続するための PEM 形式の X509 キーを含むファイルのパス。 +- DM-masterが他のコンポーネントに接続するための PEM 形式の X509 キーを含むファイルのパス。 #### `cert-allowed-cn` {#cert-allowed-cn} diff --git a/dm/dm-open-api.md b/dm/dm-open-api.md index 0516cb450dc62..4bca816019bab 100644 --- a/dm/dm-open-api.md +++ b/dm/dm-open-api.md @@ -9,7 +9,7 @@ DM は、 [dmctlツール](/dm/dmctl-introduction.md)の機能と同様に、DM OpenAPI を有効にするには、次のいずれかの操作を実行します。 -- DM クラスターがバイナリを使用して直接デプロイされている場合は、DM マスター構成ファイルに次の構成を追加します。 +- DM クラスターがバイナリを使用して直接デプロイされている場合は、DM-master構成ファイルに次の構成を追加します。 ```toml openapi = true @@ -27,7 +27,7 @@ OpenAPI を有効にするには、次のいずれかの操作を実行します > > - DMはOpenAPI 3.0.0標準に準拠した[仕様書](https://github.com/pingcap/tiflow/blob/release-8.5/dm/openapi/spec/dm.yaml)提供します。このドキュメントには、すべてのリクエストパラメータと戻り値が含まれています。このドキュメントのyamlをコピーして、 [Swaggerエディター](https://editor.swagger.io/)でプレビューできます。 > -> - DM マスターノードを展開した後、 `http://{master-addr}/api/v1/docs`アクセスしてドキュメントをオンラインでプレビューできます。 +> - DM-masterノードを展開した後、 `http://{master-addr}/api/v1/docs`アクセスしてドキュメントをオンラインでプレビューできます。 > > - 設定ファイルでサポートされている一部の機能は、OpenAPIではサポートされていません。これらの機能は完全には連携されていません。本番環境では、 [設定ファイル](/dm/dm-config-overview.md)を使用することをお勧めします。 @@ -35,10 +35,10 @@ API を使用して、DM クラスターで次のメンテナンス操作を実 ## クラスターを管理するためのAPI {#apis-for-managing-clusters} -- [DMマスターノードの情報を取得する](#get-the-information-of-a-dm-master-node) -- [DMマスターノードを停止する](#stop-a-dm-master-node) -- [DMワーカーノードの情報を取得する](#get-the-information-of-a-dm-worker-node) -- [DMワーカーノードを停止する](#stop-a-dm-worker-node) +- [DM-masterノードの情報を取得する](#get-the-information-of-a-dm-master-node) +- [DM-masterノードを停止する](#stop-a-dm-master-node) +- [DM-workerノードの情報を取得する](#get-the-information-of-a-dm-worker-node) +- [DM-workerノードを停止する](#stop-a-dm-worker-node) ## データソースを管理するためのAPI {#apis-for-managing-data-sources} @@ -53,7 +53,7 @@ API を使用して、DM クラスターで次のメンテナンス操作を実 - [データソースのリレーログ機能を開始する](#start-the-relay-log-feature-for-data-sources) - [データソースのリレーログ機能を停止する](#stop-the-relay-log-feature-for-data-sources) - [不要になったリレーログファイルを消去する](#purge-relay-log-files-that-are-no-longer-required) -- [データソースとDMワーカー間のバインディングを変更する](#change-the-bindings-between-the-data-source-and-dm-workers) +- [データソースとDM-worker間のバインディングを変更する](#change-the-bindings-between-the-data-source-and-dm-workers) - [データソースのスキーマ名のリストを取得する](#get-the-list-of-schema-names-of-a-data-source) - [データソース内の指定されたスキーマのテーブル名のリストを取得します](#get-the-list-of-table-names-of-a-specified-schema-in-a-data-source) @@ -89,7 +89,7 @@ API リクエストの送信後にエラーが発生した場合、返される 上記の JSON 出力では、 `error_msg`エラーメッセージを示し、 `error_code`対応するエラーコードを示します。 -## DMマスターノードの情報を取得する {#get-the-information-of-a-dm-master-node} +## DM-masterノードの情報を取得する {#get-the-information-of-a-dm-master-node} このAPIは同期インターフェースです。リクエストが成功すると、対応するノードの情報が返されます。 @@ -119,7 +119,7 @@ curl -X 'GET' \ } ``` -## DMマスターノードを停止する {#stop-a-dm-master-node} +## DM-masterノードを停止する {#stop-a-dm-master-node} このAPIは同期インターフェースです。リクエストが成功した場合、返されるボディのステータスコードは204です。 @@ -135,7 +135,7 @@ curl -X 'DELETE' \ -H 'accept: */*' ``` -## DMワーカーノードの情報を取得する {#get-the-information-of-a-dm-worker-node} +## DM-workerノードの情報を取得する {#get-the-information-of-a-dm-worker-node} このAPIは同期インターフェースです。リクエストが成功すると、対応するノードの情報が返されます。 @@ -165,7 +165,7 @@ curl -X 'GET' \ } ``` -## DMワーカーノードを停止する {#stop-a-dm-worker-node} +## DM-workerノードを停止する {#stop-a-dm-worker-node} このAPIは同期インターフェースです。リクエストが成功した場合、返されるボディのステータスコードは204です。 @@ -613,9 +613,9 @@ curl -X 'POST' \ }' ``` -## データソースとDMワーカー間のバインディングを変更する {#change-the-bindings-between-the-data-source-and-dm-workers} +## データソースとDM-worker間のバインディングを変更する {#change-the-bindings-between-the-data-source-and-dm-workers} -このAPIは非同期インターフェースです。リクエストが成功した場合、返されるボディのステータスコードは200です。最新のステータスを確認するには、 [DMワーカーノードの情報を取得する](#get-the-information-of-a-dm-worker-node)を参照してください。 +このAPIは非同期インターフェースです。リクエストが成功した場合、返されるボディのステータスコードは200です。最新のステータスを確認するには、 [DM-workerノードの情報を取得する](#get-the-information-of-a-dm-worker-node)を参照してください。 ### リクエストURI {#request-uri} diff --git a/dm/dm-performance-test.md b/dm/dm-performance-test.md index a7467e3b1ae10..d4c73c05efb46 100644 --- a/dm/dm-performance-test.md +++ b/dm/dm-performance-test.md @@ -15,7 +15,7 @@ MySQL -> DM -> TiDB という単純な移行データフローを使用し - すべてのデフォルト構成で、 TiUPを使用して TiDB テストクラスターをデプロイ。 - MySQL サービスをデプロイ。binlogの`ROW`モードを有効にし、その他の設定項目はデフォルト設定を使用します。 -- DM ワーカーと DM マスターを使用して DM クラスターをデプロイ。 +- DM-workerと DM-masterを使用して DM クラスターをデプロイ。 ## パフォーマンステスト {#performance-test} diff --git a/dm/dm-query-status.md b/dm/dm-query-status.md index dfb99f171de8b..fd1f424a6ea27 100644 --- a/dm/dm-query-status.md +++ b/dm/dm-query-status.md @@ -56,7 +56,7 @@ summary: データ複製タスクのステータスを照会する方法を学 ## タスクのステータス {#task-status} -DM移行タスクのステータスは、DMワーカーに割り当てられた各サブタスクのステータスによって決まります。サブタスクのステータスの詳細については、 [サブタスクのステータス](#subtask-status)を参照してください。以下の表は、サブタスクのステータスとタスクのステータスの関係を示しています。 +DM移行タスクのステータスは、DM-workerに割り当てられた各サブタスクのステータスによって決まります。サブタスクのステータスの詳細については、 [サブタスクのステータス](#subtask-status)を参照してください。以下の表は、サブタスクのステータスとタスクのステータスの関係を示しています。 | タスク内のサブタスクのステータス | タスクのステータス | | :----------------------------------------------------------- | :--------------------------------------------- | @@ -236,7 +236,7 @@ DM移行タスクのステータスは、DMワーカーに割り当てられた - `masterBinlogGtid` : アップストリーム データベース内の GTID 情報。 - `syncerBinlog` : `Sync`処理単位で複製されたbinlogの位置。 - `syncerBinlogGtid` : GTID を使用して複製されたbinlogの位置。 - - `blockingDDLs` : 現在ブロックされているDDLリスト。このDMワーカーのすべての上流テーブルが「同期済み」ステータスにある場合にのみ空になります。この場合、実行されるかスキップされるシャーディングDDL文を示します。 + - `blockingDDLs` : 現在ブロックされているDDLリスト。このDM-workerのすべての上流テーブルが「同期済み」ステータスにある場合にのみ空になります。この場合、実行されるかスキップされるシャーディングDDL文を示します。 - `unresolvedGroups` : 解決されていないシャーディンググループ。各グループには以下のフィールドが含まれます。 - `target` : 複製されるダウンストリームデータベーステーブル。 - `DDLs` : DDL ステートメントのリスト。 diff --git a/dm/dm-safe-mode.md b/dm/dm-safe-mode.md index bbd51302a5304..ab128b45a6bf4 100644 --- a/dm/dm-safe-mode.md +++ b/dm/dm-safe-mode.md @@ -56,7 +56,7 @@ DMはSQL文を書き換えることで、重複挿入または更新操作を実 ### 自動的に有効にする {#automatically-enable} -DMがチェックポイントから増分レプリケーションタスクを再開する場合（例えば、DMワーカーの再起動やネットワークの再接続など）、DMは自動的に一定期間（デフォルトでは60秒）セーフモードを有効にします。 +DMがチェックポイントから増分レプリケーションタスクを再開する場合（例えば、DM-workerの再起動やネットワークの再接続など）、DMは自動的に一定期間（デフォルトでは60秒）セーフモードを有効にします。 セーフモードを有効にするかどうかは、チェックポイント内の`safemode_exit_point`に関連しています。増分レプリケーションタスクが異常に一時停止された場合、DM はメモリ内のすべての DML ステートメントをダウンストリームにレプリケートしようとし、DML ステートメントの中で最新のbinlog位置を`safemode_exit_point`として記録し、最後のチェックポイントに保存します。 diff --git a/dm/dm-source-configuration-file.md b/dm/dm-source-configuration-file.md index de6f7386b29df..1f6ffcecd7642 100644 --- a/dm/dm-source-configuration-file.md +++ b/dm/dm-source-configuration-file.md @@ -87,8 +87,8 @@ from: #### `relay-binlog-gtid` {#relay-binlog-gtid} -- DMワーカーがbinlogのプルを開始するGTIDを指定します。例： `"e9a1fc22-ec08-11e9-b2ac-0242ac110003:1-7849"` 。 -- [`enable-gtid`](#enable-gtid)が`true`の場合にのみ機能します。このパラメータが指定されていない場合、DMワーカーはレプリケーション中の最新のGTIDからプルを開始します。通常、手動設定は必要ありません。 +- DM-workerがbinlogのプルを開始するGTIDを指定します。例： `"e9a1fc22-ec08-11e9-b2ac-0242ac110003:1-7849"` 。 +- [`enable-gtid`](#enable-gtid)が`true`の場合にのみ機能します。このパラメータが指定されていない場合、DM-workerはレプリケーション中の最新のGTIDからプルを開始します。通常、手動設定は必要ありません。 #### `relay-dir` {#relay-dir} diff --git a/dm/dm-worker-configuration-file.md b/dm/dm-worker-configuration-file.md index a6e5fbbb3f39c..23ef797302a79 100644 --- a/dm/dm-worker-configuration-file.md +++ b/dm/dm-worker-configuration-file.md @@ -3,13 +3,13 @@ title: DM-worker Configuration File summary: DM-worker の設定ファイルについて学習します。 --- -# DMワーカーコンフィグレーションファイル {#dm-worker-configuration-file} +# DM-workerコンフィグレーションファイル {#dm-worker-configuration-file} -このドキュメントでは、構成ファイル テンプレートと、このファイル内の各構成パラメータの説明を含む、DM ワーカーの構成について説明します。 +このドキュメントでは、構成ファイル テンプレートと、このファイル内の各構成パラメータの説明を含む、DM-workerの構成について説明します。 ## コンフィグレーションファイルテンプレート {#configuration-file-template} -以下は、DM ワーカーの構成ファイル テンプレートです。 +以下は、DM-workerの構成ファイル テンプレートです。 ```toml # Worker Configuration. @@ -40,7 +40,7 @@ cert-allowed-cn = ["dm"] #### `name` {#name} -- DM ワーカーの名前。 +- DM-workerの名前。 #### `log-level` {#log-level} @@ -54,25 +54,25 @@ cert-allowed-cn = ["dm"] #### `worker-addr` {#worker-addr} -- サービスを提供するDMワーカーのアドレスを指定します。IPアドレスを省略し、ポート番号のみ（例： `":8262"` ）を指定することもできます。 +- サービスを提供するDM-workerのアドレスを指定します。IPアドレスを省略し、ポート番号のみ（例： `":8262"` ）を指定することもできます。 #### `advertise-addr` {#advertise-addr} -- DM ワーカーが外部にアドバタイズするアドレスを指定します。 +- DM-workerが外部にアドバタイズするアドレスを指定します。 #### `join` {#join} -- DM マスター構成ファイル内の 1つ以上の[`master-addr`](/dm/dm-master-configuration-file.md#global-configuration)に対応します。 +- DM-master構成ファイル内の 1つ以上の[`master-addr`](/dm/dm-master-configuration-file.md#global-configuration)に対応します。 #### `keepalive-ttl` {#keepalive-ttl} -- DM ワーカーノードの上流データソースがリレーログを有効にしていない場合の、DM ワーカーノードから DM マスターノードへのキープアライブ時間 (秒単位)。 +- DM-workerノードの上流データソースがリレーログを有効にしていない場合の、DM-workerノードから DM-masterノードへのキープアライブ時間 (秒単位)。 - デフォルト値: `60` - 単位: 秒 #### `relay-keepalive-ttl` DM v2.0.2の新機能 {#relay-keepalive-ttl-new-in-dm-v202} -- DM ワーカーノードの上流データソースがリレーログを有効にしている場合の、DM ワーカーノードから DM マスターノードへのキープアライブ時間 (秒単位)。 +- DM-workerノードの上流データソースがリレーログを有効にしている場合の、DM-workerノードから DM-masterノードへのキープアライブ時間 (秒単位)。 - デフォルト値: `1800` - 単位: 秒 diff --git a/dm/dm-worker-intro.md b/dm/dm-worker-intro.md index 3d14722bf7b73..3b9a2aac584ca 100644 --- a/dm/dm-worker-intro.md +++ b/dm/dm-worker-intro.md @@ -3,7 +3,7 @@ title: DM-worker Introduction summary: DM-worker の機能について学びます。 --- -# DMワーカー紹介 {#dm-worker-introduction} +# DM-worker紹介 {#dm-worker-introduction} DM-worker は、TiDB Data Migration (DM) のコンポーネントであり、DM-master によって割り当てられたタスクとサブタスクを実行します。フルおよび増分移行では、1つの MySQL 互換ソースインスタンスからデータをダンプし、ダンプしたデータをターゲット TiDB クラスターにロードします。その後、レプリケーションクライアントとしてソース Binlog を読み取り、イベントを変換およびフィルタリングして、ターゲットに適用します。DM-master は、ソースとサブタスクのステータスについて DM-worker に問い合わせます。 @@ -36,7 +36,7 @@ DM-worker は、TiDB Data Migration (DM) のコンポーネントであり、DM- Binlogログレプリケーション/同期処理ユニットは、上流の MySQL/MariaDB のbinlogイベントまたはリレーログのbinlogイベントを読み取り、これらのイベントを SQL ステートメントに変換し、下流の TiDB にこれらのステートメントを適用します。 -## DMワーカーに必要な権限 {#privileges-required-by-dm-worker} +## DM-workerに必要な権限 {#privileges-required-by-dm-worker} このセクションでは、DM-worker に必要な上流および下流のデータベースユーザーの権限と、それぞれの処理ユニットに必要なユーザー権限について説明します。 diff --git a/dm/dmctl-introduction.md b/dm/dmctl-introduction.md index 5d8e75994a312..b65ac01a9f4f2 100644 --- a/dm/dmctl-introduction.md +++ b/dm/dmctl-introduction.md @@ -13,7 +13,7 @@ dmctl は、DM クラスタのメンテナンスに使用するコマンドラ ## インタラクティブモード {#interactive-mode} -DM マスターと対話するには、対話モードに入ります。 +DM-masterと対話するには、対話モードに入ります。 > **Note:** > diff --git a/dm/feature-shard-merge-optimistic.md b/dm/feature-shard-merge-optimistic.md index 9f9d07b0c1531..5642b00b017a1 100644 --- a/dm/feature-shard-merge-optimistic.md +++ b/dm/feature-shard-merge-optimistic.md @@ -107,7 +107,7 @@ ALTER TABLE `tbl00` ADD COLUMN `Age` INT DEFAULT -1; ## 実装原理 {#implementation-principle} -楽観的モードでは、DMワーカーは上流からDDL文を受信すると、更新されたテーブルスキーマをDMマスターに転送します。DMワーカーは各シャードテーブルの現在のスキーマを追跡し、DMマスターはこれらのスキーマを、各シャードテーブルのDML文と互換性のある複合スキーマにマージします。その後、DMマスターは対応するDDL文を下流に移行します。DML文は下流に直接移行されます。 +楽観的モードでは、DM-workerは上流からDDL文を受信すると、更新されたテーブルスキーマをDM-masterに転送します。DM-workerは各シャードテーブルの現在のスキーマを追跡し、DM-masterはこれらのスキーマを、各シャードテーブルのDML文と互換性のある複合スキーマにマージします。その後、DM-masterは対応するDDL文を下流に移行します。DML文は下流に直接移行されます。 ![optimistic-ddl-flow](/media/dm/optimistic-ddl-flow.png) @@ -146,7 +146,7 @@ ALTER TABLE `tbl01` ADD COLUMN `Level` INT; ![optimistic-ddl-example-5](/media/dm/optimistic-ddl-example-5.png) -この時点で、ダウンストリームにはすでに同じ`Level`列があるため、DM マスターはテーブルスキーマを比較した後、何も操作を実行しません。 +この時点で、ダウンストリームにはすでに同じ`Level`列があるため、DM-masterはテーブルスキーマを比較した後、何も操作を実行しません。 `tbl01`に`Name`列をドロップします。 diff --git a/dm/feature-shard-merge-pessimistic.md b/dm/feature-shard-merge-pessimistic.md index ed53a9a52765f..3be841a2c6abd 100644 --- a/dm/feature-shard-merge-pessimistic.md +++ b/dm/feature-shard-merge-pessimistic.md @@ -29,7 +29,7 @@ DM の悲観的モードでは、シャーディング DDL の使用に関して - シャーディング DDL ステートメントの移行中に、 `dmctl`を使用して`router-rules`を変更するとエラーが報告されます。 - DDL ステートメントが実行されるシャーディンググループに新しいテーブルを`CREATE`追加する必要がある場合は、テーブルスキーマが新しく変更されたテーブルスキーマと同じであることを確認する必要があります。 - 例えば、元の`table_1`と`table_2`はどちらも最初は 2つの列 (a、b) を持ち、シャーディング DDL 操作後には 3つの列 (a、b、c) を持つため、移行後に新しく作成されたテーブルも 3つの列 (a、b、c) を持つ必要があります。 -- DDLステートメントを受信したDMワーカーは、他のDMワーカーがDDLステートメントを受信するまでタスクを一時停止するため、データ移行の遅延が増加します。 +- DDLステートメントを受信したDM-workerは、他のDM-workerがDDLステートメントを受信するまでタスクを一時停止するため、データ移行の遅延が増加します。 ## 背景 {#background} @@ -97,15 +97,15 @@ sequenceDiagram 6. `DM-worker-1`は、ステップ #2 で受信した DDL ロック情報に基づいて DDL ステートメント実行要求を検証し、この DDL ステートメントをダウンストリームに移行し、結果を`DM-master`に送信します。この操作が成功した場合、 `DM-worker-1`は後続の ( `t2`のbinlogから始まる) DML ステートメントの移行を続行します。 7. `DM-master`はロック所有者から DDL が正常に実行されたという応答を受け取り、DDL ロックを待機している他のすべての DM-worker ( `DM-worker-2` ) に、この DDL ステートメントを無視し、後続の ( `t4`のbinlogから始まる) DML ステートメントの移行を続行するように要求します。 -複数のDMワーカー間でシャーディングDDL移行を処理するDMの特性は、以下のようにまとめられます。 +複数のDM-worker間でシャーディングDDL移行を処理するDMの特性は、以下のようにまとめられます。 -- タスク構成とDMクラスタ展開トポロジ情報に基づいて、DDL移行を調整するための論理シャーディンググループ`DM-master`に構築されます。グループメンバーは、移行タスクから分割された各サブタスクを処理するDMワーカーです。 +- タスク構成とDMクラスタ展開トポロジ情報に基づいて、DDL移行を調整するための論理シャーディンググループ`DM-master`に構築されます。グループメンバーは、移行タスクから分割された各サブタスクを処理するDM-workerです。 - binlogイベントから DDL ステートメントを受け取った後、各 DM-worker は DDL 情報を`DM-master`に送信します。 - `DM-master`は各 DM-worker から受信した DDL 情報とシャーディンググループ情報に基づいて、DDL ロックを作成または更新します。 - シャーディンググループのすべてのメンバーが同じ特定のDDLステートメントを受信した場合、これは、アップストリームのシャーディングされたテーブルでのDDL実行前のすべてのDMLステートメントが完全に移行されたことを示しており、このDDLステートメントを実行できます。その後、DMは後続のDMLステートメントの移行を続行できます。 -- [テーブルルーター](/dm/dm-table-routing.md)によって変換された後、上流のシャーディングされたテーブルのDDLステートメントは、下流で実行されるDDLステートメントと一致している必要があります。したがって、このDDLステートメントはDDL所有者によって一度だけ実行されればよく、他のすべてのDMワーカーはこのDDLステートメントを無視できます。 +- [テーブルルーター](/dm/dm-table-routing.md)によって変換された後、上流のシャーディングされたテーブルのDDLステートメントは、下流で実行されるDDLステートメントと一致している必要があります。したがって、このDDLステートメントはDDL所有者によって一度だけ実行されればよく、他のすべてのDM-workerはこのDDLステートメントを無視できます。 -上記の例では、各DMワーカーに対応するアップストリームのMySQLインスタンスでマージする必要があるのは、シャーディングされたテーブル1つだけです。しかし、実際のシナリオでは、複数のシャーディングされたスキーマに複数のシャーディングされたテーブルが存在し、それらを1つのMySQLインスタンスでマージする必要がある場合があります。このような場合、シャーディングDDLの移行を調整するのがより複雑になります。 +上記の例では、各DM-workerに対応するアップストリームのMySQLインスタンスでマージする必要があるのは、シャーディングされたテーブル1つだけです。しかし、実際のシナリオでは、複数のシャーディングされたスキーマに複数のシャーディングされたテーブルが存在し、それらを1つのMySQLインスタンスでマージする必要がある場合があります。このような場合、シャーディングDDLの移行を調整するのがより複雑になります。 `table_1`と`table_2`という 2つのシャーディングされたテーブルを、1つの MySQL インスタンスにマージすると仮定します。 @@ -119,33 +119,33 @@ sequenceDiagram 4. `t3`では、DM-worker の同期ユニットが`table_2`の DDL ステートメントを受け取ります。 5. `t4`以降、DM-workerの同期ユニットは、両方のテーブルから`schema V2`のDMLステートメントを受け取ります。 -データ移行中に特にDDLステートメントが処理されない場合、 `table_1`のDDLステートメントがダウンストリームに移行され、ダウンストリームのテーブルスキーマが変更されると、 `schema V1`からの`table_2` }のDMLステートメントは正常に移行されません。そのため、単一のDMワーカー内で、 `DM-master`内のものと同様の論理シャーディンググループが作成されますが、このグループのメンバーは、同じアップストリームMySQLインスタンス内の異なるシャーディングテーブルになります。 +データ移行中に特にDDLステートメントが処理されない場合、 `table_1`のDDLステートメントがダウンストリームに移行され、ダウンストリームのテーブルスキーマが変更されると、 `schema V1`からの`table_2` }のDMLステートメントは正常に移行されません。そのため、単一のDM-worker内で、 `DM-master`内のものと同様の論理シャーディンググループが作成されますが、このグループのメンバーは、同じアップストリームMySQLインスタンス内の異なるシャーディングテーブルになります。 -しかし、DMワーカーがシャーディンググループの移行を内部で調整する場合、それは`DM-master`によって実行されるものとは完全には同じではありません。理由は以下のとおりです。 +しかし、DM-workerがシャーディンググループの移行を内部で調整する場合、それは`DM-master`によって実行されるものとは完全には同じではありません。理由は以下のとおりです。 - DM-worker が`table_1`の DDL ステートメントを受信すると、移行を一時停止することはできず、binlogの解析を続行して、後続の`table_2`の DDL ステートメントを取得する必要があります。つまり`t2`と`t3`の間の解析を続行する必要があります。 - `t2`と`t3`間のbinlog解析処理中、シャーディング DDL ステートメントが移行され、正常に実行されるまで、 `schema V2`の`table_1`の DML ステートメントはダウンストリームに移行できません。 -DMでは、DMワーカー内でDDLステートメントをシャーディングする簡略化された移行プロセスは次のとおりです。 +DMでは、DM-worker内でDDLステートメントをシャーディングする簡略化された移行プロセスは次のとおりです。 1. `table_1`で`t1`の DDL ステートメントを受信すると、DM-worker は DDL 情報とbinlogの現在の位置を記録します。 2. DM-worker は`t2`と`t3`の間のbinlogの解析を続行します。 3. DM-worker は`schema V2`に属する`table_1`スキーマの DML ステートメントを無視し、 `schema V1`に属する`table_2`スキーマの DML ステートメントをダウンストリームに移行します。 4. `table_2`で`t3`の DDL ステートメントを受信すると、DM-worker は DDL 情報とbinlogの現在の位置を記録します。 -5. DMワーカーは、移行タスク構成と上流のスキーマおよびテーブルの情報に基づいて、MySQLインスタンス内のすべてのシャーディングされたテーブルのDDLステートメントが受信されたと判断し、下流に移行して下流のテーブルスキーマを変更します。 +5. DM-workerは、移行タスク構成と上流のスキーマおよびテーブルの情報に基づいて、MySQLインスタンス内のすべてのシャーディングされたテーブルのDDLステートメントが受信されたと判断し、下流に移行して下流のテーブルスキーマを変更します。 6. DM-workerは、新しいbinlogストリームの解析開始点を、ステップ1で保存された位置に設定します。 7. DM-worker は`t2`と`t3`の間のbinlogの解析を再開します。 8. DM-worker は`schema V2`に属する`table_1`スキーマの DML ステートメントをダウンストリームに移行し、 `schema V1`に属する`table_2`スキーマの DML ステートメントを無視します。 -9. ステップ4で保存されたbinlogの位置を解析した後、DMワーカーは、ステップ3で無視されたすべてのDMLステートメントが再びダウンストリームに移行されたと判断します。 +9. ステップ4で保存されたbinlogの位置を解析した後、DM-workerは、ステップ3で無視されたすべてのDMLステートメントが再びダウンストリームに移行されたと判断します。 10. DM-worker は`t4`のbinlog位置から移行を再開します。 上記の分析から、DMはシャーディングDDLの移行処理において、調整と制御のために主に2レベルのシャーディンググループを使用していることがわかります。以下に簡略化したプロセスを示します。 -1. 各DMワーカーは、アップストリームのMySQLインスタンス内の複数のシャーディングテーブルで構成される対応するシャーディンググループに対して、DDLステートメントの移行を個別に調整します。 -2. DMワーカーは、シャーディングされたすべてのテーブルのDDLステートメントを受け取った後、DDL情報を`DM-master`に送信します。 +1. 各DM-workerは、アップストリームのMySQLインスタンス内の複数のシャーディングテーブルで構成される対応するシャーディンググループに対して、DDLステートメントの移行を個別に調整します。 +2. DM-workerは、シャーディングされたすべてのテーブルのDDLステートメントを受け取った後、DDL情報を`DM-master`に送信します。 3. `DM-master`は受信した DDL 情報に基づいて、DM-workers で構成されるシャーディンググループの DDL 移行を調整します。 4. すべての DM-worker から DDL 情報を受信した後、 `DM-master`は DDL ロック所有者 (特定の DM-worker) に DDL ステートメントを実行するように要求します。 5. DDLロックの所有者はDDLステートメントを実行し、結果を`DM-master`に返します。その後、所有者はDDL移行の内部調整中に以前に無視されたDMLステートメントの移行を再開します。 6. `DM-master`は、所有者が DDL ステートメントを正常に実行したことを確認した後、他のすべての DM-worker に移行を続行するように要求します。 -7. 他のすべてのDMワーカーは、DDL移行の内部調整中に、以前に無視されたDMLステートメントの移行を個別に再開します。 -8. 無視されたDMLステートメントの移行が完了すると、すべてのDMワーカーは通常の移行プロセスを再開します。 +7. 他のすべてのDM-workerは、DDL移行の内部調整中に、以前に無視されたDMLステートメントの移行を個別に再開します。 +8. 無視されたDMLステートメントの移行が完了すると、すべてのDM-workerは通常の移行プロセスを再開します。 diff --git a/dm/maintain-dm-using-tiup.md b/dm/maintain-dm-using-tiup.md index 00dc1a452fb36..6b5a4516035e4 100644 --- a/dm/maintain-dm-using-tiup.md +++ b/dm/maintain-dm-using-tiup.md @@ -12,11 +12,11 @@ DM クラスターをまだ展開していない場合は、手順[TiUPを使用 > **Note:** > > - 以下のコンポーネント間のポートが相互接続されていることを確認してください -> - DM マスターノードのうち`peer_port` (デフォルトでは`8291` ) が相互接続されています。 -> - 各 DM マスターノードは、すべての DM ワーカーノードの`port` (デフォルトでは`8262` ) に接続できます。 -> - 各 DM ワーカーノードは、すべての DM マスターノードの`port` (デフォルトでは`8261` ) に接続できます。 -> - TiUPノードは、すべての DM マスターノードの`port` (デフォルトでは`8261` ) に接続できます。 -> - TiUPノードは、すべての DM ワーカーノードの`port` (デフォルトでは`8262` ) に接続できます。 +> - DM-masterノードのうち`peer_port` (デフォルトでは`8291` ) が相互接続されています。 +> - 各 DM-masterノードは、すべての DM-workerノードの`port` (デフォルトでは`8262` ) に接続できます。 +> - 各 DM-workerノードは、すべての DM-masterノードの`port` (デフォルトでは`8261` ) に接続できます。 +> - TiUPノードは、すべての DM-masterノードの`port` (デフォルトでは`8261` ) に接続できます。 +> - TiUPノードは、すべての DM-workerノードの`port` (デフォルトでは`8262` ) に接続できます。 TiUP DMコンポーネントのヘルプ情報については、次のコマンドを実行します。 @@ -109,13 +109,13 @@ ID Role Host Ports OS/Arch Status `Status`列では、 `Up`または`Down`を使用して、サービスが正常に実行されているかどうかを示します。 -DMマスターコンポーネントの場合、ステータスに`|L`が付加され、DMマスターノードがLeaderであることを示します。DMワーカーコンポーネントの場合、 `Free`は現在のDMワーカーノードがアップストリームにバインドされていないことを示します。 +DM-masterコンポーネントの場合、ステータスに`|L`が付加され、DM-masterノードがLeaderであることを示します。DM-workerコンポーネントの場合、 `Free`は現在のDM-workerノードがアップストリームにバインドされていないことを示します。 ## クラスターのスケールイン {#scale-in-a-cluster} クラスターのスケールインとは、一部のノードをオフラインにすることを意味します。この操作により、指定されたノードがクラスターから削除され、残りのデータファイルが削除されます。 -クラスターをスケールインすると、DM マスター コンポーネントと DM ワーカー コンポーネントに対する DM 操作が次の順序で実行されます。 +クラスターをスケールインすると、DM-master コンポーネントと DM-worker コンポーネントに対する DM 操作が次の順序で実行されます。 1. コンポーネントプロセスを停止します。 2. DM-master の API を呼び出して`member`を削除します。 @@ -139,7 +139,7 @@ tiup dm scale-in prod-cluster -N 172.16.5.140:8262 スケールアウト操作には、デプロイメントと同様の内部ロジックがあります。TiUP TiUP DMコンポーネントは、まずノードの SSH 接続を確認し、ターゲットノードに必要なディレクトリを作成し、次にデプロイメント操作を実行して、ノード サービスを開始します。 -たとえば、クラスター`prod-cluster`内の DM ワーカーノードをスケールアウトするには、次の手順を実行します (DM マスターのスケールアウトにも同様の手順があります)。 +たとえば、クラスター`prod-cluster`内の DM-workerノードをスケールアウトするには、次の手順を実行します (DM-masterのスケールアウトにも同様の手順があります)。 1. `scale.yaml`ファイルを作成し、新しいワーカーノードの情報を追加します。 @@ -233,13 +233,13 @@ Global Flags: -y, --yes Skip all confirmations and assumes 'yes' ``` -DM マスター ホットフィックス パッケージが`/tmp/dm-master-hotfix.tar.gz`にあり、クラスター内のすべての DM マスター パッケージを置き換える場合は、次のコマンドを実行します。 +DM-master ホットフィックス パッケージが`/tmp/dm-master-hotfix.tar.gz`にあり、クラスター内のすべての DM-master パッケージを置き換える場合は、次のコマンドを実行します。 ```bash tiup dm patch prod-cluster /tmp/dm-master-hotfix.tar.gz -R dm-master ``` -クラスター内の DM マスター パッケージを 1つだけ置き換えることもできます。 +クラスター内の DM-master パッケージを 1つだけ置き換えることもできます。 ```bash tiup dm patch prod-cluster /tmp/dm--hotfix.tar.gz -N 172.16.4.5:8261 @@ -256,7 +256,7 @@ tiup dm patch prod-cluster /tmp/dm--hotfix.tar.gz -N 172.16.4.5:8261 > - `import`コマンドは、DM 1.0 クラスターから新しい DM 2.0 クラスターにデータをインポートするために使用されます。既存の DM 2.0 クラスターに DM 移行タスクをインポートする必要がある場合は、 [TiDB データ移行を v1.0.x から v2.0+ に手動でアップグレードする](/dm/manually-upgrade-dm-1.0-to-2.0.md)を参照してください。 > - 一部のコンポーネントのデプロイメントディレクトリは、元のクラスタのものと異なります。詳細を確認するには、 `display`コマンドを実行してください。 > - インポートする前に`tiup update --self && tiup update dm`を実行して、 TiUP DMコンポーネントが最新バージョンであることを確認します。 -> - インポート後、クラスターにはDMマスターノードが1つだけ存在します。DMマスターをスケールアウトするには、 [クラスターをスケールアウトする](#scale-out-a-cluster)を参照してください。 +> - インポート後、クラスターにはDM-masterノードが1つだけ存在します。DM-masterをスケールアウトするには、 [クラスターをスケールアウトする](#scale-out-a-cluster)を参照してください。 TiUPがリリースされる前は、DMクラスターのデプロイにはDM-Ansibleがよく使用されていました。DM-AnsibleによってデプロイされたDM 1.0クラスターをTiUPで引き継ぐには、 `import`コマンドを使用します。 diff --git a/dm/manually-handling-sharding-ddl-locks.md b/dm/manually-handling-sharding-ddl-locks.md index bf78491feac15..150586b15331b 100644 --- a/dm/manually-handling-sharding-ddl-locks.md +++ b/dm/manually-handling-sharding-ddl-locks.md @@ -18,7 +18,7 @@ DMはシャーディングDDLロックを使用して、操作が正しい順序 ### `shard-ddl-lock` {#shard-ddl-lock} -このコマンドを使用すると、DDLロックを表示し、DMマスターに指定されたDDLロックの解放を要求できます。このコマンドはDM v6.0以降でのみサポートされています。それより前のバージョンでは、コマンド`show-ddl-locks`と`unlock-ddl-locks`を使用する必要があります。 +このコマンドを使用すると、DDLロックを表示し、DM-masterに指定されたDDLロックの解放を要求できます。このコマンドはDM v6.0以降でのみサポートされています。それより前のバージョンでは、コマンド`show-ddl-locks`と`unlock-ddl-locks`を使用する必要があります。 ```bash shard-ddl-lock -h @@ -40,17 +40,17 @@ Use "dmctl shard-ddl-lock [command] --help" for more information about a command #### 引数の説明 {#arguments-description} -- `shard-ddl-lock [task] [flags]` : 現在の DM マスターの DDL ロック情報を表示します。 +- `shard-ddl-lock [task] [flags]` : 現在の DM-masterの DDL ロック情報を表示します。 -- `shard-ddl-lock [command]` : 指定された DDL ロックを解放するように DM マスターに要求します。`[command]`は値として`unlock`のみを受け入れます。 +- `shard-ddl-lock [command]` : 指定された DDL ロックを解放するように DM-masterに要求します。`[command]`は値として`unlock`のみを受け入れます。 ## 使用例 {#usage-examples} ### `shard-ddl-lock [task] [flags]` {#shard-ddl-lock-task-flags} -`shard-ddl-lock [task] [flags]`を使用すると、現在の DM マスターの DDL ロック情報を表示できます。例: +`shard-ddl-lock [task] [flags]`を使用すると、現在の DM-masterの DDL ロック情報を表示できます。例: ```bash shard-ddl-lock test @@ -86,7 +86,7 @@ shard-ddl-lock test ### `shard-ddl-lock unlock` {#shard-ddl-lock-unlock} -このコマンドは、所有者に DDL ステートメントを実行するよう要求し、所有者以外の他のすべての DM ワーカーに DDL ステートメントをスキップするよう要求し、 `DM-master`のロック情報を削除するなど、指定された DDL ロックを解除するように`DM-master`に積極的に要求します。 +このコマンドは、所有者に DDL ステートメントを実行するよう要求し、所有者以外の他のすべての DM-workerに DDL ステートメントをスキップするよう要求し、 `DM-master`のロック情報を削除するなど、指定された DDL ロックを解除するように`DM-master`に積極的に要求します。 > **Note:** > @@ -153,11 +153,11 @@ shard-ddl-lock unlock test-`shard_db`.`shard_table` #### 異常なロックの理由 {#the-reason-for-the-abnormal-lock} -`DM-master`シャーディングDDLロックを自動的に解除しようとする前に、すべてのMySQLソースがシャーディングDDLイベントを受信する必要があります（詳細は[シャードマージの原則](/dm/feature-shard-merge-pessimistic.md#principles)を参照）。シャーディングDDLイベントが既に移行プロセス中であり、一部のMySQLソースが削除されて再ロードされない場合（これらのMySQLソースはアプリケーションの要求に応じて削除されています）、すべてのDMワーカーがDDLイベントを受信できないため、シャーディングDDLロックを自動的に移行して解除することはできません。 +`DM-master`シャーディングDDLロックを自動的に解除しようとする前に、すべてのMySQLソースがシャーディングDDLイベントを受信する必要があります（詳細は[シャードマージの原則](/dm/feature-shard-merge-pessimistic.md#principles)を参照）。シャーディングDDLイベントが既に移行プロセス中であり、一部のMySQLソースが削除されて再ロードされない場合（これらのMySQLソースはアプリケーションの要求に応じて削除されています）、すべてのDM-workerがDDLイベントを受信できないため、シャーディングDDLロックを自動的に移行して解除することはできません。 > **Note:** > -> シャーディング DDL イベントの移行プロセス中でないときに一部の DM ワーカーをオフラインにする必要がある場合、より適切な解決策は、まず`stop-task`を使用して実行中のタスクを停止し、DM ワーカーをオフラインにして、タスク構成ファイルから対応する構成情報を削除し、最後に`start-task`と新しいタスク構成を使用して移行タスクを再開することです。 +> シャーディング DDL イベントの移行プロセス中でないときに一部の DM-workerをオフラインにする必要がある場合、より適切な解決策は、まず`stop-task`を使用して実行中のタスクを停止し、DM-workerをオフラインにして、タスク構成ファイルから対応する構成情報を削除し、最後に`start-task`と新しいタスク構成を使用して移行タスクを再開することです。 #### 手動ソリューション {#manual-solution} @@ -232,7 +232,7 @@ MySQLとDMの操作プロセスは次のとおりです。 6. `shard-ddl-lock unlock`を使用して`DM-master`に要求し、DDL ロックをアクティブにロック解除します。 - - DDL ロックの所有者がオフラインになった場合は、パラメータ`--owner`を使用して、別の DM ワーカーを新しい所有者として指定し、DDL を実行できます。 + - DDL ロックの所有者がオフラインになった場合は、パラメータ`--owner`を使用して、別の DM-workerを新しい所有者として指定し、DDL を実行できます。 - いずれかの MySQL ソースがエラーを報告した場合、 `result`が`false`に設定され、この時点で、各 MySQL ソースのエラーが許容範囲内であり、期待どおりであるかどうかを慎重に確認する必要があります。 ```bash @@ -286,30 +286,30 @@ MySQLとDMの操作プロセスは次のとおりです。 > **Note:** > -> `shard-ddl-lock unlock`を実行した後、オフラインになった MySQL ソースが再ロードされ、DM ワーカーがシャードテーブルのデータを移行しようとすると、データとダウンストリームテーブル構造の間で一致エラーが発生する可能性があります。 +> `shard-ddl-lock unlock`を実行した後、オフラインになった MySQL ソースが再ロードされ、DM-workerがシャードテーブルのデータを移行しようとすると、データとダウンストリームテーブル構造の間で一致エラーが発生する可能性があります。 -### シナリオ2: DDLロック解除プロセス中に一部のDMワーカーが異常停止するか、ネットワーク障害が発生する {#scenario-2-some-dm-workers-stop-abnormally-or-the-network-failure-occurs-during-the-ddl-unlocking-process} +### シナリオ2: DDLロック解除プロセス中に一部のDM-workerが異常停止するか、ネットワーク障害が発生する {#scenario-2-some-dm-workers-stop-abnormally-or-the-network-failure-occurs-during-the-ddl-unlocking-process} #### 異常なロックの理由 {#the-reason-for-the-abnormal-lock} -`DM-master`がすべての DM ワーカーの DDL イベントを受信した後、 `unlock DDL lock`が自動的に実行され、主に次の手順が含まれます。 +`DM-master`がすべての DM-workerの DDL イベントを受信した後、 `unlock DDL lock`が自動的に実行され、主に次の手順が含まれます。 1. ロックの所有者に DDL を実行し、対応するシャードテーブルのチェックポイントを更新するように依頼します。 2. 所有者が DDL を正常に実行した後、 `DM-master`に保存されている DDL ロック情報を削除します。 3. 所有者が DDL を正常に実行した後、他のすべての非所有者に DDL をスキップし、対応するシャードテーブルのチェックポイントを更新するように依頼します。 -4. すべての所有者または非所有者の操作が成功した後、DM マスターは対応する DDL ロック情報を削除します。 +4. すべての所有者または非所有者の操作が成功した後、DM-masterは対応する DDL ロック情報を削除します。 -現在、上記のロック解除プロセスはアトミックではありません。非オーナーがDDL操作を正常にスキップした場合、非オーナーが配置されているDMワーカーが異常停止するか、下流のTiDBでネットワーク異常が発生し、チェックポイントの更新が失敗する可能性があります。 +現在、上記のロック解除プロセスはアトミックではありません。非オーナーがDDL操作を正常にスキップした場合、非オーナーが配置されているDM-workerが異常停止するか、下流のTiDBでネットワーク異常が発生し、チェックポイントの更新が失敗する可能性があります。 -非所有者に対応するMySQLソースがデータ移行を復元する際、非所有者はDMマスターに対して、例外発生前に調整されていたDDL操作の再調整を要求しようとします。このため、他のMySQLソースから対応するDDL操作を受け取ることはありません。これにより、DDL操作によって対応するロックが自動的に解除される可能性があります。 +非所有者に対応するMySQLソースがデータ移行を復元する際、非所有者はDM-masterに対して、例外発生前に調整されていたDDL操作の再調整を要求しようとします。このため、他のMySQLソースから対応するDDL操作を受け取ることはありません。これにより、DDL操作によって対応するロックが自動的に解除される可能性があります。 #### 手動ソリューション {#manual-solution} ここで、上流と下流のテーブル構造が同じであり、テーブルのマージと移行に対する要求も[一部のMySQLソースが削除されました](#scenario-1-some-mysql-sources-are-removed)の手動ソリューションと同じであるとします。 -`DM-master`自動的にロック解除処理を実行すると、オーナー（ `mysql-replica-01` ）はDDLを正常に実行し、移行処理を継続します。しかし、非オーナー（ `mysql-replica-02` ）にDDL操作のスキップを要求する処理において、対応するDMワーカーが再起動されたため、DMワーカーがDDL操作をスキップした後にチェックポイントの更新に失敗します。 +`DM-master`自動的にロック解除処理を実行すると、オーナー（ `mysql-replica-01` ）はDDLを正常に実行し、移行処理を継続します。しかし、非オーナー（ `mysql-replica-02` ）にDDL操作のスキップを要求する処理において、対応するDM-workerが再起動されたため、DM-workerがDDL操作をスキップした後にチェックポイントの更新に失敗します。 -`mysql-replica-02`に対応するデータ移行サブタスクが復元された後、DM マスターに新しいロックが作成されますが、他の MySQL ソースは DDL 操作を実行またはスキップし、後続の移行を実行しています。 +`mysql-replica-02`に対応するデータ移行サブタスクが復元された後、DM-masterに新しいロックが作成されますが、他の MySQL ソースは DDL 操作を実行またはスキップし、後続の移行を実行しています。 操作プロセスは次のとおりです。 diff --git a/dm/manually-upgrade-dm-1.0-to-2.0.md b/dm/manually-upgrade-dm-1.0-to-2.0.md index cb457d7089132..f3de495c07171 100644 --- a/dm/manually-upgrade-dm-1.0-to-2.0.md +++ b/dm/manually-upgrade-dm-1.0-to-2.0.md @@ -25,7 +25,7 @@ TiDB DM ツールを v1.0.x から v2.0+ に自動的にアップグレードす ### アップストリームデータベース構成ファイル {#upstream-database-configuration-file} -v2.0以降では、[アップストリームデータベース構成ファイル](/dm/dm-source-configuration-file.md)ファイルがDMワーカーのプロセス構成から分離されているため、 [v1.0.x DMワーカー設定](/dm/dm-worker-configuration-file.md)をベースにしたソース構成を取得する必要があります。 +v2.0以降では、[アップストリームデータベース構成ファイル](/dm/dm-source-configuration-file.md)ファイルがDM-workerのプロセス構成から分離されているため、 [v1.0.x DM-worker設定](/dm/dm-worker-configuration-file.md)をベースにしたソース構成を取得する必要があります。 > **Note:** > diff --git a/dm/migrate-data-using-dm.md b/dm/migrate-data-using-dm.md index df5b8bc0b5e09..1287b0f852dfa 100644 --- a/dm/migrate-data-using-dm.md +++ b/dm/migrate-data-using-dm.md @@ -178,10 +178,10 @@ tiup dmctl --master-addr 172.16.10.71:8261 stop-task test TiUPを使用して DM クラスタのデプロイとともに Prometheus、Alertmanager、および Grafana が正常にデプロイされ、Grafana のアドレスが`172.16.10.71`であると仮定します。DM に関連するアラート情報を表示するには、ブラウザで[http://172.16.10.71:9093](http://172.16.10.71:9093)を開き、Alertmanager にアクセスします。監視メトリックを確認するには、 [http://172.16.10.71:3000](http://172.16.10.71:3000)にアクセスし、DM ダッシュボードを選択します。 -DMクラスタの実行中、DMマスター、DMワーカー、およびdmctlは、監視メトリクス情報をログに出力します。各コンポーネントのログディレクトリは以下のとおりです。 +DMクラスタの実行中、DM-master、DM-worker、およびdmctlは、監視メトリクス情報をログに出力します。各コンポーネントのログディレクトリは以下のとおりです。 -- DMマスターのログディレクトリ：これは`--log-file` DMマスタープロセスパラメータで指定されます。DMがTiUPを使用してデプロイされている場合、ログディレクトリはDMマスターノードの`{log_dir}`になります。 -- DMワーカーのログディレクトリ：これは`--log-file` DMワーカープロセスパラメータで指定されます。DMがTiUPを使用してデプロイされている場合、ログディレクトリはDMワーカーノードの`{log_dir}`になります。 +- DM-masterのログディレクトリ：これは`--log-file` DM-masterプロセスパラメータで指定されます。DMがTiUPを使用してデプロイされている場合、ログディレクトリはDM-masterノードの`{log_dir}`になります。 +- DM-workerのログディレクトリ：これは`--log-file` DM-workerプロセスパラメータで指定されます。DMがTiUPを使用してデプロイされている場合、ログディレクトリはDM-workerノードの`{log_dir}`になります。 ## 関連リソース {#related-resources} diff --git a/dm/monitor-a-dm-cluster.md b/dm/monitor-a-dm-cluster.md index f275c5a1103f1..9bb73dc9f5eed 100644 --- a/dm/monitor-a-dm-cluster.md +++ b/dm/monitor-a-dm-cluster.md @@ -13,7 +13,7 @@ Grafana ダッシュボードでは、DM のデフォルト名は`DM-task`です ### `overview` {#overview} -`Overview` 、現在選択されているタスク内のすべての DM ワーカーおよび DM マスターインスタンスまたはソースの監視メトリクスが含まれています。現在のデフォルトのアラートルールは、単一の DM ワーカー/DM マスターインスタンス/ソースのみに適用されます。 +`Overview` 、現在選択されているタスク内のすべての DM-workerおよび DM-masterインスタンスまたはソースの監視メトリクスが含まれています。現在のデフォルトのアラートルールは、単一の DM-worker/DM-masterインスタンス/ソースのみに適用されます。 | メトリック名 | 説明 | 警告 | 重大度レベル | | :--------------------------- | :-------------------------------------------------------------------------------- | :--- | :----- | @@ -42,10 +42,10 @@ Grafana ダッシュボードでは、DM のデフォルト名は`DM-task`です | メトリック名 | 説明 | 警告 | 重大度レベル | | :-------------------------- | :------------------------------------------ | :------------------------------- | :----- | -| 1分あたりのDMマスター開始リーダーコンポーネントの数 | DM マスターがリーダー関連コンポーネントを有効にしようとする 1分あたりの試行回数 | 該当なし | 該当なし | -| 異なる州の労働者の数 | 各州のDM労働者の数 | 一部の DM ワーカーが 1時間以上オフラインになっています | 致命的 | -| 労働者国家 | DMワーカーの状態 | 該当なし | 該当なし | -| ワーカーイベントエラーの数 | DMワーカーエラーのさまざまなタイプの数 | 該当なし | 該当なし | +| 1分あたりのDM-master開始リーダーコンポーネントの数 | DM-masterがリーダー関連コンポーネントを有効にしようとする 1分あたりの試行回数 | 該当なし | 該当なし | +| 異なる州の労働者の数 | 各州のDM労働者の数 | 一部の DM-workerが 1時間以上オフラインになっています | 致命的 | +| 労働者国家 | DM-workerの状態 | 該当なし | 該当なし | +| ワーカーイベントエラーの数 | DM-workerエラーのさまざまなタイプの数 | 該当なし | 該当なし | | 1分あたりのシャードDDLエラー | 1分あたりのさまざまな種類のシャーディング DDL エラーの数 | シャーディングDDLエラーが発生した場合 | 致命的 | | 保留中のシャード DDL の数 | 保留中のシャーディングDDL操作の数 | 保留中のシャーディング DDL 操作が 1時間以上経過している | 致命的 | @@ -67,8 +67,8 @@ Grafana ダッシュボードでは、DM のデフォルト名は`DM-task`です | ロードユニットの合計バイト数 | ロードユニットによるインポートプロセスの解析、データKVの生成、およびインデックスKVの生成の各段階で処理されたバイト | 該当なし | 該当なし | | チャンク処理期間 | ロードユニットがデータソースファイルチャンクを処理する時間（秒） | 該当なし | 該当なし | | データファイルサイズ | ロードユニットによってインポートされた完全なデータ内のデータファイルの合計サイズ（ `INSERT INTO`ステートメントを含む） | 該当なし | 該当なし | -| ダンププロセスがエラーで終了しました | ダンプユニットはDMワーカー内でエラーに遭遇し、終了します。 | 即時アラート | 致命的 | -| ロードプロセスがエラーで終了しました | ロードユニットはDMワーカー内でエラーに遭遇し、終了します。 | 即時アラート | 致命的 | +| ダンププロセスがエラーで終了しました | ダンプユニットはDM-worker内でエラーに遭遇し、終了します。 | 即時アラート | 致命的 | +| ロードプロセスがエラーで終了しました | ロードユニットはDM-worker内でエラーに遭遇し、終了します。 | 即時アラート | 致命的 | ### Binlogレプリケーション {#binlog-replication} @@ -79,7 +79,7 @@ Grafana ダッシュボードでは、DM のデフォルト名は`DM-task`です | 同期の残り時間 | `syncer`アップストリーム マスターに完全に移行されるまでにかかる予測残り時間 (分) | 該当なし | 該当なし | | 遅延ゲージを複製する | binlogを上流から下流に複製するのにかかるレイテンシー時間（秒） | 該当なし | 該当なし | | 複製ラグヒストグラム | 上流から下流へのbinlogの複製のヒストグラム（秒単位）。統計メカニズムが異なるため、データが不正確になる可能性があることに注意してください。 | 該当なし | 該当なし | -| プロセスはエラーありで存在します | binlogレプリケーションユニットはDMワーカー内でエラーに遭遇し、終了します。 | 即時アラート | 致命的 | +| プロセスはエラーありで存在します | binlogレプリケーションユニットはDM-worker内でエラーに遭遇し、終了します。 | 即時アラート | 致命的 | | マスターと同期サーバー間のbinlogファイルのギャップ | `syncer`処理ユニットが上流マスターより遅れているbinlogファイルの数 | `syncer`処理ユニットが上流マスターより遅れているbinlogファイルの数が1つ（> 1）を超え、その状態が10分以上続くと、アラートが発生します。 | 致命的 | | リレーと同期の間のbinlogファイルのギャップ | `syncer`が`relay`遅れているbinlogファイルの数 | `syncer`処理ユニットが`relay`処理ユニットより遅れているbinlogファイルの数が1つを超え（>1）、その状態が10分以上続くと、アラートが発生します。 | 致命的 | | binlogイベントQPS | 単位時間あたりに受信したbinlogイベントの数 (この数にはスキップする必要があるイベントは含まれません) | 該当なし | 該当なし | @@ -114,7 +114,7 @@ Grafana ダッシュボードでは、DM のデフォルト名は`DM-task`です | :------------------------ | :------------------------------------------------------------ | :------------------------------------------------------------------------------ | :----- | | ストレージ容量 | リレーログが占有するディスクのストレージ容量 | 該当なし | 該当なし | | ストレージ残り | リレーログが占有するディスクの残りストレージ容量 | 値が10G未満になるとアラートが必要になります | 致命的 | -| プロセスはエラーで終了しました | リレーログはDMワーカー内でエラーが発生し、終了します。 | 即時アラート | 致命的 | +| プロセスはエラーで終了しました | リレーログはDM-worker内でエラーが発生し、終了します。 | 即時アラート | 致命的 | | リレーログデータの破損 | 破損したリレーログファイルの数 | 即時アラート | 緊急 | | マスターからのbinlogの読み取りに失敗しました | リレーログが上流のMySQLからbinlogを読み込む際に発生したエラーの数 | 即時アラート | 致命的 | | リレーログの書き込みに失敗しました | リレーログがbinlogをディスクに書き込むときに発生したエラーの数 | 即時アラート | 致命的 | @@ -135,7 +135,7 @@ Grafana ダッシュボードでは、インスタンスのデフォルト名は | :------------------------ | :------------------------------------------------------------ | :------------------------------------------------------------------------------ | :----- | | ストレージ容量 | リレーログが占有するディスクの総ストレージ容量 | 該当なし | 該当なし | | ストレージ残り | リレーログが占めるディスク内の残りのストレージ容量 | 値が10G未満になるとアラートが発生します | 致命的 | -| プロセスはエラーで終了しました | リレーログはDMワーカーでエラーが発生し、終了します | 即時アラート | 致命的 | +| プロセスはエラーで終了しました | リレーログはDM-workerでエラーが発生し、終了します | 即時アラート | 致命的 | | リレーログデータの破損 | 破損したリレーログの数 | 即時アラート | 緊急 | | マスターからのbinlogの読み取りに失敗しました | リレーログが上流のMySQLからbinlogを読み込む際に発生したエラーの数 | 即時アラート | 致命的 | | リレーログの書き込みに失敗しました | リレーログがbinlogをディスクに書き込むときに発生したエラーの数 | 即時アラート | 致命的 | diff --git a/dm/quick-start-create-task.md b/dm/quick-start-create-task.md index c7b3e4b83882a..eb6e77ce316b5 100644 --- a/dm/quick-start-create-task.md +++ b/dm/quick-start-create-task.md @@ -12,7 +12,7 @@ summary: DM クラスターがデプロイされた後に移行タスクを作 次のサンプル シナリオに基づいてデータ移行タスクを作成するとします。 - binlogを有効にした 2つの MySQL インスタンスと 1つの TiDB インスタンスをローカルにデプロイ。 -- DM クラスターの DM マスターを使用して、クラスターとデータ移行タスクを管理します。 +- DM クラスターの DM-masterを使用して、クラスターとデータ移行タスクを管理します。 各ノードの情報は以下の通りです。 @@ -21,7 +21,7 @@ summary: DM クラスターがデプロイされた後に移行タスクを作 | MySQL1 | 127.0.0.1 | 3306 | | MySQL2 | 127.0.0.1 | 3307 | | TiDB | 127.0.0.1 | 4000 | -| DMマスター | 127.0.0.1 | 8261 | +| DM-master | 127.0.0.1 | 8261 | このシナリオに基づいて、次のセクションではデータ移行タスクを作成する方法について説明します。 diff --git a/dm/quick-start-with-dm.md b/dm/quick-start-with-dm.md index 6ee84b8d7a37e..0c3458ee2d467 100644 --- a/dm/quick-start-with-dm.md +++ b/dm/quick-start-with-dm.md @@ -53,7 +53,7 @@ summary: TiUP Playground を使用してデータ移行環境をすばやくセ 4. 現在のターミナルで`tiup playground`を実行したままにして、次の手順のために新しいターミナルを開きます。 - このPlayground環境は、ターゲットTiDBデータベースとレプリケーションエンジン（DMマスターとDMワーカー）の実行プロセスを提供します。MySQL（ソース）→ DM（レプリケーションエンジン）→ TiDB（ターゲット）というデータフローを処理します。 + このPlayground環境は、ターゲットTiDBデータベースとレプリケーションエンジン（DM-masterとDM-worker）の実行プロセスを提供します。MySQL（ソース）→ DM（レプリケーションエンジン）→ TiDB（ターゲット）というデータフローを処理します。 ## ステップ2: ソースデータベースを準備する（オプション） {#step-2-prepare-a-source-database-optional} diff --git a/dm/relay-log.md b/dm/relay-log.md index 1dedc9d4efb10..45692b25d5e93 100644 --- a/dm/relay-log.md +++ b/dm/relay-log.md @@ -7,7 +7,7 @@ summary: DM リレーログのディレクトリ構造、初期移行ルール データ移行 (DM) リレーログは、データベースの変更を記述するイベントを含む番号付きファイルの複数のセットと、使用されたすべてのリレーログファイルの名前を含むインデックスファイルで構成されます。 -リレーログを有効にすると、DM-workerはアップストリームのbinlogをローカル設定ディレクトリに自動的に移行します（DMがTiUPを使用してデプロイされている場合、デフォルトの移行ディレクトリは`/`です）。デフォルト値は``で、 `relay-dir`に設定されていますが、 [上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)で変更できます。v5.4.0以降では、 [DMワーカー構成ファイル](/dm/dm-worker-configuration-file.md)の`relay-dir`でローカル設定ディレクトリを設定できます。これは、アップストリームデータベースの設定ファイルよりも優先されます。 +リレーログを有効にすると、DM-workerはアップストリームのbinlogをローカル設定ディレクトリに自動的に移行します（DMがTiUPを使用してデプロイされている場合、デフォルトの移行ディレクトリは`/`です）。デフォルト値は``で、 `relay-dir`に設定されていますが、 [上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)で変更できます。v5.4.0以降では、 [DM-worker構成ファイル](/dm/dm-worker-configuration-file.md)の`relay-dir`でローカル設定ディレクトリを設定できます。これは、アップストリームデータベースの設定ファイルよりも優先されます。 ## ユーザーシナリオ {#user-scenarios} @@ -68,7 +68,7 @@ start-relay -s mysql-replica-01 > > この起動方法はバージョン6.1で非推奨とされており、将来のリリースで削除される可能性があります。関連コマンドの出力には、次のプロンプトが表示されます: `start-relay/stop-relay with worker name will be deprecated soon. You can try stopping relay first and use start-relay without worker name instead` 。 -コマンド`start-relay`では、指定されたデータソースのリレーログを移行する 1つ以上の DM ワーカーを設定できます。ただし、パラメータで指定する DM ワーカーは、空いているか、上流のデータソースにバインドされている必要があります。例を以下に示します。 +コマンド`start-relay`では、指定されたデータソースのリレーログを移行する 1つ以上の DM-workerを設定できます。ただし、パラメータで指定する DM-workerは、空いているか、上流のデータソースにバインドされている必要があります。例を以下に示します。 ```bash start-relay -s mysql-replica-01 worker1 worker2 @@ -96,7 +96,7 @@ stop-relay -s mysql-replica-01 worker1 worker2
    -DM バージョン 2.0.2 より前のバージョン（v2.0.2 は含まない）では、DM ワーカーを上流データソースにバインドする際に、ソース設定ファイルの設定項目`enable-relay`がチェックされます。`enable-relay`が`true`に設定されている場合、DM はデータソースのリレーログ機能を有効にします。 +DM バージョン 2.0.2 より前のバージョン（v2.0.2 は含まない）では、DM-workerを上流データソースにバインドする際に、ソース設定ファイルの設定項目`enable-relay`がチェックされます。`enable-relay`が`true`に設定されている場合、DM はデータソースのリレーログ機能を有効にします。 設定項目`enable-relay`の設定方法については[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)を参照してください。 @@ -255,8 +255,8 @@ purge: - デフォルトは「0」で、リレーログの更新時刻に応じてデータのパージが実行されないことを示します。 - `purge.remain-space` - - 指定されたDMワーカーマシンが、自動バックグラウンドパージで安全にパージできるリレーログをパージしようとするディスク残量（GB単位）です`0`に設定すると、ディスク残量に応じたデータパージは実行されません。 - - デフォルトでは「15」で、使用可能なディスク容量が 15 GB 未満になると、DM マスターはリレーログを安全に消去しようとします。 + - 指定されたDM-workerマシンが、自動バックグラウンドパージで安全にパージできるリレーログをパージしようとするディスク残量（GB単位）です`0`に設定すると、ディスク残量に応じたデータパージは実行されません。 + - デフォルトでは「15」で、使用可能なディスク容量が 15 GB 未満になると、DM-masterはリレーログを安全に消去しようとします。 #### 手動パージ {#manual-purge} @@ -364,14 +364,14 @@ deb76a2b-09cc-11e9-9129-5242cf3bb246.000003 - 有効なローカルリレーログが存在しないが、アップストリームデータソース構成ファイルで`relay-binlog-name`または`relay-binlog-gtid`が指定されている場合: - - 非 GTID モードでは、 `relay-binlog-name`を指定すると、DM ワーカーは指定されたbinlogファイルから移行を開始します。 - - GTID モードでは、 `relay-binlog-gtid`を指定すると、DM ワーカーは指定された GTID から移行を開始します。 + - 非 GTID モードでは、 `relay-binlog-name`を指定すると、DM-workerは指定されたbinlogファイルから移行を開始します。 + - GTID モードでは、 `relay-binlog-gtid`を指定すると、DM-workerは指定された GTID から移行を開始します。 - 有効なローカルリレーログがなく、DM 構成ファイルに`relay-binlog-name`または`relay-binlog-gtid`が指定されていない場合: - - 非 GTID モードでは、DM ワーカーは、各サブタスクが移行している最も古いbinlogから移行を開始し、最新のbinlogが移行されるまで続けます。 + - 非 GTID モードでは、DM-workerは、各サブタスクが移行している最も古いbinlogから移行を開始し、最新のbinlogが移行されるまで続けます。 - - GTID モードでは、DM ワーカーは、各サブタスクが移行している最も古い GTID から移行を開始し、最新の GTID が移行されるまで続けます。 + - GTID モードでは、DM-workerは、各サブタスクが移行している最も古い GTID から移行を開始し、最新の GTID が移行されるまで続けます。 > **Note:** > diff --git a/dm/shard-merge-best-practices.md b/dm/shard-merge-best-practices.md index ad5dfde17c34a..f8407cd6533a7 100644 --- a/dm/shard-merge-best-practices.md +++ b/dm/shard-merge-best-practices.md @@ -19,7 +19,7 @@ summary: シャードマージのシナリオにおけるデータ移行のベ [シャードテーブルからのデータのマージと移行](/dm/feature-shard-merge-pessimistic.md#principles)から、DM のシャーディング DDL ロックは、複数の上流シャードテーブルから下流への DDL 操作の実行を調整するためのメカニズムであることが簡単にわかります。 -したがって、 `DM-master`の`shard-ddl-lock`コマンドでシャーディング DDL ロックが見つかった場合、または`query-status`コマンドで一部の DM ワーカーに`unresolvedGroups`または`blockingDDLs`ロックが見つかった場合は、 `shard-ddl-lock unlock`コマンドでシャーディング DDL ロックを手動で解除しようとしないでください。 +したがって、 `DM-master`の`shard-ddl-lock`コマンドでシャーディング DDL ロックが見つかった場合、または`query-status`コマンドで一部の DM-workerに`unresolvedGroups`または`blockingDDLs`ロックが見つかった場合は、 `shard-ddl-lock unlock`コマンドでシャーディング DDL ロックを手動で解除しようとしないでください。 代わりに、次のことができます。 @@ -161,4 +161,4 @@ CREATE TABLE `tbl_multi_pk` ( ## 速度制限とトラフィックフロー制御 {#speed-limits-and-traffic-flow-control} -複数の上流MySQLまたはMariaDBインスタンスから下流の同じTiDBクラスタにデータがマージされ移行されると、各上流インスタンスに対応するすべてのDMワーカーが、フルデータレプリケーションと増分データレプリケーションを同時に実行します。つまり、DMワーカーの数が増えるにつれて、デフォルトの同時実行度（フルデータ移行では`pool-size` 、増分データレプリケーションでは`worker-count` ）が蓄積され、下流データベースに過負荷がかかる可能性があります。このような場合、TiDBとDMの監視メトリクスに基づいて予備的なパフォーマンス分析を実施し、各同時実行パラメータの値を調整する必要があります。将来的には、DMは部分的に自動化されたトラフィックフロー制御をサポートする予定です。 +複数の上流MySQLまたはMariaDBインスタンスから下流の同じTiDBクラスタにデータがマージされ移行されると、各上流インスタンスに対応するすべてのDM-workerが、フルデータレプリケーションと増分データレプリケーションを同時に実行します。つまり、DM-workerの数が増えるにつれて、デフォルトの同時実行度（フルデータ移行では`pool-size` 、増分データレプリケーションでは`worker-count` ）が蓄積され、下流データベースに過負荷がかかる可能性があります。このような場合、TiDBとDMの監視メトリクスに基づいて予備的なパフォーマンス分析を実施し、各同時実行パラメータの値を調整する必要があります。将来的には、DMは部分的に自動化されたトラフィックフロー制御をサポートする予定です。 diff --git a/dm/task-configuration-file-full.md b/dm/task-configuration-file-full.md index a58ff93447361..d747a18fc3fa1 100644 --- a/dm/task-configuration-file-full.md +++ b/dm/task-configuration-file-full.md @@ -9,7 +9,7 @@ summary: このドキュメントでは、データ移行（DM）の高度なタ ## 重要な概念 {#important-concepts} -`source-id`や DM ワーカー ID などの重要な概念の説明については、 [重要な概念](/dm/dm-config-overview.md#important-concepts)を参照してください。 +`source-id`や DM-worker ID などの重要な概念の説明については、 [重要な概念](/dm/dm-config-overview.md#important-concepts)を参照してください。 ## タスク設定ファイルテンプレート（上級者向け） {#task-configuration-file-template-advanced} diff --git a/dm/usage-scenario-master-slave-switch.md b/dm/usage-scenario-master-slave-switch.md index ca1303ad1b6cf..ee6bb598b71cf 100644 --- a/dm/usage-scenario-master-slave-switch.md +++ b/dm/usage-scenario-master-slave-switch.md @@ -1,22 +1,22 @@ --- title: Switch DM-worker Connection between Upstream MySQL Instances -summary: アップストリーム MySQL インスタンス間で DM ワーカー接続を切り替える方法を学習します。 +summary: アップストリーム MySQL インスタンス間で DM-worker接続を切り替える方法を学習します。 --- -# アップストリーム MySQL インスタンス間の DM ワーカー接続を切り替える {#switch-dm-worker-connection-between-upstream-mysql-instances} +# アップストリーム MySQL インスタンス間の DM-worker接続を切り替える {#switch-dm-worker-connection-between-upstream-mysql-instances} DM-worker が接続するアップストリーム MySQL インスタンスでダウンタイム メンテナンスが必要になった場合、またはインスタンスが予期せずクラッシュした場合は、DM-worker 接続を同じ移行グループ内の別の MySQL インスタンスに切り替える必要があります。 > **Note:** > -> - DM ワーカー接続は、同じプライマリ - セカンダリ移行クラスター内のインスタンスにのみ切り替えることができます。 +> - DM-worker接続は、同じプライマリ - セカンダリ移行クラスター内のインスタンスにのみ切り替えることができます。 > - 新しく接続する MySQL インスタンスには、DM-worker に必要なbinlogが必要です。 -> - DM ワーカーは GTID セット モードで動作する必要があります。つまり、対応するソース構成ファイルで`enable-gtid: true`を指定する必要があります。 +> - DM-workerは GTID セット モードで動作する必要があります。つまり、対応するソース構成ファイルで`enable-gtid: true`を指定する必要があります。 > - 接続切り替えは以下の2つのシナリオのみをサポートします。各シナリオの手順を厳密に守ってください。そうしないと、新しく接続されたMySQLインスタンスに合わせてDMクラスタを再デプロイし、データ移行タスクを最初からやり直す必要がある場合があります。 GTID セットの詳細については、 [MySQLドキュメント](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-concepts.html#replication-gtids-concepts-gtid-sets)を参照してください。 -## 仮想IP経由でDMワーカー接続を切り替える {#switch-dm-worker-connection-via-virtual-ip} +## 仮想IP経由でDM-worker接続を切り替える {#switch-dm-worker-connection-via-virtual-ip} DM-worker が仮想 IP (VIP) を介してアップストリーム MySQL インスタンスに接続する場合、VIP 接続を別の MySQL インスタンスに切り替えると、アップストリーム接続アドレスは変更されずに、DM-worker に接続されている MySQL インスタンスが切り替わります。 @@ -24,7 +24,7 @@ DM-worker が仮想 IP (VIP) を介してアップストリーム MySQL イン > > このような状況では、DMに必要な変更を加えてください。そうしないと、VIP接続を別のMySQLインスタンスに切り替えた際に、DMが新旧のMySQLインスタンスに同時に異なる接続で接続してしまう可能性があります。このような状況では、DMに複製されたbinlogが、DMが受信する他のアップストリームステータスと一致しなくなり、予期しない異常やデータ損傷が発生する可能性があります。 -あるアップストリーム MySQL インスタンス (DM ワーカーが VIP 経由で接続している場合) を別のアップストリーム MySQL インスタンスに切り替えるには、次の手順を実行します。 +あるアップストリーム MySQL インスタンス (DM-workerが VIP 経由で接続している場合) を別のアップストリーム MySQL インスタンスに切り替えるには、次の手順を実行します。 1. `query-status`コマンドを使用して、binlogレプリケーションの現在の処理単位が下流に複製したbinlogに対応するGTIDセット（ `syncerBinlogGtid` ）を取得します。これらのセットを`gtid-S`としてマークします。 2. 新しいMySQLインスタンスで`SELECT @@GLOBAL.gtid_purged;`コマンドを使用して、削除されたバイナリログに対応するGTIDセットを取得します。これらのセットを`gtid-P`としてマークします。 diff --git a/migrate-large-mysql-shards-to-tidb.md b/migrate-large-mysql-shards-to-tidb.md index c0bba5a7d9283..9a0b0dacceac8 100644 --- a/migrate-large-mysql-shards-to-tidb.md +++ b/migrate-large-mysql-shards-to-tidb.md @@ -33,7 +33,7 @@ MySQL シャードのデータサイズが 1 TiB 未満の場合は、[小規模 - [Dumplingに必要なターゲットデータベース権限](/dumpling-overview.md#export-data-from-tidb-or-mysql) - [TiDB Lightningに必要なターゲットデータベース権限](/tidb-lightning/tidb-lightning-requirements.md) - [TiDB Lightningのダウンストリームストレージスペース](/tidb-lightning/tidb-lightning-requirements.md) -- [DMワーカーに必要な権限](/dm/dm-worker-intro.md) +- [DM-workerに必要な権限](/dm/dm-worker-intro.md) ### シャーディングされたテーブルの競合をチェックする {#check-conflicts-for-sharded-tables} @@ -248,7 +248,7 @@ tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml | パラメータ | 説明 | | ----------------------- | ----------------------------------------------------------------- | -| `--master-addr` | dmctlが接続するクラスタ内の任意のDMマスターノードの{advertise-addr}。例：172.16.10.71:8261 | +| `--master-addr` | dmctlが接続するクラスタ内の任意のDM-masterノードの{advertise-addr}。例：172.16.10.71:8261 | | `operate-source create` | データソースをDMクラスターにロードします。 | 上記の手順を繰り返して、すべてのMySQL上流インスタンスをデータソースとしてDMに追加します。 @@ -338,7 +338,7 @@ tiup dmctl --master-addr ${advertise-addr} start-task task.yaml | パラメータ | 説明 | | ---------- | ----------------------------------------------------------------- | -| --master-addr | dmctlが接続するクラスタ内の任意のDMマスターノードの{advertise-addr}。例：172.16.10.71:8261 | +| --master-addr | dmctlが接続するクラスタ内の任意のDM-masterノードの{advertise-addr}。例：172.16.10.71:8261 | | タスクの開始 | データ移行タスクを開始します。 | タスクの開始に失敗した場合は、返された結果のプロンプト メッセージに従って構成を変更し、次に`start-task task.yaml`の`tiup dmctl`サブコマンドを実行してタスクを再開します。問題が発生した場合は、[エラーを処理する](/dm/dm-error-handling.md)および[TiDB Data Migrationに関するFAQ](/dm/dm-faq.md)を参照してください。 diff --git a/migrate-small-mysql-shards-to-tidb.md b/migrate-small-mysql-shards-to-tidb.md index 5d32fb3a19af2..a229b286c177b 100644 --- a/migrate-small-mysql-shards-to-tidb.md +++ b/migrate-small-mysql-shards-to-tidb.md @@ -29,7 +29,7 @@ summary: シャードの小さなデータセットを MySQL から TiDB に移 移行を開始する前に、次のタスクが完了していることを確認してください。 - [TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md) -- [DMワーカーに必要な権限](/dm/dm-worker-intro.md) +- [DM-workerに必要な権限](/dm/dm-worker-intro.md) ### シャードテーブルの競合をチェックする {#check-conflicts-for-the-sharded-tables} @@ -89,7 +89,7 @@ tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml | パラメータ | 説明 | | ----------------------- | ------------------------------------------------------------------ | -| `--master-addr` | dmctlが接続するクラスタ内の任意のDMマスターノードの`{advertise-addr}`例：172.16.10.71:8261 | +| `--master-addr` | dmctlが接続するクラスタ内の任意のDM-masterノードの`{advertise-addr}`例：172.16.10.71:8261 | | `operate-source create` | データソースを DM クラスターにロードします。 | すべてのデータソースが DM クラスターに追加されるまで、上記の手順を繰り返します。 @@ -191,7 +191,7 @@ tiup dmctl --master-addr ${advertise-addr} start-task task.yaml | パラメータ | 説明 | | --------------- | ------------------------------------------------------------------ | -| `--master-addr` | dmctlが接続するクラスタ内の任意のDMマスターノードの`{advertise-addr}`例：172.16.10.71:8261 | +| `--master-addr` | dmctlが接続するクラスタ内の任意のDM-masterノードの`{advertise-addr}`例：172.16.10.71:8261 | | `start-task` | データ移行タスクを開始します。 | 移行タスクの開始に失敗した場合は、エラー情報に従って構成情報を変更し、手順`start-task task.yaml`再度実行して移行タスクを開始してください。問題が発生した場合は、 [エラーの処理](/dm/dm-error-handling.md)と[FAQ](/dm/dm-faq.md)を参照してください。 @@ -218,8 +218,8 @@ Grafana またはログを通じて、移行タスクの履歴と内部運用メ DM の実行中、DM-master、DM-worker、dmctl は、移行タスクに関する情報を含むログを出力します。各コンポーネントのログディレクトリは以下のとおりです。 - - DMマスターログディレクトリ：DMマスタープロセスパラメータ`--log-file`で指定されます。DMがTiUPを使用して展開されている場合、ログディレクトリは`/dm-deploy/dm-master-8261/log/`です。 - - DMワーカーログディレクトリ：DMワーカープロセスパラメータ`--log-file`で指定します。DMがTiUPを使用してデプロイされている場合、ログディレクトリは`/dm-deploy/dm-worker-8262/log/`です。 + - DM-masterログディレクトリ：DM-masterプロセスパラメータ`--log-file`で指定されます。DMがTiUPを使用して展開されている場合、ログディレクトリは`/dm-deploy/dm-master-8261/log/`です。 + - DM-workerログディレクトリ：DM-workerプロセスパラメータ`--log-file`で指定します。DMがTiUPを使用してデプロイされている場合、ログディレクトリは`/dm-deploy/dm-worker-8262/log/`です。 ## 参照 {#see-also} diff --git a/migrate-small-mysql-to-tidb.md b/migrate-small-mysql-to-tidb.md index e6df1b91c7058..0e24305d5aac0 100644 --- a/migrate-small-mysql-to-tidb.md +++ b/migrate-small-mysql-to-tidb.md @@ -44,7 +44,7 @@ tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml | パラメータ | 説明 | | :---------------------- | :-------------------------------------------------------------------- | -| `--master-addr` | `dmctl`が接続するクラスタ内の任意のDMマスターノードの`{advertise-addr}`例：172.16.10.71:8261。 | +| `--master-addr` | `dmctl`が接続するクラスタ内の任意のDM-masterノードの`{advertise-addr}`例：172.16.10.71:8261。 | | `operate-source create` | データソースを DM クラスターにロードします。 | ## ステップ2. 移行タスクを作成する {#step-2-create-the-migration-task} @@ -103,7 +103,7 @@ tiup dmctl --master-addr ${advertise-addr} start-task task.yaml | パラメータ | 説明 | | --------------- | ---------------------------------------------------------------------- | -| `--master-addr` | `dmctl`が接続するクラスター内の任意のDMマスターノードの`{advertise-addr}`例：172.16.10.71:8261。 | +| `--master-addr` | `dmctl`が接続するクラスター内の任意のDM-masterノードの`{advertise-addr}`例：172.16.10.71:8261。 | | `start-task` | 移行タスクを開始する | タスクの起動に失敗した場合は、返された結果に従って設定を変更した後、コマンド`start-task task.yaml`を実行してタスクを再起動できます。問題が発生した場合は、コマンド[エラーの処理](/dm/dm-error-handling.md)と[FAQ](/dm/dm-faq.md)を参照してください。 @@ -124,7 +124,7 @@ tiup dmctl --master-addr ${advertise-addr} query-status ${task-name} TiUPを使用して DM をデプロイする際に Prometheus、Alertmanager、Grafana をデプロイしている場合は、デプロイ時に指定した IP アドレスとポートを使用して Grafana にアクセスできます。その後、DM ダッシュボードを選択して、DM 関連の監視メトリクスを表示できます。 -- DMマスターのログディレクトリ：DMマスタープロセスパラメータ`--log-file`で指定されます。TiUPを使用してDMを展開した場合、ログディレクトリはデフォルトで`/dm-deploy/dm-master-8261/log/`なります。 +- DM-masterのログディレクトリ：DM-masterプロセスパラメータ`--log-file`で指定されます。TiUPを使用してDMを展開した場合、ログディレクトリはデフォルトで`/dm-deploy/dm-master-8261/log/`なります。 - DM-workerのログディレクトリ：DM-workerプロセスパラメータ`--log-file`で指定されます。TiUPを使用してDMをデプロイした場合、デフォルトのログディレクトリは`/dm-deploy/dm-worker-8262/log/`です。 ## 次は何？ {#what-s-next} diff --git a/migrate-with-more-columns-downstream.md b/migrate-with-more-columns-downstream.md index 9bea1ddc4d3ab..aeb1c8c5e1139 100644 --- a/migrate-with-more-columns-downstream.md +++ b/migrate-with-more-columns-downstream.md @@ -77,7 +77,7 @@ DM がダウンストリームテーブルスキーマを使用してアップ | パラメータ | 説明 | | :------------------ | :--------------------------------------------------------------------------------------------------------------- | - | `-master-addr` | dmctl が接続されるクラスター内の任意の DM マスターノードの`${advertise-addr}`を指定します。`${advertise-addr}`は 、DM マスターが外部にアドバタイズするアドレスを示します。 | + | `-master-addr` | dmctl が接続されるクラスター内の任意の DM-masterノードの`${advertise-addr}`を指定します。`${advertise-addr}`は 、DM-masterが外部にアドバタイズするアドレスを示します。 | | `binlog-schema set` | スキーマ情報を手動で設定します。 | | `-s` | ソースを指定します。`${source-id}`は MySQL データのソース ID を示します。 | | `${task-name}` | データ移行タスクの`task.yaml`構成ファイルで定義されている移行タスクの名前を指定します。 | diff --git a/releases/release-5.3.1.md b/releases/release-5.3.1.md index 66134f2ad7342..8aa44ceba44eb 100644 --- a/releases/release-5.3.1.md +++ b/releases/release-5.3.1.md @@ -119,7 +119,7 @@ TiDB バージョン: 5.3.1 - 長いvarcharsがエラーを報告するバグを修正`Column length too big` [＃4637](https://github.com/pingcap/tiflow/issues/4637) - PDリーダーが強制終了した際にTiCDCノードが異常終了するバグを修正[＃4248](https://github.com/pingcap/tiflow/issues/4248) - - セーフモードでの更新ステートメントの実行エラーにより、DMワーカーがpanicになる可能性がある問題を修正しました[＃4317](https://github.com/pingcap/tiflow/issues/4317) + - セーフモードでの更新ステートメントの実行エラーにより、DM-workerがpanicになる可能性がある問題を修正しました[＃4317](https://github.com/pingcap/tiflow/issues/4317) - TiKVクライアントのキャッシュされたリージョンメトリックが負になる可能性がある問題を修正しました[＃4300](https://github.com/pingcap/tiflow/issues/4300) - 必要なプロセッサ情報が存在しない場合にHTTP APIがパニックを起こすバグを修正[＃3840](https://github.com/pingcap/tiflow/issues/3840) - 一時停止中の変更フィードを削除したときに、REDO ログがクリーンアップされないバグを修正しました。 [＃4740](https://github.com/pingcap/tiflow/issues/4740) @@ -149,7 +149,7 @@ TiDB バージョン: 5.3.1 - TiDB Data Migration (DM) - - DMマスターとDMワーカーを特定の順序で再起動した後にDMマスターのリレーステータスが間違っているというバグを修正[＃3478](https://github.com/pingcap/tiflow/issues/3478) + - DM-masterとDM-workerを特定の順序で再起動した後にDM-masterのリレーステータスが間違っているというバグを修正[＃3478](https://github.com/pingcap/tiflow/issues/3478) - DM-workerが再起動後に起動に失敗するバグを修正[＃3344](https://github.com/pingcap/tiflow/issues/3344) - PARTITION DDLの実行に時間がかかりすぎるとDMタスクが失敗するバグを修正[＃3854](https://github.com/pingcap/tiflow/issues/3854) - アップストリームがMySQL 8.0 場合にDMが`invalid sequence`報告する可能性があるバグを修正しました [＃3847](https://github.com/pingcap/tiflow/issues/3847) diff --git a/releases/release-5.3.2.md b/releases/release-5.3.2.md index ebe59db69e0af..9d16338cacb4e 100644 --- a/releases/release-5.3.2.md +++ b/releases/release-5.3.2.md @@ -36,7 +36,7 @@ TiDB バージョン: 5.3.2 - TiDB Data Migration (DM) - - `/tmp`ではなく DM ワーカーの作業ディレクトリを使用して内部ファイルを書き込み、タスクが停止した後にディレクトリを消去する Syncer のサポート[＃4107](https://github.com/pingcap/tiflow/issues/4107) + - `/tmp`ではなく DM-workerの作業ディレクトリを使用して内部ファイルを書き込み、タスクが停止した後にディレクトリを消去する Syncer のサポート[＃4107](https://github.com/pingcap/tiflow/issues/4107) - TiDB Lightning @@ -152,9 +152,9 @@ TiDB バージョン: 5.3.2 - タスクが自動的に再開された後にDMがより多くのディスクスペースを占有する問題を修正[＃3734](https://github.com/pingcap/tiflow/issues/3734) [＃5344](https://github.com/pingcap/tiflow/issues/5344) - `case-sensitive: true`が設定されていない場合、大文字テーブルを複製できない問題を修正[＃5255](https://github.com/pingcap/tiflow/issues/5255) - 下流でフィルタリングされたDDLを手動で実行すると、タスク再開が失敗する場合がある問題を修正しました[＃5272](https://github.com/pingcap/tiflow/issues/5272) - - `SHOW CREATE TABLE`ステートメントによって返されるインデックスの先頭に主キーがない場合に発生する DM ワーカーpanicの問題を修正しました。 [＃5159](https://github.com/pingcap/tiflow/issues/5159) + - `SHOW CREATE TABLE`ステートメントによって返されるインデックスの先頭に主キーがない場合に発生する DM-workerpanicの問題を修正しました。 [＃5159](https://github.com/pingcap/tiflow/issues/5159) - GTID が有効になっているときやタスクが自動的に再開されたときに CPU 使用率が上昇し、大量のログが出力される問題を修正しました[＃5063](https://github.com/pingcap/tiflow/issues/5063) - - DMマスターの再起動後にリレーログが無効になる可能性がある問題を修正[＃4803](https://github.com/pingcap/tiflow/issues/4803) + - DM-masterの再起動後にリレーログが無効になる可能性がある問題を修正[＃4803](https://github.com/pingcap/tiflow/issues/4803) - TiDB Lightning diff --git a/releases/release-5.4.0.md b/releases/release-5.4.0.md index 7854c01feeaf9..46c8f9501dd3b 100644 --- a/releases/release-5.4.0.md +++ b/releases/release-5.4.0.md @@ -250,7 +250,7 @@ TiDB バージョン: 5.4.0 - **DM の`transfer source`を最適化して、レプリケーションタスクをスムーズに実行できるようにします。** - DMワーカーノードの負荷が不均衡な場合、 `transfer source`コマンドを使用して、 `source`の構成を別の負荷に手動で転送できます。最適化後、 `transfer source`コマンドを使用すると、手動操作が簡素化されます。DMは他の操作を内部的に完了するため、関連するすべてのタスクを一時停止することなく、ソースをスムーズに転送できます。 + DM-workerノードの負荷が不均衡な場合、 `transfer source`コマンドを使用して、 `source`の構成を別の負荷に手動で転送できます。最適化後、 `transfer source`コマンドを使用すると、手動操作が簡素化されます。DMは他の操作を内部的に完了するため、関連するすべてのタスクを一時停止することなく、ソースをスムーズに転送できます。 - **DM OpenAPIが一般提供開始（GA）となりました** diff --git a/releases/release-5.4.1.md b/releases/release-5.4.1.md index 23d3779b5ce01..53731a9e0abb6 100644 --- a/releases/release-5.4.1.md +++ b/releases/release-5.4.1.md @@ -43,7 +43,7 @@ TiDB v5.4.1では、製品設計上の互換性に関する変更は行われて - TiDB Data Migration (DM) - - `/tmp`ではなく DM ワーカーの作業ディレクトリを使用して内部ファイルを書き込み、タスクが停止した後にディレクトリを消去する Syncer のサポート[＃4107](https://github.com/pingcap/tiflow/issues/4107) + - `/tmp`ではなく DM-workerの作業ディレクトリを使用して内部ファイルを書き込み、タスクが停止した後にディレクトリを消去する Syncer のサポート[＃4107](https://github.com/pingcap/tiflow/issues/4107) ## バグ修正 {#bug-fixes} @@ -166,8 +166,8 @@ TiDB v5.4.1では、製品設計上の互換性に関する変更は行われて - ログに「チェックポイントに変更はありません。同期フラッシュチェックポイントをスキップしてください」というメッセージが数百件出力され、レプリケーションが非常に遅くなる問題を修正しました[＃4619](https://github.com/pingcap/tiflow/issues/4619) - 長いvarcharsがエラーを報告するバグを修正`Column length too big` [＃4637](https://github.com/pingcap/tiflow/issues/4637) - - セーフモードでの更新ステートメントの実行エラーにより、DMワーカーがpanicになる可能性がある問題を修正しました[＃4317](https://github.com/pingcap/tiflow/issues/4317) + - セーフモードでの更新ステートメントの実行エラーにより、DM-workerがpanicになる可能性がある問題を修正しました[＃4317](https://github.com/pingcap/tiflow/issues/4317) - 下流でフィルタリングされたDDLを手動で実行すると、タスク再開が失敗する場合がある問題を修正しました[＃5272](https://github.com/pingcap/tiflow/issues/5272) - アップストリームでbinlogが有効になっていない場合に`query-status`コマンドでデータが返されないバグを修正 [＃5121](https://github.com/pingcap/tiflow/issues/5121) - - `SHOW CREATE TABLE`ステートメントによって返されるインデックスの先頭に主キーがない場合に発生する DM ワーカーpanicの問題を修正しました。 [＃5159](https://github.com/pingcap/tiflow/issues/5159) + - `SHOW CREATE TABLE`ステートメントによって返されるインデックスの先頭に主キーがない場合に発生する DM-workerpanicの問題を修正しました。 [＃5159](https://github.com/pingcap/tiflow/issues/5159) - GTID が有効になっているときやタスクが自動的に再開されたときに CPU 使用率が上昇し、大量のログが出力される問題を修正しました[＃5063](https://github.com/pingcap/tiflow/issues/5063) diff --git a/releases/release-5.4.3.md b/releases/release-5.4.3.md index 767b02995c663..3ed447be051b2 100644 --- a/releases/release-5.4.3.md +++ b/releases/release-5.4.3.md @@ -83,7 +83,7 @@ TiDB バージョン: 5.4.3 - TiDB Data Migration (DM) - - DB Connを取得する際に DM ワーカーがスタックする可能性がある問題を修正しました[＃3733](https://github.com/pingcap/tiflow/issues/3733) + - DB Connを取得する際に DM-workerがスタックする可能性がある問題を修正しました[＃3733](https://github.com/pingcap/tiflow/issues/3733) - DMが`Specified key was too long`エラーを報告する問題を修正しました[＃5315](https://github.com/pingcap/tiflow/issues/5315) - レプリケーション中にlatin1データが破損する可能性がある問題を修正[＃7028](https://github.com/pingcap/tiflow/issues/7028) - TiDBがIPv6ホストを使用しているときにDMが起動に失敗する問題を修正[＃6249](https://github.com/pingcap/tiflow/issues/6249) diff --git a/releases/release-6.0.0-dmr.md b/releases/release-6.0.0-dmr.md index f33e37aee3bbb..2236a5ccbb7bf 100644 --- a/releases/release-6.0.0-dmr.md +++ b/releases/release-6.0.0-dmr.md @@ -407,7 +407,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - 上流のテーブルスキーマが不整合で楽観的モードの場合のタスクの開始をサポート[＃3629](https://github.com/pingcap/tiflow/issues/3629) [＃3708](https://github.com/pingcap/tiflow/issues/3708) [＃3786](https://github.com/pingcap/tiflow/issues/3786) - `stopped`状態でのタスク作成をサポート [＃4484](https://github.com/pingcap/tiflow/issues/4484) - - `/tmp`ではなく DM ワーカーの作業ディレクトリを使用して内部ファイルを書き込み、タスクが停止した後にディレクトリを消去する Syncer をサポートします[＃4107](https://github.com/pingcap/tiflow/issues/4107) + - `/tmp`ではなく DM-workerの作業ディレクトリを使用して内部ファイルを書き込み、タスクが停止した後にディレクトリを消去する Syncer をサポートします[＃4107](https://github.com/pingcap/tiflow/issues/4107) - 事前チェックが改善されました。重要なチェックが省略されなくなりました[＃3608](https://github.com/pingcap/tiflow/issues/3608) - TiDB Lightning @@ -531,9 +531,9 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - TiDB Data Migration (DM) - ステータスを照会するときにのみ同期メトリックが更新される問題を修正しました [＃4281](https://github.com/pingcap/tiflow/issues/4281) - - セーフモードでの更新ステートメントの実行エラーにより、DMワーカーがpanicになる可能性がある問題を修正しました[＃4317](https://github.com/pingcap/tiflow/issues/4317) + - セーフモードでの更新ステートメントの実行エラーにより、DM-workerがpanicになる可能性がある問題を修正しました[＃4317](https://github.com/pingcap/tiflow/issues/4317) - 長いvarcharsがエラーを報告するバグを修正`Column length too big` [＃4637](https://github.com/pingcap/tiflow/issues/4637) - - 複数の DM ワーカーが同じアップストリームからデータを書き込むことで発生する競合の問題を修正しました。 [＃3737](https://github.com/pingcap/tiflow/issues/3737) + - 複数の DM-workerが同じアップストリームからデータを書き込むことで発生する競合の問題を修正しました。 [＃3737](https://github.com/pingcap/tiflow/issues/3737) - ログに「チェックポイントに変更はありません。同期フラッシュチェックポイントをスキップしてください」というメッセージが数百件出力され、レプリケーションが非常に遅くなる問題を修正しました[＃4619](https://github.com/pingcap/tiflow/issues/4619) - 悲観的モードでシャードをマージし、上流から増分データを複製する際のDML損失の問題を修正しました。 [＃5002](https://github.com/pingcap/tiflow/issues/5002) diff --git a/releases/release-6.1.0.md b/releases/release-6.1.0.md index 05b019cce2a41..a0c15e0e8440a 100644 --- a/releases/release-6.1.0.md +++ b/releases/release-6.1.0.md @@ -423,7 +423,7 @@ TiDB バージョン: 6.1.0 - チェックポイントフラッシュにより失敗した行のデータがスキップされる可能性がある問題を修正[＃5279](https://github.com/pingcap/tiflow/issues/5279) - 一部のケースでダウンストリームでフィルタリングされた DDL を手動で実行するとタスクの再開に失敗する可能性がある問題を修正しました [＃5272](https://github.com/pingcap/tiflow/issues/5272) - `case-sensitive: true`が設定されていない場合、大文字テーブルを複製できない問題を修正[＃5255](https://github.com/pingcap/tiflow/issues/5255) - - `SHOW CREATE TABLE`ステートメントによって返されるインデックスの先頭に主キーがない場合に発生する DM ワーカーpanicの問題を修正しました。 [＃5159](https://github.com/pingcap/tiflow/issues/5159) + - `SHOW CREATE TABLE`ステートメントによって返されるインデックスの先頭に主キーがない場合に発生する DM-workerpanicの問題を修正しました。 [＃5159](https://github.com/pingcap/tiflow/issues/5159) - GTID が有効になっているときやタスクが自動的に再開されたときに CPU 使用率が上昇し、大量のログが出力される問題を修正しました[＃5063](https://github.com/pingcap/tiflow/issues/5063) - DM WebUI のオフライン オプションとその他の使用上の問題を修正しました [＃4993](https://github.com/pingcap/tiflow/issues/4993) - アップストリームでGTIDが空の場合に増分タスクの開始に失敗する問題を修正 [＃3731](https://github.com/pingcap/tiflow/issues/3731) diff --git a/releases/release-6.1.1.md b/releases/release-6.1.1.md index f17b9814db676..56dfd625d3c3e 100644 --- a/releases/release-6.1.1.md +++ b/releases/release-6.1.1.md @@ -147,7 +147,7 @@ Quick access: [クイックスタート](https://docs-archive.pingcap.com/tidb/v - `query-status`で発生する可能性のあるデータ競合の問題を修正 [#4811](https://github.com/pingcap/tiflow/issues/4811) @[lyzx2001](https://github.com/lyzx2001) - `operate-schema`コマンドの異なる出力形式を修正 [＃5688](https://github.com/pingcap/tiflow/issues/5688) @[ForwardStar](https://github.com/ForwardStar) - リレーがエラーに遭遇したときの goroutine リークを修正 [＃6193](https://github.com/pingcap/tiflow/issues/6193) @[lance6716](https://github.com/lance6716) - - DB Conn を取得する際に DM ワーカーがスタックする可能性がある問題を修正しました [＃3733](https://github.com/pingcap/tiflow/issues/3733) @[lance6716](https://github.com/lance6716) + - DB Conn を取得する際に DM-workerがスタックする可能性がある問題を修正しました [＃3733](https://github.com/pingcap/tiflow/issues/3733) @[lance6716](https://github.com/lance6716) - TiDBがIPv6ホストを使用するとDMが起動に失敗する問題を修正 [＃6249](https://github.com/pingcap/tiflow/issues/6249) @[D3Hunter](https://github.com/D3Hunter) - TiCDC diff --git a/releases/release-6.1.2.md b/releases/release-6.1.2.md index 00a5cfc61b8fc..ecdea48917a93 100644 --- a/releases/release-6.1.2.md +++ b/releases/release-6.1.2.md @@ -79,7 +79,7 @@ Quick access: [クイックスタート](https://docs-archive.pingcap.com/tidb/v - DMタスクが同期ユニットに入り、中断されると上流のテーブル構造情報が失われる問題を修正[#7159](https://github.com/pingcap/tiflow/issues/7159) @[lance6716](https://github.com/lance6716) - チェックポイントを保存するときに SQL ステートメントを分割して、大規模なトランザクションエラーを修正します。 [＃5010](https://github.com/pingcap/tiflow/issues/5010) @[lance6716](https://github.com/lance6716) - DM事前チェックに`INFORMATION_SCHEMA` の`SELECT`権限が必要になる問題を修正 [＃7317](https://github.com/pingcap/tiflow/issues/7317) @[lance6716](https://github.com/lance6716) - - 高速/完全バリデータで DM タスクを実行した後に DM ワーカーがデッドロックエラーをトリガーする問題を修正しました [＃7241](https://github.com/pingcap/tiflow/issues/7241) @[buchuitoudegou](https://github.com/buchuitoudegou) + - 高速/完全バリデータで DM タスクを実行した後に DM-workerがデッドロックエラーをトリガーする問題を修正しました [＃7241](https://github.com/pingcap/tiflow/issues/7241) @[buchuitoudegou](https://github.com/buchuitoudegou) - DMが`Specified key was too long`エラーを報告する問題を修正 [＃5315](https://github.com/pingcap/tiflow/issues/5315) @[lance6716](https://github.com/lance6716) - レプリケーション中に latin1 データが破損する可能性がある問題を修正しました [＃7028](https://github.com/pingcap/tiflow/issues/7028) @[lance6716](https://github.com/lance6716) diff --git a/releases/release-6.1.3.md b/releases/release-6.1.3.md index dd13d67632522..04faf46edac6a 100644 --- a/releases/release-6.1.3.md +++ b/releases/release-6.1.3.md @@ -86,4 +86,4 @@ Quick access: [クイックスタート](https://docs-archive.pingcap.com/tidb/v - `collation_compatible` `"strict"`に設定すると、DM が重複した照合順序を持つ SQL を生成する可能性がある問題を修正しました。 [#6832](https://github.com/pingcap/tiflow/issues/6832) @[lance6716](https://github.com/lance6716) - DMタスクが`Unknown placement policy`エラーで停止する可能性がある問題を修正 [＃7493](https://github.com/pingcap/tiflow/issues/7493) @[lance6716](https://github.com/lance6716) - 場合によってはリレーログがアップストリームから再度取得される可能性がある問題を修正[＃7525](https://github.com/pingcap/tiflow/issues/7525) @[liumengya94](https://github.com/liumengya94) - - 既存のワーカーが終了する前に新しい DM ワーカーがスケジュールされると、データが複数回複製される問題を修正しました[#7658](https://github.com/pingcap/tiflow/issues/7658) @[GMHDBJD](https://github.com/GMHDBJD) + - 既存のワーカーが終了する前に新しい DM-workerがスケジュールされると、データが複数回複製される問題を修正しました[#7658](https://github.com/pingcap/tiflow/issues/7658) @[GMHDBJD](https://github.com/GMHDBJD) diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 0420356b81413..c0fe52aa87101 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -446,7 +446,7 @@ TiDBバージョン: 6.4.0-DMR - TiDB Data Migration (DM) - DM WebUI が間違った`allow-list`パラメータを生成する問題を修正 [#7096](https://github.com/pingcap/tiflow/issues/7096) @[zoubingwu](https://github.com/zoubingwu) - - DMワーカーが起動または停止時にデータ競合を引き起こす確率がある問題を修正します [#6401](https://github.com/pingcap/tiflow/issues/6401) @[liumengya94](https://github.com/liumengya94) + - DM-workerが起動または停止時にデータ競合を引き起こす確率がある問題を修正します [#6401](https://github.com/pingcap/tiflow/issues/6401) @[liumengya94](https://github.com/liumengya94) - DM が`UPDATE`または`DELETE`ステートメントを複製する際に、対応する行データが存在しない場合、DM がイベントをサイレントに無視する問題を修正します。 [#6383](https://github.com/pingcap/tiflow/issues/6383) @[GMHDBJD](https://github.com/GMHDBJD) - `secondsBehindMaster`コマンドを実行した後、 `query-status`フィールドが表示されない問題を修正しました [#7189](https://github.com/pingcap/tiflow/issues/7189) @[GMHDBJD](https://github.com/GMHDBJD) - チェックポイントの更新時に大きなトランザクションが発生する可能性がある問題を修正しました [#5010](https://github.com/pingcap/tiflow/issues/5010) @[lance6716](https://github.com/lance6716) diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index d1a3780c60ffb..20ad50bf358d5 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -488,7 +488,7 @@ v6.5.0 以降では、v4.0.7 で導入された`AMEND TRANSACTION`メカニズ - TiDB Data Migration (DM) - 上流データベースがGTIDモードを有効にしているが、データがない場合に`task-mode:all`タスクを開始できない問題を修正しました。 [＃7037](https://github.com/pingcap/tiflow/issues/7037) @[liumengya94](https://github.com/liumengya94) - - 既存のワーカーが終了する前に新しい DM ワーカーがスケジュールされると、データが複数回複製される問題を修正しました[＃7658](https://github.com/pingcap/tiflow/issues/7658) @[GMHDBJD](https://github.com/GMHDBJD) + - 既存のワーカーが終了する前に新しい DM-workerがスケジュールされると、データが複数回複製される問題を修正しました[＃7658](https://github.com/pingcap/tiflow/issues/7658) @[GMHDBJD](https://github.com/GMHDBJD) - アップストリームデータベースが正規表現を使用して権限を付与するときに DM 事前チェックに合格しない問題を修正しました [＃7645](https://github.com/pingcap/tiflow/issues/7645) @[lance6716](https://github.com/lance6716) - TiDB Lightning diff --git a/releases/release-6.5.12.md b/releases/release-6.5.12.md index a783c26e0d9d6..cd42718a17de0 100644 --- a/releases/release-6.5.12.md +++ b/releases/release-6.5.12.md @@ -167,7 +167,7 @@ TiDBバージョン: 6.5.12 - TiDB Data Migration (DM) - - 複数の DM マスターノードが同時にリーダーになり、データの不整合が発生する可能性がある問題を修正しました[＃11602](https://github.com/pingcap/tiflow/issues/11602) @[GMHDBJD](https://github.com/GMHDBJD) + - 複数の DM-masterノードが同時にリーダーになり、データの不整合が発生する可能性がある問題を修正しました[＃11602](https://github.com/pingcap/tiflow/issues/11602) @[GMHDBJD](https://github.com/GMHDBJD) - パスワードの長さが19文字を超えるとMySQL 8.0への接続に失敗する問題を修正[＃11603](https://github.com/pingcap/tiflow/issues/11603) @[fishiu](https://github.com/fishiu) - TLSと`shard-mode`の両方が設定されている場合に`start-task`の事前チェックが失敗する問題を修正 [＃11842](https://github.com/pingcap/tiflow/issues/11842) @[sunxiaoguang](https://github.com/sunxiaoguang) diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md index 4dcc05567864e..a06f2ae727b0f 100644 --- a/releases/release-7.0.0.md +++ b/releases/release-7.0.0.md @@ -443,7 +443,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - TiDB Data Migration (DM) - - DMワーカーノードがGoogle Cloud Storageを使用する際に、ブレークポイントが多すぎるためにGoogle Cloud Storageのリクエスト頻度制限に達し、DMワーカーがGoogle Cloud Storageにデータを書き込めなくなり、結果としてデータ全体の読み込みに失敗する問題を修正しました。 [#8482](https://github.com/pingcap/tiflow/issues/8482) @[maxshuang](https://github.com/maxshuang) + - DM-workerノードがGoogle Cloud Storageを使用する際に、ブレークポイントが多すぎるためにGoogle Cloud Storageのリクエスト頻度制限に達し、DM-workerがGoogle Cloud Storageにデータを書き込めなくなり、結果としてデータ全体の読み込みに失敗する問題を修正しました。 [#8482](https://github.com/pingcap/tiflow/issues/8482) @[maxshuang](https://github.com/maxshuang) - 複数のDMタスクが同時に同じダウンストリームデータを複製し、すべてがダウンストリームメタデータテーブルを使用してブレークポイント情報を記録する場合、すべてのタスクのブレークポイント情報が同じメタデータテーブルに書き込まれ、同じタスクIDが使用される問題を修正しました。 [#8500](https://github.com/pingcap/tiflow/issues/8500) @[maxshuang](https://github.com/maxshuang) - TiDB Lightning diff --git a/releases/release-7.1.1.md b/releases/release-7.1.1.md index 73bf70839b5d6..b79092e3a0331 100644 --- a/releases/release-7.1.1.md +++ b/releases/release-7.1.1.md @@ -135,7 +135,7 @@ TiDB バージョン: 7.1.1 - TiDB Data Migration (DM) - - 移行対象のテーブル内の一意インデックスに空の列が含まれている場合にDMマスターが異常終了する問題を修正[＃9247](https://github.com/pingcap/tiflow/issues/9247) @[lance6716](https://github.com/lance6716) + - 移行対象のテーブル内の一意インデックスに空の列が含まれている場合にDM-masterが異常終了する問題を修正[＃9247](https://github.com/pingcap/tiflow/issues/9247) @[lance6716](https://github.com/lance6716) - TiDB Lightning diff --git a/releases/release-7.1.6.md b/releases/release-7.1.6.md index e09042d1ac0ee..9b9efde32c11d 100644 --- a/releases/release-7.1.6.md +++ b/releases/release-7.1.6.md @@ -280,7 +280,7 @@ TiDB バージョン: 7.1.6 - TiDB Data Migration (DM) - DMが`ALTER DATABASE`ステートメントを処理するときにデフォルトのデータベースを設定せず、レプリケーションエラーが発生する問題を修正しました。 [＃11503](https://github.com/pingcap/tiflow/issues/11503) @[lance6716](https://github.com/lance6716) - - 複数の DM マスターノードが同時にリーダーになり、データの不整合が発生する可能性がある問題を修正しました[＃11602](https://github.com/pingcap/tiflow/issues/11602) @[GMHDBJD](https://github.com/GMHDBJD) + - 複数の DM-masterノードが同時にリーダーになり、データの不整合が発生する可能性がある問題を修正しました[＃11602](https://github.com/pingcap/tiflow/issues/11602) @[GMHDBJD](https://github.com/GMHDBJD) - `go-mysql` にアップグレードして接続ブロックの問題を修正しました [＃11041](https://github.com/pingcap/tiflow/issues/11041) @[D3Hunter](https://github.com/D3Hunter) - インデックスの長さがデフォルト値の`max-index-length` を超えるとデータレプリケーションが中断される問題を修正しました [＃11459](https://github.com/pingcap/tiflow/issues/11459) @[michaelmdeng](https://github.com/michaelmdeng) - LISTパーティションテーブルの`ALTER TABLE ... DROP PARTITION`文を複製するときにDMがエラーを返す問題を修正しました。 [＃54760](https://github.com/pingcap/tidb/issues/54760) @[lance6716](https://github.com/lance6716) diff --git a/releases/release-7.5.4.md b/releases/release-7.5.4.md index d16fb9d344ca0..cc3e78c49e695 100644 --- a/releases/release-7.5.4.md +++ b/releases/release-7.5.4.md @@ -118,7 +118,7 @@ TiDB バージョン: 7.5.4 - インデックスの長さがデフォルト値の`max-index-length` を超えるとデータレプリケーションが中断される問題を修正しました [＃11459](https://github.com/pingcap/tiflow/issues/11459) @[michaelmdeng](https://github.com/michaelmdeng) - DMが`ALTER DATABASE`文を処理するときにデフォルトのデータベースを設定せず、レプリケーションエラーが発生する問題を修正しました。 [＃11503](https://github.com/pingcap/tiflow/issues/11503) @[lance6716](https://github.com/lance6716) - - 複数の DM マスターノードが同時にリーダーになり、データの不整合が発生する可能性がある問題を修正しました[＃11602](https://github.com/pingcap/tiflow/issues/11602) @[GMHDBJD](https://github.com/GMHDBJD) + - 複数の DM-masterノードが同時にリーダーになり、データの不整合が発生する可能性がある問題を修正しました[＃11602](https://github.com/pingcap/tiflow/issues/11602) @[GMHDBJD](https://github.com/GMHDBJD) - TiDB Lightning diff --git a/releases/release-8.1.2.md b/releases/release-8.1.2.md index a4abc1135f32c..453b90ee8cb22 100644 --- a/releases/release-8.1.2.md +++ b/releases/release-8.1.2.md @@ -156,4 +156,4 @@ TiDB バージョン: 8.1.2 - TiDB Data Migration (DM) - - 複数の DM マスターノードが同時にリーダーになり、データの不整合が発生する可能性がある問題を修正しました[＃11602](https://github.com/pingcap/tiflow/issues/11602) @[GMHDBJD](https://github.com/GMHDBJD) + - 複数の DM-masterノードが同時にリーダーになり、データの不整合が発生する可能性がある問題を修正しました[＃11602](https://github.com/pingcap/tiflow/issues/11602) @[GMHDBJD](https://github.com/GMHDBJD) diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index 43c20658106c3..99e89dca4a57d 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -407,7 +407,7 @@ TiDB をアップグレードする前に、オペレーティングシステム - TiDB Data Migration (DM) - - 複数のDMマスターノードが同時にリーダーになる可能性があり、データ不整合を引き起こす問題を修正しました [#11602](https://github.com/pingcap/tiflow/issues/11602) @[GMHDBJD](https://github.com/GMHDBJD) + - 複数のDM-masterノードが同時にリーダーになる可能性があり、データ不整合を引き起こす問題を修正しました [#11602](https://github.com/pingcap/tiflow/issues/11602) @[GMHDBJD](https://github.com/GMHDBJD) - `ALTER DATABASE`ステートメントを処理する際に DM がデフォルトデータベースを設定しないことでレプリケーション エラーが発生する問題を修正します [#11503](https://github.com/pingcap/tiflow/issues/11503) @[lance6716](https://github.com/lance6716) - TiDB Lightning diff --git a/releases/release-8.5.0.md b/releases/release-8.5.0.md index c3c1562658e24..cc64837e36f26 100644 --- a/releases/release-8.5.0.md +++ b/releases/release-8.5.0.md @@ -217,7 +217,7 @@ TiDB をアップグレードする前に、オペレーティングシステム - TiDB Data Migration (DM) - - DMクラスタ起動時にDMワーカーがDMマスターに接続するための再試行を追加 [#4287](https://github.com/pingcap/tiflow/issues/4287) @[GMHDBJD](https://github.com/GMHDBJD) + - DMクラスタ起動時にDM-workerがDM-masterに接続するための再試行を追加 [#4287](https://github.com/pingcap/tiflow/issues/4287) @[GMHDBJD](https://github.com/GMHDBJD) ## バグ修正 {#bug-fixes} diff --git a/tidb-cloud/migrate-sql-shards.md b/tidb-cloud/migrate-sql-shards.md index bffa02c380c6e..509dd63de2eba 100644 --- a/tidb-cloud/migrate-sql-shards.md +++ b/tidb-cloud/migrate-sql-shards.md @@ -285,7 +285,7 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 | パラメータ | 説明 | | ----------------------- | ------------------------------------------------------------------------- | - | `--master-addr` | dmctlが接続するクラスタ内の任意のDMマスターノードの`{advertise-addr}`。例：192.168.11.110:9261 | + | `--master-addr` | dmctlが接続するクラスタ内の任意のDM-masterノードの`{advertise-addr}`。例：192.168.11.110:9261 | | `operate-source create` | データソースをDMクラスターにロードします。 | 以下は出力例です。 @@ -470,7 +470,7 @@ Starting component `dmctl`: /root/.tiup/components/dmctl/${tidb_version}/dmctl/d | パラメータ | 説明 | | --------------- | ------------------------------------------------------------------------- | -| `--master-addr` | dmctlが接続するクラスタ内の任意のDMマスターノードの`{advertise-addr}`。例：192.168.11.110:9261 | +| `--master-addr` | dmctlが接続するクラスタ内の任意のDM-masterノードの`{advertise-addr}`。例：192.168.11.110:9261 | | `start-task` | 移行タスクを開始します。 | 以下は出力例です。 diff --git a/tiup/tiup-component-dm-import.md b/tiup/tiup-component-dm-import.md index c130ff1b728f3..d94be2af22f56 100644 --- a/tiup/tiup-component-dm-import.md +++ b/tiup/tiup-component-dm-import.md @@ -1,6 +1,6 @@ --- title: tiup dm import -summary: TiUP DMの「import」コマンドは、DMクラスタをv1.0からv2.0以降のバージョンにアップグレードするために使用されます。このコマンドは、v1.0クラスタからのDMポータルコンポーネントのインポートをサポートしておらず、インポート前に元のクラスタを停止する必要があります。このコマンドはDM v2.0.0-rc.2以降のバージョンへのインポートのみをサポートしており、DM v1.0クラスタを新しいDM v2.0クラスタにインポートするために使用できます。インポート後、クラスタ内のDMマスターノードは1つだけになり、一部のコンポーネントのデプロイメントディレクトリは元のクラスタと異なる場合があります。 +summary: TiUP DMの「import」コマンドは、DMクラスタをv1.0からv2.0以降のバージョンにアップグレードするために使用されます。このコマンドは、v1.0クラスタからのDMポータルコンポーネントのインポートをサポートしておらず、インポート前に元のクラスタを停止する必要があります。このコマンドはDM v2.0.0-rc.2以降のバージョンへのインポートのみをサポートしており、DM v1.0クラスタを新しいDM v2.0クラスタにインポートするために使用できます。インポート後、クラスタ内のDM-masterノードは1つだけになり、一部のコンポーネントのデプロイメントディレクトリは元のクラスタと異なる場合があります。 --- # tiup dm import DM v1.0 のアップグレードのみ {#tiup-dm-import-only-for-upgrading-dm-v10} @@ -22,7 +22,7 @@ DM v1.0では、クラスターは基本的にTiDB Ansibleを使用してデプ > - `import`コマンドは、DM v1.0 クラスタを新しい DM v2.0 クラスタにインポートするために使用されます。既存の v2.0 クラスタにデータ移行タスクをインポートする必要がある場合は、 [TiDB データ移行を v1.0.x から v2.0+ に手動でアップグレードする](/dm/manually-upgrade-dm-1.0-to-2.0.md)を参照してください。 > - 一部のコンポーネントのデプロイメントディレクトリは、元のクラスタのものと異なる場合があります。`display`コマンドで確認できます。 > - クラスターをインポートする前に、 `tiup update --self && tiup update dm`を実行してTiUP DMコンポーネントを最新バージョンにアップグレードします。 -> - クラスターをインポートすると、クラスター内のDMマスターノードは1つだけになります。DMマスターノードをスケールアウトするには、 [`scale out`コマンド](/tiup/tiup-component-dm-scale-out.md)を参照してください。 +> - クラスターをインポートすると、クラスター内のDM-masterノードは1つだけになります。DM-masterノードをスケールアウトするには、 [`scale out`コマンド](/tiup/tiup-component-dm-scale-out.md)を参照してください。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-dm-template.md b/tiup/tiup-component-dm-template.md index 13d15a6402384..9fa9f25c85193 100644 --- a/tiup/tiup-component-dm-template.md +++ b/tiup/tiup-component-dm-template.md @@ -1,6 +1,6 @@ --- title: tiup dm template -summary: TiUP DMテンプレートコマンドは、クラスターデプロイメント用の組み込みトポロジファイルテンプレートを出力するために使用されます。デフォルトのテンプレートには、DMマスターインスタンス3個、DMワーカーインスタンス3個、Prometheusインスタンス1個、Grafanaインスタンス1個、Alertmanagerインスタンス1個が含まれます。-- --fullオプションを指定すると、設定可能なパラメータを含む詳細なトポロジテンプレートが出力されます。出力は、デプロイメント用のトポロジファイルにリダイレクトできます。 +summary: TiUP DMテンプレートコマンドは、クラスターデプロイメント用の組み込みトポロジファイルテンプレートを出力するために使用されます。デフォルトのテンプレートには、DM-masterインスタンス3個、DM-workerインスタンス3個、Prometheusインスタンス1個、Grafanaインスタンス1個、Alertmanagerインスタンス1個が含まれます。-- --fullオプションを指定すると、設定可能なパラメータを含む詳細なトポロジテンプレートが出力されます。出力は、デプロイメント用のトポロジファイルにリダイレクトできます。 --- # tiup dm template {#tiup-dm-template} @@ -15,8 +15,8 @@ tiup dm template [flags] このオプションを指定しない場合、出力のデフォルト テンプレートには次のインスタンスが含まれます。 -- 3 つの DM マスター インスタンス -- 3 つの DM ワーカーインスタンス +- 3 つの DM-master インスタンス +- 3 つの DM-workerインスタンス - 1つのPrometheusインスタンス - 1 つの Grafana インスタンス - 1 つの Alertmanager インスタンス diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index f2c71f6f20e75..5d4a6c00f5a88 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -15,8 +15,8 @@ TiUPを使用した DM クラスターのデプロイメントのトポロジ構 - [グローバル](#global) : クラスターのグローバル設定。一部の設定項目はクラスターのデフォルト値を使用しますが、インスタンスごとに個別に設定できます。 - [サーバー構成](#server_configs) : コンポーネントのグローバル設定。各コンポーネントを個別に設定できます。インスタンスに同じキーの設定項目がある場合、そのインスタンスの設定項目が有効になります。 -- [マスターサーバー](#master_servers) : DMマスターインスタンスの構成。この構成では、DMコンポーネントのマスターサービスがデプロイされるマシンを指定します。 -- [ワーカーサーバー](#worker_servers) : DMワーカーインスタンスの設定。この設定では、DMコンポーネントのワーカーサービスがデプロイされるマシンを指定します。 +- [マスターサーバー](#master_servers) : DM-masterインスタンスの構成。この構成では、DMコンポーネントのマスターサービスがデプロイされるマシンを指定します。 +- [ワーカーサーバー](#worker_servers) : DM-workerインスタンスの設定。この設定では、DMコンポーネントのワーカーサービスがデプロイされるマシンを指定します。 - [監視サーバー](#monitoring_servers) : Prometheusインスタンスがデプロイされるマシンを指定します。TiUPは複数のPrometheusインスタンスのデプロイをサポートしていますが、最初のインスタンスのみが使用されます。 - [grafana_servers](#grafana_servers) : Grafanaインスタンスの設定。この設定では、Grafanaインスタンスがデプロイされるマシンを指定します。 - [Alertmanagerサーバー](#alertmanager_servers) : Alertmanagerインスタンスの設定。この設定では、Alertmanagerインスタンスがデプロイされるマシンを指定します。 @@ -65,8 +65,8 @@ global: `server_configs`は、サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。`global`セクションと同様に、 `server_configs`セクションの設定は、インスタンス内の同じキーを持つ設定によって上書きできます。`server_configs`には主に以下のフィールドが含まれます。 -- `master` : DMマスターサービスに関連する設定。サポートされているすべての設定項目については、 [DMマスターコンフィグレーションファイル](/dm/dm-master-configuration-file.md)を参照してください。 -- `worker` : DM ワーカー サービスに関連する構成。サポートされているすべての構成項目については、 [DMワーカーコンフィグレーションファイル](/dm/dm-worker-configuration-file.md)を参照してください。 +- `master` : DM-masterサービスに関連する設定。サポートされているすべての設定項目については、 [DM-masterコンフィグレーションファイル](/dm/dm-master-configuration-file.md)を参照してください。 +- `worker` : DM-worker サービスに関連する構成。サポートされているすべての構成項目については、 [DM-workerコンフィグレーションファイル](/dm/dm-worker-configuration-file.md)を参照してください。 `server_configs`構成の例は次のとおりです。 @@ -87,9 +87,9 @@ server_configs: - `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 -- `name` : DMマスターインスタンスの名前を指定します。名前はインスタンスごとに一意である必要があります。一意でない場合、クラスターをデプロイできません。 -- `port` : DMマスターがサービスを提供するポートを指定します。デフォルト値は「8261」です。 -- `peer_port` : DMマスター間の通信ポートを指定します。デフォルト値は「8291」です。 +- `name` : DM-masterインスタンスの名前を指定します。名前はインスタンスごとに一意である必要があります。一意でない場合、クラスターをデプロイできません。 +- `port` : DM-masterがサービスを提供するポートを指定します。デフォルト値は「8261」です。 +- `peer_port` : DM-master間の通信ポートを指定します。デフォルト値は「8291」です。 - `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 - `data_dir` : データディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、データディレクトリはセクション`global`の`data_dir`設定に従って生成されます。 - `log_dir` : ログディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、ログディレクトリはセクション`global`の`log_dir`設定に従って生成されます。 @@ -144,8 +144,8 @@ master_servers: - `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 -- `name` : DMワーカーインスタンスの名前を指定します。名前はインスタンスごとに一意である必要があります。一意でない場合、クラスターをデプロイできません。 -- `port` : DMワーカーがサービスを提供するポートを指定します。デフォルト値は「8262」です。 +- `name` : DM-workerインスタンスの名前を指定します。名前はインスタンスごとに一意である必要があります。一意でない場合、クラスターをデプロイできません。 +- `port` : DM-workerがサービスを提供するポートを指定します。デフォルト値は「8262」です。 - `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 - `data_dir` : データディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、データディレクトリはセクション`global`の`data_dir`設定に従って生成されます。 - `log_dir` : ログディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、ログディレクトリはセクション`global`の`log_dir`設定に従って生成されます。