無効なメッセージの管理

レプリケーションが失敗したときの無効なメッセージを管理するためのDSE Advanced Replication(DSE拡張レプリケーション)ストラテジ。

メッセージのレプリケーション時に、DSE Advanced Replication(DSE拡張レプリケーション)はレプリケーションを成功させるためにメッセージの操作を試みます。場合によっては、データのサブセットのみでレプリケーションが発生することもあります。

また、ソース・クラスターのスキーマとデスティネーション・クラスターのスキーマの相違が多い場合も、レプリケーションは失敗します。たとえば、デスティネーションのカラムとソースの同じカラムの型が異なる場合や、ソースのテーブルに、デスティネーションの同じテーブルのプライマリ・キーを構成するすべてのカラムが含まれていない場合、スキーマの互換性が失われます。

メッセージをレプリケートできない場合は、2回目の送信が試行されます。2回目もレプリケーションが失敗すると、メッセージは破棄され、レプリケーション・ログから削除されます。ソース・クラスターのレプリケーション・ログは、デスティネーション・クラスターへの送信に備えてデータを格納します。

メッセージが破棄されると、CQLクエリー文字列とそれに関連するエラー・メッセージがデスティネーション・クラスターのログに記録されます。失敗したメッセージ・レプリケーションに関連するCQL文字列とエラー・メッセージを格納する場所を定義するには、以下のロギング・ストラテジのいずれかを使用します。
  • SYSTEM_LOG:CQLクエリーとエラー・メッセージをデスティネーションのシステム・ログに記録します。
  • CHANNEL_LOG:CQLクエリーとエラー・メッセージをデスティネーションの/var/lib/cassandra/advrep/invalid_queriesにあるファイルに格納します。これはデフォルト値です。
  • NONE:ロギングは実行されません。
チャネル・ロギング・ストラテジでは、/var/lib/cassandra/advrep/invalid_queries/<keyspace>/<table>/<destination>/invalid_queries.logというパターンに従って、ソース・ノードのチャネル・ログ・ディレクトリーにファイルが作成されます。ここで、keyspace、table、destinationは、以下のとおりです。
  • keyspace:無効なクエリーのキースペース名
  • table:無効なクエリーのテーブル名
  • destination:チャネルのデスティネーション・クラスター
ログ・ファイルには、失敗したメッセージのレプリケーションに関連する以下のデータが格納されます。
  • time_bucket:データベース・パーティションが広がり過ぎないようにするための1時間ごとのバケット。
  • id:時間ベースのID(timeuuid)
  • cql_string:CQLクエリー文字列。USING TIMESTAMPオプションを含めることで、元のタイムスタンプを明示的に指定します。
  • error_msg:エラー・メッセージ

無効なメッセージはログ・テーブルに時間順に挿入されます。

手順

チャネル・ロギングを使用して無効なメッセージを管理する:

  1. デフォルトのシステム・ログの場所ではなく、チャネル・ログを使用してCQLクエリー文字列とエラー・メッセージを格納するには、invalid_message_log構成キーにCHANNEL_LOGを指定します。
    $ dse advrep conf update --invalid_message_log CHANNEL_LOG

システム・ロギングを使用して無効なメッセージを管理する:

  1. デフォルトのチャネル・ログの場所ではなく、システム・ログを使用してCQLクエリー文字列とエラー・メッセージを格納するには、invalid_message_log構成キーにSYSTEM_LOGを指定します。
    $ dse advrep conf update --invalid_message_log SYSTEM_LOG
  2. 問題を特定するには、エラー・メッセージ、CQLクエリー文字列、およびソースとデスティネーションのデータのスキーマを確認します。
  3. 非互換性の問題を解決するための適切な処置を講じます。