DataWorks:リアルタイム同期

リアルタイム同期をサポートするデータソースの種類

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

リアルタイム同期タスクのレイテンシが高い理由

リアルタイム同期タスクによって同期された一部のデータがクエリできない場合、タスクにレイテンシが発生している可能性があります。 オペレーションセンターの リアルタイムコンピューティングノード ページに移動し、[レイテンシ] を示す値が過度に大きくなっていないか確認できます。 詳細については、「リアルタイム同期ノードのレイテンシに対するソリューション」をご参照ください。

次の表に、レイテンシが高い原因として考えられるものを示します。

インターネットがリアルタイム同期に推奨されない理由

インターネット経由のリアルタイム同期には、次のような欠点があります。

• 不安定なネットワーク接続が原因でパケット損失が発生し、データ同期のパフォーマンスに影響が及ぶ可能性があります。

• データ同期のセキュリティが低くなります。

DataWorks がリアルタイムで同期するデータレコードに対して実行する操作

Data Integration が MySQL、Oracle、LogHub、PolarDB などのデータソースから DataHub または Kafka データソースにデータをリアルタイムで同期する場合、Data Integration はデスティネーションのデータレコードに 5 つのフィールドを追加します。 これらのフィールドは、メタデータ管理、ソート、重複排除などの操作に使用されます。 詳細については、「リアルタイム同期に使用されるフィールド」をご参照ください。

リアルタイム同期中の TRUNCATE 文の処理方法

リアルタイム同期は TRUNCATE 文をサポートしています。 TRUNCATE 文は、完全データと増分データがマージされるときに有効になります。 TRUNCATE 文を実行しないと、データ同期中に過剰なデータが生成される可能性があります。

リアルタイム同期の速度とパフォーマンスを向上させる方法

デスティネーションへのデータの書き込み速度が遅い場合は、デスティネーションのパラレルスレッド数を増やし、Java 仮想マシン ( JVM ) パラメーターの値を変更できます。 JVM パラメーターの値は、完全ヒープガベージコレクション ( Full GC ) の頻度のみに影響します。 JVM ヒープメモリサイズを大きくすると、Full GC の頻度が減り、リアルタイム同期のパフォーマンスが向上します。

コードレス UI でリアルタイム同期タスクを直接実行できるか

コードレス ユーザーインターフェース ( UI ) でリアルタイム同期タスクを直接実行することはできません。 リアルタイム同期タスクの構成を完了した後、タスクをコミットおよびデプロイし、本番環境でタスクを実行する必要があります。 詳細については、「リアルタイム同期ノードの O&M」をご参照ください。

MySQL からデータを同期するために使用されるリアルタイム同期タスクが遅くなる理由

考えられる理由の 1 つは、MySQL データソース用に生成されたバイナリログが増加することです。 バイナリロギング機能は、インスタンスレベルでのみ有効にできます。 MySQL データソースに対してこの機能を有効にすると、MySQL データソース内のすべてのテーブルに対する変更のバイナリログが生成されます。 その結果、リアルタイム同期タスクで指定されていないテーブルに対する変更用に生成されたバイナリログによって、タスクの実行速度が低下します。

単一のデータベースからデータを同期する場合に消費されるリソース量と、複数のデータベースからデータを同期する場合に消費されるリソース量に違いがある理由

複数のデータベースからデータを同期するためにリアルタイム同期タスクを実行すると、同期タスクはインスタンス全体の同期モードになります。 この場合、同期タスクによって消費されるリソース量は、単一データベースからそれぞれデータを同期するために使用される 2 つのリアルタイム同期タスクによって消費されるリソース量よりも多くなります。

リアルタイム同期タスクがサポートする DDL 処理ポリシーの種類

サポートされている DDL 処理ポリシー

DDL 操作タイプ

DDL または DML 操作が実行されるソーステーブルからのデータ同期に関する注意事項

• ソーステーブルに新しいフィールドが追加された場合、関連するリアルタイム同期タスクは次の方法で動作します。

  • DEFAULT VALUE という名前のフィールドがソーステーブルに追加された場合、リアルタイム同期タスクの実行後に、そのフィールドも関連するデスティネーションテーブルに追加されます。 デスティネーションテーブルのフィールドの値は NULL です。 後続の操作でソーステーブルのフィールドにデータが書き込まれると、リアルタイム同期タスクはそのデータをデスティネーションテーブルのフィールドに同期します。

  • VIRTUAL という名前のフィールドがソーステーブルに追加された場合、リアルタイム同期タスクの実行後に、そのフィールドも関連するデスティネーションテーブルに追加されます。 デスティネーションテーブルのフィールドの値は NULL です。 後続の操作でソーステーブルのフィールドにデータが書き込まれると、リアルタイム同期タスクはそのデータをデスティネーションテーブルのフィールドに同期します。

• MySQL または PolarDB for MySQL データソースからデータを同期するためにリアルタイム同期タスクを実行し、データソースのソーステーブルにフィールドを追加する場合、ソーステーブルの途中に追加するのではなく、最後に追加することをお勧めします。 ソーステーブルの途中にフィールドを追加する必要がある場合は、次の制限事項に注意する必要があります。

  • 完全データと増分データの両方を同期するために使用される同期タスクの場合、完全データの同期中にソーステーブルの途中にフィールドを追加しないでください。 そうしないと、リアルタイムで増分データを同期中にデータ例外が発生します。

  • リアルタイムで増分データを同期中に、増分データの同期を開始するオフセットをリセットし、ソーステーブルの途中にフィールドを追加する DDL 操作を実行する場合は、新しいオフセットがソーステーブルの途中にフィールドを追加した時刻よりも後であることを確認する必要があります。 そうしないと、リアルタイムで増分データを同期中にデータ例外が発生します。

• データ例外が発生した場合は、データの初期化を再度実行して、データを通常の状態に復元できます。 フィールドを追加するテーブルの途中を削除し、データの初期化を実行するだけで済みます。 すべてのテーブルでデータを初期化する必要はありません。

システムは、自動的に作成されるマッピングされたデスティネーションテーブルに、ソーステーブルの情報 (NULL 非許容プロパティやフィールドのデフォルト値など) を保持するか

システムがデスティネーションテーブルを作成する場合、システムはマッピングされたソーステーブルのフィールド名、データ型、備考などの情報のみをデスティネーションテーブルに保持しますが、マッピングされたソーステーブルのフィールドのデフォルト値や、NULL 非許容制約やインデックスの制約などの制約は保持しません。

PostgreSQL からデータを同期するために使用されるリアルタイム同期タスクで、タスクのフェールオーバー発生後にレイテンシが高くなる理由

レイテンシは、PostgreSQL データベースの特性が原因で発生します。 レイテンシがビジネスに影響を与える場合は、リアルタイム同期タスクを停止してから再起動し、PostgreSQL から完全データと増分データを同期できます。

既存のリアルタイム同期タスクを実行して完全同期を実行する方法

Data Integration の [同期タスク] ページの [タスク] セクションでリアルタイム同期タスクを見つけ、[操作] 列の 詳細操作再実行 アイコンをクリックし、[再実行] を選択して同期タスクを再実行できます。

MySQL からデータを同期するためにリアルタイム同期タスクを実行すると、最初はデータを読み取ることができるが、一定期間後に読み取ることができなくなる。どうすればよいか。

1. 関連する MySQL データベースで次のコマンドを実行して、データベースへのデータ書き込み操作を記録するバイナリログファイルを表示します。

   show master status

2. MySQL データベースのバイナリログファイルで journalName=mysql-bin.xx,position=xx を検索し、バイナリログファイルに position パラメーターで指定されたオフセットに関するデータレコードが含まれているかどうかを確認します。 たとえば、journalName=mysql-bin.000001,position=50 を検索できます。

3. MySQL データベースにデータが書き込まれているにもかかわらず、バイナリログにデータ書き込み操作が記録されていない場合は、データベース管理者に連絡してください。

Oracle、PolarDB、または MySQL からデータを同期するためにリアルタイム同期ノードを実行すると、エラーが繰り返し報告される理由

• 問題の説明: Oracle、PolarDB、または MySQL からデータを同期するためにリアルタイム同期タスクを実行すると、エラーが繰り返し報告されます。

  デフォルトでは、Oracle、PolarDB、または MySQL データソースからデータを同期するためにリアルタイム同期タスクを実行する場合、関連するデスティネーションは、ソースで実行された DDL 操作によって生成されたデータ変更の同期をサポートしていません。 ソースでのテーブル作成以外の DDL 操作によって生成されたデータ変更が同期されると、システムはリアルタイム同期タスクのエラーを報告し、ノードは失敗します。 再開可能なアップロードシナリオでは、次のような状況が発生する可能性があります。 ソースで DDL 操作は実行されませんが、システムは引き続きリアルタイム同期タスクのエラーを報告します。

  説明

  特定の期間内のデータの損失または混乱を防ぐために、rename コマンドを使用して 1 つの列の名前を別の列の名前と交換しないことをお勧めします。 たとえば、rename コマンドを使用して列 A の名前と列 B の名前を交換すると、データの損失または混乱が発生する可能性があります。

• 原因: リアルタイム同期は再開可能なアップロードをサポートしています。 データの整合性を確保するために、リアルタイム同期タスクの開始後、同期タスクは以前の DDL 操作によって生成されたデータ変更を再度読み取る場合があります。 その結果、エラーが再度報告されます。

• ソリューション:

  1. ソースの DDL 操作によってデータ変更が生成された場合は、デスティネーションで同じ変更を手動で行います。

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

     説明

     再開可能なアップロードシナリオでは、リアルタイム同期タスクも DDL イベントをサブスクライブします。 同期タスクが想定どおりに実行されるようにするには、DDL メッセージの処理ルールを一時的にエラー報告から無視に変更する必要があります。

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

Kafka からデータを同期するためにリアルタイム同期タスクを実行すると、Startup mode for the consumer set to timestampOffset, but no begin timestamp was specified というエラーメッセージが返されます。どうすればよいか。

データの同期を開始するオフセットを指定します。

Data Integration では、同期タスクのオフセットをリセットして、データ同期の開始位置を指定できます。 特定の時点または特定のデータ位置から再びデータの同期を開始するために同期タスクを実行する場合は、同期タスクのオフセットをリセットできます。 たとえば、データ同期中にエラーが発生した場合、または一部のデータを再度同期する必要がある場合は、関連する同期タスクのオフセットをリセットして、指定した位置から再びデータを同期できます。 これにより、データの整合性と完全性が確保されます。

MySQL からデータを同期するためにリアルタイム同期タスクを実行すると、Cannot replicate because the master purged required binary logs というエラーメッセージが返されます。どうすればよいか。

Cannot replicate because the master purged required binary logs. Replicate the missing transactions from elsewhere, or provision a new slave from backup というエラーメッセージが返された場合、Data Integration は、データの同期を開始するオフセット用に生成されたバイナリログを見つけられない可能性があります。 MySQL データソースのバイナリログの保持期間を確認し、同期タスクを開始する前に、保持期間内のオフセットを指定する必要があります。

MySQL からデータを同期するためにリアルタイム同期タスクを実行すると、MySQLBinlogReaderException エラーメッセージが返されます。どうすればよいか。

MySQLBinlogReaderException: The database you are currently syncing is the standby database, but the current value of log_slave_updates is OFF, you need to enable the binlog log update of the standby database first というエラーメッセージが返された場合、セカンダリ ApsaraDB RDS for MySQL インスタンスのバイナリロギング機能が無効になっています。 セカンダリ ApsaraDB RDS for MySQL インスタンスからデータを同期する場合は、インスタンスに対してこの機能を有効にする必要があります。 この機能を有効にするには、関連するデータベース管理者に連絡してください。

詳細については、「MySQL からのデータ同期のためのデータソースの構成」トピックの「バイナリロギング機能を有効にする」の手順をご参照ください。

MySQL からデータを同期するためにリアルタイム同期タスクを実行すると、show master status' has an error! が含まれるエラーメッセージが返されます。どうすればよいか。

詳細なエラーメッセージが 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 の場合、DataWorks に MySQL データソースを追加したときに指定したアカウントには、関連する MySQL データベースに対する権限が付与されていません。

アカウントには、MySQL データベースに対する SELECT、REPLICATION SLAVE、REPLICATION CLIENT の権限が付与されている必要があります。 データベースに対する必要な権限をアカウントに付与する方法については、「アカウントを作成し、必要な権限をアカウントに付与する」をご参照ください。

MySQL からデータを同期するためにリアルタイム同期タスクを実行すると、parse.exception.PositionNotFoundException: can't find start position forxxx というエラーメッセージが返されます。どうすればよいか。

Data Integration は、データの同期を開始するオフセット用に生成されたバイナリログを見つけられません。 ノードのオフセットをリセットする必要があります。

Hologres からデータを同期するためにリアルタイム同期タスクを実行すると、permission denied for database xxx というエラーメッセージが返されます。どうすればよいか。

Hologres からデータを同期するためにリアルタイム同期タスクを実行する前に、Hologres コンソールでアカウントの <db>_admin ユーザーグループに属する権限を取得する必要があります。 権限を取得した後、アカウントを使用してスキーマを作成できます。 詳細については、「Hologres 権限モデル」をご参照ください。

MaxCompute にデータを同期するためにリアルタイム同期タスクを実行すると、ODPS-0410051:invalid credentials-accessKeyid not found というエラーメッセージが返されます。どうすればよいか。

MaxCompute にデータを同期するためにリアルタイム同期タスクを実行し、データ同期に一時 AccessKey ペアが使用されている場合、一時 AccessKey ペアは 7 日間のみ有効です。 期間が経過すると、一時 AccessKey ペアは自動的に期限切れになり、リアルタイム同期タスクは失敗します。 システムは、一時 AccessKey ペアが期限切れであることを検出すると、リアルタイム同期タスクを再起動します。 関連するアラートルールが同期タスクに構成されている場合、システムはエラーを報告します。

Oracle にデータを同期するためにリアルタイム同期タスクを実行すると、logminer doesn't init, send HeartbeatRecord というエラーメッセージが返されます。どうすればよいか。

Oracle にデータを同期するために使用されるリアルタイム同期タスクが、データ同期に適切なオフセットを見つけるために初期化されているとき、ノードは以前のアーカイブログファイルをロードする必要があります。 アーカイブログファイルのサイズが大きい場合、初期化の完了に 3 ～ 5 分かかる場合があります。