無効なメッセージの管理

レプリケーションが失敗したときの無効なメッセージを管理するための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. 非互換性の問題を解決するための適切な処置を講じます。