6.8. Debezium Oracle コネクターによる障害および問題の処理方法
Debezium は、複数のアップストリームデータベースのすべての変更をキャプチャーする分散システムであり、イベントの見逃しや損失は発生しません。システムが正常に操作している場合や、慎重に管理されている場合は、Debezium は変更イベントレコードごとに 1 度だけ 配信します。
障害が発生しても、Debezium からイベントがなくなることはありません。ただし、障害から復旧している間は、変更イベントが繰り返えされる可能性があります。このような正常でない状態では、Debezium は Kafka と同様に、変更イベントを 少なくとも 1 回 配信します。
本セクションのこれ以降では、Debezium がどのようにさまざまな種類の障害や問題を処理するかを説明します。
ログにはオフセットが含まれず、新しいスナップショットを実行します。
Debezium Oracle コネクターが再起動した後、以下のエラーが報告される場合があります。
Online REDO LOG files or archive logs do not contain the offset scn xxxxxxx. Please perform a new snapshot.
コネクターが REDO ログとアーカイブログを調査した後、コネクターオフセットに記録されている SCN が見つからない場合、前述のエラーを返します。コネクターは SCN を使用して処理を再開する場所を決定するため、期待した SCN が見つからない場合、新しいスナップショットを完了する必要があります。
V$ARCHIVED_LOG テーブルに、予想される範囲に一致する SCN のあるレコードが含まれることがあります。ただし、このレコードはマイニングに利用できない場合があります。採掘可能なレコードは、NAME 列にファイル名、DELETED 列に値 NO、STATUS 列に値 A (利用可能) を含む必要があります。レコードがこれらの基準のいずれにも一致しない場合は不完全なと見なされ、最小値はできません。
少なくとも、コネクターのダウンタイム期間が最長である限り、アーカイブログを保持する必要があります。
NAME 列に値のないレコードがファイルシステムに存在しなくなりました。このようなレコードでは、DELETED フィールドの値が YES に設定され、STATUS フィールドは D に設定され、ログが削除されていることを示します。
ORA-25191: インデックス編集テーブルのオーバーフローテーブルを参照できない
Oracle は、インデックス編集テーブル (IOT) に遭遇すると、スナップショットフェーズでこのエラーが発生する可能性があります。このエラーは、コネクターが、指定のオーバーフローテーブルが含まれる親のインデックス編集テーブルに対して実行する必要がある操作の実行を試行したことを意味します。
これを解決するには、SQL 操作で使用される IOT 名を、親のインデックス編集テーブル名に置き換える必要があります。親のインデックス編集テーブル名を確認するには、以下の SQL を使用します。
SELECT IOT_NAME FROM DBA_TABLES WHERE OWNER='<tablespace-owner>' AND TABLE_NAME='<iot-table-name-that-failed>'
コネクターの table.include.list または table.exclude.list 設定オプションを調整して、コネクターが子のインデックス編集テーブルから変更をキャプチャーしないように、適切なテーブルを明示的に追加または除外する必要があります。
ORA-04036: インスタンスが PGA_AGGREGATE_LIMIT を超える PGA メモリー
Debezium が頻繁に変更が行われるデータベースに接続する場合、Oracle はこのエラーを報告するかもしれません。Debezium コネクターは、Oracle LogMiner セッションを開始し、ログスイッチが検出されるまでこのセッションを再利用します。再利用は、パフォーマンスとリソース利用の両方の最適化ですが、長時間稼働する採掘セッションは、PGA (Program Global Area) のメモリー使用量が多くなる可能性があります。
redo ログスイッチが頻繁に発生する場合は、Oracle スイッチのログを頻度で指定して ORA-04036 エラーを回避できます。ログスイッチにより、コネクターがマイニングセッションを再開するため、PGA のメモリー使用量が多くなるのを防ぐことができます。以下の設定では、間隔中にログスイッチが発生しない場合には、Oracle がログファイルを 20 分ごとに強制的に切り替えます。
ALTER SYSTEM SET archive_lag_target=1200 scope=both;
前述のクエリーを実行するには、特定の管理者権限が必要です。データベース管理者と連携し、変更を実装します。
Oracle データベースパラメーターを調整できない場合は、代わりにコネクター設定オプション log.mining.session.max.ms を使用して Oracle LogMiner セッションの期間を制御し、データベースログが切り替えられていない場合でも、セッションが定期的に再起動されるようにすることができます。
LogMiner アダプターは、SYS または SYSTEM による変更をキャプチャーしません。
Oracle は、SYS と SYSTEM アカウントを使用して、多くの内部変更を実行します。Debezium Oracle コネクターが LogMiner から変更をフェッチするとき、これらの管理者アカウントから発信された変更を自動的にフィルターリングします。テーブルの変更時にコネクターがイベントレコードを出力するようにするには、SYS または SYSTEM ユーザーアカウントを使用してテーブルを変更しないようにします。
コネクターが AWS の Oracle から変更のキャプチャーを停止する
タイムアウト AWS Gateway Load Balancer で 350 秒の修正されたアイドルタイムアウト により、完了までに 350 秒を超える JDBC 呼び出しは無期限にハングする可能性があります。
Oracle LogMiner API の呼び出しが完了するまでに 350 秒以上かかる状況では、タイムアウトが発生し、AWS Gateway Load Balancer がハングアップすることがあります。例えば、大量のデータを処理する LogMiner セッションと Oracle の定期的なチェックポイントタスクが同時に実行された場合、このようなタイムアウトが発生する可能性があります。
AWS Gateway Load Balancer でタイムアウトが発生しないように、Kafka Connect 環境から root または superuser で次の手順を実行して、キープアライブパケットを有効にします。
ターミナルから、以下のコマンドを実行します。
sysctl -w net.ipv4.tcp_keepalive_time=60
/etc/sysctl.confを編集し、以下のように以下の変数の値を設定します。net.ipv4.tcp_keepalive_time=60
Oracle コネクターが
database.hostnameではなくdatabase.urlプロパティーを使用するように再設定し、以下の例のように Oracle 接続文字列記述子(ENABLE=broken)を追加します。database.url=jdbc:oracle:thin:username/password!@(DESCRIPTION=(ENABLE=broken)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(Host=hostname)(Port=port)))(CONNECT_DATA=(SERVICE_NAME=serviceName)))
前述の手順では、TCP ネットワークスタックが 60 秒ごとにキープアライブパケットを送信するように設定します。その結果、LogMiner API への JDBC 呼び出しが完了するまで 350 秒を超える時間がかかる場合、AWS Gateway ロードバランサーはタイムアウトしません。これにより、コネクターはデータベースのトランザクションログから変更の読み取りを続行します。
