- ドキュメント ホーム
- TiDBについて
- クイックスタート
- 発展させる
- 概要
- クイックスタート
- TiDB Cloud(開発者層) で TiDB クラスターを構築する
- TiDB の CRUD SQL
- TiDB でシンプルな CRUD アプリを構築する
- 応用例
- TiDB に接続する
- データベース スキーマの設計
- 書き込みデータ
- データの読み取り
- 取引
- 最適化
- トラブルシューティング
- 参照
- 書店のサンプル アプリケーション
- ガイドライン
- アーカイブされたドキュメント
- クラウドネイティブ開発環境
- サードパーティのサポート
- デプロイ
- 移行する
- 管理
- 監視と警告
- トラブルシューティング
- TiDB トラブルシューティング マップ
- 遅いクエリを特定する
- 遅いクエリを分析する
- SQL 診断
- Top SQLを使用して高価なクエリを特定する
- ログを使用して高価なクエリを特定する
- ステートメント要約表
- ホットスポットの問題のトラブルシューティング
- 増加した読み取りおよび書き込み遅延のトラブルシューティング
- クラスターのオンサイト情報の保存と復元
- クラスタ セットアップのトラブルシューティング
- 高いディスク I/O 使用率のトラブルシューティング
- ロック競合のトラブルシューティング
- TiFlash のトラブルシューティング
- オプティミスティック トランザクションでの書き込み競合のトラブルシューティング
- データとインデックス間の不一致のトラブルシューティング
- 性能チューニング
- チューニングガイド
- Configuration / コンフィグレーションのチューニング
- システムのチューニング
- ソフトウェアのチューニング
- 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
- TiUP DMコマンド
- TiDB クラスター トポロジ リファレンス
- DM クラスタ トポロジ リファレンス
- ミラー リファレンス ガイド
- TiUP コンポーネント
- PingCAPクリニック診断サービス
- TiDB Operator
- Dumpling
- TiDB Lightning
- TiDB データ移行
- バックアップと復元 (BR)
- Binlog
- TiCDC
- Dumpling
- 同期差分インスペクター
- ティスパーク
- 参照
- クラスタ アーキテクチャ
- 主な監視指標
- セキュリティ
- 権限
- 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 TABLE COMPACT
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
- 情報_スキーマ
- 概要
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
- 用語集
シャードマージシナリオでのデータ移行のベストプラクティス
このドキュメントでは、シャードマージシナリオにおけるTiDBデータ移行 (DM)の機能と制限について説明し、アプリケーションのデータ移行のベストプラクティスガイドを提供します(デフォルトの「悲観的」モードが使用されます)。
別のデータ移行タスクを使用する
シャードテーブルからのデータのマージと移行のドキュメントでは、「シャーディンググループ」の定義が示されています。シャーディンググループは、同じダウンストリームテーブルにマージおよび移行する必要があるすべてのアップストリームテーブルで構成されます。
現在のシャーディングDDLメカニズムには、さまざまなシャードテーブルでのDDL操作によってもたらされるスキーマの変更を調整するための使用制限があります。予期しない理由でこれらの制限に違反した場合は、 DMでシャーディングDDLロックを手動で処理するを実行するか、データ移行タスク全体をやり直す必要があります。
例外が発生した場合のデータ移行への影響を軽減するために、各シャーディンググループを個別のデータ移行タスクとしてマージおよび移行することをお勧めします。これにより、少数のデータ移行タスクのみを手動で処理する必要があり、他のタスクは影響を受けないままになる可能性があります。
シャーディングDDLロックを手動で処理する
DMのシャーディングDDLロックは、複数のアップストリームシャードテーブルからダウンストリームへのDDL操作の実行を調整するためのメカニズムであるとシャードテーブルからのデータのマージと移行から簡単に結論付けることができます。
したがって、 DM-master
コマンドでシャーディングDDLロックを見つけた場合、またはshard-ddl-lock
コマンドで一部のDMワーカーでunresolvedGroups
またはblockingDDLs
を見つけた場合は、 query-status
コマンドでシャーディングshard-ddl-lock unlock
ロックを手動で解放しないでください。
代わりに、次のことができます。
- シャーディングDDLロックの自動解放の失敗がリストされた異常なシナリオのいずれかである場合は、対応する手動ソリューションに従ってシナリオを処理します。
- サポートされていないシナリオの場合は、データ移行タスク全体をやり直します。まず、ダウンストリームデータベースのデータと、移行タスクに関連付けられている
dm_meta
の情報を空にします。次に、完全な増分データレプリケーションを再実行します。
複数のシャードテーブル間での主キーまたは一意のインデックス間の競合を処理します
複数のシャードテーブルからのデータは、主キーまたは一意のインデックス間で競合を引き起こす可能性があります。これらのシャーディングされたテーブルのシャーディングロジックに基づいて、各主キーまたは一意のインデックスを確認する必要があります。以下は、主キーまたは一意のインデックスに関連する3つのケースです。
- シャードキー:通常、同じシャードキーは1つのシャードテーブルにのみ存在します。つまり、シャードキーでデータの競合は発生しません。
- 自動インクリメントの主キー:各シャーディングされたテーブルの自動インクリメントの主キーは個別にカウントされるため、範囲が重複する可能性があります。この場合、それを解決するために次のセクション自動インクリメント主キーの競合を処理しますを参照する必要があります。
- その他の主キーまたは一意のインデックス:ビジネスロジックに基づいてそれらを分析する必要があります。データが競合する場合は、次のセクション自動インクリメント主キーの競合を処理しますを参照して解決することもできます。
自動インクリメント主キーの競合を処理します
このセクションでは、自動インクリメント主キーの競合を処理するための2つの推奨ソリューションを紹介します。
列からPRIMARY KEY
属性を削除します
アップストリームスキーマが次のとおりであると想定します。
CREATE TABLE `tbl_no_pk` (
`auto_pk_c1` bigint(20) NOT NULL,
`uk_c2` bigint(20) NOT NULL,
`content_c3` text,
PRIMARY KEY (`auto_pk_c1`),
UNIQUE KEY `uk_c2` (`uk_c2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
次の要件が満たされている場合:
auto_pk_c1
列はアプリケーションに影響を与えず、列のPRIMARY KEY
属性に依存しません。uk_c2
列にはUNIQUE KEY
属性があり、すべてのアップストリームシャードテーブルでグローバルに一意です。
次に、次の手順を実行して、シャードテーブルをマージするときにauto_pk_c1
列が原因で発生する可能性のあるERROR 1062 (23000): Duplicate entry '***' for key 'PRIMARY'
エラーを修正できます。
完全なデータ移行の前に、データをマージおよび移行するためのテーブルをダウンストリームデータベースに作成し、
auto_pk_c1
列のPRIMARY KEY
属性を通常のインデックスに変更します。CREATE TABLE `tbl_no_pk_2` ( `auto_pk_c1` bigint(20) NOT NULL, `uk_c2` bigint(20) NOT NULL, `content_c3` text, INDEX (`auto_pk_c1`), UNIQUE KEY `uk_c2` (`uk_c2`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1
次の構成を
task.yaml
に追加して、自動インクリメントの主キーの競合のチェックをスキップします。ignore-checking-items: ["auto_increment_ID"]
フルおよびインクリメンタルデータレプリケーションタスクを開始します。
query-status
を実行して、データ移行タスクが正常に処理されたかどうか、およびアップストリームからのデータが既にマージされてダウンストリームデータベースに移行されているかどうかを確認します。
複合主キーを使用する
アップストリームスキーマが次のとおりであると想定します。
CREATE TABLE `tbl_multi_pk` (
`auto_pk_c1` bigint(20) NOT NULL,
`uuid_c2` bigint(20) NOT NULL,
`content_c3` text,
PRIMARY KEY (`auto_pk_c1`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
次の要件が満たされている場合:
- アプリケーションは、
auto_pk_c1
列のPRIMARY KEY
属性に依存しません。 auto_pk_c1
列とuuid_c2
列で構成される複合主キーは、グローバルに一意です。- アプリケーションで複合主キーを使用することは許容されます。
次に、次の手順を実行して、シャードテーブルをマージするときにauto_pk_c1
列が原因で発生する可能性のあるERROR 1062 (23000): Duplicate entry '***' for key 'PRIMARY'
エラーを修正できます。
完全なデータ移行の前に、データをマージおよび移行するためのテーブルをダウンストリームデータベースに作成します。
auto_pk_c1
列にPRIMARY KEY
属性を指定せずに、auto_pk_c1
列とuuid_c2
列を使用して複合主キーを構成します。CREATE TABLE `tbl_multi_pk_c2` ( `auto_pk_c1` bigint(20) NOT NULL, `uuid_c2` bigint(20) NOT NULL, `content_c3` text, PRIMARY KEY (`auto_pk_c1`,`uuid_c2`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1
完全な増分データ移行タスクを開始します。
query-status
を実行して、データ移行タスクが正常に処理されたかどうか、およびアップストリームからのデータが既にマージされてダウンストリームデータベースに移行されているかどうかを確認します。
アップストリームRDSにシャードテーブルが含まれている場合の特別な処理
アップストリームデータソースがRDSであり、シャードテーブルが含まれている場合、SQLクライアントに接続するときにMySQLbinlogのテーブル名が表示されない場合があります。たとえば、アップストリームがUCloud分散データベースである場合、binlogのテーブル名に追加のプレフィックス_0001
が付いている可能性があります。したがって、SQLクライアントのテーブル名ではなく、binlogのテーブル名に基づいてテーブルルーティングを構成する必要があります。
アップストリームでテーブルを作成/削除します
シャードテーブルからのデータのマージと移行では、シャーディングDDLロックの調整は、ダウンストリームデータベースがすべてのアップストリームシャードテーブルのDDLステートメントを受信するかどうかに依存することは明らかです。さらに、DMは現在、アップストリームでのシャードテーブルの動的な作成または削除をサポートしていません。したがって、アップストリームでシャードテーブルを作成または削除するには、次の手順を実行することをお勧めします。
上流にシャードテーブルを作成する
アップストリームに新しいシャードテーブルを作成する必要がある場合は、次の手順を実行します。
アップストリームシャードテーブルで実行されたすべてのシャーディングDDLの調整が完了するのを待ちます。
stop-task
を実行して、データ移行タスクを停止します。アップストリームに新しいシャードテーブルを作成します。
task.yaml
ファイルの構成で、新しく追加されたシャードテーブルを1つのダウンストリームテーブルで他の既存のシャードテーブルとマージできることを確認してください。start-task
を実行してタスクを開始します。query-status
を実行して、データ移行タスクが正常に処理されたかどうか、およびアップストリームからのデータが既にマージされてダウンストリームデータベースに移行されているかどうかを確認します。
シャードテーブルをアップストリームにドロップします
シャードテーブルをアップストリームにドロップする必要がある場合は、次の手順を実行します。
シャーディングされたテーブルを削除し、
SHOW BINLOG EVENTS
を実行してbinlogイベントのDROP TABLE
ステートメントに対応するEnd_log_pos
をフェッチし、 Pos-Mとしてマークします。query-status
を実行して、DMによって処理されたbinlogイベントに対応する位置(syncerBinlog
)をフェッチし、 Pos-Sとしてマークします。Pos-SがPos-Mより大きい場合は、DMが
DROP TABLE
のステートメントすべてを処理し、ドロップする前のテーブルのデータがダウンストリームに移行されたため、後続の操作を実行できることを意味します。それ以外の場合は、DMがデータの移行を完了するのを待ちます。stop-task
を実行してタスクを停止します。task.yaml
ファイルの構成が、アップストリームでドロップされたシャードテーブルを無視していることを確認してください。start-task
を実行してタスクを開始します。query-status
を実行して、データ移行タスクが正常に処理されたかどうかを確認します。
制限速度と交通流制御
複数のアップストリームMySQLまたはMariaDBインスタンスからのデータがマージされ、ダウンストリームの同じTiDBクラスタに移行されると、各アップストリームインスタンスに対応するすべてのDMワーカーが、完全なデータレプリケーションと増分データレプリケーションを同時に実行します。これは、DMワーカーの数が増えると、デフォルトの同時実行度(完全なデータ移行でpool-size
、増分データレプリケーションでworker-count
)が累積し、ダウンストリームデータベースが過負荷になる可能性があることを意味します。この場合、TiDBおよびDMの監視メトリックに基づいて予備的なパフォーマンス分析を実行し、各同時実行パラメーターの値を調整する必要があります。将来的には、DMは部分的に自動化されたトラフィックフロー制御をサポートすることが期待されています。