- TiDBについて
- クイックスタート
- デプロイ
- 移行する
- 管理
- アップグレード
- 規模
- バックアップと復元
- BRツールを使用する(推奨)
- タイムゾーンの構成
- 毎日のチェックリスト
- TiFlashを管理する
- TiUPを使用してTiDBを管理する
- オンラインで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
- 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コンポーネント
- TiDB Operator
- バックアップと復元(BR)
- TiDB Binlog
- TiDB Lightning
- TiDBデータ移行
- TiDBデータ移行について
- DMの概要
- 基本的な機能
- 高度な機能
- シャーディングされたテーブルからのデータのマージと移行
- GH-ost/PT-oscを使用するMySQLデータベースからの移行
- SQL式を使用してDMLをフィルタリングする
- DMアーキテクチャ
- ベンチマーク
- クイックスタート
- データ移行シナリオ
- デプロイ
- 管理
- ツール
- クラスターのアップグレード
- データソースを作成する
- データソースの管理
- データ移行タスクの管理
- シャーディングDDLロックを手動で処理する
- 移行するMySQLインスタンスを切り替える
- 移行するテーブルのスキーマを管理する
- アラートを処理する
- デイリーチェック
- トラブルシューティング
- 性能チューニング
- 参照
- セキュリティ
- モニタリング指標
- アラートルール
- エラーコード
- FAQ
- 用語集
- 例
- リリースノート
- 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
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_RULES
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バージョニング
- v5.4
- v5.3
- v5.2
- v5.1
- v5.0
- v4.0
- v3.1
- v3.0
- v2.1
- v2.0
- v1.0
- 用語集
TiDBデータ移行FAQ
このドキュメントは、TiDBデータ移行(DM)に関するよくある質問(FAQ)を集めたものです。
DMは、Alibaba RDSまたは他のクラウドデータベースからのデータの移行をサポートしていますか?
現在、DMはMySQLまたはMariaDBbinlogの標準バージョンのデコードのみをサポートしています。 AlibabaCloudRDSまたはその他のクラウドデータベースではテストされていません。 binlogが標準形式であることが確認された場合は、サポートされています。
Alibaba Cloud RDSに主キーがないアップストリームテーブルの場合、そのbinlogに非表示の主キー列が含まれていることが既知の問題であり、元のテーブル構造と矛盾しています。
互換性のない既知の問題は次のとおりです。
- Alibaba Cloud RDSでは、主キーのないアップストリームテーブルの場合、そのbinlogに非表示の主キー列が含まれているため、元のテーブル構造と矛盾しています。
- HUAWEI Cloud RDSでは、binlogファイルの直接読み取りはサポートされていません。詳細については、 HUAWEI Cloud RDSはBinlogバックアップファイルを直接読み取ることができますか?を参照してください。
タスク構成のブロックと許可リストの正規表現は、 non-capturing (?!)
サポートしていますか?
現在、DMはそれをサポートしておらず、Golang標準ライブラリの正規表現のみをサポートしています。 re2-構文を介してGolangでサポートされている正規表現を参照してください。
アップストリームで実行されるステートメントに複数のDDL操作が含まれている場合、DMはそのような移行をサポートしますか?
DMは、複数のDDL変更操作を含む単一のステートメントを1つのDDL操作のみを含む複数のステートメントに分割しようとしますが、すべてのケースをカバーするわけではありません。アップストリームで実行されるステートメントにDDL操作を1つだけ含めるか、テスト環境で検証することをお勧めします。サポートされていない場合は、DMリポジトリに問題をファイルできます。
互換性のないDDLステートメントを処理する方法は?
TiDBでサポートされていないDDLステートメントに遭遇した場合は、dmctlを使用して手動で処理する必要があります(DDLステートメントをスキップするか、指定されたDDLステートメントに置き換えます)。詳細については、 失敗したDDLステートメントを処理するを参照してください。
ノート:
現在、TiDBはMySQLがサポートするすべてのDDLステートメントと互換性があるわけではありません。 MySQLの互換性を参照してください。
データ移行タスクをリセットするにはどうすればよいですか?
データ移行中に例外が発生し、データ移行タスクを再開できない場合は、タスクをリセットしてデータを再移行する必要があります。
stop-task
コマンドを実行して、異常なデータ移行タスクを停止します。ダウンストリームに移行されたデータをパージします。
次のいずれかの方法を使用して、データ移行タスクを再開します。
- タスク構成ファイルで新しいタスク名を指定します。次に、
start-task {task-config-file}
を実行します。 start-task --remove-meta {task-config-file}
を実行します。
- タスク構成ファイルで新しいタスク名を指定します。次に、
online-ddl-scheme: "gh-ost"
が設定された後、gh-ostテーブルに関連するDDL操作によって返されるエラーを処理する方法は?
[unit=Sync] ["error information"="{\"msg\":\"[code=36046:class=sync-unit:scope=internal:level=high] online ddls on ghost table `xxx`.`_xxxx_gho`\\ngithub.com/pingcap/dm/pkg/terror.(*Error).Generate ......
上記のエラーは、次の理由で発生する可能性があります。
最後のrename ghost_table to origin table
ステップで、DMはメモリ内のDDL情報を読み取り、それを元のテーブルのDDLに復元します。
ただし、メモリ内のDDL情報は、次の2つの方法のいずれかで取得されます。
alter ghost_table
操作中にgh-ostテーブルを処理しますおよびghost_table
のDDL情報を記録します。- DM-workerを再起動してタスクを開始すると、DMは
dm_meta.{task_name}_onlineddl
からDDLを読み取ります。
したがって、インクリメンタルレプリケーションのプロセスで、指定されたPosがalter ghost_table
DDLをスキップしたが、Posがまだgh-ostのonline-ddlプロセスにある場合、ghost_tableはメモリまたはdm_meta.{task_name}_onlineddl
に正しく書き込まれません。このような場合、上記のエラーが返されます。
次の手順でこのエラーを回避できます。
タスクの
online-ddl-scheme
の構成を削除します。_{table_name}_del
_{table_name}_gho
_{table_name}_ghc
しblock-allow-list.ignore-tables
。ダウンストリームTiDBでアップストリームDDLを手動で実行します。
Posがgh-ostプロセス後の位置に複製されたら、
online-ddl-scheme
を再度有効にして、block-allow-list.ignore-tables
をコメントアウトします。
既存のデータ移行タスクにテーブルを追加するにはどうすればよいですか?
実行中のデータ移行タスクにテーブルを追加する必要がある場合は、タスクの段階に応じて次の方法で対処できます。
ノート:
既存のデータ移行タスクへのテーブルの追加は複雑であるため、この操作は必要な場合にのみ実行することをお勧めします。
Dump
段階で
MySQLはエクスポート用のスナップショットを指定できないため、エクスポート中にデータ移行タスクを更新してから再起動してチェックポイントからエクスポートを再開することはサポートされていません。したがって、 Dump
段階で移行する必要のあるテーブルを動的に追加することはできません。
移行のためにテーブルを本当に追加する必要がある場合は、新しい構成ファイルを使用してタスクを直接再開することをお勧めします。
Load
段階で
エクスポート中、複数のデータ移行タスクは通常、異なるbinlog位置を持ちます。 Load
段階でタスクをマージすると、binlogの位置について合意に達することができない場合があります。したがって、 Load
段階のデータ移行タスクにテーブルを追加することはお勧めしません。
Sync
段階
データ移行タスクがSync
段階の場合、構成ファイルにテーブルを追加してタスクを再開すると、DMは新しく追加されたテーブルの完全なエクスポートとインポートを再実行しません。代わりに、DMは前のチェックポイントから増分レプリケーションを続行します。
したがって、新しく追加されたテーブルの完全なデータがダウンストリームにインポートされていない場合は、別のデータ移行タスクを使用して、完全なデータをダウンストリームにエクスポートおよびインポートする必要があります。
既存の移行タスクに対応するグローバルチェックポイント( is_global=1
)の位置情報を(mysql-bin.000100, 1234)
などのcheckpoint-T
として記録します。移行タスクに追加するテーブルの完全エクスポートmetedata
(またはSync
ステージの別のデータ移行タスクのチェックポイント)の位置情報をcheckpoint-S
( (mysql-bin.000099, 5678)
など)として記録します。次の手順で、テーブルを移行タスクに追加できます。
stop-task
を使用して、既存の移行タスクを停止します。追加するテーブルが実行中の別の移行タスクに属している場合は、そのタスクも停止します。MySQLクライアントを使用してダウンストリームTiDBデータベースに接続し、既存の移行タスクに対応するチェックポイントテーブルの情報を
checkpoint-T
の小さい値に手動で更新しcheckpoint-S
。この例では、(mysql- bin.000099, 5678)
です。更新されるチェックポイントテーブルは、
{dm_meta}
スキーマの{task-name}_syncer_checkpoint
つです。更新されるチェックポイント行は
id=(source-id)
とis_global=1
に一致します。更新されるチェックポイント列は
binlog_name
とbinlog_pos
です。
再入可能な実行を確実にするために、タスクの
syncers
にsafe-mode: true
を設定します。start-task
を使用してタスクを開始します。query-status
を介してタスクのステータスを観察します。syncerBinlog
がcheckpoint-T
とcheckpoint-S
の大きい方の値を超えたら、safe-mode
を元の値に戻し、タスクを再開します。この例では、(mysql-bin.000100, 1234)
です。
packet for query is too large. Try adjusting the 'max_allowed_packet' variable
完全なインポート中に発生packet for query is too large. Try adjusting the 'max_allowed_packet' variable
。
以下のパラメータをデフォルトの67108864(64M)より大きい値に設定します。
- TiDBサーバーのグローバル変数:
max_allowed_packet
。 - タスク構成ファイルの構成項目:
target-database.max-allowed-packet
。詳しくはDM高度なタスクConfiguration / コンフィグレーションファイルをご覧ください。
エラー1054の処理方法:DM1.0クラスタの既存のDM移行タスクがDM2.0以降のクラスタで実行されているときに発生するError 1054: Unknown column 'binlog_gtid' in 'field list'
?
DM v2.0以降、DM 1.0クラスタのタスク構成ファイルを使用してstart-task
コマンドを直接実行し、増分データ複製を続行すると、エラーError 1054: Unknown column 'binlog_gtid' in 'field list'
が発生します。
このエラーはDM1.0クラスタのDM移行タスクをDM2.0クラスタに手動でインポートするで処理できます。
TiUPがDMの一部のバージョン(v2.0.0-hotfixなど)の展開に失敗するのはなぜですか?
tiup list dm-master
コマンドを使用して、TiUPが展開をサポートするDMバージョンを表示できます。 TiUPは、このコマンドで表示されないDMバージョンを管理しません。
エラーparse mydumper metadata error: EOF
?
このエラーをさらに分析するには、エラーメッセージとログファイルを確認する必要があります。原因は、権限がないためにダンプユニットが正しいメタデータファイルを生成しないことである可能性があります。
シャーディングされたスキーマとテーブルを複製するときにDMが致命的なエラーを報告しないのに、ダウンストリームデータが失われるのはなぜですか?
構成項目block-allow-list
およびtable-route
を確認してください。
block-allow-list
未満のアップストリームデータベースとテーブルの名前を構成する必要があります。do-tables
の前に「〜」を追加して、正規表現を使用して名前を照合できます。table-route
は、正規表現の代わりにワイルドカード文字を使用してテーブル名を照合します。たとえば、table_parttern_[0-63]
はtable_parttern_0
からtable_pattern_6
までの7つのテーブルにのみ一致します。
DMがアップストリームからレプリケートしていないのに、 replicate lag
モニターメトリックにデータが表示されないのはなぜですか?
DM 1.0では、モニターデータを生成するためにenable-heartbeat
を有効にする必要があります。 DM 2.0以降のバージョンでは、この機能がサポートされていないため、モニターメトリックreplicate lag
にデータがないことが予想されます。
DMがタスクを開始しているときfail to initial unit Sync of subtask
たエラーを処理する方法。エラーメッセージのRawCause
は、 context deadline exceeded
たことを示していますか?
これはDM2.0.0バージョンの既知の問題であり、DM2.0.1バージョンで修正される予定です。レプリケーションタスクに処理するテーブルが多数ある場合にトリガーされる可能性があります。 TiUPを使用してDMを展開する場合は、DMをナイトリーバージョンにアップグレードしてこの問題を修正できます。または、GitHubでDMのリリースページから2.0.0-hotfixバージョンをダウンロードして、実行可能ファイルを手動で置き換えることができます。
DMがデータを複製しているときにエラーduplicate entry
を処理するにはどうすればよいですか?
まず、次のことを確認して確認する必要があります。
disable-detect
はレプリケーションタスクで構成されていません(v2.0.7以前のバージョン)。- データは手動または他のレプリケーションプログラムによって挿入されません。
- このテーブルに関連付けられたDMLフィルターは構成されていません。
トラブルシューティングを容易にするために、最初にダウンストリームTiDBインスタンスの一般的なログファイルを収集してから、 TiDBコミュニティのスラックチャネルでテクニカルサポートを依頼できます。次の例は、一般的なログファイルを収集する方法を示しています。
# Enable general log collection
curl -X POST -d "tidb_general_log=1" http://{TiDBIP}:10080/settings
# Disable general log collection
curl -X POST -d "tidb_general_log=0" http://{TiDBIP}:10080/settings
duplicate entry
エラーが発生した場合は、ログファイルで競合データを含むレコードを確認する必要があります。
一部の監視パネルにNo data point
のはなぜですか?
一部のパネルにはデータがないのが普通です。たとえば、エラーが報告されていない場合、DDLロックがない場合、またはリレーログ機能が有効になっていない場合、対応するパネルにはNo data point
が表示されます。各パネルの詳細については、 DMモニタリングメトリクスを参照してください。
DM v1.0では、タスクにエラーがあるときにコマンドsql-skip
が一部のステートメントをスキップできないのはなぜですか?
sql-skip
を実行した後、最初にbinlogの位置がまだ進んでいるかどうかを確認する必要があります。もしそうなら、それはsql-skip
が有効になったことを意味します。このエラーが発生し続ける理由は、アップストリームがサポートされていない複数のDDLステートメントを送信するためです。 sql-skip -s <sql-pattern>
を使用して、これらのステートメントに一致するパターンを設定できます。
エラーメッセージにparse statement
の情報が含まれている場合があります。次に例を示します。
if the DDL is not needed, you can use a filter rule with \"*\" schema-pattern to ignore it.\n\t : parse statement: line 1 column 11 near \"EVENT `event_del_big_table` \r\nDISABLE\" %!!(MISSING)(EXTRA string=ALTER EVENT `event_del_big_table` \r\nDISABLE
このタイプのエラーの理由は、TiDBパーサーがALTER EVENT
などのアップストリームによって送信されたDDLステートメントを解析できないため、 sql-skip
が期待どおりに有効にならないためです。構成ファイルにbinlogイベントフィルターを追加して、これらのステートメントをフィルター処理し、 schema-pattern: "*"
を設定できます。 DM v2.0.1以降、DMはEVENT
に関連するステートメントを事前にフィルタリングします。
DM v2.0以降、 handle-error
がsql-skip
に置き換わります。この問題を回避するには、代わりにhandle-error
を使用できます。
DMが複製しているときに、 REPLACE
ステートメントがダウンストリームに表示され続けるのはなぜですか?
セーフモードがタスクに対して自動的に有効になっているかどうかを確認する必要があります。エラー後にタスクが自動的に再開される場合、または高可用性スケジューリングがある場合、タスクが開始または再開されてから1分以内であるため、セーフモードが有効になります。
DM-workerログファイルを確認して、 change count
を含む行を検索できます。行のnew count
がゼロでない場合、セーフモードが有効になります。有効になっている理由を確認するには、いつ発生するか、以前にエラーが報告されていないかどうかを確認してください。
DM v2.0では、タスク中にDMが再起動すると、完全なインポートタスクが失敗するのはなぜですか?
DM v2.0.1以前のバージョンでは、完全なインポートが完了する前にDMが再起動すると、アップストリームデータソースとDMワーカーノード間のバインディングが変更される可能性があります。たとえば、ダンプユニットの中間データがDM-workerノードAにあるが、ロードユニットがDM-workerノードBによって実行されているため、操作が失敗する可能性があります。
この問題に対する2つの解決策は次のとおりです。
データ量が少ない場合(1 TB未満)、またはタスクがシャーディングされたテーブルをマージする場合は、次の手順を実行します。
- ダウンストリームデータベースにインポートされたデータをクリーンアップします。
- エクスポートされたデータのディレクトリ内のすべてのファイルを削除します。
- dmctlを使用してタスクを削除し、コマンド
start-task --remove-meta
を実行して新しいタスクを作成します。
新しいタスクの開始後、冗長なDMワーカーノードがないことを確認し、完全なインポート中にDMクラスタを再起動またはアップグレードしないようにすることをお勧めします。
データ量が多い(1 TBを超える)場合は、次の手順を実行します。
- ダウンストリームデータベースにインポートされたデータをクリーンアップします。
- データを処理するDMワーカーノードにTiDB-Lightningをデプロイします。
- TiDB-Lightningのローカルバックエンドモードを使用して、DMダンプユニットがエクスポートするデータをインポートします。
- 完全なインポートが完了したら、次の方法でタスク構成ファイルを編集し、タスクを再開します。
task-mode
をincremental
に変更します。- ダンプユニットが出力するメタデータファイルに記録されている位置に値
mysql-instance.meta.pos
を設定します。
DMがエラーを報告する理由ERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.
インクリメンタルタスク中に再起動した場合はどうなりますか?
このエラーは、ダンプユニットによって出力されたメタデータファイルに記録されたアップストリームbinlogの位置が、完全な移行中にパージされたことを示します。
この問題が発生した場合は、タスクを一時停止し、ダウンストリームデータベース内の移行されたすべてのデータを削除して、 --remove-meta
オプションで新しいタスクを開始する必要があります。
次の方法で構成することにより、この問題を事前に回避できます。
- 完全な移行タスクが完了する前に必要なbinlogファイルを誤ってパージしないように、アップストリームのMySQLデータベースの値を
expire_logs_days
に増やします。データ量が多い場合は、餃子とTiDB-Lightningを同時に使用してタスクを高速化することをお勧めします。 - このタスクのリレーログ機能を有効にして、binlogの位置が削除されてもDMがリレーログからデータを読み取れるようにします。
クラスタがTiUPv1.3.0またはv1.3.1を使用してデプロイされている場合、DMクラスタディスプレイのGrafanaダッシュボードがダッシュボードのfailed to fetch dashboard
たのはなぜですか?
これはTiUPの既知のバグであり、TiUPv1.3.2で修正されています。この問題に対する2つの解決策は次のとおりです。
- 解決策1:
- コマンド
tiup update --self && tiup update dm
を使用して、TiUPを新しいバージョンにアップグレードします。 - クラスタのGrafanaノードをスケールインしてからスケールアウトし、Grafanaサービスを再起動します。
- コマンド
- 解決策2:
deploy/grafana-$port/bin/public
のフォルダをバックアップします。- TiUPDMオフラインパッケージをダウンロードして解凍します。
- オフラインパッケージで
grafana-v4.0.3-**.tar.gz
を解凍します。 - フォルダ
deploy/grafana-$port/bin/public
をgrafana-v4.0.3-**.tar.gz
のpublic
フォルダに置き換えます。 tiup dm restart $cluster_name -R grafana
を実行して、Grafanaサービスを再起動します。
DM v2.0で、コマンドquery-status
のクエリ結果に、タスクでenable-relay
とenable-gtid
が同時に有効になっている場合に、SyncerチェックポイントGTIDが連続していないことが示されるのはなぜですか。
これはDMの既知のバグであり、DMv2.0.2で修正されています。このバグは、次の2つの条件が同時に完全に満たされたときにトリガーされます。
- ソース設定ファイルでは、パラメータ
enable-relay
とenable-gtid
がtrue
に設定されています。 - アップストリームデータベースはMySQLセカンダリデータベースです。コマンド
show binlog events in '<newest-binlog>' limit 2
を実行してデータベースのprevious_gtids
を照会すると、次の例のように、結果は連続しません。
mysql> show binlog events in 'mysql-bin.000005' limit 2;
+------------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+------------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| mysql-bin.000005 | 4 | Format_desc | 123452 | 123 | Server ver: 5.7.32-35-log, Binlog ver: 4 |
| mysql-bin.000005 | 123 | Previous_gtids | 123452 | 194 | d3618e68-6052-11eb-a68b-0242ac110002:6-7 |
+------------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
このバグは、dmctlでquery-status <task>
を実行してタスク情報を照会し、 subTaskStatus.sync.syncerBinlogGtid
が連続していないが、 subTaskStatus.sync.masterBinlogGtid
が連続していることがわかった場合に発生します。次の例を参照してください。
query-status test
{
...
"sources": [
{
...
"sourceStatus": {
"source": "mysql1",
...
"relayStatus": {
"masterBinlog": "(mysql-bin.000006, 744)",
"masterBinlogGtid": "f8004e25-6067-11eb-9fa3-0242ac110003:1-50",
...
}
},
"subTaskStatus": [
{
...
"sync": {
...
"masterBinlog": "(mysql-bin.000006, 744)",
"masterBinlogGtid": "f8004e25-6067-11eb-9fa3-0242ac110003:1-50",
"syncerBinlog": "(mysql-bin|000001.000006, 738)",
"syncerBinlogGtid": "f8004e25-6067-11eb-9fa3-0242ac110003:1-20:40-49",
...
"synced": false,
"binlogType": "local"
}
}
]
},
{
...
"sourceStatus": {
"source": "mysql2",
...
"relayStatus": {
"masterBinlog": "(mysql-bin.000007, 1979)",
"masterBinlogGtid": "ddb8974e-6064-11eb-8357-0242ac110002:1-25",
...
}
},
"subTaskStatus": [
{
...
"sync": {
"masterBinlog": "(mysql-bin.000007, 1979)",
"masterBinlogGtid": "ddb8974e-6064-11eb-8357-0242ac110002:1-25",
"syncerBinlog": "(mysql-bin|000001.000008, 1979)",
"syncerBinlogGtid": "ddb8974e-6064-11eb-8357-0242ac110002:1-25",
...
"synced": true,
"binlogType": "local"
}
}
]
}
]
}
この例では、データソースmysql1
のsyncerBinlogGtid
は連続していません。この場合、データ損失を処理するために次のいずれかを実行できます。
- 現在の時刻から完全エクスポートタスクのメタデータに記録されている位置までのアップストリームbinlogがパージされていない場合は、次の手順を実行できます。
- 現在のタスクを停止し、GTIDが連続していないすべてのデータソースを削除します。
- すべてのソース構成ファイルで
enable-relay
からfalse
に設定します。 - GTIDが連続していないデータソース(上記の例の
mysql1
など)の場合、タスクをインクリメンタルタスクに変更し、binlog-name
、およびbinlog-pos
の情報を含む各完全エクスポートタスクのメタデータ情報を使用して関連するmysql-instances.meta
を構成しbinlog-gtid
。 - インクリメンタルタスクの
task.yaml
分のsyncers.safe-mode
をtrue
に設定し、タスクを再開します。 - インクリメンタルタスクが欠落しているすべてのデータをダウンストリームに複製した後、タスクを停止し、
task.yaml
のsafe-mode
をfalse
に変更します。 - タスクを再開します。
- アップストリームbinlogがパージされたが、ローカルリレーログが残っている場合は、次の手順を実行できます。
- 現在のタスクを停止します。
- GTIDが連続していないデータソース(上記の例の
mysql1
など)の場合、タスクをインクリメンタルタスクに変更し、binlog-name
、およびbinlog-pos
の情報を含む各完全エクスポートタスクのメタデータ情報を使用して関連するmysql-instances.meta
を構成しbinlog-gtid
。 - インクリメンタルタスクの
task.yaml
で、前の値binlog-gtid
を前の値previous_gtids
に変更します。上記の例では、1-y
を6-y
に変更します。 task.yaml
にsyncers.safe-mode
をtrue
に設定し、タスクを再開します。- インクリメンタルタスクが欠落しているすべてのデータをダウンストリームに複製した後、タスクを停止し、
task.yaml
のsafe-mode
をfalse
に変更します。 - タスクを再開します。
- データソースを再起動し、ソース構成ファイルで
enable-relay
またはenable-gtid
をfalse
に設定します。
- 上記の条件のいずれも満たされない場合、またはタスクのデータ量が少ない場合は、次の手順を実行できます。
- ダウンストリームデータベースにインポートされたデータをクリーンアップします。
- データソースを再起動し、ソース構成ファイルで
enable-relay
またはenable-gtid
をfalse
に設定します。 - 新しいタスクを作成し、コマンド
start-task task.yaml --remove-meta
を実行して、データを最初から再度移行します。
上記の1番目と2番目のソリューションで正常に複製できるデータソース(上記の例のmysql2
など)の場合、増分タスクを設定するときに、関連するmysql-instances.meta
をsubTaskStatus.sync
からのsyncerBinlog
とsyncerBinlogGtid
の情報で構成します。
DM v2.0で、 heartbeat
機能が有効になっている仮想IP環境でDMワーカーとMySQLインスタンス間の接続を切り替えるときに、「ハートビート構成が以前に使用されたものと異なります:serverIDが等しくありません」というエラーを処理するにはどうすればよいですか?
DM v2.0以降のバージョンでは、 heartbeat
機能はデフォルトで無効になっています。タスク構成ファイルでこの機能を有効にすると、高可用性機能が妨げられます。この問題を解決するには、タスク構成ファイルでenable-heartbeat
をfalse
に設定して、 heartbeat
機能を無効にしてから、タスク構成ファイルを再ロードします。 DMは、以降のリリースでheartbeat
機能を強制的に無効にします。
DMマスターが再起動した後、クラスタへの参加に失敗し、DMが「埋め込みetcdの開始に失敗しました。RawCause:メンバーxxxはすでにブートストラップされています」というエラーを報告するのはなぜですか?
DMマスターが起動すると、DMはetcd情報を現在のディレクトリに記録します。 DMマスターの再起動後にディレクトリが変更された場合、DMはetcd情報にアクセスできないため、再起動は失敗します。
この問題を解決するには、TiUPを使用してDMクラスターを維持することをお勧めします。バイナリファイルを使用して展開する必要がある場合は、DMマスターの構成ファイルで絶対パスを使用してdata-dir
を構成するか、コマンドを実行する現在のディレクトリに注意する必要があります。
dmctlを使用してコマンドを実行するとDMマスターに接続できないのはなぜですか?
dmctl executeコマンドを使用すると、DMマスターへの接続が失敗する場合があり(コマンドでパラメーター値--master-addr
を指定した場合でも)、エラーメッセージはRawCause: context deadline exceeded, Workaround: please check your network connection.
のようになります。ただし、 telnet <master-addr>
などのコマンドを使用してネットワーク接続を確認した後、例外は見つかりません。
この場合、環境変数https_proxy
を確認できます( httpsであることに注意してください)。この変数が構成されている場合、dmctlはhttps_proxy
で指定されたホストとポートを自動的に接続します。ホストに対応する転送サービスがない場合、接続は失敗しproxy
。
この問題を解決するには、 https_proxy
が必須かどうかを確認してください。そうでない場合は、設定をキャンセルしてください。それ以外の場合は、元のdmctlコマンドの前に環境変数設定https_proxy="" ./dmctl --master-addr "x.x.x.x:8261"
を追加します。
ノート:
proxy
に関連する環境変数には、http_proxy
、およびhttps_proxy
が含まれno_proxy
。上記の手順を実行しても接続エラーが続く場合は、http_proxy
とno_proxy
の構成パラメーターが正しいかどうかを確認してください。
2.0.2から2.0.6までのDMバージョンでstart-relayコマンドを実行するときに返されたエラーを処理するにはどうすればよいですか?
flush local meta, Rawcause: open relay-dir/xxx.000001/relay.metayyyy: no such file or directory
上記のエラーは、次の場合に発生する可能性があります。
- DMはv2.0.1以前からv2.0.2-v2.0.6にアップグレードされており、リレーログはアップグレード前に開始され、アップグレード後に再起動されます。
- stop-relayコマンドを実行してリレーログを一時停止してから、再起動します。
次のオプションを使用して、このエラーを回避できます。
リレーログを再起動します。
» stop-relay -s sourceID workerName » start-relay -s sourceID workerName
DMをv2.0.7以降のバージョンにアップグレードします。
- DMは、Alibaba RDSまたは他のクラウドデータベースからのデータの移行をサポートしていますか?
- タスク構成のブロックと許可リストの正規表現は、 <code>non-capturing (?!)</code>サポートしていますか?
- アップストリームで実行されるステートメントに複数のDDL操作が含まれている場合、DMはそのような移行をサポートしますか?
- 互換性のないDDLステートメントを処理する方法は?
- データ移行タスクをリセットするにはどうすればよいですか?
- <code>online-ddl-scheme: "gh-ost"</code>が設定された後、gh-ostテーブルに関連するDDL操作によって返されるエラーを処理する方法は?
- 既存のデータ移行タスクにテーブルを追加するにはどうすればよいですか?
- <code>packet for query is too large. Try adjusting the 'max_allowed_packet' variable</code>完全なインポート中に発生<code>packet for query is too large. Try adjusting the 'max_allowed_packet' variable</code> 。
- エラー1054の処理方法:DM1.0クラスタの既存のDM移行タスクがDM2.0以降のクラスタで実行されているときに発生する<code>Error 1054: Unknown column 'binlog_gtid' in 'field list'</code> ?
- TiUPがDMの一部のバージョン(v2.0.0-hotfixなど)の展開に失敗するのはなぜですか?
- エラー<code>parse mydumper metadata error: EOF</code> ?
- シャーディングされたスキーマとテーブルを複製するときにDMが致命的なエラーを報告しないのに、ダウンストリームデータが失われるのはなぜですか?
- DMがアップストリームからレプリケートしていないのに、 <code>replicate lag</code>モニターメトリックにデータが表示されないのはなぜですか?
- DMがタスクを開始しているとき<code>fail to initial unit Sync of subtask</code>たエラーを処理する方法。エラーメッセージの<code>RawCause</code>は、 <code>context deadline exceeded</code>たことを示していますか?
- DMがデータを複製しているときにエラー<code>duplicate entry</code>を処理するにはどうすればよいですか?
- 一部の監視パネルに<code>No data point</code>のはなぜですか?
- DM v1.0では、タスクにエラーがあるときにコマンド<code>sql-skip</code>が一部のステートメントをスキップできないのはなぜですか?
- DMが複製しているときに、 <code>REPLACE</code>ステートメントがダウンストリームに表示され続けるのはなぜですか?
- DM v2.0では、タスク中にDMが再起動すると、完全なインポートタスクが失敗するのはなぜですか?
- DMがエラーを報告する理由<code>ERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.</code>インクリメンタルタスク中に再起動した場合はどうなりますか?
- クラスタがTiUPv1.3.0またはv1.3.1を使用してデプロイされている場合、DMクラスタディスプレイのGrafanaダッシュボードがダッシュボードの<code>failed to fetch dashboard</code>たのはなぜですか?
- DM v2.0で、コマンド<code>query-status</code>のクエリ結果に、タスクで<code>enable-relay</code>と<code>enable-gtid</code>が同時に有効になっている場合に、SyncerチェックポイントGTIDが連続していないことが示されるのはなぜですか。
- DM v2.0で、 <code>heartbeat</code>機能が有効になっている仮想IP環境でDMワーカーとMySQLインスタンス間の接続を切り替えるときに、「ハートビート構成が以前に使用されたものと異なります:serverIDが等しくありません」というエラーを処理するにはどうすればよいですか?
- DMマスターが再起動した後、クラスタへの参加に失敗し、DMが「埋め込みetcdの開始に失敗しました。RawCause:メンバーxxxはすでにブートストラップされています」というエラーを報告するのはなぜですか?
- dmctlを使用してコマンドを実行するとDMマスターに接続できないのはなぜですか?
- 2.0.2から2.0.6までのDMバージョンでstart-relayコマンドを実行するときに返されたエラーを処理するにはどうすればよいですか?