このトピックでは、リアルタイム同期に関する一般的な質問について説明します。
概要
|
カテゴリ |
関連トピック |
|
リアルタイム同期タスクの設定に関する注意事項 |
|
|
MySQL データのリアルタイム同期に関するよくある質問 |
MySQL データソースからリアルタイムでデータを同期する際、タスクは最初にデータを読み取りますが、その後停止します。どうすればよいですか? |
|
Oracle、PolarDB、MySQL データのリアルタイム同期に関するよくある質問 |
|
|
エラーメッセージと解決策 |
|
リアルタイム同期の設定に関する注意事項
サポートされるデータソース
リアルタイム同期でサポートされるデータソースのリストについては、「リアルタイム同期でサポートされるデータソース」をご参照ください。
リアルタイム同期における高遅延
ターゲットテーブルをクエリして新しいデータが見つからない場合、リアルタイム同期タスクの遅延が大きい可能性があります。[オペレーションセンター] のリアルタイム同期タスクページに移動して、タスクの [遅延] が高すぎないか確認できます。詳細については、「リアルタイム同期タスクにおける高遅延の解決策」をご参照ください。
高遅延は、以下の理由で発生する可能性があります:
|
症状 |
直接的な原因 |
解決策 |
|
読み取り側の高遅延 |
ソースでのデータ変更が過剰。 遅延の急激な増加は、特定の時間にソースのデータ量が急増したことを示します。 |
ソースでの頻繁な更新と大量のデータが原因で同期遅延が大きくなる場合は、次のアクションを実行します:
|
|
開始オフセットが早すぎる設定になっている。 |
開始オフセットが早すぎる場合、リアルタイム同期タスクがデータに追いつくまでに時間がかかります。 |
|
|
書き込み側の高遅延 |
ターゲットデータベースのパフォーマンスまたは負荷の問題。 |
データベースの負荷が高い場合、同期タスクの同時実行数を調整するだけでは問題は解決しません。データベース管理者に連絡して支援を求める必要があります。 |
|
読み取り側と書き込み側の両方で高遅延 |
パブリックネットワーク経由の同期がネットワーク問題を引き起こし、タスクの遅延につながる。 |
パブリックネットワーク経由の同期では、リアルタイム性が保証されません。ネットワーク接続を確立し、内部ネットワーク経由でデータを同期してください。 説明
パブリックネットワーク経由の同期には、ネットワークの不安定性や頻繁なパケット損失が同期パフォーマンスに影響を与えるリスクと、セキュリティが低いというリスクがあります。 |
|
ソースデータベースとターゲットデータベースのパフォーマンスに大きな差がある場合や、データベースの負荷が高い場合も、高遅延の原因となります。 |
データベースの負荷が高い場合、同期タスクの同時実行数を調整するだけでは問題は解決しません。データベース管理者に連絡して支援を求める必要があります。 |
パブリックネットワークの使用
リアルタイム同期タスクにパブリックネットワークを使用すると、次のリスクがあります:
-
ネットワークが不安定で、頻繁なパケット損失が同期パフォーマンスに影響を与える可能性があります。
-
セキュリティが低いです。
列フォーマット
Data Integration が MySQL、Oracle、LogHub、PolarDB から DataHub または Apache Kafka にリアルタイムでデータを同期する際、メタデータ管理、レコードのソート、重複排除をサポートするために、ターゲットに 5 つの追加列を追加します。詳細については、「リアルタイム同期における列フォーマット」をご参照ください。
TRUNCATE 操作の処理
リアルタイム同期は TRUNCATE 操作をサポートしており、これは増分マージおよび完全マージ中に有効になります。TRUNCATE を無視することを選択した場合、ターゲットテーブルに余分なデータが表示される可能性があります。
パフォーマンスの向上
書き込み速度が遅い場合は、書き込み側の同時実行数を増やし、JVM パラメーターを調整します。JVM パラメーターの設定は、同期されるデータベースの数ではなく、データ変更の頻度に依存します。リソースグループで許可されている場合は、より多くのメモリを割り当てることで、フル GC の頻度を減らし、リアルタイム同期のパフォーマンスを向上させることができます。[同時実行数] を 3 に設定します。タスクの [基本設定] パネルで、[JVM パラメーター] を -Xms8192m -Xmx8192m に設定します。
コンソールでのタスク実行
いいえ、DataWorks コンソールから直接リアルタイム同期タスクを実行することはできません。リアルタイム同期タスクを設定した後、リアルタイム同期ノードを送信してデプロイし、本番環境でノードを実行する必要があります。詳細については、「単一テーブルのリアルタイム同期の操作とチューニング」をご参照ください。
MySQL ソース使用時の速度低下
一つの理由は、同期する binlog の数が増加することです。binlog はインスタンスレベルで生成されるため、同期タスクがテーブル A のみを同期するように設定されていても、インスタンス内の他のテーブル (テーブル B やテーブル C など) への変更も binlog を生成します。これらの追加の binlog が同期プロセスを遅くします。
単一データベースと複数データベースのメモリ使用量
2 つ以上のデータベースを選択すると、タスクはフルインスタンスのリアルタイム同期モードに入ります。このモードは、それぞれが単一のデータベースを同期する 2 つの別々のリアルタイムタスクよりも多くのリソースを消費します。
サポートされる DDL ポリシー
処理方法:
|
処理 |
無視 |
アラート |
エラー |
|
DDL メッセージは処理のためにターゲットデータソースに転送されます。処理ポリシーはターゲットデータソースによって異なる場合があります。 |
DDL メッセージは破棄され、ターゲットデータソースは何もアクションを実行しません。 |
DDL メッセージは破棄され、アラートが送信されます。 説明
リアルタイムタスクにアラートルールが設定されていない場合、対応するアラートは受信されません。 |
タスクはエラーで終了します。 説明
リアルタイムタスクにタスクステータスに対応するアラートルールが設定されている場合、対応するアラートを受信できます。 |
DDL タイプ:
|
テーブルの作成 |
|
|
テーブルの削除 |
|
|
列の追加 |
|
|
列の削除 |
「処理」はサポートされていません。「無視」、「アラート」、または「エラー」のみを選択できます。 |
|
テーブル名の変更 |
「処理」はサポートされていません。「無視」、「アラート」、または「エラー」のみを選択できます。 |
|
列名の変更 |
「処理」はサポートされていません。「無視」、「アラート」、または「エラー」のみを選択できます。 |
|
列の型の変更 |
|
|
テーブルの切り捨て |
|
ソース DDL および DML に関する考慮事項
-
ソースで新しい列が追加され、ターゲットで処理された後、次の制限が適用されます:
-
DEFAULT VALUE を持つ列が追加された場合、ターゲットテーブルの新しい列は NULL のままです。その後、ソースでこの列に新しいデータが追加されると、タスクはそれをターゲットに同期します。
-
VIRTUAL 列が追加された場合、ターゲットテーブルの新しい列は NULL のままです。その後、ソースでこの列に新しいデータが追加されると、タスクはそれをターゲットに同期します。
-
-
MySQL および PolarDB for MySQL ソースからのリアルタイム同期では、新しい列はテーブルの末尾に追加し、途中に挿入しないでください。ソースで列を途中に挿入することが避けられない場合は、次の制約が適用されます:
-
完全同期と増分同期のソリューションでは、完全同期フェーズ中に列を途中に挿入しないでください。これにより、リアルタイム同期フェーズでデータ異常が発生する可能性があります。
-
リアルタイム同期フェーズ中、同期オフセットのリセット時間は、列を途中に挿入する DDL イベントの後に設定する必要があります。そうしないと、その後の同期でデータ異常が発生します。
-
-
データ異常が発生した場合は、影響を受けたテーブルを再初期化することでデータを復元できます。タスク内のすべてのテーブルではなく、列が追加された単一のテーブルのみを再初期化する必要があります。
ソーステーブルにデフォルト値がある場合、Data Integration によって作成されたターゲットテーブルにデフォルト値と NOT NULL 制約は保持されますか?
PostgreSQL のフェールオーバー後の高遅延
これは PostgreSQL データベース自体の動作です。遅延が許容できない場合は、タスクを停止して再起動し、完全同期と増分データ同期を実行できます。
完全同期の実行
Data Integration で、同期タスクリストからタスクを見つけます。次に、[操作] 列で、 をクリックします。
MySQL リアルタイム同期に関するよくある質問
タスクが MySQL からの読み取りを停止する
-
データベースで次のコマンドを実行して、現在の binlog ファイルを特定します。
show master status -
これをタスクが読み取っている binlog ファイルと比較します。ログで
journalName=mysql-bin.000001,position=50を検索して、データがデータベースに書き込まれているか確認します。 -
データは書き込まれているが binlog が進まない場合は、DBA に連絡して支援を求めてください。
Oracle、PolarDB、MySQL に関するよくある質問
Oracle、PolarDB、MySQL のタスクが繰り返し失敗する
-
症状:リアルタイム同期タスクが繰り返し失敗します。
リアルタイム同期のソースが Oracle、PolarDB、または MySQL データソースの場合、ソースからの DDL メッセージの処理はデフォルトではサポートされていません。新しいテーブルの作成以外の DDL 変更が発生すると、リアルタイムタスクは失敗して終了します。ブレークポイント再開を使用すると、ソースで DDL メッセージが生成されなくても同期が失敗する可能性があります。
説明データ損失や破損を避けるため、Rename コマンドを使用して 2 つの列の名前を交換しないでください。たとえば、列 A と列 B の名前を交換しないでください。
-
原因:リアルタイム同期はブレークポイント再開をサポートしています。データが失われないようにするため、タスクは再起動時に以前のオフセットにさかのぼることがあります。これにより、タスクが以前の DDL メッセージを再度読み取り、別の失敗を引き起こす可能性があります。
-
解決策:
-
ソースで DDL 変更が発生した場合、ターゲットデータベースで対応する DDL 変更を手動で実行します。
-
リアルタイム同期タスクを開始し、DDL ポリシーを エラー から 無視 に変更します。
説明ブレークポイント再開がこの DDL イベントをまだサブスクライブしている可能性があるため、タスクが再び失敗するのを防ぐために、一時的にポリシーを「無視」に変更します。
-
リアルタイム同期タスクを停止し、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.
MySQL リアルタイム同期タスクがメッセージ Cannot replicate because the master purged required binary logs. Replicate the missing transactions from elsewhere, or provision a new slave from backup. で失敗した場合、MySQL が消費されたオフセットの binlog レコードを持っていない可能性があります。MySQL 設定で binlog の保存期間を確認し、同期タスクが開始されるときにオフセットがこの時間範囲内に設定されていることを確認してください。
binlog をサブスクライブできない場合は、オフセットを現在の時刻にリセットしてみてください。
MySQL エラー: MySQLBinlogReaderException
MySQL リアルタイム同期タスクがメッセージ 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. で失敗した場合、スタンバイデータベースで binlog が有効になっていない可能性があります。スタンバイデータベースを同期したい場合は、カスケードスタンバイデータベースの binlog を有効にする必要があります。DBA に助けを求めることができます。
binlog を有効にする方法の詳細については、「ステップ 3:MySQL の binlog を有効にする」をご参照ください。
MySQL エラー: show master status' has an error!
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 である場合、データソースアカウントに必要なデータベース権限がない可能性があります。
データソースに設定されたアカウントには、データベースに対する SELECT、REPLICATION SLAVE、および REPLICATION CLIENT 権限が必要です。データソースアカウントに権限を付与する方法の詳細については、「ステップ 2:アカウントを作成して権限を付与する」をご参照ください。
MySQL エラー: parse.exception.PositionNotFoundException: can't find start position forxxx
同期プロセスがオフセットを見つけられませんでした。オフセットをリセットしてください。
PolarDB エラー: MySQL サーバーでは binlog 書き込み機能が有効になっていません。まず MySQL の binlog 書き込み機能を有効にしてください
-
考えられる原因:ソース 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 データソースにリアルタイムでデータを同期すると、一時的な AccessKey は 7 日後に自動的に期限切れになり、タスクが失敗します。プラットフォームは、一時的な AccessKey の期限切れによる失敗を検出すると、タスクを自動的に再起動します。このタイプの失敗に対してモニタリングアラートを設定している場合は、アラートが届きます。
Oracle エラー: logminer doesn't init, send HeartbeatRecord
Oracle リアルタイム同期タスクが初期化されるとき、適切な同期オフセットを見つけるために以前のアーカイブログをロードします。アーカイブログが大きい場合、初期化フェーズが完了するまでに 3〜5 分かかることがあります。