- TiDBについて
- クイックスタート
- 発展させる
- 概要
- クイックスタート
- TiDB CloudでTiDBクラスターを構築する(DevTier)
- TiDBのCRUDSQL
- TiDBを使用してシンプルなCRUDアプリを構築する
- アプリケーション例
- TiDBに接続する
- データベーススキーマの設計
- データの書き込み
- データの読み取り
- 取引
- 最適化
- トラブルシューティング
- 参照
- デプロイ
- 移行する
- 管理
- 監視と警告
- トラブルシューティング
- TiDBトラブルシューティングマップ
- 遅いクエリを特定する
- 遅いクエリを分析する
- SQL診断
- Top SQLを使用して高価なクエリを特定する
- ログを使用して高価なクエリを特定する
- ステートメント要約表
- ホットスポットの問題のトラブルシューティング
- 読み取りと書き込みの待ち時間の増加のトラブルシューティング
- クラスタのオンサイト情報を保存および復元する
- クラスタセットアップのトラブルシューティング
- 高いディスクI/O使用量のトラブルシューティング
- ロックの競合のトラブルシューティング
- TiFlashのトラブルシューティング
- 楽観的なトランザクションでの書き込みの競合のトラブルシューティング
- データとインデックス間の不整合のトラブルシューティング
- 性能チューニング
- チューニングガイド
- Configuration / コンフィグレーションの調整
- システムチューニング
- ソフトウェアのチューニング
- SQLチューニング
- チュートリアル
- TiDBツール
- 概要
- ユースケース
- ダウンロード
- TiUP
- ドキュメントマップ
- 概要
- 用語と概念
- TiUPコンポーネントを管理する
- FAQ
- トラブルシューティングガイド
- コマンドリファレンス
- 概要
- TiUPコマンド
- TiUPクラスターコマンド
- 概要
- tiup cluster audit
- tiup cluster check
- tiup cluster clean
- tiup cluster deploy
- tiup cluster destroy
- tiup cluster disable
- tiup cluster display
- tiup cluster edit-config
- tiup cluster enable
- tiup cluster help
- tiup cluster import
- tiup cluster list
- tiup cluster patch
- tiup cluster prune
- tiup cluster reload
- tiup cluster rename
- tiup cluster replay
- tiup cluster restart
- tiup cluster scale-in
- tiup cluster scale-out
- tiup cluster start
- tiup cluster stop
- tiup cluster template
- tiup cluster upgrade
- TiUPDMコマンド
- 概要
- tiup dm audit
- tiup dm deploy
- tiup dm destroy
- tiup dm disable
- tiup dm display
- tiup dm edit-config
- tiup dm enable
- tiup dm help
- tiup dm import
- tiup dm list
- tiup dm patch
- tiup dm prune
- tiup dm reload
- tiup dm replay
- tiup dm restart
- tiup dm scale-in
- tiup dm scale-out
- tiup dm start
- tiup dm stop
- tiup dm template
- tiup dm upgrade
- TiDBクラスタートポロジリファレンス
- DMクラスタートポロジリファレンス
- ミラーリファレンスガイド
- TiUPコンポーネント
- PingCAPクリニック診断サービス(テクニカルプレビュー)
- TiDB Operator
- Dumpling
- TiDB Lightning
- TiDBデータ移行
- TiDBデータ移行について
- クイックスタート
- DMクラスタをデプロイする
- チュートリアル
- 高度なチュートリアル
- シャーディングされたテーブルからのデータのマージと移行
- GH-ost/PT-oscを使用するMySQLデータベースからの移行
- より多くの列を持つダウンストリームTiDBテーブルにデータを移行する
- 管理
- 参照
- 例
- トラブルシューティング
- リリースノート
- バックアップと復元(BR)
- TiDB Binlog
- TiCDC
- Dumpling
- sync-diff-inspector
- TiSpark
- 参照
- クラスターアーキテクチャ
- 主要な監視指標
- セキュリティ
- 権限
- SQL
- SQL言語の構造と構文
- SQLステートメント
ADD COLUMN
ADD INDEX
ADMIN
ADMIN CANCEL DDL
ADMIN CHECKSUM TABLE
ADMIN CHECK [TABLE|INDEX]
ADMIN SHOW DDL [JOBS|QUERIES]
ADMIN SHOW TELEMETRY
ALTER DATABASE
ALTER INDEX
ALTER INSTANCE
ALTER PLACEMENT POLICY
ALTER TABLE
ALTER USER
ANALYZE TABLE
BACKUP
BATCH
BEGIN
CHANGE COLUMN
COMMIT
CHANGE DRAINER
CHANGE PUMP
CREATE [GLOBAL|SESSION] BINDING
CREATE DATABASE
CREATE INDEX
CREATE PLACEMENT POLICY
CREATE ROLE
CREATE SEQUENCE
CREATE TABLE LIKE
CREATE TABLE
CREATE USER
CREATE VIEW
DEALLOCATE
DELETE
DESC
DESCRIBE
DO
DROP [GLOBAL|SESSION] BINDING
DROP COLUMN
DROP DATABASE
DROP INDEX
DROP PLACEMENT POLICY
DROP ROLE
DROP SEQUENCE
DROP STATS
DROP TABLE
DROP USER
DROP VIEW
EXECUTE
EXPLAIN ANALYZE
EXPLAIN
FLASHBACK TABLE
FLUSH PRIVILEGES
FLUSH STATUS
FLUSH TABLES
GRANT <privileges>
GRANT <role>
INSERT
KILL [TIDB]
LOAD DATA
LOAD STATS
MODIFY COLUMN
PREPARE
RECOVER TABLE
RENAME INDEX
RENAME TABLE
REPLACE
RESTORE
REVOKE <privileges>
REVOKE <role>
ROLLBACK
SELECT
SET DEFAULT ROLE
SET [NAMES|CHARACTER SET]
SET PASSWORD
SET ROLE
SET TRANSACTION
SET [GLOBAL|SESSION] <variable>
SHOW ANALYZE STATUS
SHOW [BACKUPS|RESTORES]
SHOW [GLOBAL|SESSION] BINDINGS
SHOW BUILTINS
SHOW CHARACTER SET
SHOW COLLATION
SHOW [FULL] COLUMNS FROM
SHOW CONFIG
SHOW CREATE PLACEMENT POLICY
SHOW CREATE SEQUENCE
SHOW CREATE TABLE
SHOW CREATE USER
SHOW DATABASES
SHOW DRAINER STATUS
SHOW ENGINES
SHOW ERRORS
SHOW [FULL] FIELDS FROM
SHOW GRANTS
SHOW INDEX [FROM|IN]
SHOW INDEXES [FROM|IN]
SHOW KEYS [FROM|IN]
SHOW MASTER STATUS
SHOW PLACEMENT
SHOW PLACEMENT FOR
SHOW PLACEMENT LABELS
SHOW PLUGINS
SHOW PRIVILEGES
SHOW [FULL] PROCESSSLIST
SHOW PROFILES
SHOW PUMP STATUS
SHOW SCHEMAS
SHOW STATS_HEALTHY
SHOW STATS_HISTOGRAMS
SHOW STATS_META
SHOW STATUS
SHOW TABLE NEXT_ROW_ID
SHOW TABLE REGIONS
SHOW TABLE STATUS
SHOW [FULL] TABLES
SHOW [GLOBAL|SESSION] VARIABLES
SHOW WARNINGS
SHUTDOWN
SPLIT REGION
START TRANSACTION
TABLE
TRACE
TRUNCATE
UPDATE
USE
WITH
- データ型
- 関数と演算子
- クラスター化インデックス
- 制約
- 生成された列
- SQLモード
- テーブル属性
- トランザクション
- ガベージコレクション(GC)
- ビュー
- パーティショニング
- 一時テーブル
- キャッシュされたテーブル
- 文字セットと照合
- SQLの配置ルール
- システムテーブル
mysql
- INFORMATION_SCHEMA
- 概要
ANALYZE_STATUS
CLIENT_ERRORS_SUMMARY_BY_HOST
CLIENT_ERRORS_SUMMARY_BY_USER
CLIENT_ERRORS_SUMMARY_GLOBAL
CHARACTER_SETS
CLUSTER_CONFIG
CLUSTER_HARDWARE
CLUSTER_INFO
CLUSTER_LOAD
CLUSTER_LOG
CLUSTER_SYSTEMINFO
COLLATIONS
COLLATION_CHARACTER_SET_APPLICABILITY
COLUMNS
DATA_LOCK_WAITS
DDL_JOBS
DEADLOCKS
ENGINES
INSPECTION_RESULT
INSPECTION_RULES
INSPECTION_SUMMARY
KEY_COLUMN_USAGE
METRICS_SUMMARY
METRICS_TABLES
PARTITIONS
PLACEMENT_POLICIES
PROCESSLIST
REFERENTIAL_CONSTRAINTS
SCHEMATA
SEQUENCES
SESSION_VARIABLES
SLOW_QUERY
STATISTICS
TABLES
TABLE_CONSTRAINTS
TABLE_STORAGE_STATS
TIDB_HOT_REGIONS
TIDB_HOT_REGIONS_HISTORY
TIDB_INDEXES
TIDB_SERVERS_INFO
TIDB_TRX
TIFLASH_REPLICA
TIKV_REGION_PEERS
TIKV_REGION_STATUS
TIKV_STORE_STATUS
USER_PRIVILEGES
VIEWS
METRICS_SCHEMA
- UI
- TiDBダッシュボード
- 概要
- 管理
- アクセス
- 概要ページ
- クラスター情報ページ
- Top SQLページ
- キービジュアライザーページ
- メトリクス関係グラフ
- SQLステートメント分析
- 遅いクエリページ
- クラスター診断
- 検索ログページ
- インスタンスプロファイリング
- セッションの管理とConfiguration / コンフィグレーション
- FAQ
- CLI
- コマンドラインフラグ
- Configuration / コンフィグレーションファイルのパラメーター
- システム変数
- ストレージエンジン
- テレメトリー
- エラーコード
- テーブルフィルター
- トポロジラベルによるレプリカのスケジュール
- よくある質問
- リリースノート
- すべてのリリース
- リリースタイムライン
- TiDBバージョニング
- v6.1
- v6.0
- v5.4
- v5.3
- v5.2
- v5.1
- v5.0
- v4.0
- v3.1
- v3.0
- v2.1
- v2.0
- v1.0
- 用語集
大規模なデータセットのMySQLをTiDBに移行する
移行するデータ量が少ない場合は、完全移行とインクリメンタルレプリケーションの両方で簡単にDMを使用してデータを移行するを実行できます。ただし、DMは低速(30〜50 GiB / h)でデータをインポートするため、データ量が多い場合は移行に時間がかかる場合があります。このドキュメントの「大規模なデータセット」とは、通常、1TiB以上のデータを意味します。
このドキュメントでは、大規模なデータセットをMySQLからTiDBに移行する方法について説明します。移行全体には2つのプロセスがあります。
- 完全な移行。 DumplingとTiDBLightningを使用して、完全な移行を実行します。 TiDB Lightningのローカルバックエンドモードでは、最大500 GiB/hの速度でデータをインポートできます。
- インクリメンタルレプリケーション。完全な移行が完了したら、DMを使用して増分データを複製できます。
前提条件
- DMをインストールする 。
- DumplingとTiDBLightningをインストールします 。
- DMに必要なソースデータベースとターゲットデータベースの権限を付与します 。
- TiDBLightningに必要なターゲットデータベース権限を付与します 。
- Dumplingに必要なソースデータベース権限を付与します 。
リソース要件
オペレーティングシステム:このドキュメントの例では、新しいCentOS7インスタンスを使用しています。仮想マシンは、ローカルホストまたはクラウドのいずれかにデプロイできます。 TiDB Lightningはデフォルトで必要なだけのCPUリソースを消費するため、専用サーバーにデプロイすることをお勧めします。これが不可能な場合は、他のTiDBコンポーネント(たとえばtikv-server
)と一緒に単一のサーバーにデプロイしてから、TiDBLightningからのCPU使用率を制限するようにregion-concurrency
を構成できます。通常、サイズは論理CPUの75%に設定できます。
メモリとCPU :TiDB Lightningは大量のリソースを消費するため、64GiBを超えるメモリと32を超えるCPUコアを割り当てることをお勧めします。最高のパフォーマンスを得るには、CPUコアとメモリ(GiB)の比率が1:2より大きいことを確認してください。
ディスク容量:
- Dumplingには、データソース全体を保存するのに十分なディスク容量が必要です。 SSDをお勧めします。
- インポート中、TiDB Lightningには、ソートされたキーと値のペアを格納するための一時的なスペースが必要です。ディスク容量は、データソースからの最大の単一テーブルを保持するのに十分である必要があります。
- フルデータボリュームが大きい場合は、アップストリームでのbinlogストレージ時間を増やすことができます。これは、インクリメンタルレプリケーション中にbinlogが失われないようにするためです。
注:MySQLからDumplingによってエクスポートされた正確なデータ量を計算することは困難ですが、次のSQLステートメントを使用してinformation_schema.tables
テーブルのdata-length
フィールドを要約することにより、データ量を見積もることができます。
/* Calculate the size of all schemas, in MiB. Replace ${schema_name} with your schema name. */
SELECT table_schema,SUM(data_length)/1024/1024 AS data_length,SUM(index_length)/1024/1024 AS index_length,SUM(data_length+index_length)/1024/1024 AS SUM FROM information_schema.tables WHERE table_schema = "${schema_name}" GROUP BY table_schema;
/* Calculate the size of the largest table, in MiB. Replace ${schema_name} with your schema name. */
SELECT table_name,table_schema,SUM(data_length)/1024/1024 AS data_length,SUM(index_length)/1024/1024 AS index_length,SUM(data_length+index_length)/1024/1024 AS SUM from information_schema.tables WHERE table_schema = "${schema_name}" GROUP BY table_name,table_schema ORDER BY SUM DESC LIMIT 5;
ターゲットTiKVクラスタのディスク容量
ターゲットTiKVクラスタには、インポートされたデータを格納するのに十分なディスク容量が必要です。 標準のハードウェア要件に加えて、ターゲットTiKVクラスタのストレージスペースは、データソースのサイズx レプリカの数x2よりも大きくする必要があります。たとえば、クラスタがデフォルトで3つのレプリカを使用する場合、ターゲットTiKVクラスタには、データソースのサイズの6倍を超えるストレージスペースが必要です。数式にはx 2
あります。理由は次のとおりです。
- インデックスには余分なスペースが必要になる場合があります。
- RocksDBにはスペース増幅効果があります。
ステップ1.MySQLからすべてのデータをエクスポートする
次のコマンドを実行して、MySQLからすべてのデータをエクスポートします。
tiup dumpling -h ${ip} -P 3306 -u root -t 16 -r 200000 -F 256MiB -B my_db1 -f 'my_db1.table[12]' -o 's3://my-bucket/sql-backup?region=us-west-2'
DumplingはデフォルトでSQLファイルのデータをエクスポートします。
--filetype
オプションを追加することにより、別のファイル形式を指定できます。上記で使用したパラメータは次のとおりです。その他のDumplingパラメータについては、 Dumplingの概要を参照してください。
パラメーター 説明 -u
または--user
MySQLユーザー -p
または--password
MySQLユーザーパスワード -P
または--port
MySQLポート -h
または--host
MySQLIPアドレス -t
または--thread
エクスポートに使用されるスレッドの数 -o
または--output
エクスポートされたファイルを保存するディレクトリ。ローカルパスまたは外部ストレージURLをサポートします -r
または--row
1つのファイルの最大行数 -F
MiBでの単一ファイルの最大サイズ。推奨値:256MiB。 B
または--database
エクスポートするデータベースを指定します -f
または--filter
パターンに一致するテーブルをエクスポートします。構文についてはテーブルフィルターを参照してください。 ${data-path}
に、エクスポートされたデータを格納するのに十分なスペースがあることを確認してください。すべてのスペースを消費する大きなテーブルによってエクスポートが中断されないようにするには、-F
オプションを使用して単一ファイルのサイズを制限することを強くお勧めします。${data-path}
ディレクトリのmetadata
ファイルを表示します。これは、餃子で生成されたメタデータファイルです。手順3の増分レプリケーションに必要なbinlog位置情報を記録します。SHOW MASTER STATUS: Log: mysql-bin.000004 Pos: 109227 GTID:
ステップ2.完全なデータをTiDBにインポートします
tidb-lightning.toml
の構成ファイルを作成します。[lightning] # log. level = "info" file = "tidb-lightning.log" [tikv-importer] # "local": Default backend. The local backend is recommended to import large volumes of data (1 TiB or more). During the import, the target TiDB cluster cannot provide any service. # "tidb": The "tidb" backend is recommended to import data less than 1 TiB. During the import, the target TiDB cluster can provide service normally. For more information on the backends, refer to https://docs.pingcap.com/tidb/stable/tidb-lightning-backends. backend = "local" # Sets the temporary storage directory for the sorted Key-Value files. The directory must be empty, and the storage space must be greater than the size of the dataset to be imported. For better import performance, it is recommended to use a directory different from `data-source-dir` and use flash storage, which can use I/O exclusively. sorted-kv-dir = "${sorted-kv-dir}" [mydumper] # The data source directory. The same directory where Dumpling exports data in "Step 1. Export all data from MySQL". data-source-dir = "${data-path}" # A local path or S3 path. For example, 's3://my-bucket/sql-backup?region=us-west-2'. [tidb] # The target TiDB cluster information. host = ${host} # e.g.: 172.16.32.1 port = ${port} # e.g.: 4000 user = "${user_name}" # e.g.: "root" password = "${password}" # e.g.: "rootroot" status-port = ${status-port} # During the import, TiDB Lightning needs to obtain the table schema information from the TiDB status port. e.g.: 10080 pd-addr = "${ip}:${port}" # The address of the PD cluster, e.g.: 172.16.31.3:2379. TiDB Lightning obtains some information from PD. When backend = "local", you must specify status-port and pd-addr correctly. Otherwise, the import will be abnormal.
TiDB Lightning構成の詳細については、 TiDBLightningConfiguration / コンフィグレーションを参照してください。
tidb-lightning
を実行してインポートを開始します。コマンドラインで直接プログラムを起動すると、SIGHUP信号を受信した後、プロセスが予期せず終了する場合があります。この場合、nohup
またはscreen
ツールを使用してプログラムを実行することをお勧めします。例えば:S3からデータをインポートする場合は、S3ストレージパスにアクセスできるSecretKeyとAccessKeyを環境変数としてTiDBLightningノードに渡します。
~/.aws/credentials
からクレデンシャルを読み取ることもできます。export AWS_ACCESS_KEY_ID=${access_key} export AWS_SECRET_ACCESS_KEY=${secret_key} nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out 2>&1 &
インポートの開始後、次のいずれかの方法でインポートの進行状況を確認できます。
grep
ログのキーワードprogress
。進行状況は、デフォルトで5分ごとに更新されます。- 監視ダッシュボードで進捗状況を確認します。
- TiDBLightningWebインターフェイスで進捗状況を確認します。
TiDB Lightningがインポートを完了すると、自動的に終了します。ログ印刷
the whole procedure completed
の最後の5行が見つかった場合、インポートは成功しています。
ノート:
インポートが成功したかどうかに関係なく、ログの最後の行には
tidb lightning exit
が表示されます。これは、TiDB Lightningが正常に終了することを意味しますが、必ずしもインポートが成功したことを意味するわけではありません。
インポートが失敗した場合、トラブルシューティングについてはTiDB Lightning FAQを参照してください。
ステップ3.インクリメンタルデータをTiDBに複製する
データソースを追加する
次のように
source1.yaml
のファイルを作成します。# Must be unique. source-id: "mysql-01" # Configures whether DM-worker uses the global transaction identifier (GTID) to pull binlogs. To enable this mode, the upstream MySQL must also enable GTID. If the upstream MySQL service is configured to switch master between different nodes automatically, GTID mode is required. enable-gtid: true from: host: "${host}" # e.g.: 172.16.10.81 user: "root" password: "${password}" # Supported but not recommended to use a plaintext password. It is recommended to use `dmctl encrypt` to encrypt the plaintext password before using it. port: 3306
次のコマンドを実行して、
tiup dmctl
を使用してデータソース構成をDMクラスタにロードします。tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml
上記のコマンドで使用されるパラメーターは、次のとおりです。
パラメータ 説明 --master-addr
dmctl
が接続されるクラスタの任意のDMマスターの{advertise-addr}
例:172.16.10.71:8261operate-source create
データソースをDMクラスタにロードします。
レプリケーションタスクを追加する
task.yaml
のファイルを編集します。インクリメンタルレプリケーションモードと各データソースの開始点を構成します。name: task-test # Task name. Must be globally unique. task-mode: incremental # Task mode. The "incremental" mode only performs incremental data replication. # Configures the target TiDB database. target-database: # The target database instance. host: "${host}" # e.g.: 127.0.0.1 port: 4000 user: "root" password: "${password}" # It is recommended to use `dmctl encrypt` to encrypt the plaintext password before using it. # Use block and allow lists to specify the tables to be replicated. block-allow-list: # The collection of filtering rules that matches the tables in the source database instance. If the DM version is earlier than v2.0.0-beta.2, use black-white-list. bw-rule-1: # The block-allow-list configuration item ID. do-dbs: ["${db-name}"] # Name of databases to be replicated. # Configures the data source. mysql-instances: - source-id: "mysql-01" # Data source ID,i.e., source-id in source1.yaml block-allow-list: "bw-rule-1" # You can use the block-allow-list configuration above. # syncer-config-name: "global" # You can use the syncers incremental data configuration below. meta: # When task-mode is "incremental" and the target database does not have a checkpoint, DM uses the binlog position as the starting point. If the target database has a checkpoint, DM uses the checkpoint as the starting point. # binlog-name: "mysql-bin.000004" # The binlog position recorded in "Step 1. Export all data from MySQL". If the upstream database service is configured to switch master between different nodes automatically, GTID mode is required. # binlog-pos: 109227 binlog-gtid: "09bec856-ba95-11ea-850a-58f2b4af5188:1-9" # (Optional) If you need to incrementally replicate data that has already been migrated in the full data migration, you need to enable the safe mode to avoid the incremental data replication error. # This scenario is common in the following case: the full migration data does not belong to the data source's consistency snapshot, and after that, DM starts to replicate incremental data from a position earlier than the full migration. # syncers: # The running configurations of the sync processing unit. # global: # Configuration name. # safe-mode: true # If this field is set to true, DM changes INSERT of the data source to REPLACE for the target database, and changes UPDATE of the data source to DELETE and REPLACE for the target database. This is to ensure that when the table schema contains a primary key or unique index, DML statements can be imported repeatedly. In the first minute of starting or resuming an incremental replication task, DM automatically enables the safe mode.
上記のYAMLは、移行タスクに必要な最小構成です。その他の設定項目については、 DM高度なタスクConfiguration / コンフィグレーションファイルを参照してください。
移行タスクを開始する前に、エラーの可能性を減らすために、次の
check-task
コマンドを実行して、構成がDMの要件を満たしていることを確認することをお勧めします。tiup dmctl --master-addr ${advertise-addr} check-task task.yaml
次のコマンドを実行して、移行タスクを開始します。
tiup dmctl --master-addr ${advertise-addr} start-task task.yaml
上記のコマンドで使用されるパラメーターは、次のとおりです。
パラメータ 説明 --master-addr
dmctl
が接続されるクラスタのDMマスターの{advertise-addr}例:172.16.10.71:8261start-task
移行タスクを開始します。 タスクの開始に失敗した場合は、プロンプトメッセージを確認し、構成を修正してください。その後、上記のコマンドを再実行してタスクを開始できます。
移行タスクのステータスを確認する
DMクラスタに進行中の移行タスクがあるかどうかを確認し、タスクステータスを表示するには、 tiup dmctl
を使用してquery-status
コマンドを実行します。
tiup dmctl --master-addr ${advertise-addr} query-status ${task-name}
結果の詳細な解釈については、 クエリステータスを参照してください。
タスクを監視し、ログを表示します
移行タスクの履歴ステータスおよびその他の内部メトリックを表示するには、次の手順を実行します。
TiUPを使用してDMをデプロイしたときにPrometheus、Alertmanager、およびGrafanaをデプロイした場合は、デプロイメント中に指定したIPアドレスとポートを使用してGrafanaにアクセスできます。次に、DMダッシュボードを選択して、DM関連の監視メトリックを表示できます。
DMの実行中、DM-worker、DM-master、およびdmctlは、関連情報をログに出力します。これらのコンポーネントのログディレクトリは次のとおりです。
- 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/
です。