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

前提条件

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

許可要件

ソースアカウント：データベース、テーブル、列、プライマリキー、インデックスなどのメタデータを読み取る権限が必要です。また、Binlog、WAL (Write-Ahead Logging)、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、またはメッセージログが削除され、タスクが最後に保存されたオフセットから再開できなくなる可能性があります。タスクを再開すると、最後に保存されたオフセットから続行されます。オフセットが期限切れになっている場合は、オフセットのリセットまたはタスクの再初期化のリスクを評価する必要があります。詳細については、FAQ セクションの「停止後にタスクを以前のオフセットから再開できない」をご参照ください。

設定の変更

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

変更タイプ	リスク	推奨事項
テーブルの追加	メタデータの再読み取りが必要であり、チャネルの機能によっては、スキーマ移行、完全初期化、および増分同期が実行される可能性があります。	新しいテーブルが選択ルールと一致していることを確認してから、テーブルマッピングを更新してください。新しいテーブルの完全初期化の進捗、増分オンボーディングステータス、およびソースのログ保持を監視してください。
テーブルの削除	実行中のタスクからテーブルを削除すると、既存のテーブルマッピング、ターゲットデータ、およびダウンストリームの依存関係に影響を与える可能性があります。	テーブルを削除する前に、それに依存するビジネスプロセスがないことを確認してください。必要に応じて、更新された範囲を処理するための新しいタスクを作成してください。
マッピングルールの変更	ターゲットのテーブル名の競合、カラムの欠落、パーティションの変更、または既存データの処理方法の変更が発生する可能性があります。	送信する前に、ターゲットのテーブル名、カラムタイプ、プライマリキー、パーティション、追加カラム、およびターゲット上の既存データを確認してください。
リソースの調整	リソースの割り当て、同時実行数、および接続数は、完全初期化と増分同期で異なります。不適切な調整は、ソースまたはターゲットへの負荷を増加させる可能性があります。	リソースを段階的に調整してください。各変更後、完全初期化の速度、リアルタイムレイテンシー、フェールオーバー、チェックポイント、およびリソース使用率を監視してください。

設定変更の有効化方法：

テーブルマッピングの更新と新しいテーブルの追加は、通常、タスクを一時停止する必要はありません。
CU (Compute Unit) などのリソース仕様の調整には、タスクの再起動または次のチェックポイントまで待機する必要がある場合があります。画面のプロンプトに従ってください。
転送中のデータに影響を与えないよう、タスクを一時停止してからマッピングルールを変更してください。
設定変更が失敗した場合は、以前の設定に元に戻して再送信してください。

アラート設定

リアルタイムフルデータベース同期タスクの場合、少なくとも次のイベントに対してアラートを設定してください。

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

MySQL や PostgreSQL などのログベースのソースの場合は、Binlog や WAL などのログ保持期間も監視して、ログの期限切れによるタスク回復の失敗を防止してください。

アラートルールの設定に関する詳細な手順については、「一般的なアラートルール」をご参照ください。

トラブルシューティング

スキーマ移行の失敗

スキーマ移行の失敗は、通常、権限の問題、メタデータ読み取りエラー、データ型の不一致、またはターゲットでのテーブル作成の問題が原因です。次の順序でトラブルシューティングを実行してください。

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

正規表現または一括でテーブルを選択する場合は、同期範囲を拡大する前に、まず少数のテーブルでテストしてください。

フル初期化の遅延または失敗

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

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

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

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

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

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

新規テーブルの同期失敗

新規テーブルが同期されていない場合は、次の順序で確認してください。

新規テーブルが、現在のデータベースとテーブルの選択ルールに一致しているかを確認してください。
テーブルマッピングが正常に更新されたかどうかを確認してください。
ターゲットでテーブルが作成されたか、またはスキーマが移行されたかを確認してください。
タスクが実行時にテーブルを動的に追加することをサポートしているかどうかを確認してください。
対応するテーブルのスキーマ移行、フル初期化、またはリアルタイムイベントの実行の詳細を確認してください。

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

チューニングの推奨事項

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

説明

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

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

よくある質問

次の質問は、リアルタイムのフルデータベース同期タスクに関するトラブルシューティング履歴から抽出し、タスクフェーズ別に整理したものです。トラブルシューティングを行う際は、まずタスクの現在のフェーズを確認してください。次に、タスクイベント、実行ログ、メトリクス、ソースログの保持期間、ターゲットの結果を使用してクロスチェックしてください。

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

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

完全初期化に関する問題

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

増分同期に関する問題

問題	確認すべき主な項目	推奨アクション
完全初期化の完了後もリアルタイムレイテンシーが高いままである	完全初期化中に蓄積された増分データ、ソースログの読み取り速度、ターゲットの書き込み速度、チェックポイント、フェールオーバー	レイテンシーが継続的に低下しているかどうかを確認してください。低下していない場合は、読み取りオフセット、書き込み待機時間、チェックポイントの失敗、およびターゲットでのレート制限を確認してください。
タスクを停止した後に、以前のオフセットから再開できない	Binlog、先行書き込みログ (WAL)、メッセージログ、または消費オフセットの保持期間が失効していないかどうかを確認してください。ソースインスタンスが再構築されたか、またはログがクリアされたかどうかを確認してください。	タスクを停止する前に、ログ保持期間が想定される停止時間をカバーしていることを確認してください。オフセットを使用できない場合は、通常、オフセットをリセットするか、タスクを再初期化する必要があります。続行する前に、データの重複とデータ損失のリスクを評価してください。ターゲットが MaxCompute Delta テーブルの場合、テーブルはプライマリキーでデータを重複排除するため、オフセットをリセットした後も、すでに同期済みの範囲のデータは再度書き込まれません。Delta テーブルは、PRIMARY KEY 宣言と `transactional=true` プロパティを指定して作成されます。テーブルが Delta テーブルかどうかを確認するには、`SHOW CREATE TABLE table_name` を実行し、出力に両方が含まれていることを確認してください。
データ定義言語 (DDL) 操作の後にタスクが失敗する、またはレイテンシーが増加する	ソースが生成できる DDL 操作の種類、ターゲットがサポートする DDL 処理アクション、タスクの DDL 戦略と権限	DDL イベントと、ターゲットでのスキーマ変更結果を確認してください。サポートされていない DDL 操作を無視しないでください。まず、ターゲットのスキーマとデータ整合性に与える影響を確認してください。
DELETE または UPDATE 操作の後にターゲットデータが正しくない	ターゲットにレコードを特定するためのプライマリキーまたは一意キーがあるかどうか。プライマリキーのマッピングが一貫しているかどうか。書き込みモードが更新と削除をサポートしているかどうか。	ソースのプライマリキー、ターゲットのプライマリキー、テーブルマッピング、およびダーティデータログを確認してください。ターゲットに有効なプライマリキーがない場合やマッピングに一貫性がない場合、UPDATE と DELETE 操作が正しいターゲットレコードに適用されない可能性があります。

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

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

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

問題	確認すべき主な項目	推奨アクション
パーティション数が多すぎるため、MaxCompute などのターゲットへの書き込みが遅い	動的パーティションフィールドの粒度、1 つのチェックポイント内のパーティション数、Tunnel またはコミット時間、ターゲットのレート制限	パーティションの粒度を下げるか、パーティション分割に高カーディナリティフィールドを使用しないでください。次に、ターゲットの機能に基づいて、バッチコミット、パーティションキャッシュ、およびリソース仕様を調整してください。
動的パーティション数が多すぎることによるチェックポイントのタイムアウト、またはメモリ不足 (OOM) エラー	1 つのチェックポイント内でコミットされる動的パーティション数 (数百に達しているかどうかなど)、パーティションのメタデータ連携時間、タスクのメモリ使用量とガベージコレクション、チェックポイントの所要時間と失敗記録	タスクに多数の動的パーティションが含まれる場合、一度にコミットするパーティション数が多すぎると、メタデータ連携のオーバーヘッドとメモリ使用量が増加し、チェックポイントのタイムアウト、またはメモリ不足 (OOM) エラーにつながる可能性があります。同期設定を調整し、すべての履歴データを前日のパーティションなど、指定した 1 つの静的パーティションに書き込み、タスク開始後に生成されたデータのみを新しい動的パーティションに書き込むようにしてください。これにより、1 つのチェックポイントでコミットされるパーティション数が過多になることを防止できます。詳細については、チューニングの推奨事項セクションの「Dynamic partition granularity」をご参照ください。

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

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

PostgreSQL 固有の問題

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

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

テーブルの削除、多数のテーブルの追加、タスクの再起動、完全初期化の再実行、または主要なパラメーターの変更を行う前に、このチェックリストの各項目を確認してください。チェックに失敗した場合は、先に進む前に推奨されるアクションを実行してください。

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