データベース全体のオフライン同期には、スキーマ移行、完全同期、オフライン増分同期など、複数の段階が含まれます。多数のテーブルと高密度のスケジュールされたインスタンスにより、運用保守は複雑になります。このトピックでは、タスクの開始と停止、設定の変更、データバックフィルのためのタスクの再実行など、主な運用保守操作について説明します。また、これらのタスクを効率的に管理するためのトラブルシューティング方法とチューニングの推奨事項も提供します。これらのタスクの設定方法については、「データベース全体のオフライン同期タスクの設定」をご参照ください。
適用性
データベース全体のオフライン同期に関する問題をトラブルシューティングする前に、タスクタイプ、チャネルの機能、およびトラブルシューティングの焦点を評価して、このトピックがお客様のシナリオに適用されることを確認してください。
基準 | 適用シナリオ | 適用外のシナリオ/主な焦点 |
タスクタイプ | データベース全体または複数テーブルのオフラインバッチ同期：1 回限りの完全同期、定期的な完全同期、またはフィールド値を使用して増分条件を定義する定期的な増分同期。 | リアルタイム CDC またはメッセージ消費タスク。オフラインのトラブルシューティング方法は適用されません。 |
典型的なチャネル | ソース：データベース、データウェアハウス、またはファイルからのオフライン読み取り。 送信先：MaxCompute、Hologres、Hive、DLF、Elasticsearch、StarRocks など。 | 安定した増分フィールドが利用できない場合、タスクをオフライン増分同期タスクとして扱わないでください。 |
トラブルシューティングの焦点 | スケジュールされたインスタンス、業務日付、WHERE 条件、 | リアルタイムのログオフセットやフェイルオーバーは含まれません。 |
データベース全体のオフライン同期は、オフラインの読み取りおよび書き込み機能に依存します。Binlog、WAL、または Oplog には依存せず、リアルタイムのログオフセット回復セマンティクスは提供しません。
タスクの段階
データベース全体のオフライン同期には、通常、次の段階が含まれます。各段階には異なる運用保守の優先事項があります。
段階 | 説明 | 運用保守の焦点 |
スキーマ移行 | ソースからテーブルスキーマを読み取り、送信先でテーブルを作成または更新します。 | メタデータ権限、送信先テーブルの作成権限、フィールドタイプのマッピング、およびテーブル名のマッピング。 |
1 回限りの完全同期 | ソースの履歴データをバッチで送信先に書き込みます。 | 分割キー、オフライン同時実行数、ソース接続、送信先の書き込み容量、およびリソース仕様。 |
定期的なオフライン増分同期 | スケジューリングサイクルに基づいて、新規または変更されたデータを同期します。 | スケジューリング時間、上流依存関係、業務日付パラメーター、送信先パーティション、および出力名。 |
オフライン増分同期は、更新タイムスタンプや自動インクリメントフィールドなど、増分データを識別するフィールドに依存します。ソーステーブルに安定した増分フィールドがない場合、通常はオフライン増分同期を設定する前に、定期的な完全同期を実行するか、ソーステーブルを変更する必要があります。
データベース全体のオフライン同期タスクは、通常、複数のオフラインサブタスクを生成します。テーブル数が増加するにつれて、スケジュールされたインスタンス、リソース消費、および送信先への書き込み負荷が大幅に増加します。
運用保守操作
タスクの開始と停止
1 回限りの完全同期タスクを送信した後、完全同期サブタスクを監視して、それらが正常に実行されていることを確認します。定期的なオフラインタスクの場合、スケジュールされたインスタンスが期待どおりに生成されているか、上流依存関係が満たされているか、および業務日付が正しいかどうかも確認する必要があります。
タスクを停止する前に、一部のテーブルまたはパーティションのデータが既に送信先に書き込まれているかどうかを確認します。送信先に書き込むタスクが上書きまたはパーティションクリア戦略を使用している場合、タスクを再実行する際には、べき等性と同時上書きの問題に注意してください。
一時停止、再開、データバックフィルなどの一般的なタスクスケジューリングおよび管理操作については、「オフライン同期タスクの運用保守」をご参照ください。
設定の変更
データベース全体のオフライン同期タスクの一般的な変更には、テーブルの追加または削除、テーブルマッピングの調整、パーティションルール、スケジューリング設定、同時実行数、およびリソースの調整が含まれます。
変更タイプ | 潜在的なリスク | 推奨事項 |
テーブルの追加 | テーブルを追加するには、スキーマ移行とスケジュールされたインスタンスの生成が必要です。 | 変更を送信した後、新しいテーブルに対応するオフラインタスクまたはインスタンスが生成されていることを確認します。 |
テーブルの削除 | 既存のスケジューリングノードと下流の依存関係に影響を与える可能性があります。 | 削除する前に、下流のコンシューマーが対応する出力に依存しなくなったことを確認します。 |
パーティションルールの変更 | データが新しいパーティションに書き込まれたり、間違ったパーティションを上書きしたりする可能性があります。 | 送信する前に、業務日付パラメーターと送信先パーティションの式を確認します。 |
スケジューリングの変更 | 上流依存関係と下流の出力時間に影響を与える可能性があります。 | 変更後、新しい時刻に定期的なインスタンスが生成されるかどうかを確認します。 |
同時実行数とリソースの調整 | ソース接続、送信先への書き込み、およびリソースグループへの負荷が増加する可能性があります。 | 段階的に調整し、ソース、送信先、およびリソースグループの負荷を監視します。 |
タスクの再実行とデータバックフィル
タスクの再実行やデータバックフィルにより、不足している送信先パーティションを修正できます。これらの操作を実行する前に、以下を確認してください：
どのテーブルと業務日付の範囲を修正する必要があるか。
送信先の書き込みモード (追記、上書き、または切り捨てて書き込み)
他のインスタンスが現在、同じ送信先テーブルまたはパーティションに書き込みを行っているかどうか。
下流タスクが既に不正なデータを消費していないか。
現在のタスクが再実行された後、下流タスクも再実行する必要があるか。
送信先の書き込みモードがパーティションをクリアする場合、同じパーティションに同時に書き込む複数のタスクを実行しないでください。必要に応じて、まず競合するインスタンスを一時停止するか、実行時間をずらしてください。
データバックフィル機能の使用方法の詳細については、「バックフィルインスタンスの運用保守」をご参照ください。
トラブルシューティング
テーブルマッピングの更新失敗または選択不可能なテーブル
一般的な原因には、ソースの権限不足、リソースグループのネットワーク問題、ソースメタデータの過剰な量、広すぎるテーブルフィルター範囲、選択されたテーブルが多すぎること、または送信先の権限不足が含まれます。以下の順序でトラブルシューティングを行ってください：
タスク設定のリソースグループを使用して、ソースと送信先の接続性を再テストします。
ソースアカウントにデータベース、テーブル、およびフィールドのメタデータを読み取る権限があることを確認します。
テーブルフィルターの範囲が広い場合や、多くのテーブルが選択されている場合は、まず範囲を絞って接続性を検証します。
送信先アカウントにテーブル作成または書き込み権限があるかどうかを確認します。
ソーステーブルの数が多すぎる場合は、メタデータインターフェイスのタイムアウトを確認します。
スキーマ移行の失敗
スキーマ移行が失敗した場合、まず送信先テーブルの作成権限、送信先データベースまたはスキーマの存在、フィールドタイプの互換性、テーブル名マッピングの競合を確認します。パーティションテーブルの場合は、パーティションフィールド、パーティション階層、パーティション式が送信先の制約を満たしていることも確認します。
完全同期タスクの実行が遅い
確認項目 | 識別方法 | 推奨アクション |
ソースクエリが遅い | ソースデータベースでの高い CPU、I/O、遅い SQL クエリ、またはロック待機。 | ソースクエリを最適化し、ビジネスのピーク時間を避け、必要に応じて同時実行数を減らします。 |
不均等な分割 | 一部のサブタスクの完了に著しく長い時間がかかります。 | より適切な分割キーを選択するか、大きなテーブルを個別に処理します。 |
低い同時実行数 | ソースと送信先の負荷が低いにもかかわらず、スループットが低い。 | オフラインの同時実行数とリソース仕様を段階的に増やします。 |
接続不足 | ログに接続またはクォータの不足が示されています。 | ソースの最大接続数またはデータソースのクォータを増やし、ソースデータベースの安定性を監視します。 |
送信先への書き込みが遅い | 送信先でのスロットリング、多すぎるパーティション、または遅いバッチコミット。 | まず、送信先のリソースの問題、スロットリング、およびパーティション設計に対処します。 |
リソース不足 | CPU、メモリ、またはネットワークの使用率が上限に近づいています。 | リソース仕様または CU を増やし、ガベージコレクション (GC) と障害率を監視します。 |
データベース全体のオフライン同期をチューニングする際、最初から同時実行数を大幅に増やさないでください。同時実行数を増やすと、ソースの接続数、送信先への書き込み負荷、およびリソースグループの消費も増加します。ボトルネックがソースまたは送信先にある場合、同時実行数を増やすと通常は問題が悪化します。
一般的なデータ同期が遅いシナリオの解決策については、「オフライン同期の高速化または速度制限」をご参照ください。
定期的なインスタンスが出力を生成しない
定期的なオフラインインスタンスが出力を生成しない、または不正な出力を生成する場合、以下の項目を順に確認してください：
定期的なスケジューリングが有効になっており、スケジューリング時間が正しいか。
上流依存関係が完了しているか。
業務日付パラメーターが正しいか。
出力名と送信先パーティションの式が正しいか。
送信先で書き込みの失敗や権限の問題がないか。
下流タスクが間違った出力またはパーティションに依存していないか。
オフライン増分インスタンスのデータ範囲は、その増分条件とスケジューリングパラメーターによって決まります。定期的なインスタンスのトラブルシューティングを行う際は、[増分条件フィールド] が存在するか、[フィールドタイプ] が比較可能か、[スケジューリングパラメーター] が送信先パーティションまたは WHERE フィルター条件に正しく渡されているかを確認します。
チューニングの推奨事項
チューニング項目 | 推奨事項 |
合計 CU | テーブル数が多い場合や並列サブタスクが多い場合は、合計リソースを増やします。ソースまたは送信先がスロットリングされている場合、CU のみを増やしても効果は限定的です。 |
タスクごとの CU | 幅の広いテーブル、大きなカラム、または単一テーブルのデータ量が多い場合は、タスクごとのリソースを増やします。 |
オフライン同時実行数 | ソースの接続容量と送信先の書き込み容量に基づいて、段階的に増やします。 |
最大ソース接続数 | オフラインの同時実行数と連携して調整します。この値を高く設定しすぎると、ソースデータベースの安定性に影響を与える可能性があります。 |
レート制限設定 | レート制限が有効な場合、スループットは意図的に削減されます。チューニングの前に、レート制限を無効にするか、引き上げる必要があるかを確認します。 |
パーティション設計 | 過度に細かい粒度のパーティションは避けてください。これは、小さなファイル、多すぎるパーティション、または過剰な書き込みオーバーヘッドにつながる可能性があります。 |
多数のテーブルを含むデータベース全体のオフライン同期タスクでは、大きなテーブル、幅の広いテーブル、および小さなテーブルごとにグループ化して観察します。少数の大きなテーブルが全体の完了時間を決定することがあり、平均スループットは実際のボトルネックを反映しません。
同時実行数とレート制限の関係の詳細については、「オフライン同期における同時実行数とレート制限の関係」をご参照ください。
アラートと監視
データベース全体のオフライン同期タスクでは、スケジューリングとオフラインインスタンスのアラートに焦点を当てます。通常、アラートは運用保守センターで生成された定期的なサブタスクまたはオフラインインスタンスに対して設定する必要があります。メインのソリューションタスクのステータスだけに依存すべきではありません。
以下のアラートルールを設定します：
[インスタンス失敗]：タスクの実行が失敗したときに直ちにアラートを発します。
[インスタンスタイムアウト]：タスクの実行が想定より長くかかった場合にアラートを発します。
[上流依存関係が不完全]：依存する上流タスクが時間内に完了しない場合にアラートを発します。
[定期インスタンス未生成]：スケジューリングサイクルが開始された後、インスタンスが生成されない場合にアラートを発します。
[ターゲットパーティション未生成]：期待される送信先パーティションが時間内に生成されない場合にアラートを発します。
[ソース/送信先接続失敗]：データソースの接続例外についてアラートを発します。
下流タスクのデータの適時性が重要な場合、インスタンスのタイムアウトと出力検証に関するアラートを設定する必要があります。失敗アラートのみを設定しても、タスクが長時間実行されても適時に出力を生成しないケースは検出できません。
アラートルールの設定方法に関する具体的な手順については、「データベース全体のオフライン同期タスクの設定 > ステップ 6：アラートルールの設定」をご参照ください。
ハイリスク操作のチェックリスト
タスクの再実行、データバックフィル、テーブルの削除、パーティションルールの変更、または同時実行数の大幅な増加などの大規模な操作を実行する前に、以下を確認してください：影響を受けるテーブルと業務日付、送信先の書き込みモードとその上書きまたはデータクリアの可能性、同じ送信先への同時書き込みの有無、下流タスクがデータを消費したかどうか、ソースと送信先がより高い同時実行数を処理できる能力、および下流タスクも再実行する必要があるかどうか。
よくある質問
以下の質問は、データベース全体を同期する定期的なタスクのトラブルシューティング事例から蓄積されたものです。トラブルシューティングを行う際は、まずタスクタイプ、ソース、および送信先を確認し、次にページ設定、スケジュールされたインスタンス、実行ログ、および送信先の結果を相互に確認してください。
テーブルを再追加した後の古いインスタンスの停止
トラブルシューティング：テーブルを削除して更新を適用した後、後続の定期的なスケジューリングノードは無効になります。既に生成されているか実行中のインスタンスが自動的に停止するとは考えないでください。
緩和策：書き込みを直ちに停止する必要がある場合は、運用保守センターで対応する定期的なインスタンスのステータスを確認してください。必要に応じて、テーブルの追加、再実行、またはデータバックフィルを行う前に、関連するインスタンスを手動で停止または一時停止してください。
新しいテーブルの不正な送信先
トラブルシューティング：スキーマ、データベース名、またはテーブル名のマッピングルールが変更されたかどうかを確認します。新しいテーブルがデフォルトのマッピングを使用したかどうかを確認してください。
緩和策：新しいテーブルが異なる送信先に書き込まれるのを防ぐために、スキーマ、データベース名、またはテーブル名のマッピングルールを確認して設定してください。
テーブルマッピングの更新失敗または選択不可能なテーブル
トラブルシューティング：リソースグループの接続性、ソースメタデータのクエリ遅延、選択されたテーブルの数、およびソースアカウントの権限を確認してください。
緩和策：まず、データベースとテーブルの範囲を絞って検証します。データソースの接続パラメーターとソースメタデータのクエリパフォーマンスを確認してください。オブジェクトが選択できない場合、ページに表示されるサポート範囲が正となります。
増分条件の結果が不一致
トラブルシューティング：増分条件が変更されたかどうか、スケジューリングパラメーターが業務日付または実行時間に基づいて計算されているか、および送信先パーティションとフィルター条件が同じパラメーターセットを使用しているかを確認してください。
緩和策：増分条件、スケジューリングパラメーター、および送信先パーティションの式を同時に確認してください。データをバックフィルする際は、業務日付の範囲を確認してください。
上流依存関係を待機している定期的なインスタンス
トラブルシューティング：詳細パラメーターに余分な上流ノード ID または上流ノード名ルールが設定されているかどうかを確認してください。
緩和策：不要な上流依存関係の設定をクリアし、タスクを再公開してから、インスタンスの依存関係を観察してください。
送信先パーティションの出力がない、または異常
トラブルシューティング：パーティションカラムが実際に存在するか、パーティション式が正しいか、およびパーティション階層、大文字小文字、スペースが送信先の要件を満たしているかを確認してください。
緩和策：送信先テーブルのメタデータと定期的なパラメーターを確認してください。必要に応じて、まず単一のテーブルまたは少数のテーブルを使用してパーティションの書き込みを検証してください。
出力名の競合または特殊文字
トラブルシューティング：スケジューリングノードの出力名ルールが重複した出力を生成したり、送信先スケジューラでサポートされていない特殊文字を含んだりしていないか確認してください。
緩和策：$ などの特殊文字の使用を避けるように出力名ルールを調整してください。保存して公開した後、下流の依存関係を確認してください。
ビューまたは特殊なオブジェクトが選択できない
トラブルシューティング：ソースオブジェクトのタイプが、データベース全体のオフライン同期のための現在のチャネルでサポートされているかどうかを確認してください。
緩和策：ページ上で選択可能なオブジェクトのみがサポートされています。サポートされていない場合は、単一テーブルのオフライン同期タスクを使用するか、同期前にビューの結果を物理テーブルにマテリアライズしてください。
splitPk が無効、またはデータ分散が不均等
トラブルシューティング：分割キーのフィールドタイプがデータソースとチャネルでサポートされているか、データ分散が均等か、および多数の NULL 値がないかを確認してください。
緩和策：より均等に分散された、サポートされている分割キーフィールドを使用してください。大きなテーブルは個別に処理して、個別にチューニングできます。
分割キーの制限の詳細については、「データベース全体のオフライン同期タスクの設定 > クォータと制限」をご参照ください。
詳細情報
データベース全体のオフライン同期タスクの設定 — データベース全体のオフライン同期タスクを設定するための完全なプロセス
オフライン同期の高速化または速度制限 — 一般的なデータ同期が遅いシナリオの解決策
オフライン同期における同時実行数とレート制限の関係 — チャネル制御で同時実行数とレート制限を設定する方法の説明