DataWorks:リアルタイム同期 FAQ

サポートされるデータソース

サポートされるデータソースの一覧については、「リアルタイム同期でサポートされるデータソース」をご参照ください。

リアルタイム同期タスクの高遅延

データが送信先テーブルに同期されない場合は、リアルタイム同期タスクの同期遅延が高くなっている可能性があります。遅延値は、オペレーションセンター内の「リアルタイムコンピューティングノード」ページで確認できます。詳細については、「リアルタイム同期タスクの高遅延を解消する方法」をご参照ください。

高遅延の原因として、以下が考えられます。

パブリックネットワーク使用時のリスク

リアルタイム同期タスクでインターネットを使用すると、以下のリスクがあります。

• ネットワークが不安定になりやすく、パケット損失などの頻繁な障害が同期パフォーマンスに影響を与えます。

• セキュリティレベルが低くなります。

リアルタイム同期におけるカラムフォーマット

Data Integration が MySQL、Oracle、LogHub、PolarDB から DataHub または Kafka へリアルタイムでデータを同期する場合、送信先に 5 つの追加カラムが自動的に追加されます。これらのカラムは、メタデータ管理、ソート、重複排除に使用されます。「リアルタイム同期におけるカラムフォーマット」をご参照ください。

TRUNCATE 操作の処理

リアルタイム同期では、増分およびフル・インクリメンタルマージ時に有効となる TRUNCATE 操作をサポートしています。TRUNCATE 操作を無視するように設定した場合、リアルタイム同期中に冗長なデータが発生する可能性があります。

同期速度およびパフォーマンスの向上

同期書き込み速度が遅い場合は、書き込み側の同時実行数を増加させたり、JVM パラメーターを調整したりできます。JVM パラメーターは、同期対象のライブラリ数ではなく、変更の頻度に応じて設定します。現在のリソースグループ内のマシンに十分なリソースがある場合、メモリ割り当て量を増やすことで Full GC の頻度を減らし、リアルタイム同期のパフォーマンスを向上させることができます。

コンソールからのタスク実行

リアルタイム同期タスクを DataWorks UI から直接実行することはできません。タスクを構成した後は、リアルタイムノードを提出およびデプロイし、本番環境で実行する必要があります。「リアルタイム同期タスクの運用と保守」をご参照ください。

MySQL での同期速度低下

速度低下の原因として、処理対象のバイナリログ数の増加が考えられます。バイナリログはインスタンス単位で生成されます。たとえ同期タスクが Table A のみを対象としているとしても、Table B や Table C などの他のテーブルの変更によってもバイナリログが生成されます。こうした追加のバイナリログが同期プロセスを遅くする可能性があります。

メモリ使用量：単一データベース vs. 複数データベース

2 つ以上のデータベースを選択すると、タスクは「フルインスタンス」リアルタイム同期モードに入ります。このモードでは、それぞれ単一のデータベースを同期する 2 つの別々のリアルタイムタスクを実行する場合よりも多くのリソースを消費します。

DDL 変更ポリシー

処理方法：

DDL の種類：

DDL および DML の考慮事項

• ソース側でカラムを追加し、送信先で正常に処理された後、以下の制限が適用されます。

  • DEFAULT VALUE を持つカラムを追加した場合、送信先テーブルの該当カラムは NULL のままになります。その後、ソース側でこのカラムに新しいデータが追加されると、リアルタイム同期タスクがそのデータを同期します。

  • VIRTUAL カラムを追加した場合、送信先テーブルの該当カラムは NULL のままになります。その後、ソース側でこのカラムに新しいデータが追加されると、リアルタイム同期タスクがそのデータを同期します。

• MySQL または PolarDB for MySQL をソースとするリアルタイム同期を行う場合、新しいカラムはテーブルの末尾に追加し、途中に挿入しないでください。やむを得ず途中に挿入する必要がある場合は、以下の制約に注意してください。

  • フルおよび増分同期ソリューションにおいては、フル同期フェーズ中にテーブルの途中にカラムを追加しないでください。そうすると、リアルタイム同期フェーズでデータの異常が発生する可能性があります。

  • リアルタイム同期フェーズ中は、カラム追加の DDL イベント以降の時点に同期オフセットをリセットする必要があります。そうしないと、その後のリアルタイムデータ同期で異常が発生する可能性があります。

• データの異常が発生した場合は、フルデータロードを実行してテーブルを再初期化できます。

PostgreSQL でのフェールオーバー後の高遅延

これは PostgreSQL 固有の動作です。この遅延が許容できない場合は、タスクを停止して再起動することで、フルおよび増分データ同期を再度トリガーできます。

フル同期の実行

Data Integration で、既存のタスクを「同期タスク」リストから見つけます。操作列で、その他 > 再実行をクリックします。

MySQL タスクがデータの読み取りを停止した場合

1. データベースで以下のコマンドを実行し、インスタンスが現在書き込んでいるバイナリログファイルを確認します。

   show master status 

2. この結果とタスクが読み込んでいるバイナリログファイルを比較します。タスクログを検索し、journalName=MySQL-bin.000001,position=50 のようなエントリを確認して、データがデータベースに書き込まれているかどうかを判断します。

3. データが書き込まれているにもかかわらずバイナリログが進行していない場合は、データベース管理者にご相談ください。

タスクが繰り返し失敗する場合

• 症状：リアルタイム同期タスクが繰り返し失敗する。

  ソースが Oracle、PolarDB、または MySQL データソースの場合、ソース側から送信される DDL メッセージはデフォルトで処理されません。`CREATE TABLE` 以外の DDL 変更が発生すると、リアルタイムタスクが失敗します。再開機能により、ソース側で DDL メッセージが存在しなくなった後でも、タスクは引き続き失敗することがあります。

  説明

  データ損失または破損を防ぐため、Column A と Column B の名前を入れ替えるなど、Rename コマンドを使用しないでください。

• 原因：再開機能は、再起動時にわずかに前のオフセットから読み込むことでデータ損失を防止します。このプロセスにより、以前の DDL メッセージが再読み込みされ、タスクが再び失敗する可能性があります。

• 解決方法：

  1. ソース側で DDL 変更が発生した場合、同じ変更を送信先データベースに手動で適用します。

  2. リアルタイム同期タスクを起動し、DDL メッセージの処理ポリシーを エラー報告 から 無視 に変更します。

     説明

     この変更は一時的なものであり、再開機能による DDL イベントの再読み込み時にタスクが再び失敗することを防ぐために行います。

  3. リアルタイム同期タスクを停止し、DDL メッセージの処理ポリシーを 無視 から エラー報告 に戻してから、タスクを再起動します。

Kafka 同期エラー： コンシューマーの起動モードが timestampOffset に設定されていますが、開始タイムスタンプが指定されていません。

開始オフセットをリセットします。

Data Integration の オフセットのリセット 機能を使用すると、データ同期の開始ポイントを再定義できます。特定の時刻またはデータ位置から同期を再開する必要がある場合に、この機能を利用します。たとえば、エラーが発生した場合や、一部のデータを再同期する必要がある場合に、オフセットをリセットすることで、指定した位置から再開でき、データ整合性および完全性を確保できます。

MySQL 同期エラー：必要なバイナリログがマスターによってパージされたため、レプリケーションできません。

MySQL リアルタイム同期中に 必要なバイナリログがマスターによってパージされたため、レプリケーションできません。欠落したトランザクションを他の場所からレプリケートするか、バックアップから新しいスレーブをプロビジョニングしてください。 というエラーが発生した場合、MySQL 内で必要なバイナリログのオフセットが見つからないことを意味します。MySQL の設定におけるバイナリログ保持期間を確認し、タスクの開始オフセットがその期間内にあることを確認してください。

MySQL 同期エラー：MySQLBinlogReaderException

MySQLBinlogReaderException: 現在同期しようとしているデータベースはスタンバイデータベースですが、現在の log_slave_updates の値が OFF です。スタンバイデータベースのバイナリログ更新を有効にする必要があります。 というエラーが発生した場合、スタンバイデータベースでバイナリログが有効になっていない可能性があります。スタンバイデータベースから同期する場合は、カスケードバイナリログを有効にする必要があります。データベース管理者にご相談ください。

バイナリログの有効化方法については、「ステップ 3：MySQL のバイナリログを有効化」をご参照ください。

MySQL 同期エラー：show master status' にエラーがあります！

show master status' にエラーがあります！ というエラーが発生し、Caused by: java.io.IOException: message=Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation, with command: show master status などの詳細が表示された場合、データソースのアカウントに必要なデータベース権限が不足している可能性があります。

データソース構成で使用するアカウントには、データベースに対する SELECT、REPLICATION SLAVE、REPLICATION CLIENT 権限が必要です。これらの権限を付与する方法については、「ステップ 2：アカウントの作成と権限の設定」をご参照ください。

MySQL 同期エラー：parse.exception.PositionNotFoundException: can't find start position forxxx

同期タスクが指定されたオフセットを見つけられませんでした。オフセットをリセットしてください。

PolarDB 同期エラー： MySQL サーバーでバイナリログの書き込み機能が有効になっていません。まず MySQL のバイナリログ書き込み機能を有効にしてください。

• 原因の可能性：PolarDB ソースデータソースで loose_polar_log_bin パラメーターが有効になっていません。

• 解決方法：loose_polar_log_bin パラメーターを有効化します。「データソースの構成（PolarDB ソース）」をご参照ください。

Hologres 同期エラー：permission denied for database xxx

Hologres へリアルタイムでデータを同期する場合、現在のユーザーに Hologres インスタンスに対する admin 権限（スキーマ作成権限を含む）を付与する必要があります。「Hologres の権限モデル」をご参照ください。

MaxCompute 同期エラー：ODPS-0410051:invalid credentials-accessKeyid not found

一時的な AccessKey を使用して MaxCompute データソースへデータを同期する場合、キーは 7 日後に自動的に期限切れとなり、タスクが失敗します。プラットフォームは、期限切れの一時キーによる失敗を検出すると、タスクを自動的に再起動します。この種類の失敗に対してモニタリングアラートを設定している場合、アラートメッセージが送信されます。

Oracle 同期エラー：logminer doesn't init, send HeartbeatRecord

Oracle リアルタイム同期タスクが適切な同期オフセットを検索して初期化する際、以前のアーカイブログを読み込む必要があります。アーカイブログが大きい場合、この初期化フェーズの完了には 3～5 分かかることがあります。