3 Cassandraハンドラの使用

Cassandraハンドラを使用する方法について説明します。Cassandraハンドラは、Apache Cassandraデータベースへのインタフェースを提供します。

トピック:

3.1 概要

Apache Cassandraは、大量のデータを格納するために設計されたNoSQLデータベース管理システムです。Cassandraクラスタ構成によって、複数のマシン間でデータの水平スケーリングおよびレプリケーションが行われます。Cassandraクラスタ内の複数のノードにデータを複製することによって、高可用性が実現し、シングル・ポイント障害を防ぐことができます。Apache Cassandraはオープン・ソースで、低価格のコモディティ・ハードウェア上で実行できるように設計されています。

Cassandraでは、原子性、整合性、独立性および永続性に関して、従来のリレーショナル・データベース管理システム(RDBMS)の原理が緩和されています。Cassandraの実装を検討する場合は、従来のRDBMSとの相違点と、その相違点が個々のユースケースにどのように影響するかを理解しておくことが重要です。

Cassandraでは最終的に整合性が保たれます。最終的整合性モデルでは、特定の行のデータの状態にアクセスすると、最新の変更によって定義されたとおりに、その行のデータの最新状態を最終的には返します。ただし、行の状態の作成および変更と、その行の状態を問い合せたときの戻り値の間に、レイテンシ期間が生じる場合があります。最終的整合性には、Cassandra構成およびCassandraクラスタが現在置かれているワークロードのレベルに応じてレイテンシ期間が予測されるという利点があります。http://cassandra.apache.org/を参照してください。

Cassandraハンドラは、Javaアダプタ・プロパティ・ファイルのgg.handler.name.consistencyLevelプロパティの構成を使用して、整合性の一部を制御します。

3.2 機能の詳細

トピック:

3.2.1 Cassandraのデータ型について

Cassandraには多くの列データ型が用意されており、そのデータ型のほとんどがCassandraハンドラでサポートされています。

サポートされているCassandraのデータ型
ASCII
BIGINT
BLOB
BOOLEAN
DATE
DECIMAL
DOUBLE
DURATION
FLOAT
INET
INT
SMALLINT
TEXT
TIME
TIMESTAMP
TIMEUUID
TINYINT
UUID
VARCHAR
VARINT
サポートされていないCassandraのデータ型
COUNTER
MAP
SET
LIST
UDT (user defined type)
TUPLE
CUSTOM_TYPE
サポートされているデータベース操作
INSERT
UPDATE (captured as INSERT)
DELETE

Cassandraコミット・ログ・ファイルには、UPDATEまたはDELETE操作の操作前イメージは記録されません。このため、キャプチャされた操作には操作前イメージ・セクションがありません。競合の検出や解決など、操作前イメージのレコードに依存するOracle GoldenGate機能は使用できません。

サポートされていないデータベース操作
TRUNCATE
DDL (CREATE, ALTER, DROP)

ソース証跡ファイルの列値のデータ型は、CassandraハンドラでCassandra列タイプを表す対応するJavaタイプに変換する必要があります。このデータ変換には、実行時変換エラーのリスクが伴います。フィールドが適切にマップされていないと(英数字データを含むvarcharのソースをCassandraのintにマップするなど)、実行時エラーが発生し、Cassandraハンドラが異常終了することがあります。次の場所でCassandra Javaタイプ・マッピングを確認できます。

https://github.com/datastax/java-driver/tree/3.x/manual#cql-to-java-type-mapping

Cassandraに取り込むために、対応するJavaタイプにデータを変換する特別な処理が必要になる場合があります。この場合、次の2つのオプションがあります。

  • 一般的な正規表現の検索と置換機能を使用して、Cassandraで使用するJavaデータ型に変換できるように、ソース列値データをフォーマットします。

    または

  • デフォルトのデータ型変換ロジックを実装または拡張して、個々のユースケース用のカスタム・ロジックにオーバーライドします。Oracleサポートにお問い合せください。

3.2.2 カタログ、スキーマ、表および列の名前マッピングについて

従来のRDBMSでは、構造化データを表に分割します。関連表は、データベースと呼ばれる高いレベルのコレクションに含まれます。Cassandraには、これら両方の概念が含まれています。RDBMSでの表はCassandraでも表ですが、RDBMSでのデータベース・スキーマはCassandraではキースペースになります。

ソース証跡ファイルのメタデータ定義からのデータ・マップを対応するCassandraのキースペースと表にマップする方法を理解することが重要です。ソース表は通常、schema.table,で定義される2部構成の名前またはcatalog.schema.tableで定義される3部構成の名前のいずれかになります。

次の表では、カタログ、スキーマおよび表の名前をCassandraにマップする方法について説明します。特別な構文を使用しないかぎり、Cassandraでは、すべてのキースペース、表名および列名は小文字に変換されます。

ソース証跡ファイルの表名 Cassandraキースペース名 Cassandra表名

QASOURCE.TCUSTMER

qasource

tcustmer

dbo.mytable

dbo

mytable

GG.QASOURCE.TCUSTORD

gg_qasource

tcustord

3.2.3 DDL機能について

トピック:

3.2.3.1 キースペースについて

Cassandraハンドラは、Cassandraのキースペースを自動的に作成しません 。Cassandraのキースペースでは、レプリケーション・ファクタ、レプリケーション・ストラテジおよびトポロジを定義します。Cassandraハンドラには、キースペースを作成するための十分な情報がないため、キースペースを手動で作成する必要があります。

CassandraシェルからCREATE KEYSPACEコマンドを使用して、Cassandraのキースペースを作成できます。

3.2.3.2 表について

Cassandraハンドラは、Cassandraの表を作成するよう構成した場合、自動的に作成できます。ソース表定義は、Cassandraの表を作成するための情報のソースが不十分でもかまいません。Cassandraの主キーは次の部分に分かれます。

  • パーティショニング・キーは、表のデータをCassandraのパーティションに分割する方法を定義します。

  • クラスタリング・キーパーティション内のアイテムの順序を定義します。

自動表作成のデフォルト・マッピングでは、最初の主キーがパーティショニング・キーになり、その他の主キーがクラスタリング・キーになるようにマッピングされます。

Cassandraハンドラによる自動表作成は、概念の証明としては機能しても、データ定義のスケーリングが適切にならない可能性があります。Cassandraハンドラが主キーの構成が不完全な表を作成した場合、Cassandraに格納されるデータの量が増えると、収集および取得のパフォーマンスが低下する可能性があります。複製される表のメタデータを分析し、対応するCassandraの表を手動で作成することをお薦めします。その表は適切にパーティション化およびクラスタ化され、スケーラビリティが向上します。

Cassandraの表の主キー定義は、作成後に変更できません。Cassandra表の主キー定義を変更するには、次の手動のステップを実行する必要があります。

  1. ステージング表を作成します。

  2. 元の表からステージング表にデータを移入します。

  3. 元の表を削除します。

  4. 変更された主キー定義を使用して、元の表を再作成します。

  5. ステージング表から元の表にデータを移入します。

  6. ステージング表を削除します。

3.2.3.3 列の追加機能

Cassandraハンドラを構成して、ソース証跡ファイルの表定義には存在するが、Cassandra表定義には存在しない列を追加できます。Cassandraハンドラは、このようなメタデータ変更イベントに対応できます。調整プロセスによって、ソース表定義がターゲットCassandra表定義に調整されます。列を追加するようCassandraハンドラ構成すると、ソース表定義に存在し、Cassandra表定義には存在しない列が追加されます。表の調整プロセスは、アプリケーションの起動後、表に対する操作が最初に発生したときに実行されます。調整プロセスは、ソース表でのメタデータ変更イベント後、その変更イベント後にソース表に対する操作が最初に発生したときに再実行されます。

3.2.3.4 列の削除機能

Cassandraハンドラを構成して、ソース証跡ファイルの定義には存在しないが、Cassandra表定義には存在する列を削除できます。Cassandraハンドラは、このようなメタデータ変更イベントに対応できます。調整プロセスによって、ソース表定義がターゲットCassandra表定義に調整されます。列を削除するようCassandraハンドラを構成すると、Cassandra表定義に存在し、ソース表定義には存在しない列が削除されます。

注意:

列を削除すると、Cassandra表からデータが永久に削除されます。このモードを構成する前に、ユースケースを慎重に考慮する必要があります。

注意:

主キー列は削除できません。試行すると、異常終了します。

注意:

DDL処理が行われないため、列名の変更は適切に処理されません。ソース・データベースで列名が変更されると、Cassandraハンドラでは、既存の列を削除して新しい列を追加したと解釈されます。

3.2.4 操作の処理方法

Cassandraハンドラは、非同期APIまたは同期APIのいずれかを使用して、Cassandraに操作をプッシュします。非同期モードでは、トランザクションのコミット(GROUPTRANSOPSを使用したグループ化されたトランザクションのコミット)時に操作がフラッシュされ、書込み永続性が保証されます。Cassandraハンドラは、トランザクションの方法でのCassandraとのインタフェースがありません。

サポートされているデータベース操作
INSERT
UPDATE (captured as INSERT)
DELETE

Cassandraコミット・ログ・ファイルには、UPDATEまたはDELETE操作の操作前イメージは記録されません。このため、キャプチャされた操作には操作前イメージ・セクションがありません。競合の検出や解決など、操作前イメージのレコードに依存するOracle GoldenGate機能は使用できません。

サポートされていないデータベース操作
TRUNCATE
DDL (CREATE, ALTER, DROP)

Cassandraでは、挿入、更新および削除操作が、従来のRDBMSとは異なる方法で処理されます。次に、挿入、更新および削除操作がCassandraでどのように解釈されるかについて説明します。

  • 挿入: Cassandraに行が存在しない場合、挿入操作は挿入として処理されます。Cassandraに行がすでに存在する場合、挿入操作は更新として処理されます。

  • 更新: Cassandraに行が存在しない場合、更新操作は挿入として処理されます。Cassandraに行がすでに存在する場合、更新操作は挿入として処理されます。

  • 削除:Cassandraに行が存在しない場合、削除操作は無効です。Cassandraに行が存在する場合、削除操作は削除として処理されます。

Cassandraのデータの状態は、冪等です。ソース証跡ファイルまたは証跡ファイルのセクションを再生できます。証跡データがCassandraに書き込まれた回数に関係なく、Cassandraデータベースの状態は同じになる必要があります。

3.2.5 圧縮更新と完全イメージ更新について

Oracle GoldenGateを使用すると、更新が発生した場合にソース証跡ファイルに伝播されるデータを制御できます。ソース証跡ファイルの更新のデータは、更新の圧縮または完全イメージのいずれかで、次のように列情報が指定されます。

圧縮

値が変更された主キーおよび列が対象です。変更されなかった列のデータは、証跡ファイルには提供されません。

完全イメージ

値が変更された主キーおよび列を含むすべての列と、値が変更されなかった列が対象です。

Cassandraハンドラにとっては、更新についての情報の量が重要です。ソース証跡ファイルに完全イメージの変更データが含まれる場合、Cassandraハンドラはプリコンパイルされた文を使用して、Cassandraで行更新を実行できます。完全イメージを使用すると、CassandraハンドラはCassandraの行に対して主キー更新を実行することもできます。Cassandraでは、主キーを変更できないため、主キーを変更する更新は、削除と挿入として処理される必要があります。逆に、圧縮更新を使用すると、Cassandraの行更新にプリコンパイルされた文を使用できません。値と主キーの変更を特定する単純な文を動的に作成し、実行する必要があります。圧縮更新では、主キー更新は不可能で、その結果Cassandraハンドラは異常終了します。

ハンドラが圧縮更新または完全イメージ更新を予期できるように、制御プロパティgg.handler.name.compressedUpdatesおよびgg.handler.name.compressedUpdatesforを設定する必要があります。

デフォルト値のtrueによって、Cassandraハンドラが圧縮更新を予期するように設定されます。プリコンパイルされた文は更新に使用されず、主キー更新によってハンドラは異常終了します。

値がfalseの場合、プリコンパイルされた文は更新に使用され、主キー更新を処理できます。ソース証跡ファイルに完全イメージ・データが含まれていないと、データ列が破損し、NULLと見なされる可能性があります。その結果、NULL値がCassandraにプッシュされます。ソース証跡ファイルに圧縮データまたは完全イメージ・データのどちらが含まれているか疑わしい場合は、gg.handler.name.compressedUpdatestrueに設定します。

CLOBおよびBLOBデータ型は、LOB列値が変更された場合を除き、更新時にLOBデータを伝播しません。そのため、ソース表にLOBデータが含まれる場合は、gg.handler.name.compressedUpdatestrueに設定します。

3.2.6 主キーの更新について

Cassandraの行の主キー値は、変更することができません。Cassandraの行の主キー値を変更する更新操作は、削除と挿入として処理される必要があります。Cassandraハンドラは、削除と挿入としてのみCassandraの主キーの変更となる更新操作を処理できます。この操作を正常に処理するには、ソース証跡ファイルに、すべての列の変更前と変更後の完全なデータ・イメージが含まれている必要があります。主キーの更新を正常に処理するには、Cassandraハンドラのgg.handler.name.compressed構成プロパティをfalseに設定する必要があります。

3.3 Cassandraハンドラの設定および実行

ここでは、Cassandraハンドラのコンポーネントの構成とハンドラの実行について説明します。

Cassandraハンドラを実行する前に、Datastax Driver for Cassandraをインストールし、gg.classpath構成プロパティを設定する必要があります。

ドライバ・ライブラリの取得

Datastax Java Driver for Cassandraは、Oracle GoldenGate for Big Dataに付属しません。Datastax Java Driver for Cassandra 3.1の推奨バージョンを次のサイトからダウンロードできます。

https://github.com/datastax/java-driver

クラスパスの設定

Javaアダプタ・プロパティ・ファイルのgg.classpath構成プロパティを構成して、Datastax Java Driver for CassandraのJARを指定する必要があります。このJARがリストの先頭にあることを確認します。

gg.classpath=/path_to_driver/cassandra-java-driver-3.6.0/*:/path_to_driver/cassandra-java-driver-3.6.0/lib/*

トピック:

3.3.1 Cassandraハンドラ構成の理解

Cassandraハンドラの構成可能な値は次のとおりです。これらのプロパティは、Javaアダプタ・プロパティ・ファイルにあります(Replicatプロパティ・ファイルにはありません)。

Cassandraハンドラの選択を有効にするには、まずgg.handler.jdbc.type=cassandraおよびその他のCassandraプロパティを次のように指定してハンドラ・タイプを構成する必要があります。

表3-1 Cassandraハンドラの構成プロパティ

プロパティ 必須/オプション 有効な値 デフォルト 説明

gg.handlerlist

必須

任意の文字列

なし

Cassandraハンドラの名前を指定します。Cassandraハンドラ名は、この表にリストしたプロパティ名の一部になります。

gg.handler.name.type=cassandra

必須

cassandra

なし

Cassandraハンドラを選択し、チェンジ・データ・キャプチャをnameにストリーミングします。

gg.handler.name.mode

オプション

op | tx

op

デフォルトが推奨されます。opモードでは、操作は受信したとおりに処理されます。txモードでは、操作はトランザクションのコミット時にキャッシュされ、処理されます。txモードのほうが低速で、作成されるメモリー・フットプリントが大きくなります。

gg.handler.name.contactPoints=

オプション

Cassandraハンドラの接続先となるホスト名のカンマ区切りリスト。

localhost

Cassandraクラスタへの初期接続を確立するドライバのCassandraホスト・マシンのカンマ区切りリスト。この構成プロパティには、Cassandraクラスタに登録されたすべてのマシンを含める必要はありません。1つのマシンに接続することによって、ドライバはCassandraクラスタ内の他のマシンについて理解し、必要に応じてそのマシンへの接続を確立できます。

gg.handler.name.username

オプション

有効なユーザー名の文字列。

なし

nameへの接続のユーザー名。資格証明が必要なCassandraを構成する場合に必須です。

gg.handler.name.password

オプション

有効なパスワードの文字列。

なし

nameに接続するためのパスワード。資格証明が必要なCassandraを構成する場合に必須です。

gg.handler.name.compressedUpdates

オプション

true | false

true

Cassandraハンドラがソース証跡ファイルからの完全イメージ更新を予期するかどうかを設定します。trueの値は、ソース証跡ファイルの更新には、変更された主キーおよび列の列データのみが含まれることを意味します。Cassandraハンドラは、変更された列のみを更新する単純な文として更新を実行します。

falseの値は、ソース証跡ファイルの更新には、列値が変更されたかどうかに関係なく、主キーおよびすべての列の列データが含まれることを意味します。Cassandraハンドラは、プリコンパイルされた文を更新に使用できます。これにより、名前へのデータのストリーミングのパフォーマンスが向上します。

gg.handler.name.ddlHandling

オプション

CREATE | ADD | DROP (任意の組合せ。値はカンマで区切る)

なし

指定するDDL機能についてCassandraハンドラを構成します。オプションには、CREATEADDおよびDROPがあります。これらのオプションは、任意の組合せをカンマで区切って設定できます。

CREATEを有効にすると、Cassandraハンドラは、対応する表が存在しない場合にCassandraに表を作成します。

ADDを有効にすると、Cassandraハンドラは、対応するCassandra表定義に存在しないソース表定義に存在する列を追加します。

DROPを有効にすると、ハンドラは、対応するソース表定義に存在しないCassandra表定義に存在する列を削除します。

gg.handler.name.cassandraMode

オプション

async | sync

async

Cassandraハンドラと名前の間の相互作用を設定します。な相互作用の場合はasyncに設定します。操作はCassandraに非同期的に送信され、トランザクションのコミット時にフラッシュされて、永続性が保証されます。非同期にすると、パフォーマンスが向上します。

同期的な相互作用の場合はsyncに設定します。操作はCassandraに同期的に送信されます。

gg.handler.name.consistencyLevel

オプション

ALL | ANY | EACH_QUORUM | LOCAL_ONE | LOCAL_QUORUM | ONE | QUORUM | THREE | TWO

Cassandraのデフォルト。

名前での操作の整合性レベルを設定します。操作の実行時にCassandraクラスタに格納するために満たす必要がある基準を構成します。整合性レベルを低くするとパフォーマンスが向上し、高くすると安全になります。

SSLのjavax.net.ssl.SSLContextおよび暗号スイートを上書きできる、高度な構成プロパティ。ここには完全修飾クラス名を指定し、クラスパスにクラスを含める必要があります。クラスでは、Datastax Cassandra Javaドライバでcom.datastax.driver.core.SSLOptionsインタフェースを実装する必要があります。この構成プロパティは、gg.handler.name.withSSLtrueに設定されている場合にのみ適用されます。http://docs.datastax.com/en/developer/java-driver/3.3/manual/ssl/を参照してください。

gg.handler.name.withSSL

オプション

true | false

false

SSLを使用したCassandraクラスタへのセキュアな接続を有効にするには、trueに設定します。これには、追加のJavaブート・オプションの構成が必要です。http://docs.datastax.com/en/developer/java-driver/3.3/manual/ssl/を参照してください。

gg.handler.name.port

オプション

整数

9042

CassandraハンドラがCassandraサーバー・インスタンスへの接続を試行するポート番号を構成する場合に設定します。Cassandra YAMLファイルのデフォルトをオーバーライドできます。

3.3.2 サンプル構成の確認

Javaアダプタ・プロパティ・ファイルからのCassandraハンドラのサンプル構成を次に示します。

gg.handlerlist=cassandra 

#The handler properties 
gg.handler.cassandra.type=cassandra 
gg.handler.cassandra.mode=op 
gg.handler.cassandra.contactPoints=localhost 
gg.handler.cassandra.ddlHandling=CREATE,ADD,DROP 
gg.handler.cassandra.compressedUpdates=true 
gg.handler.cassandra.cassandraMode=async 
gg.handler.cassandra.consistencyLevel=ONE

3.3.3 セキュリティの構成

ユーザー名資格証明およびパスワード資格証明を使用して、CassandraクラスタへのCassandraハンドラの接続を保護できます。これは、次の構成プロパティを使用して設定されます。

gg.handler.name.username 
gg.handler.name.password

オプションで、SSLを使用してCassandraクラスタへの接続を保護できます。SSLのセキュリティを有効にするには、次のパラメータを設定します。

gg.handler.name.withSSL=true

さらに、Javaのbootoptionsは、keystoreの場所とパスワード、truststoreの場所とパスワードを含むように構成する必要があります。次に例を示します。

javawriter.bootoptions=-Xmx512m -Xms32m -Djava.class.path=.:ggjava/ggjava.jar:./dirprm
-Djavax.net.ssl.trustStore=/path/to/client.truststore
-Djavax.net.ssl.trustStorePassword=password123
-Djavax.net.ssl.keyStore=/path/to/client.keystore
-Djavax.net.ssl.keyStorePassword=password123

3.4 自動DDL処理について

Cassandraハンドラは、ソース表に対する操作が最初に発生したときに表チェックおよび調整プロセスを実行します。また、DDLイベントまたはメタデータ変更イベントによって、Cassandraハンドラの表定義が使用済としてマークされます。したがって、次回に表の操作が発生した場合は、ハンドラは、次の項で説明する表チェックと調整プロセスを繰り返します。

トピック:

3.4.1 表チェックおよび調整プロセスについて

Cassandraハンドラは、最初に、ターゲットCassandraキースペースが存在するかどうかを判断するために、ターゲットCassandraデータベースを問い合せます。ターゲットCassandraキースペースが存在しない場合、Cassandraハンドラは異常終了します。キースペースはユーザーが作成する必要があります。ログ・ファイルには、Cassandraハンドラが予期する正確なキースペース名のエラーが含まれている必要があります。

次に、Cassandraハンドラは、表定義が存在するかどうかをターゲットCassandraデータベースに問い合せます。表が存在しない場合、Cassandraハンドラは、gg.handler.name.ddlHandlingCREATEオプションが含まれている場合は表を作成し、含まれていない場合はプロセスを異常終了させます。Cassandraに表が存在しないことを示すメッセージが記録されます。

Cassandraに表が存在する場合、Cassandraハンドラは、ソース証跡ファイルの表定義とCassandraの表定義を調整します。この調整プロセスは、ソース表定義に存在し、対応するCassandra表定義に存在しない列を検索します。この基準に一致する列が見つかり、gg.handler.name.ddlHandlingプロパティにADDが含まれている場合、Cassandraハンドラは、Cassandraのターゲット表に列を追加します。それ以外の場合、これらの列は無視されます。

次に、Cassandraハンドラは、ターゲットCassandra表に存在するが、ソース表定義に存在しない列を検索します。この基準に一致する列が見つかり、gg.handler.name.ddlHandlingプロパティにDROPが含まれている場合、Cassandraハンドラは、Cassandraのターゲット表からこれらの列を削除します。それ以外の場合、これらの列は無視されます。

最後に、プリコンパイルされた文が作成されます。

3.4.2 新規変更データのキャプチャ

該当するターゲットについて、証跡内のDDL変更を含むCassandraデータベースへのすべての新しい変更データをキャプチャできます。受入れ基準は次のとおりです。

AC1: Support Cassandra as a bulk extract 
AC2: Support Cassandra as a CDC source
AC4: All Cassandra supported data types are supported
AC5: Should be able to write into different tables based on any filter conditions, like Updates to Update tables or based on primary keys
AC7: Support Parallel processing with multiple threads 
AC8: Support Filtering based on keywords
AC9: Support for Metadata provider
AC10: Support for DDL handling on sources and target
AC11: Support for target creation and updating of metadata.
AC12: Support for error handling and extensive logging
AC13: Support for Conflict Detection and Resolution
AC14: Performance should be on par or better than HBase

3.5 パフォーマンスに関する考慮事項

Cassandraハンドラをasyncモードに構成すると、syncモードの場合よりパフォーマンスが向上します。ReplicatプロパティGROUPTRANSOPSをデフォルト値の1000に設定する必要があります。

整合性レベルの設定は、パフォーマンスに直接影響します。整合性レベルを高くするほど、特定の操作の伝送が完了と見なされる前に、Cassandraクラスタでの動作が適切になります。個々のユースケースの要件を満たす最低限の整合性レベルを選択します。

Cassandraハンドラは、操作(op)モードまたはトランザクション(tx)モードのいずれかで動作します。最高のパフォーマンスを得るためには、操作モードが推奨されます。

gg.handler.name.mode=op

3.6 その他の考慮事項

  • Cassandraデータベースには、少なくとも1つの主キーが必要です。主キーの値をNULLにすることはできません。主キーがないソース表の自動表作成は失敗します。

  • gg.handler.name.compressedUpdates=falseを設定すると、Cassandraハンドラは、データの完全な操作前イメージと操作後イメージを更新することを予期します。

    注意:

    部分的なイメージ更新が行われたソース証跡ファイルでこのプロパティを設定すると、データが欠落した列に対してnull値が更新されます。この構成は正しくありません。更新操作を行うと、変更されなかった列のnull値のターゲット・データは汚染されます。
  • ソース・データベースでDDLが指定されていても、Cassandraハンドラはソース・データベースからのDDLを処理しません。かわりに、ソース表定義とターゲットCassandra表定義を調整します。ソース・データベースで実行される、列名を変更するDDL文は、Cassandraハンドラでは、列がソース表から削除され、新しい列が追加された場合と同じように解釈されます。この動作は、gg.handler.name.ddlHandlingプロパティがどのように構成されているかに応じて異なります。

    gg.handler.name.ddlHandlingの構成 動作

    ADDDROPのどちらも構成しない

    Cassandraで古い列名とデータが保持されます。Cassandraで新しい列が作成されないため、DDLの変更から新しい列名のデータは複製されません。

    ADDのみを構成する

    Cassandraで古い列名とデータが保持されます。Cassandraで新しい列が追加され、DDLの変更から新しい列名のデータが複製されます。DDL変更の前と後で、データが存在する列が一致しません。

    DROPのみを構成する

    Cassandraで古い列名とデータが削除されます。Cassandraで新しい列が作成されないため、新しい列名のデータは複製されません。

    ADDDROPを構成する

    Cassandraで古い列名とデータが削除されます。Cassandraで新しい列が作成され、DDLの変更から新しい列名のデータが複製されます。

3.7 トラブルシューティング

この項では、様々な問題のトラブルシューティングに役立つ情報を示します。その他のヘルプについては、次のトピックを確認してください。

3.7.1 Javaクラスパス

クラスパスに必要なクライアント・ライブラリが含まれる場合、ログ・ファイルにClassNotFound例外が表示されます。トラブルシューティングするには、Javaアダプタ・ロギングをDEBUGに設定してから、プロセスを再実行します。デバッグ・レベルでは、ログにgg.classpath構成変数からクラスパスに追加されたJARに関するデータが含まれます。gg.classpath変数は、構成されたディレクトリのすべてのJARを選択するアスタリスク(*)ワイルドカード文字を選択します。たとえば、/usr/cassandra/cassandra-java-driver-3.3.1/*:/usr/cassandra/cassandra-java-driver-3.3.1/lib/*のようになります。

クラスパスの設定の詳細は、「Cassandraハンドラの設定および実行」および「Cassandraハンドラ・クライアント依存性」を参照してください。

3.7.2 ロギング

Cassandraハンドラは、ハンドラの構成の状態をJavaログ・ファイルに記録します。これは、Cassandraハンドラの構成値を確認できるため、役に立ちます。構成の状態のロギングのサンプルを次に示します。
**** Begin Cassandra Handler - Configuration Summary **** 
  Mode of operation is set to op. 
  The Cassandra cluster contact point(s) is [localhost]. 
  The handler has been configured for GoldenGate compressed updates (partial image updates). 
  Sending data to Cassandra in [ASYNC] mode. 
  The Cassandra consistency level has been set to [ONE]. 
  Cassandra Handler DDL handling: 
    The handler will create tables in Cassandra if they do not exist. 
    The handler will add columns to Cassandra tables for columns in the source metadata that do not exist in Cassandra. 
    The handler will drop columns in Cassandra tables for columns that do not exist in the source metadata. 
**** End Cassandra Handler - Configuration Summary ****

3.7.3 書込みタイムアウトの例外

Cassandraハンドラを実行すると、Replicatプロセスが異常終了する原因となるcom.datastax.driver.core.exceptions.WriteTimeoutException例外が発生することがあります。これは、次に示す一部またはすべての条件下で発生する可能性があります。

  • Cassandraハンドラが、かなりの処理ロードでCassandraクラスタを配置する多数の操作を処理する。

  • GROUPTRANSOPSがデフォルト値の1000より高く構成されている。

  • Cassandraハンドラが非同期モードで構成されている。

  • CassandraハンドラがONEより高い整合性レベルで構成されている。

この問題が発生すると、CassandraハンドラがCassandraクラスタの処理速度より速くデータをストリーミングします。Cassandraクラスタの書込みレイテンシは、最終的に書込みリクエスト・タイムアウト期間を超え、例外が発生します。

考えられる解決策は、次のとおりです。

  • 書込みリクエスト・タイムアウト期間を増やします。これは、Cassandraのwrite_request_timeout_in_msプロパティで制御され、cassandra_install/confディレクトリのcassandra.yamlファイルにあります。デフォルトは2000 (2秒)です。この値を増やすと、エラーを回避できます。変更を有効にするには、Cassandraノードを再起動します。

  • ReplicatプロセスのGROUPTRANSOPS構成値を減らします。通常、GROUPTRANSOPS構成を減らすと、処理されるトランザクションのサイズが減少し、CassandraハンドラがCassandraクラスタに負担をかけすぎる可能性が少なくなります。

  • Cassandraハンドラの整合性レベルを減らします。これにより、書込みと見なされている操作に対してCassandraクラスタが完了する必要がある作業の量が減少します。

3.7.4 ロギング

java.lang.NoClassDefFoundError: io/netty/util/Timerエラーは、ダウンロードしたDatastax Java Driverの3.3および3.2の両方のバージョンで発生します。これは、JARファイルのnetty-commonが、誤ってDatastaxドライバのtarファイルに存在しないためです。同じnettyバージョンのJARファイルnetty-commonを手動で取得してクラスパスに追加する必要があります。

3.7.5 Datastax Driverエラー

gg.classpathプロパティでcassandra-driver-core-3.3.1.jarファイルを追加しなかった場合に、この例外が発生する可能性があります。

com.datastax.driver.core.exceptions.UnresolvedUserTypeException: Cannot
resolve user type keyspace.duration

durationデータ型の列を含む表がある場合は、この例外が発生します。gg.classpathプロパティでCassandra driver, cassandra-driver-core-3.3.1.jarを使用してエラーを解決します。「Cassandraハンドラの設定および実行」を参照してください。