フルデータベースのリアルタイム同期：運用とチューニング - DataWorks

前提条件

操作を実行する前、または問題のトラブルシューティングを行う前に、次の条件を満たしていることを確認してください。

権限要件

ソースアカウント：データベース、テーブル、列、プライマリキー、インデックスなどのメタデータを読み取る権限が必要です。また、Binlog、先行書き込みログ (WAL)、Oplog などのソース変更ログを読み取る権限も必要です。
ターゲットアカウント：テーブルの作成、テーブルの変更、およびデータの書き込みを行う権限が必要です。

ネットワーク接続性

リソースグループは、ソースとターゲットの両方へのネットワーク接続が必要です。ネットワークの問題により、スキーマ移行が失敗したり、完全初期化がスタックしたり、増分同期が中断されたりする可能性があります。

ソースログの保持

タスクの停止後に元のオフセットから再開できない最も一般的な理由は、ログの保持期間が不十分であるためです。

データソースとチャネルの互換性

同期機能 (フルロード、増分、DDL など) は、データソースによって異なります。UI ページで設定可能なオプションが、サポートされている機能です。ソースとターゲットのバージョンがチャネルでサポートされていることを確認してください。

適用範囲

リアルタイムフルデータベース同期タスクのトラブルシューティングを行う前に、タスクタイプ、チャネルの機能、および主なトラブルシューティングの対象範囲を確認し、このドキュメントがお使いのシナリオに適用されるかをご確認ください。

基準	適用範囲	該当なし / 主な焦点
タスクタイプ	複数のテーブルまたはデータベース全体のリアルタイム変更データキャプチャ (CDC)。	このドキュメントは、単一テーブルのリアルタイム同期には適用されません。単一テーブルタスクのトラブルシューティングについては、単一テーブルのリアルタイム同期の運用とチューニングをご参照ください。
典型的なチャネル	データベースソースから Hologres、MaxCompute、ADB (AnalyticDB)、Doris、StarRocks、SelectDB、Kafka、DLF (Data Lake Formation)、Lindorm、Elasticsearch、または OSS (Object Storage Service) へ。	他のチャネルタイプは対象外です。
トラブルシューティングの焦点	ログ保持、オフセット、プライマリキー、DDL、ソースの負荷、ターゲットの書き込みパフォーマンス、パーティション、コミット、スモールファイル、レート制限、およびバックログ。	タスクのステータスに加えて、メトリクスとログを使用してきめ細かいトラブルシューティングを行います。

重要

リアルタイムフルデータベース同期は、ソースが継続的に変更ログ (Binlog、WAL、Oplog など) を提供することを前提とします。ターゲットは、現在の書き込みモード、プライマリキーまたは一意キーのセマンティクス、および必要なスキーマ変更をサポートする必要があります。これらの条件が満たされない場合、タスクが正しく実行されないか、データ整合性が保証されない可能性があります。

タスクステージ

リアルタイムフルデータベース同期タスクには、通常、以下のステージがあり、それぞれ運用上の焦点が異なります：

ステージ	説明	運用上の焦点
スキーマ移行	ソースからデータベース、テーブル、列の情報を読み取り、ターゲットにテーブル構造を作成または更新します。	ソースメタデータ権限、ターゲットテーブル作成権限、データ型マッピング、テーブル名マッピングルール
完全初期化	ソースの履歴データを読み取ってターゲットに書き込み、タスク開始前に存在していたデータをバックフィルします。	分割キー、フルロード同時実行数、ソース接続数、リソースグループ、ターゲット書き込みキャパシティ、完全および増分のキャッチアップ
増分同期	ソースの変更を継続的に消費し、ターゲットに書き込みます。	オフセットラグ、読み取りおよび書き込みスループット、フェールオーバー、チェックポイント、DDL イベント、ソースログ保持

重要

リアルタイムフルデータベース同期タスクは、通常、最初に スキーマ移行 と 完全初期化 を完了し、その後、増分同期 を継続的に処理します。

完全初期化 中に生成される増分データは、ソースログ保持とリアルタイムパイプラインのキャッチアップ能力に依存します。したがって、タスクの開始、停止、再実行、またはテーブルの追加を行う際には、完全初期化の進捗 と リアルタイムレイテンシー の両方を監視する必要があります。

運用

タスクの開始と停止

タスクを開始した後、次の項目を順に確認し、正しく実行されていることを確認してください：

スキーマ移行が完了し、ターゲットにテーブル構造が作成されていることを確認します。
完全初期化の状況を確認し、データの読み取りと書き込みが正常に行われていることを確認します。フル読み取りレートと書き込みレートが安定しており、完了済みテーブル数が継続的に増加している必要があります。
増分同期が正常に実行されていることを確認します。リアルタイムレイテンシーが妥当な範囲内であり、フェールオーバーが頻発せず、チェックポイントのコミットが成功している必要があります。

タスクを停止する前に、ソースログの保持期間が停止期間に対応できる十分な長さであることを確認してください。タスクの停止時間が長すぎると、ソースの Binlog、WAL、またはメッセージログがパージされ、タスクが最後に保存されたオフセットから再開できなくなる可能性があります。タスクを再開すると、最後に保存されたオフセットから処理を続行します。オフセットの有効期限が切れている場合は、オフセットのリセット、またはタスクの再初期化に伴うリスクを評価する必要があります。詳細については、「停止後に以前のオフセットからタスクを再開できない」をご参照ください。

構成の変更

実行中のリアルタイムのフルデータベース同期タスクでは、テーブルの追加または削除、テーブルマッピングの調整、フルまたは増分のワークロード用のリソースの変更が必要になる場合があります。構成を変更した後、画面の指示に従って更新内容を送信し、適用してください。

変更タイプ	リスク	推奨事項
テーブルの追加	メタデータの再読み取りが必要です。また、チャネルの機能によっては、スキーマ移行と完全初期化を実行し、増分同期を開始する必要がある場合があります。	新しいテーブルが選択ルールに一致していることを確認してから、テーブルマッピングを更新してください。新しいテーブルについて、完全初期化の進捗、増分同期の進捗状況、およびソースログの保持期間を監視してください。
テーブルの削除	実行中のタスクからテーブルを削除すると、既存のテーブルマッピング、ターゲットデータ、および下流の依存関係に影響する可能性があります。	削除する前に、業務が当該テーブルに依存しなくなったことを確認してください。例外的なケースでは、新しいスコープに対応するために新しいタスクを作成してください。
マッピングルールの変更	ターゲットのテーブル名の競合、カラム欠落、パーティション変更、または既存データの取り扱い方法の変更が発生する可能性があります。	送信する前に、ターゲットのテーブル名、カラム型、プライマリキー、パーティション、追加カラム、およびターゲット上の既存データを確認してください。
リソースの調整	リソース、同時実行数、および接続数は、完全初期化と増分同期で異なる場合があります。不適切な調整により、ソースまたはターゲットの負荷が増加する可能性があります。	リソースは段階的に調整してください。変更のたびに、完全初期化のレート、リアルタイムレイテンシー、フェールオーバー、チェックポイント、およびリソース使用率を監視してください。

構成変更の反映方法：

テーブルマッピングの更新と新しいテーブルの追加では、通常、タスクを一時停止する必要はありません。
CU (Compute Unit) などのリソース仕様の調整が反映されるには、タスクの再起動が必要になる場合や、次のチェックポイントまで待つ必要がある場合があります。画面の指示に従ってください。
インフライトデータへの影響を避けるため、タスクの一時停止中にマッピングルールを変更することを推奨します。
構成変更に失敗した場合は、以前の構成にリバートしてから再送信してください。

アラート構成

リアルタイムのフルデータベース同期タスクでは、少なくとも次のイベントについてアラートを構成することを推奨します：

アラートタイプ	ユースケース	説明
タスクステータスの異常	すべてのタスク	タスクが失敗した場合、または予期せず終了した場合に、直ちにアラートをトリガーします。
リアルタイムレイテンシー	すべてのタスク	リアルタイムレイテンシーが業務で許容可能なしきい値を超えた場合に、アラートをトリガーします。
フェールオーバー	すべてのタスク	フェールオーバーが頻発する場合は、通常、手動での対応が必要な問題が発生していることを示します。
リソース使用率	リソース制約があるシナリオ	CPU、メモリ、またはネットワークの使用率が過度に高い場合に、アラートをトリガーします。
DDL 通知	DDL イベントを処理するチャネル	DDL イベントはターゲットのスキーマに影響する可能性があるため、監視する必要があります。
バックログ	Kafka、DataHub、または LogHub のソース	ソースコンソールまたはタスクメトリクスを使い、パーティション、シャード、またはトピックのバックログを監視してください。

MySQL や PostgreSQL などのログベースのソースでは、ログの有効期限切れによるタスク復旧の失敗を防ぐために、Binlog や WAL などのログの保持期間も監視する必要があります。

アラートルールを構成する手順の詳細については、「Common Alerting Rules」をご参照ください。

トラブルシューティング方法

スキーマ移行の失敗

スキーマ移行の失敗は、多くの場合、権限、メタデータの読み取り、データ型、またはターゲットでのテーブル作成が原因です。次の順序でトラブルシューティングを行ってください：

ソースアカウントに、データベース、テーブル、カラム、プライマリキー、インデックスなどのメタデータを読み取る権限があるかどうかを確認してください。
タスクのリソースグループと、ソースおよびターゲット間のネットワーク接続性を確認してください。
ターゲットアカウントに、テーブルの作成、テーブルの変更、およびデータの書き込みを行う権限があるかどうかを確認してください。
テーブル名、データベース名、またはスキーマ名のマッピングルールによって、重複した名前または無効な名前が生成されていないかどうかを確認してください。
データ型、プライマリキー、パーティションカラム、および追加カラムがターゲットと互換性があるかどうかを確認してください。

正規表現を使用してテーブルを選択する場合、または一括でテーブルを選択する場合は、同期範囲を拡大する前に少数のテーブルでテストすることを推奨します。

完全初期化の遅延または失敗

完全初期化が遅い、または失敗する場合は、まず、タスクがリソースの初期化、ソースからの読み取り、ターゲットへの書き込み、増分変更のキャッチアップ待機のいずれの段階で停止しているかを判断してください。トラブルシューティングでは、完全読み取りレート、書き込みレート、完了済みテーブル数、残りのシャード、ソース接続数、ターゲット書き込みレイテンシーなどのメトリクスを確認してください。

症状	考えられる原因	推奨事項
完全初期化タスクが長時間開始されません。	リソースグループのキューイング、リソース初期化の失敗、またはソースもしくはターゲットとの接続性の問題。	リソースグループのステータスとネットワーク接続性を確認してください。ソースとターゲットのアカウント権限が正しいことを確認してください。
完全読み取りレートが低い。	分割キーの分布が不均一、ソース SQL クエリでインデックスが使用されていない、ソースの負荷が高い、または接続数もしくはクォータが不足している。	分割キーとインデックスを確認し、完全ロードの同時実行を適度に調整してください。ソースの負荷が高い場合は、レート制限を適用するか、オフピーク時間にタスクを実行してください。
完全書き込みレートが低い。	ターゲットの書き込みキャパシティーが不足している、パーティション設計が不適切、またはバッチ書き込みパラメータが適切でない。	ターゲットの負荷、書き込み QPS、バッチコミットレイテンシー、およびパーティション数を確認してください。
完全初期化の完了後、増分キャッチアップが遅い。	完全初期化中にソースで大量の変更が発生し、リアルタイムパイプラインでログのバックログを処理する必要がある。	リアルタイムレイテンシーが継続的に低下しているかどうかを監視し、ソースログの保持期間が十分であることを確認してください。

高いリアルタイムレイテンシー

リアルタイムレイテンシーが増加した場合は、まず、タスクが完全初期化後の増分キャッチアップフェーズにあるかどうかを判断してください。次に、ボトルネックがリーダー、処理パイプライン、またはライターのいずれにあるかを特定してください。

症状	考えられる原因	推奨事項
完全初期化が完了した後もレイテンシーが高いままです。	完全初期化中に増分変更のバックログが大量に蓄積された、ソースログの読み取りが遅い、またはターゲットへのキャッチアップ書き込みが遅い。	増分読み取りレート、書き込みレート、およびソースログの保持時間を監視し、レイテンシーが継続的に低下していることを確認してください。
リーダーの待機時間が長い。	ソースの変更量が急増した、大規模なトランザクション、ソースのログのバックログ、またはパーティション/シャードのスキュー。	ソースの書き込みスパイク、ログの増加、およびパーティションまたはシャードの分布を確認してください。
ライターの待機時間が長い。	ターゲットの書き込み性能が低い、レート制限、接続数が不足している、または動的パーティションが多すぎる。	ターゲットのリソース、書き込み QPS、バッチコミットレイテンシー、およびパーティション設計を確認してください。
フェールオーバーが頻発する。	メモリが不足している、外部サービスが不安定である、チェックポイントが失敗している、または DDL の処理エラーが発生している。	フェールオーバーの前後のログを確認してください。メモリ、リソース使用率、およびチェックポイントのメトリクスを分析し、問題を解決してください。
DDL イベントの後にレイテンシーが増加する。	DDL の処理に時間がかかる、またはターゲットでスキーマを変更できない。	DDL イベントとターゲットの権限を確認し、DDL の処理ポリシーが想定どおりであることを確認してください。

ソースが Kafka、DataHub、または LogHub の場合、通常、単一のパーティションまたはシャードは 1 つの同時実行プロセスでしか消費できません。データが一部のパーティションに集中している場合、タスク全体の同時実行数を増やしても効果がない可能性があります。

新しいテーブルの同期問題

新しいテーブルが同期されない場合は、次の項目を順に確認してください：

新しいテーブルが、現在のデータベースおよびテーブルの選択ルールに一致しているかどうかを確認してください。
テーブルマッピングが正常に更新されたかどうかを確認してください。
ターゲットでテーブルが作成されているか、スキーマ移行が完了しているかどうかを確認してください。
タスクが、実行中にテーブルを動的に追加する機能をサポートしているかどうかを確認してください。
該当テーブルのスキーマ移行、完全初期化、またはリアルタイムイベントの実行詳細を確認してください。

実行中にテーブルを動的に追加する機能をサポートしていないチャネルの場合は、構成を変更して再公開するか、新しいテーブルに対応するために新しいタスクを作成する必要があります。新しいテーブルで履歴データが必要な場合は、チャネルが完全初期化を実行するかどうかを確認してください。この機能がサポートされていない場合は、データバックフィル、または別の完全同期機能を使用してください。

チューニングの推奨事項

チューニング項目	シナリオ	推奨事項
フルロードリソース仕様 / コンピューティングユニット (CU)	完全初期化がキューイングされている、実行速度が低い、またはリソースグループの使用率が高い。	フルロードリソースを段階的に増やすか、オフピーク時間にタスクを実行します。フルロードの読み取りレート、書き込みレート、およびソースの負荷を監視します。
フルロードの同時実行数と分割キー	フルロードフェーズが実行されているが、全体的な速度が遅い。	均等に分散され、インデックスを持つ分割キーを選択します。同時実行数を適度に増やします。ソースの負荷が高い場合は、同時実行数を減らすか、レート制限を適用します。
ソース接続数 / クォータ	完全初期化で接続、クォータ、またはレート制限に関連するエラーが発生する。	同じソースからのタスクの同時実行数を減らします。または、ソースの容量に余裕がある場合は、接続数とクォータを増やします。
増分リソース仕様 / CU	CPU、メモリ、ネットワーク、またはリソースグループの使用率が高い。	リソースを段階的に増やします。レイテンシー、フェールオーバー、およびチェックポイントのパフォーマンスが改善されるかどうかを観察します。
増分の同時実行数	複数のテーブル、パーティション、またはシャードに十分な並列度がある。	まず、単一テーブルのホットスポットや単一シャードのボトルネックがないことを確認します。その後、同時実行数を増やします。
チェックポイント / フラッシュ間隔	ターゲットが頻繁にコミットするか、バッチコミットのオーバーヘッドが高い。	間隔をわずかに増やし、スループットとデータ可視性のレイテンシーを観察します。一度に大幅に増やさないでください。
ターゲットのバッチ書き込みパラメーター	ターゲットの待機時間が長い。	ターゲット製品の制約に合わせて、バッチ、フラッシュ、コミット、またはコネクションプールのパラメーターを調整します。
動的パーティションの粒度	ターゲットのパーティションが多すぎるか、フラッシュ圧力が高い。	パーティション粒度の調整を優先します。秒レベルのタイムスタンプ、注文 ID、ユーザー ID などの高カーディナリティフィールドをパーティショニングに使用することは避けてください。

説明

完全初期化と増分同期では、チューニングの目標が異なります。完全初期化は、履歴データの書き込みを安定的に完了することに重点を置きます。増分同期は、増分レイテンシーを継続的に解消することに重点を置きます。チューニング後は、少なくとも 1 つの安定した期間でパフォーマンスを観察してください。再起動後の短期的なスループットのみに基づいて効果を判断すると、誤解を招く可能性があります。

推奨されるリソース設定については、Data Integration の推奨 CU を参照してください。必要に応じて設定を調整してください。

よくある質問

以下の質問は、リアルタイム完全データベース同期タスクのトラブルシューティング履歴に基づいており、タスクフェーズごとに分類されています。トラブルシューティングを行う際は、まずタスクの現在のフェーズを確認してください。次に、タスクイベント、実行ログ、メトリクス、ソースログの保持期間、およびターゲットの結果を使用してクロス検証を行ってください。

スキーマ移行に関する問題

問題	主な確認項目	推奨される対処法
テーブルマッピングの更新が遅い、タイムアウトする、またはテーブルが選択できない	リソースグループの接続性、ソースのメタデータ権限、データベースとテーブルの数、フィールド数、ソースのオブジェクトタイプ、およびデータソースのキャッシュ	まず、データベースとテーブルの範囲を絞ってテストしてください。アカウントにデータベース、テーブル、フィールド、プライマリキー、およびインデックスを読み取る権限があることを確認してください。オブジェクトが選択できない場合、選択可能かどうかは現在のチャネルのサポート範囲によって決まります。

フル初期化に関する問題

問題	主な確認項目	推奨される対処法
フル初期化がスタックするか、開始に失敗する	リソースグループのキュー、ソースまたはターゲットの接続性、データソースのクォータ、フル初期化フェーズのリソース、およびターゲットでのテーブル作成の結果	まず、スキーマ移行が完了していることを確認してください。次に、フルサブタスクが開始されているかどうかを確認してください。クォータまたは接続数が不足している場合は、同時実行数を減らすか、ソースまたはターゲットのクォータを増やしてください。

増分同期に関する問題

問題	主な確認項目	推奨される対処法
フル初期化の完了後もリアルタイムレイテンシーが高いまま	フル初期化中に蓄積された増分データ、ソースログの読み取り速度、ターゲットの書き込み速度、チェックポイント、およびフェールオーバー	レイテンシーが継続的に減少しているかどうかを観察してください。減少しない場合は、読み取りオフセット、書き込み待機時間、チェックポイントの失敗、およびターゲットでのレート制限を確認してください。
停止後、タスクが以前のオフセットから再開できない	Binlog、先行書き込みログ (WAL)、メッセージログ、または消費オフセットの保持期間が期限切れになっていないかを確認してください。ソースインスタンスが再構築されたか、そのログがクリアされたかを確認してください。	タスクを停止する前に、ログの保持期間が予想されるダウンタイムをカバーしていることを確認してください。オフセットが利用できない場合、通常はオフセットをリセットするか、タスクを再初期化する必要があります。処理を進める前に、データの重複と損失のリスクを評価してください。
データ定義言語 (DDL) 操作後にタスクが失敗するか、レイテンシーが増加する	ソースが生成できる DDL 操作のタイプ、ターゲットがサポートする DDL 処理アクション、およびタスクの DDL 戦略と権限	DDL イベントとターゲットでのスキーマ変更の結果を確認してください。サポートされていない DDL 操作は無視しないでください。まず、ターゲットのスキーマとデータ整合性への影響を確認してください。
DELETE または UPDATE 操作後にターゲットのデータが正しくない	ターゲットにレコードを特定するためのプライマリキーまたは一意キーがあるかどうか。プライマリキーのマッピングに一貫性があるかどうか。書き込みモードが更新と削除をサポートしているかどうか。	ソースのプライマリキー、ターゲットのプライマリキー、テーブルマッピング、およびダーティデータログを確認してください。ターゲットに有効なプライマリキーがない場合、またはマッピングに一貫性がない場合、UPDATE および DELETE 操作が正しいターゲットレコードに適用されない可能性があります。

メッセージソースに関する問題

問題	主な確認項目	推奨される対処法
Kafka、DataHub、LogHub などのメッセージソースからの高いレイテンシー	パーティション、シャード、またはトピックのホットスポットを確認してください。消費の同時実行数が並列で消費できるパーティション数を超えていないかを確認してください。消費オフセットが大幅に遅れていないかを確認してください。	まず、単一のパーティションまたはシャードのボトルネックを確認してください。ホットスポットが集中している場合、全体の同時実行数を増やしても効果がない可能性があります。代わりに、ソースのパーティションまたはターゲットの書き込み能力を調整してください。

ターゲットへの書き込みに関する問題

問題	主な確認項目	推奨される対処法
パーティション数が過剰なため、MaxCompute などのターゲットへの書き込みが遅い	動的パーティションフィールドの粒度、単一のチェックポイント内のパーティション数、Tunnel またはコミット時間、およびターゲットのレート制限	パーティションの粒度を減らすか、高カーディナリティのフィールドをパーティショニングに使用しないようにしてください。次に、ターゲットの能力に基づいて、バッチコミット、パーティションキャッシュ、およびリソースの仕様を調整してください。

データ整合性に関する問題

問題	主な確認項目	推奨される対処法
新しいテーブルを追加した後、履歴データが同期されない	新しいテーブルが選択ルールに一致しているかを確認してください。テーブルマッピングが正常に更新されたかを確認してください。チャネルが新しいテーブルのフル初期化をサポートしているかを確認してください。新しいテーブルが増分同期のみに設定されているかを確認してください。	履歴データが必要な場合は、新しいテーブルに対してフル初期化が有効になっているか、トリガーされていることを確認してください。これがサポートされていない場合は、データバックフィルプロセスまたは個別の完全同期タスクを使用して履歴データを投入してください。
ランタイム中またはソースでテーブルが削除された後、データが不整合になる	削除されたテーブルがタスクのルールにまだ一致しているかを確認してください。DDL 戦略が DROP TABLE をどのように処理するかを確認してください。ターゲットテーブルに対するダウンストリームの依存関係を確認してください。	ランタイム中にテーブルを削除する前に、ビジネスプロセスがそれに依存していないことを確認してください。ソースでテーブルを削除しても、ターゲットで自動的にクリーンアップされるわけではありません。必要に応じて、データガバナンスポリシーに従ってターゲットテーブルを個別に管理してください。
異常な量のダーティデータが生成される	タスクがダーティデータを許容するように設定されているかを確認してください。フィールドタイプ、長さ、プライマリキー、非 NULL 制約、またはターゲットの書き込み制限への変更を確認してください。	タスクを続行できるようにするために、単にダーティデータのしきい値を増やさないでください。まず、ダーティデータがターゲットでデータの欠落やフィールドの異常を引き起こすかどうかを判断してください。次に、データを修正するか、マッピングを調整するか、一時的にエラーを許容するかを決定してください。

PostgreSQL 固有の問題

問題	主な確認項目	推奨される対処法
PostgreSQL のソースで WAL ファイルが蓄積する	レプリケーションスロットの遅延、消費オフセット、チェックポイント、およびタスクがオフセットを正しくコミットしているかどうか	タスクが正常にデータを消費しているにもかかわらず WAL サイズが減少しない場合は、レプリケーションスロットの遅延とオフセットのコミットステータスを確認してください。これにより、ソースのディスクが WAL ファイルで満杯になることを防ぎます。

高リスク操作チェックリスト

テーブルの削除、多数のテーブルの追加、タスクの再起動、完全初期化の再実行、またはパラメーターの大幅な調整を行う前に、このチェックリストの各項目を確認してください。チェックに失敗した場合は、推奨される対処を実施してから続行してください。

ソースのログ保持期間は、完全初期化と増分キャッチアップに十分な長さですか。
ターゲットに既存データまたは下流の依存関係がある場合、完全初期化を再実行する前に、明確な上書き、追加、またはクリーンアップ戦略が用意されていますか。
新しいテーブルに履歴データは必要ですか。また、現在のチャネルはそれらの完全初期化をサポートしていますか。
未処理のデータ定義言語 (DDL) ステートメント、またはフェールオーバーの頻発はありませんか。
アラートは、タスクのステータス、完全初期化の例外、ビジネスレイテンシー、フェールオーバー、DDL をカバーしていますか。