- 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
- 用語集
TiCDCのFAQ
このドキュメントでは、TiCDCを使用するときに発生する可能性のある一般的な質問を紹介します。
ノート:
このドキュメントでは、
cdc cli
コマンドで指定されたPDアドレスは--pd=http://10.0.10.25:2379
です。コマンドを使用するときは、アドレスを実際のPDアドレスに置き換えてください。
TiCDCでタスクを作成するときにstart-ts
を選択するにはどうすればよいですか?
レプリケーションタスクのstart-ts
は、アップストリームTiDBクラスタのタイムスタンプOracle(TSO)に対応します。 TiCDCは、レプリケーションタスクでこのTSOにデータを要求します。したがって、レプリケーションタスクのstart-ts
は、次の要件を満たす必要があります。
start-ts
の値は、現在のTiDBクラスタのtikv_gc_safe_point
の値よりも大きくなります。そうしないと、タスクの作成時にエラーが発生します。- タスクを開始する前に、ダウンストリームに
start-ts
より前のすべてのデータがあることを確認してください。メッセージキューへのデータの複製などのシナリオで、アップストリームとダウンストリーム間のデータの整合性が必要ない場合は、アプリケーションのニーズに応じてこの要件を緩和できます。
start-ts
を指定しない場合、またはstart-ts
を0
として指定する場合、レプリケーションタスクの開始時に、TiCDCは現在のTSOを取得し、このTSOからタスクを開始します。
TiCDCでタスクを作成するときに、一部のテーブルを複製できないのはなぜですか?
cdc cli changefeed create
を実行してレプリケーションタスクを作成すると、TiCDCはアップストリームテーブルがレプリケーションの制限を満たしているかどうかを確認します。一部のテーブルが制限を満たしていない場合、不適格なテーブルのリストとともにsome tables are not eligible to replicate
が返されます。 Y
またはy
を選択してタスクの作成を続行でき、これらのテーブルのすべての更新はレプリケーション中に自動的に無視されます。 Y
またはy
以外の入力を選択した場合、レプリケーションタスクは作成されません。
TiCDCレプリケーションタスクの状態を表示するにはどうすればよいですか?
TiCDCレプリケーションタスクのステータスを表示するには、 cdc cli
を使用します。例えば:
cdc cli changefeed list --pd=http://10.0.10.25:2379
期待される出力は次のとおりです。
[{
"id": "4e24dde6-53c1-40b6-badf-63620e4940dc",
"summary": {
"state": "normal",
"tso": 417886179132964865,
"checkpoint": "2020-07-07 16:07:44.881",
"error": null
}
}]
checkpoint
:TiCDCは、このタイムスタンプより前のすべてのデータをダウンストリームに複製しました。state
:このレプリケーションタスクの状態:normal
:タスクは正常に実行されます。stopped
:タスクが手動で停止されたか、エラーが発生しました。removed
:タスクは削除されます。
ノート:
この機能はTiCDC4.0.3で導入されました。
TiCDC gc-ttl
とは何ですか?
v4.0.0-rc.1以降、PDはサービスレベルのGCセーフポイントの設定で外部サービスをサポートします。どのサービスでも、GCセーフポイントを登録および更新できます。 PDは、このGCセーフポイントより後のキー値データがGCによってクリーンアップされないようにします。
レプリケーションタスクが使用できないか中断されている場合、この機能により、TiCDCによって消費されるデータがGCによってクリーンアップされることなくTiKVに保持されます。
TiCDCサーバーを起動するときに、 gc-ttl
を構成することにより、GCセーフポイントの存続時間(TTL)期間を指定できます。 gc-ttl
もできTiUPを使用して変更する 。デフォルト値は24時間です。 TiCDCでは、この値は次のことを意味します。
- TiCDCサービスが停止した後、GCセーフポイントがPDに保持される最大時間。
- タスクが中断または手動で停止された後、レプリケーションタスクを一時停止できる最大時間。中断されたレプリケーションタスクの時間が
gc-ttl
で設定された値より長い場合、レプリケーションタスクはfailed
ステータスになり、再開できず、GCセーフポイントの進行に影響を与え続けることができません。
上記の2番目の動作は、TiCDCv4.0.13以降のバージョンで導入されています。目的は、TiCDCのレプリケーションタスクが長時間中断され、アップストリームTiKVクラスタのGCセーフポイントが長時間継続せず、古いデータバージョンが多すぎて、アップストリームクラスタのパフォーマンスに影響を与えるのを防ぐことです。
ノート:
たとえば、一部のシナリオでは、 Dumpling/ BRを使用した完全レプリケーションの後に増分レプリケーションにTiCDCを使用する場合、デフォルトの24時間の
gc-ttl
では不十分な場合があります。 TiCDCサーバーを起動するときは、gc-ttl
に適切な値を指定する必要があります。
TiCDCガベージコレクション(GC)セーフポイントの完全な動作は何ですか?
TiCDCサービスの開始後にレプリケーションタスクが開始された場合、TiCDC所有者は、すべてのレプリケーションタスクの中で最小値のcheckpoint-ts
でPDサービスGCセーフポイントを更新します。サービスGCセーフポイントは、TiCDCがその時点およびそれ以降に生成されたデータを削除しないことを保証します。レプリケーションタスクが中断された場合、または手動で停止された場合、このタスクのcheckpoint-ts
は変更されません。一方、PDの対応するサービスGCセーフポイントも更新されません。
レプリケーションタスクがgc-ttl
で指定された時間より長く中断された場合、レプリケーションタスクはfailed
ステータスになり、再開できません。 PDに対応するサービスGCセーフポイントは継続されます。
TiCDCがサービスGCセーフポイントに設定する存続時間(TTL)は24時間です。つまり、TiCDCサービスが中断されてから24時間以内に回復できる場合、GCメカニズムはデータを削除しません。
TiCDCタイムゾーンとアップストリーム/ダウンストリームデータベースのタイムゾーンの関係を理解するにはどうすればよいですか?
上流のタイムゾーン | TiCDCタイムゾーン | 下流のタイムゾーン | |
---|---|---|---|
Configuration / コンフィグレーション方法 | タイムゾーンのサポートを参照してください | TiCDCサーバーの起動時に--tz パラメーターを使用して構成 | sink-uri のtime-zone パラメータを使用して構成 |
説明 | タイムスタンプタイプのDML操作およびタイムスタンプタイプの列に関連するDDL操作に影響を与えるアップストリームTiDBのタイムゾーン。 | TiCDCは、アップストリームTiDBのタイムゾーンがTiCDCタイムゾーン構成と同じであると想定し、タイムスタンプ列で関連する操作を実行します。 | ダウンストリームMySQLは、ダウンストリームタイムゾーン設定に従って、DMLおよびDDL操作のタイムスタンプを処理します。 |
ノート:
TiCDCサーバーのタイムゾーンを設定するときは注意してください。このタイムゾーンはタイムタイプの変換に使用されるためです。アップストリームタイムゾーン、TiCDCタイムゾーン、およびダウンストリームタイムゾーンの一貫性を保ちます。 TiCDCサーバーは、次の優先順位でタイムゾーンを選択します。
- TiCDCは、最初に
--tz
を使用して指定されたタイムゾーンを使用します。--tz
が使用できない場合、TiCDCはTZ
環境変数を使用して設定されたタイムゾーンを読み取ろうとします。TZ
の環境変数が使用できない場合、TiCDCはマシンのデフォルトのタイムゾーンを使用します。
--config
で構成ファイルを指定せずにレプリケーションタスクを作成した場合のTiCDCのデフォルトの動作は何ですか?
-config
パラメータを指定せずにcdc cli changefeed create
コマンドを使用すると、TiCDCは次のデフォルトの動作でレプリケーションタスクを作成します。
- システムテーブルを除くすべてのテーブルを複製します
- 古い値機能を有効にします
- 有効なインデックスを含まないテーブルの複製をスキップします
TiCDCは、運河形式でのデータ変更の出力をサポートしていますか?
はい。 Canal出力を有効にするには、 --sink-uri
パラメーターでプロトコルをcanal
として指定します。例えば:
cdc cli changefeed create --pd=http://10.0.10.25:2379 --sink-uri="kafka://127.0.0.1:9092/cdc-test?kafka-version=2.4.0&protocol=canal" --config changefeed.toml
ノート:
- この機能はTiCDC4.0.2で導入されました。
- TiCDCは現在、KafkaやPulsarなどのMQシンクにのみCanal形式でデータ変更を出力することをサポートしています。
詳細については、 レプリケーションタスクを作成するを参照してください。
TiCDCからKafkaまでのレイテンシーがますます高くなるのはなぜですか?
TiCDCレプリケーションタスクの状態を表示するにはどうすればよいですかを確認してください。
Kafkaの次のパラメータを調整します。
message.max.bytes
の値をserver.properties
から1073741824
(1 GB)に増やします。replica.fetch.max.bytes
の値をserver.properties
から1073741824
(1 GB)に増やします。consumer.properties
のfetch.message.max.bytes
の値を増やして、message.max.bytes
の値より大きくします。
TiCDCがデータをKafkaに複製するとき、トランザクションのすべての変更を1つのメッセージに書き込みますか?そうでない場合、それはどのような基準で変更を分割しますか?
いいえ。構成されたさまざまな配布戦略に従って、 row id
は、 default
、およびtable
を含むさまざまなベースで変更を分割しts
。
詳細については、 レプリケーションタスク構成ファイルを参照してください。
TiCDCがデータをKafkaに複製するとき、TiDB内の単一メッセージの最大サイズを制御できますか?
はい。 max-message-bytes
パラメーターを設定して、毎回Kafkaブローカーに送信されるデータの最大サイズを制御できます(オプション、デフォルトでは10MB
)。 max-batch-size
を設定して、各Kafkaメッセージの変更レコードの最大数を指定することもできます。現在、この設定は、Kafkaのprotocol
がopen-protocol
(オプション、デフォルトでは16
)の場合にのみ有効になります。
TiCDCがデータをKafkaに複製するとき、メッセージには複数のタイプのデータ変更が含まれていますか?
はい。 1つのメッセージに複数のupdate
またはdelete
が含まれる場合があり、 update
とdelete
が共存する場合があります。
TiCDCがデータをKafkaに複製する場合、TiCDC Open Protocolの出力でタイムスタンプ、テーブル名、およびスキーマ名を表示するにはどうすればよいですか?
この情報は、Kafkaメッセージのキーに含まれています。例えば:
{
"ts":<TS>,
"scm":<Schema Name>,
"tbl":<Table Name>,
"t":1
}
詳細については、 TiCDCオープンプロトコルイベント形式を参照してください。
TiCDCがデータをKafkaに複製するとき、メッセージ内のデータ変更のタイムスタンプをどのように知ることができますか?
Kafkaメッセージのキーのts
を右に18ビット移動すると、UNIXタイムスタンプを取得できます。
TiCDCオープンプロトコルはどのようにnull
を表しますか?
TiCDC Open Protocolでは、タイプコード6
はnull
を表します。
タイプ | コード | 出力例 | ノート |
---|---|---|---|
ヌル | 6 | {"t":6,"v":null} |
詳細については、 TiCDCOpenProtocol列タイプコードを参照してください。
TiCDC Open Protocolの行変更イベントがINSERT
イベントなのかUPDATE
イベントなのかはどうすればわかりますか?
Old Value機能が有効になっていない場合、TiCDCOpenProtocolの行変更イベントがINSERT
イベントであるかUPDATE
イベントであるかを判断できません。この機能が有効になっている場合は、含まれているフィールドによってイベントタイプを判別できます。
UPDATE
イベントには"p"
フィールドと"u"
フィールドの両方が含まれますINSERT
イベントには"u"
フィールドのみが含まれますDELETE
イベントには"d"
フィールドのみが含まれます
詳細については、 オープンプロトコル行変更イベント形式を参照してください。
TiCDCはどのくらいのPDストレージを使用しますか?
TiCDCはPDでetcdを使用して、メタデータを保存し、定期的に更新します。 etcdのMVCCとPDのデフォルトの圧縮の間の時間間隔は1時間であるため、TiCDCが使用するPDストレージの量は、この1時間以内に生成されるメタデータバージョンの量に比例します。ただし、v4.0.5、v4.0.6、およびv4.0.7では、TiCDCに頻繁な書き込みの問題があるため、1時間に1000個のテーブルが作成またはスケジュールされている場合、etcdストレージをすべて使用し、 etcdserver: mvcc: database space exceeded
のエラーを返します。 。このエラーが発生した後、etcdストレージをクリーンアップする必要があります。詳細については、 etcdはスペースクォータを維持しますを参照してください。クラスタをv4.0.9以降のバージョンにアップグレードすることをお勧めします。
TiCDCは大規模なトランザクションの複製をサポートしていますか?リスクはありますか?
TiCDCは、大規模なトランザクション(5 GBを超えるサイズ)を部分的にサポートします。さまざまなシナリオに応じて、次のリスクが存在する可能性があります。
- TiCDCの内部処理能力が不十分な場合、レプリケーションタスクエラー
ErrBufferReachLimit
が発生する可能性があります。 - TiCDCの内部処理能力が不十分な場合、またはTiCDCのダウンストリームのスループット能力が不十分な場合、メモリ不足(OOM)が発生する可能性があります。
上記のエラーが発生した場合は、BRを使用して大規模なトランザクションの増分データを復元することをお勧めします。詳細な操作は次のとおりです。
- 大規模なトランザクションのために終了したチェンジフィードの
checkpoint-ts
を記録し、このTSOをBR増分バックアップの--lastbackupts
として使用して、 増分データバックアップを実行します。 - インクリメンタルデータをバックアップした後、BRログ出力で
["Full backup Failed summary : total backup ranges: 0, total success: 0, total failed: 0"] [BackupTS=421758868510212097]
に類似したログレコードを見つけることができます。このログにBackupTS
を記録します。 - インクリメンタルデータを復元する 。
- 新しいチェンジフィードを作成し、
BackupTS
からレプリケーションタスクを開始します。 - 古いチェンジフィードを削除します。
DDLステートメントをダウンストリームのMySQL 5.7に複製する場合、時間タイプフィールドのデフォルト値に一貫性がありません。私に何ができる?
create table test (id int primary key, ts timestamp)
ステートメントがアップストリームTiDBで実行されると仮定します。 TiCDCがこのステートメントをダウンストリームのMySQL5.7に複製する場合、 MySQL 5.7はデフォルト構成を使用します。レプリケーション後のテーブルスキーマは次のとおりです。 timestamp
フィールドのデフォルト値はCURRENT_TIMESTAMP
になります:
mysql root@127.0.0.1:test> show create table test;
+-------+----------------------------------------------------------------------------------+
| Table | Create Table |
+-------+----------------------------------------------------------------------------------+
| test | CREATE TABLE `test` ( |
| | `id` int(11) NOT NULL, |
| | `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, |
| | PRIMARY KEY (`id`) |
| | ) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
+-------+----------------------------------------------------------------------------------+
1 row in set
結果から、レプリケーションの前後のテーブルスキーマに一貫性がないことがわかります。これは、TiDBのデフォルト値explicit_defaults_for_timestamp
がMySQLのデフォルト値と異なるためです。詳細については、 MySQLの互換性を参照してください。
v5.0.1またはv4.0.13以降、MySQLへのレプリケーションごとに、TiCDCは自動的にexplicit_defaults_for_timestamp = ON
を設定して、時間タイプがアップストリームとダウンストリームの間で一貫していることを確認します。 v5.0.1またはv4.0.13より前のバージョンの場合、TiCDCを使用して時間タイプデータを複製するときに、一貫性のないexplicit_defaults_for_timestamp
値によって引き起こされる互換性の問題に注意してください。
TiCDCレプリケーションタスクを作成すると、 enable-old-value
がtrue
に設定されますが、アップストリームからのINSERT
/ UPDATE
ステートメントは、ダウンストリームにレプリケートされた後、 REPLACE INTO
になります。
TiCDCでチェンジフィードが作成されると、 safe-mode
の設定はデフォルトでtrue
になり、アップストリームのINSERT
ステートメントに対して実行するREPLACE INTO
ステートメントが生成されUPDATE
。
現在、ユーザーはsafe-mode
の設定を変更できないため、この問題は現在解決策がありません。
ダウンストリームのレプリケーションのシンクがTiDBまたはMySQLの場合、ダウンストリームデータベースのユーザーにはどのような権限が必要ですか?
シンクがTiDBまたはMySQLの場合、ダウンストリームデータベースのユーザーには次の権限が必要です。
Select
Index
Insert
Update
Delete
Create
Drop
Alter
Create View
recover table
をダウンストリームTiDBに複製する必要がある場合は、 Super
の権限が必要です。
TiCDCがディスクを使用するのはなぜですか? TiCDCはいつディスクに書き込みますか? TiCDCはレプリケーションパフォーマンスを向上させるためにメモリバッファを使用しますか?
アップストリームの書き込みトラフィックがピーク時にある場合、ダウンストリームはすべてのデータをタイムリーに消費できず、データが山積みになる可能性があります。 TiCDCは、ディスクを使用して、積み上げられたデータを処理します。 TiCDCは、通常の操作中にディスクにデータを書き込む必要があります。ただし、ディスクへの書き込みでは100ミリ秒以内の遅延しか発生しないため、これは通常、レプリケーションスループットとレプリケーション遅延のボトルネックにはなりません。 TiCDCはまた、メモリを使用してディスクからのデータの読み取りを高速化し、レプリケーションのパフォーマンスを向上させます。
TiCDCを使用したレプリケーションが停止したり、 TiDB LightningとBRを使用したデータの復元後に停止したりするのはなぜですか?
現在、TiCDCはTiDB LightningおよびBRと完全には互換性がありません。したがって、TiCDCによって複製されるテーブルでTiDB LightningおよびBRを使用することは避けてください。
- TiCDCでタスクを作成するときに<code>start-ts</code>を選択するにはどうすればよいですか?
- TiCDCでタスクを作成するときに、一部のテーブルを複製できないのはなぜですか?
- TiCDCレプリケーションタスクの状態を表示するにはどうすればよいですか?
- TiCDC <code>gc-ttl</code>とは何ですか?
- TiCDCガベージコレクション(GC)セーフポイントの完全な動作は何ですか?
- TiCDCタイムゾーンとアップストリーム/ダウンストリームデータベースのタイムゾーンの関係を理解するにはどうすればよいですか?
- <code>--config</code>で構成ファイルを指定せずにレプリケーションタスクを作成した場合のTiCDCのデフォルトの動作は何ですか?
- TiCDCは、運河形式でのデータ変更の出力をサポートしていますか?
- TiCDCからKafkaまでのレイテンシーがますます高くなるのはなぜですか?
- TiCDCがデータをKafkaに複製するとき、トランザクションのすべての変更を1つのメッセージに書き込みますか?そうでない場合、それはどのような基準で変更を分割しますか?
- TiCDCがデータをKafkaに複製するとき、TiDB内の単一メッセージの最大サイズを制御できますか?
- TiCDCがデータをKafkaに複製するとき、メッセージには複数のタイプのデータ変更が含まれていますか?
- TiCDCがデータをKafkaに複製する場合、TiCDC Open Protocolの出力でタイムスタンプ、テーブル名、およびスキーマ名を表示するにはどうすればよいですか?
- TiCDCがデータをKafkaに複製するとき、メッセージ内のデータ変更のタイムスタンプをどのように知ることができますか?
- TiCDCオープンプロトコルはどのように<code>null</code>を表しますか?
- TiCDC Open Protocolの行変更イベントが<code>INSERT</code>イベントなのか<code>UPDATE</code>イベントなのかはどうすればわかりますか?
- TiCDCはどのくらいのPDストレージを使用しますか?
- TiCDCは大規模なトランザクションの複製をサポートしていますか?リスクはありますか?
- DDLステートメントをダウンストリームのMySQL 5.7に複製する場合、時間タイプフィールドのデフォルト値に一貫性がありません。私に何ができる?
- TiCDCレプリケーションタスクを作成すると、 <code>enable-old-value</code>が<code>true</code>に設定されますが、アップストリームからの<code>INSERT</code> / <code>UPDATE</code>ステートメントは、ダウンストリームにレプリケートされた後、 <code>REPLACE INTO</code>になります。
- ダウンストリームのレプリケーションのシンクがTiDBまたはMySQLの場合、ダウンストリームデータベースのユーザーにはどのような権限が必要ですか?
- TiCDCがディスクを使用するのはなぜですか? TiCDCはいつディスクに書き込みますか? TiCDCはレプリケーションパフォーマンスを向上させるためにメモリバッファを使用しますか?
- TiCDCを使用したレプリケーションが停止したり、 TiDB LightningとBRを使用したデータの復元後に停止したりするのはなぜですか?