cassandra.yaml構成ファイル

この cassandra.yaml ファイルは、DataStax Enterpriseの主要な構成ファイルです。dse.yamlファイルは、セキュリティ、DSE Search、DSE Graph、DSE Analyticsの主要な構成ファイルです。

構文

各セクションのプロパティで、親の設定にはスペースが含まれていません。各子エントリーにはスペースを少なくとも2つ入力する必要があります。YAML構文に従い、スペースを維持してください。

構成

構成プロパティを以下の各セクションにグループ分けしました。

• クイック・スタート

  クラスターを構成するために必要な最小限のプロパティ。

• デフォルトのディレクトリー

  インストール時にデフォルトのディレクトリーのいずれかを変更した場合は、以下のプロパティを新しい場所に設定します。rootアクセス権があることを確認します。

• 一般的に使用されているプロパティ

  DataStax Enterpriseの構成時に頻繁に使用されるプロパティ。

• パフォーマンスの調整

  コミット・ログ、コンパクション、メモリー、ディスクI/O、CPU、読み取り、書き込みを含むパフォーマンスとシステム・リソースの活用を調整します。

• 高度なプロパティ

  上級ユーザー用のプロパティまたは使用頻度の低いプロパティ。

• セキュリティ・プロパティ

  DSE Unified Authenticationには、認証、権限付与、ならびにロール管理が用意されています。

• ユーザー定義関数（UDF）のプロパティ
• 連続ページング・オプション 継続的にページをクライアントにプッシュする際のメモリー、スレッド、間隔を構成するプロパティ。
• メモリー・リーク検出の設定 メモリー・リークの検出を構成するプロパティ。

クイック・スタート・プロパティ

クラスターを構成するために必要な最小限のプロパティ。

cluster_name: 'Test Cluster'
listen_address: localhost
# listen_interface: wlan0
# listen_interface_prefer_ipv6: false

cluster_name

クラスターの名前。この設定により、論理クラスター内のノードが別のクラスターに参加するのを防ぎます。クラスター内のすべてのノードが同じ値を持つ必要があります。

デフォルト： 'Test Cluster'

listen_address

このノードが他のノードに接続するためにバインドするIPアドレスまたはホスト名。

警告:

• 絶対に、listen_addressを0.0.0.0に設定しないでください。
• listen_addressまたはlisten_interfaceを設定します。両方を設定しないでください。

デフォルト： localhost

listen_interface

他のノードに接続するためにデータベースがバインドするインターフェイス。インターフェイスは1つのアドレスのみに対応していなければなりません。IPの別名使用はサポートされていません。

警告: listen_addressまたはlisten_interfaceを設定します。両方は設定できません。

デフォルト：コメントアウト（wlan0）

listen_interface_prefer_ipv6

インスタンスを名前で指定する際は、IPv4またはIPv6を使用します。

• false - 最初のIPv4アドレスを使用します。
• true - 最初のIPv6アドレスを使用します。

1つのアドレスだけを使用する場合、この設定に関係なく、そのアドレスが選択されます。

デフォルト：コメントアウト（false）

デフォルトのディレクトリー

data_file_directories:
     - /var/lib/cassandra/data
commitlog_directory: /var/lib/cassandra/commitlog
cdc_raw_directory: /var/lib/cassandra/cdc_raw
hints_directory: /var/lib/cassandra/hints
saved_caches_directory: /var/lib/cassandra/saved_caches

インストール時にデフォルトのディレクトリーのいずれかを変更した場合は、以下のプロパティを新しい場所に設定します。rootアクセス権があることを確認します。

data_file_directories

ディスク上でテーブル・データが格納されるディレクトリー。データベースは、構成されているコンパクション・ストラテジの細分性に応じて、データをその場所全体に均等に分散します。設定しない場合、ディレクトリーは、$DSE_HOME/data/dataです。

ヒント: プロダクション環境では、DataStaxはRAID 0およびSSDを推奨しています。

デフォルト：- /var/lib/cassandra/data

commitlog_directory

コミット・ログが格納されているディレクトリー。設定しない場合、ディレクトリーは、$DSE_HOME/data/commitlogです。

書き込みパフォーマンスを最適化するには、コミット・ログを、データ・ファイル・ディレクトリーとは別のディスク・パーティションに置くか、理想的には別の物理デバイスに置いてください。コミット・ログは追加書き込み専用なので、この目的にはハード・ディスク・ドライブ（HDD）が適しています。

デフォルト：/var/lib/cassandra/commitlog

cdc_raw_directory

フラッシュ時に、Change Data Capture（CDC）コミット・ログ・セグメントが格納されるディレクトリー。DataStaxでは、データ・ディレクトリとは異なる物理デバイスを推奨しています。設定しない場合、ディレクトリーは、$DSE_HOME/data/cdc_rawです。

デフォルト：/var/lib/cassandra/cdc_raw

hints_directory

ヒントを格納するディレクトリー。設定しない場合、ディレクトリーは、$CASSANDRA_HOME/data/hintsです。

デフォルト： /var/lib/cassandra/hints

saved_caches_directory

テーブル・キーと行キャッシュが格納されるディレクトリーの場所。設定しない場合、ディレクトリーは、$DSE_HOME/data/saved_cachesです。

デフォルト：/var/lib/cassandra/saved_caches

一般的に使用されているプロパティ

DataStax Enterpriseの構成時に頻繁に使用されるプロパティ。

一般的な初期化プロパティ

commit_failure_policy: stop
prepared_statements_cache_size_mb:
# disk_optimization_strategy: ssd
disk_failure_policy: stop
endpoint_snitch: com.datastax.bdp.snitch.DseSimpleSnitch
seed_provider:
    - org.apache.cassandra.locator.SimpleSeedProvider 
        - seeds: "127.0.0.1"
enable_user_defined_functions: false
enable_scripted_user_defined_functions: false
enable_user_defined_functions_threads: true
user_defined_function_warn_micros: 500
user_defined_function_fail_micros: 10000
user_defined_function_warn_heap_mb: 200
user_defined_function_fail_heap_mb: 500
user_function_timeout_policy: die

commit_failure_policy

ディスクのコミット障害に関するポリシー：

• die - ノードを停止してJVMを強制終了し、ノードが置き換えられるようにします。
• stop - ノードを停止して、JMXを使用した調査は可能なまま、そのノードを実質的に停止状態にします。
• stop_commit - 書き込みを禁止し、コミット・ログを停止し、読み取りを継続します。
• ignore - 致命的なエラーを無視し、バッチ処理を失敗にします。

デフォルト：stop

prepared_statements_cache_size_mb

ネイティブ・プロトコルのプリペアド・ステートメント・キャッシュの最大サイズ。この値は、キャッシュに収まらないほど多くの準備済みステートメントがある場合にのみ変更します。

一般的に、計算されたデフォルト値は適切な値であり、調整する必要はありません。DataStaxでは、この値を変更する前に、DataStaxサービス・チームにご相談いただくことを推奨しています。

注: 指定した値が大きすぎると、GCが長時間実行され、メモリー不足エラーになる可能性があります。ヒープに対して小さい値になるようにしてください。

文のプリペアを繰り返すと、パフォーマンス・ペナルティーをもたらします。設定しない場合、デフォルトでは自動的にheap / 256または10 MBのどちらか大きな方に計算されます。

デフォルト： calculated

disk_optimization_strategy

ディスク読み取りを最適化するストラテジ。

• ssd - ソリッド・ステート・ディスク
• spinning - 回転式ディスク

コメントアウトされる場合、デフォルトはssdです。

デフォルト：コメントアウト（ssd）

disk_failure_policy

データベースがディスク障害にどのように応答するのかを設定します。推奨設定は、stopまたはbest_effortです。有効な値：

• die - すべてのファイル・システム・エラーまたは1つのSSTableエラーに対してゴシップとクライアント・トランスポートを終了し、JVMを強制終了して、ノードが置き換えられるようにします。
• stop_paranoid - 単一の SSTableエラーの場合でも、ノードを終了します。
• stop - ノードを停止して、JMXを使用した調査は可能なまま、そのノードを実質的に停止状態にします。
• best_effort - 障害が発生したディスクの使用を停止し、使用可能な残りのSSTableに基づいて要求に応答します。この設定により、整合性レベルがONEの場合に古いデータを取得することができます。
• ignore - 致命的なエラーを無視し、要求を失敗にします。すべてのファイル・システム・エラーが記録され、それ以外は無視されます。

ヒント: 「JBODを使用した単一ディスク障害からの復旧」を参照してください。

デフォルト：stop

endpoint_snitch

IEndpointSnitchインターフェイスを実装しているクラス。データベースでは、ノードを探す際や要求をルーティングする際にスニッチを使用します。

重要: DSEにバンドルされているスニッチ実装以外は使用しないでください。

• DseSimpleSnitch

  開発デプロイだけに適しています。近接度はDSEワークロードによって決定され、個々のデータ・センター内にトランザクション・ノード、Analyticsノード、Searchノードを配置します。データ・センターやラックの情報は認識しません。

• GossipingPropertyFileSnitch

  プロダクション環境で推奨します。ローカル・ノードのラックとデータ・センターをcassandra-rackdc.propertiesファイルで読み取り、ゴシップを介してこれらの値を他のノードに伝搬します。PropertyFileSnitchから移行するには、cassandra-topology.propertiesファイルを使用します（ファイルが存在する場合）。

• PropertyFileSnitch

  ラックとデータ・センターにより近接度を決定します。これらはcassandra-topology.propertiesファイルで明示的に構成されています。

• Ec2Snitch

  1つのリージョンのEC2デプロイで使用します。リージョンとアベイラビリティー・ゾーンの情報をAmazon EC2 APIから読み込みます。リージョンはデータ・センターとして扱われ、アベイラビリティー・ゾーンはラックとして扱われ、プライベートIPアドレスのみを使用します。このため、Ec2Snitchは複数のリージョンでは機能しません。

• Ec2MultiRegionSnitch

  パブリックIPをbroadcast_addressとして使用することでリージョン間の接続を可能にします。つまり、パブリックIPに対してseedアドレスも設定し、storage_portまたはssl_storage_portをパブリックIPのファイアウォール上で開く必要があります。リージョン内トラフィックのために、接続が確立した後はプライベートIPに切り替わります。

• RackInferringSnitch

  ラックとデータ・センターにより近接度を決定します。これらの場所は、ノードのIPアドレスのそれぞれ3番目と2番目のオクテットに対応していると見なされます。カスタム・スニッチ・クラスを作成する例として適しています（これがデプロイ規則に合っている場合を除く）。

• GoogleCloudSnitch

  Google Cloud Platformの1つ以上のリージョンにデプロイする場合に使用します。リージョンはデータ・センターとして扱われ、アベイラビリティー・ゾーンはデータ・センター内のラックとして扱われます。すべての通信は、同じ論理ネットワーク内のプライベートIPアドレスを介して行われます。

• CloudstackSnitch

  Apache Cloudstack環境ではCloudstackSnitchを使用します。

ヒント: 「スニッチ」を参照してください。

デフォルト：com.datastax.bdp.snitch.DseSimpleSnitch

seed_provider

クラスター内のコンタクト・ポイントに指定されているホストのアドレス。参加するノードは-seedsリスト内のいずれかのノードに接続し、リングのトポロジーを学習します。

重要: DSEにバンドルされているシード・プロバイダー実装以外は使用しないでください。

• class_name - シード・ロジックを処理するクラス。カスタマイズできますが、通常は必要ありません。

  デフォルト：org.apache.cassandra.locator.SimpleSeedProvider

• - seeds - gossipが、クラスターに追加する新しいノードをブートストラップするために使用するアドレスのコンマ区切りリスト。クラスターに複数のノードが含まれる場合、リストをデフォルト値からいずれかのノードのIPアドレスに変更する必要があります。

  デフォルト： "127.0.0.1"

  重要: 保守タスクが増え、ゴシップのパフォーマンスが低下するため、すべてのノードをシード・ノードにすることは推奨しません。ゴシップの最適化は重要ではありませんが、シード・リストを小さくすることを推奨します（データ・センターあたり約3つのノード）。

ヒント: 「ワークロードの種類別に単一データ・センターを初期化する」と「ワークロードの種類別に複数のデータ・センターを初期化する」を参照してください。

デフォルト：org.apache.cassandra.locator.SimpleSeedProvider

一般的なコンパクションの設定

compaction_throughput_mb_per_sec: 16
compaction_large_partition_warning_threshold_mb: 100

compaction_throughput_mb_per_sec

システム全体のコンパクションをスロットルするMB/秒単位。データベースのデータの挿入が高速であるほど、SSTableの数を低く維持するためにはより高速でコンパクションする必要があります。

• 書き込みスループット速度の16～32倍。単位はMB/秒。推奨値。
• 0 - コンパクションのスロットルが無効

ヒント: 「コンパクションの構成」を参照してください。

デフォルト：16

compaction_large_partition_warning_threshold_mb

警告のロギング前に、サイズのしきい値のパーティショニングを行います。

デフォルト：100

memtableの設定

# memtable_space_in_mb: 2048
memtable_allocation_type: heap_buffers
# memtable_cleanup_threshold: 0.2
memtable_flush_writers: 4

memtable_space_in_mb

memtableで使用する合計許容メモリー。このしきい値を上回ると、フラッシュが完了するまで、書き込みの受け入れを停止します。フラッシュは、memtable_cleanup_thresholdに基づいてトリガーされます。設定しない場合、

• 廃止予定の設定がない場合、計算されたデフォルトはヒープ・サイズの1/4です。
• 廃止予定のmemtable_heap_space_in_mb or memtable_offheap_space_in_mb設定が存在する場合、エラーが記録され、memtable_allocation_typeに基づいて適切な値が使用されます。廃止予定の設定を削除します。

ヒント: 「Javaヒープのチューニング」を参照してください。

デフォルト：コメントアウト2048

memtable_cleanup_threshold

自動memtableフラッシュで使用する割合。

一般的に、計算されたデフォルト値は適切な値であり、調整する必要はありません。DataStaxでは、この値を変更する前に、DataStaxサービス・チームにご相談いただくことを推奨しています。

設定しない場合、計算されたデフォルトは、1/(memtable_flush_writers + 1)

デフォルト：コメントアウト（0.2）

memtable_allocation_type

データベースがmemtableメモリーの割り当てと管理に使用する方法。

• offheap_objects - ネイティブのメモリー。NIOバッファーのヒープ・オーバーヘッドをなくします。
• heap_buffers - オンヒープNIO（ノンブロッキングI/O）バッファー。
• offheap_buffers - オフヒープ（直接）NIOバッファー。

デフォルト：offheap_objects

memtable_flush_writers

ディスクあたりのmemtableフラッシュ書き込みスレッドの数と同時にフラッシュ可能なmemtablesの総数。通常は、コンピューターとI/Oバウンドの組み合わせ。memtableフラッシュは、memtableの取り込みよりもCPU的には効率的です。単一スレッドは、競合下でサーバーが一時的にIOバウンドになるまでは（通常はコンパクション）、単一高速ディスク上サーバーの取り込み速度に追従可能です。一般的に、デフォルト値は適切な値であり、調整する必要はありません。

SSDのデフォルト：4

HDDのデフォルト：2

memtable_heap_space_in_mb（廃止予定）

注: この設定は廃止予定です。代わりに、memtable_space_in_mbを使用してください。

memtableに割り当てるオンヒープ・メモリーの量。データベースは、この量の合計とmemtable_offheap_space_in_mbの値を使用して、自動memtableフラッシュのしきい値を設定します。

デフォルト：calculated 1/4 of heap size（2048）

memtable_offheap_space_in_mb（廃止予定）

注: この設定は廃止予定です。代わりに、memtable_space_in_mbを使用してください。

memtable_space_in_mbに置換されました。memtableに割り当てるオフヒープ・メモリーの量。データベースは、この量の合計とmemtable_heap_space_in_mbの値を使用して、自動memtableフラッシュのしきい値を設定します。

デフォルト：calculated 1/4 of heap size（2048）

一般的な自動バックアップ設定

incremental_backups: false
snapshot_before_compaction: false

incremental_backups

インクリメンタル・バックアップを有効にするかどうか。

• true - インクリメンタル・バックアップを有効にして、データベースはローカルにフラッシュまたはストリームされた各SSTableへのハードリンクを、対応するキースペース・データの backupsサブディレクトリーに作成します。インクリメンタル・バックアップにより、スナップショット全体を転送せずに、オフサイトでバックアップを保存できるようになります。
  重要: データベースは、インクリメンタル・バックアップ・ファイルを自動的に消去しません。DataStaxでは、新しいスナップショットが作成されるたびにインクリメンタル・バックアップのハードリンクを消去するプロセスを設定することを推奨します。
• false - インクリメンタル・バックアップを有効にしないでください。

ヒント: 「インクリメンタル・バックアップの有効化」を参照してください。

デフォルト：false

snapshot_before_compaction

各コンパクションの前にスナップショットを取得するかどうか。スナップショットは、データ形式に変更がある場合のデータのバックアップに役立ちます。

重要: このオプションの使用には注意してください。データベースは古いスナップショットを自動的にクリーンアップしません。

ヒント: 「コンパクションの構成」を参照してください。

デフォルト：false

パフォーマンスの調整プロパティ

コミット・ログ、コンパクション、メモリー、ディスクI/O、CPU、読み取り、書き込みを含むパフォーマンスとシステム・リソースの活用を調整します。

• コミット・ログの設定
• Change-data-capture（CDC）スペースの設定
• 一般的なコンパクションの設定
• memtableの設定
• キャッシュとインデックスの設定
• ディスクの設定

コミット・ログの設定

commitlog_sync: periodic
commitlog_sync_period_in_ms: 10000
# commitlog_sync_group_window_in_ms: 1000
# commitlog_sync_batch_window_in_ms: 2  //deprecated
commitlog_segment_size_in_mb: 32
# commitlog_total_space_in_mb: 8192
# commitlog_compression:
#   - class_name: LZ4Compressor
#     parameters:
#         -

commitlog_sync

データベースがミリ秒単位で書き込みを確認応答するために使用する方法。

• periodic - 書き込み用のACK信号を即座に送信します。コミット・ログは、commitlog_sync_period_in_msごとに同期されます。
• group - コミット・ログがディスクにフラッシュされた後に書き込み用のACK信号を送信します。フラッシュ間のcommitlog_sync_group_window_in_msまで待機します。
• batch - コミット・ログがディスクにフラッシュされた後に書き込み用のACK信号を送信します。受信する書き込みごとに、フラッシュ・タスクをトリガーします。

デフォルト： periodic

commitlog_sync_period_in_ms

commitlog_sync: periodicを使用します。コミット・ログをディスクに同期する間の時間間隔。周期的同期は即座に認識されます。

デフォルト：10000

commitlog_sync_group_window_in_ms

commitlog_sync: groupを使用します。コミット・ログをディスクにフラッシュする間にデータベースが待機する時間。DataStaxでは、batchの代わりにgroupを使用することをお勧めします。

デフォルト：コメントアウト（1000）

commitlog_sync_batch_window_in_ms

廃止予定。commitlog_sync: batchを使用します。クエリをまとめてバッチ処理できる最大時間。

デフォルト：コメントアウト（2）

commitlog_segment_size_in_mb

個々のコミット・ログ・ファイル・セグメントのサイズ。コミット・ログ・セグメントは、すべてのデータがSSTableにフラッシュされた後、アーカイブしたり、削除したり、再利用したりできます。このデータには、システム内の各テーブルからのコミット・ログ・セグメントが含まれる可能性があります。コミット・ログ・アーカイブの場合、通常はデフォルトのサイズで十分ですが、細分性を上げたい場合は、8または16 MBが妥当です。

制約事項:

max_mutation_size_in_kbを明示的に設定する場合、commitlog_segment_size_in_mbを次のように設定する必要があります。

2 * max_mutation_size_in_kb / 1024

値は正で、2018未満である必要があります。

ヒント: 「コミット・ログ・アーカイブの構成」を参照してください。

デフォルト：32

max_mutation_size_in_kb

ミューテーションが拒否される前のミューテーションの最大サイズ。コミット・ログ・セグメントのサイズを大きくする前に、そのミューテーションが予想よりも大きくなっている理由を調査してください。コミット・ログ・セグメント・サイズを大きくする修正には制限があるため、アクセス・パターンとデータ・モデルに根本的な問題がないか確認してください。設定しない場合、デフォルトは(commitlog_segment_size_in_mb * 1024) / 2として計算されます。

デフォルト：calculated

commitlog_total_space_in_mb

コミット・ログに使用される合計容量。すべてのコミット・ログで使用している合計容量がこのしきい値を超えると、データベースは次に最も近い倍数のセグメントへの切り上げを行い、最も古いコミット・ログ・セグメントのmemtableをディスクにフラッシュし、コミット・ログからこれらのログ・セグメントを削除します。このフラッシュによって起動時にリプレイされるデータ量が削減され、更新頻度の低いテーブルがコミット・ログ・セグメントをいつまでも維持し続けるのを防ぎます。commitlog_total_space_in_mbが小さい場合、あまりアクティブでないテーブルのフラッシュ・アクティビティーが増えることになります。

ヒント: 「memtableのしきい値の構成」を参照してください。

64ビットJVMのデフォルト： calculated (8192 or 25% of the total space of the commit log value, whichever is smaller)

64ビットJVMのデフォルト： calculated (32 or 25% of the total space of the commit log value, whichever is smaller )

commitlog_compression

コミット・ログを圧縮する場合に使用する圧縮方式。変更するには、commitlog_compressionセクションのコメントを解除して、オプションに変更を加えます。

# commitlog_compression:
#   - class_name: LZ4Compressor
#     parameters:
#         -

• class_name：LZ4Compressor、Snappy、またはDeflate
• parameters：圧縮形式用のオプション・パラメーター

設定しない場合、コミット・ログのデフォルトの圧縮は圧縮されません。

デフォルト：コメントアウト

軽量トランザクション（LWT）の設定

# concurrent_lw_transactions: 128
# max_pending_lw_transactions: 10000

concurrent_lw_transactions

許容されている同時軽量トランザクション（LWT）の数。

• 非競合のLWTが頻繁に使用されている場合、数字が大きい方がスループットが改善することがあります。ただし、使用メモリーが増え、競合における成功率が下がります。
• 設定しない場合、デフォルト値はTPCコア数の8倍です。このデフォルト値は、大抵の状況において妥当です。

デフォルト： calculated 8x the number of TPC cores

max_pending_lw_transactions

ノードが、LWTにOverloadedExceptionをレポートする前のキュー内の軽量トランザクション（LWT）の最大数。

デフォルト：10000

Change-data-capture（CDC）スペースの設定

cdc_enabled: false
cdc_total_space_in_mb: 4096
cdc_free_space_check_interval_ms: 250

「cdc_raw_directory」も参照してください。

cdc_enabled

ノードごとにChange Data Capture（CDC）機能を有効にするかどうか。書き込みパスの割り当て拒否で使用しているロジックを変更します。

• true - cdc_raw_directoryで容量が制限されている場合、cdc機能を使用して、CDCが有効になっているテーブルのデータを含むミューテーションを拒否します。
• false - 標準動作、絶対に拒否しません。

デフォルト：false

cdc_total_space_in_mb

ディスク上のchange-data-capture（CDC）ログで使用する合計容量。CDCに割り当てられた容量がこの値を超えると、データベースはCDCが有効になっているテーブルを含むミューテーションでWriteTimeoutExceptionをスローします。生のCDCログの解析と、解析後のログの削除は、CDCCompactor（コンシューマー）が行います。

デフォルト： calculated (4096 or 1/8th of the total space of the drive where the cdc_raw_directory resides)

cdc_free_space_check_interval_ms

cdc_total_space_in_mbのしきい値に達し、CDCCompactorの実行が遅れるか、バック・プレッシャーが発生すると、CDCを追跡するテーブルに新しい空き領域を使用できるようになったかどうかを確認するためにこの間隔でチェックします。設定しない場合、デフォルトは250です。

デフォルト：コメントアウト（250）

コンパクションの設定

#concurrent_compactors: 1
# concurrent_validations: 0
concurrent_materialized_view_builders: 2
sstable_preemptive_open_interval_in_mb: 50
# pick_level_on_streaming: false

concurrent_compactors

1つのノードで同時に実行できる同時コンパクション・プロセスの数。anti-entropyリペア用の検証コンパクションは含まれません。同時コンパクションでは、1回の時間のかかるコンパクション中に小さいSSTableが累積する数を制限することにより、読み取りと書き込みが混在するワークロードでの読み取りパフォーマンスを維持しやすくなります。データ・ディレクトリーがSSDでサポートされている場合は、この値をコアの数まで増やしてください。コンパクションの実行が遅すぎる、または速すぎる場合は、まず、compaction_throughput_mb_per_secを調整してください。

重要: 同時接続コンパクター数を増やすと、特にSTCSでは同時コンパクションは並列処理されるため、コンパクションに使用可能なディスク領域をさらに使用することになります。この構成値を大きくする前に、十分なディスク領域を使用できることを確認します。

一般的に、計算されたデフォルト値は適切な値であり、調整する必要はありません。DataStaxでは、この値を変更する前に、DataStaxサービス・チームにご相談いただくことを推奨しています。

デフォルト：calculatedディスクの数とコアの数の一番小さい方（CPUコアあたりの最小値は2、最大値は8）。

concurrent_validations

可能な同時リペア検証の数。設定しない場合、デフォルトは無制限です。1未満の値の場合、無制限と解釈されます。

デフォルト：コメントアウト（0）無制限

concurrent_materialized_view_builders

同時実行可能な同時マテリアライズド・ビュー・ビルダー・タスクの数。ビューが作成されると、ノード範囲は（num_processors * 4）ビルダー・タスクに分割され、このExecutorに送信されます。

デフォルト：2

sstable_preemptive_open_interval_in_mb

推測的オープンをトリガーするSSTableのサイズ。コンパクション・プロセスで、コンパクションの書き込みが完全に終わる前にSSTableが開かれ、以前のSSTableに書き込まれた範囲の代わりに使用されます。プロセスは、キャッシュのチャーンを減らし、ホット行をホットに維持することによって、SSTable間の読み取りの転送がスムーズに行われるよう支援します。

重要: 低い値の場合、パフォーマンスに悪影響があり、最終的にヒープ圧力とGCアクティビティを引き起こします。最適な値は、ハードウェアと負荷によって異なります。

デフォルト：50

pick_level_on_streaming

ストリームインしたSSTableのコンパクション・レベル。

• true - LeveledCompactionStrategy (LCS)を使用するテーブルのストリームインしたSSTableは、ソース・ノードと同じレベルに配置されます。nodetool refreshやreplacing a node、true操作タスクは、コンパクション処理のパフォーマンスを改善します。
• false - ストリームインしたSSTableは、レベル0に配置されます。

設定しない場合、デフォルトはfalseです。

デフォルト：コメントアウト（false）

キャッシュとインデックスの設定

column_index_size_in_kb: 16
# file_cache_size_in_mb: 4096
# direct_reads_size_in_mb: 128

column_index_size_in_kb

パーティション内の行インデックスの細分性。巨大な行については、この設定値を小さくするとシーク時間が改善されます。密度の低いノードの場合、この値を4、2または1に減らすことで利点が生まれる場合があります。

デフォルト：16

file_cache_size_in_mb

DSE 6.7.0-6.7.2: バッファーのプーリングとSSTableチャーン・キャッシュの最大メモリー。バッファーのプーリング用に32 MBが予約されています。残りのメモリーは、最近使用したまたは頻繁に使用するインデックス・ページと非圧縮のSSTableチャンクを維持するためのキャッシュです。このプールにはオフヒープが割り当てられており、ヒープに割り当てられているメモリーの追加です。メモリーは必要な場合に限り、割り当てられます。

DSE 6.7.3以降の場合： バッファー・プールは、2つのプールに分割されます。この設定で、ファイル・キャッシュ内に格納されるファイル・バッファーを使用する最大メモリー（別名：チャンク・キャッシュ）を定義します。メモリーは必要な場合に限り、割り当てられますが、リリースされません。別のバッファー・プールは、direct_reads_size_in_mbです。

「Java仮想マシンの調整」を参照してください。

デフォルト： calculated (0.5 of -XX:MaxDirectMemorySize)

direct_reads_size_in_mb

DSE 6.7.3以降の場合： バッファー・プールは、2つのプールに分割されます。この設定で、一時的な読み取り操作のためのバッファー・プールを定義します。バッファーは一般的に読み取り操作で使用されてから、操作完了時にこのプールに返されますので、他の操作で再利用可能です。別のバッファー・プールは、file_cache_size_in_mbです。設定しない場合、デフォルトではTPCコア・スレッドあたり2 MBと計算され、さらに非TPCスレッドで2 MBが共有されます。最大値は128 MBです。

デフォルト：calculated

ディスクの設定

# stream_throughput_outbound_megabits_per_sec: 200
# inter_dc_stream_throughput_outbound_megabits_per_sec: 200
# streaming_keep_alive_period_in_secs: 300
# streaming_connections_per_host: 1

stream_throughput_outbound_megabits_per_sec

ノードのすべての送信ストリーミング・ファイル転送のスループットを抑制します。データベースは、ブートストラップ中またはリペア中のデータ・ストリーミングではほとんどの場合シーケンシャルI/Oを行いますが、これはネットワーク接続を飽和させ、クライアント（RPC）のパフォーマンスを低下させる場合があります。設定しない場合、値は200 Mbpsです。

デフォルト：コメントアウト（200）

inter_dc_stream_throughput_outbound_megabits_per_sec

データ・センター間のすべてのストリーミング・ファイル転送と、stream_throughput_outbound_megabits_per_secで構成されているネットワーク・ストリーム・トラフィックを抑制します。設定しない場合、値は200 Mbpsです。

注: 値は、合計スループットのサブセットであるため、stream_throughput_outbound_megabits_per_sec以下である必要があります。

デフォルト：コメントアウト（200）

streaming_keep_alive_period_in_secs

キープアライブ・メッセージを送信する間隔。2回のキープアライブ・サイクルでキープアライブ・メッセージを受信しない場合、ストリーム・セッションは失敗します。設定しない場合、デフォルトは300秒（5分）ですので、停止状態のストリームは10分以内でタイムアウトします。

デフォルト：コメントアウト（300）。

streaming_connections_per_host

ストリーミング用ホストあたりの最大接続数。結合が、ネットワーク・バウンドでなくCPUバウンドであることに気付いた際、この値を増やします。たとえば、大きなファイルを持ついくつかのノードの場合です。設定しない場合、デフォルトは1です。

デフォルト：コメントアウト（1）

Fsyncの設定

trickle_fsync: true
trickle_fsync_interval_in_kb: 10240

trickle_fsync

trueに設定すると、fsyncはオペレーティング・システムに対しtrickle_fsync_interval_in_kbに設定された間隔でダーティ・バッファーを強制的にフラッシュするように指示します。このパラメーターを有効にすると、突発的なダーティ・バッファーのフラッシュによって読み取りレイテンシーに影響が及ぶのを回避できます。SSDを使用している場合は推奨されますが、HDDの場合には推奨されません。

デフォルト：false

trickle_fsync_interval_in_kb

fsyncのサイズ（キロバイト）。

デフォルト： 10240

max_value_size_in_mb

SSTableの値の最大サイズ。しきい値を上回ると、SSTableは破損とマークされます。

デフォルト： 256

コアごとのスレッド（TPC）パラメーター

#tpc_cores:
# tpc_io_cores:
io_global_queue_depth: 128

NodeSyncパラメーター

nodesync:
    rate_in_kb: 1024

rate_in_kb

ローカル・ノードのデータ検証用の最大バイト/秒。最適な検証レートはノードごと異なります。

デフォルト：1024

高度なプロパティ

上級ユーザー用のプロパティまたは使用頻度の低いプロパティ。

高度な初期化プロパティ

batch_size_warn_threshold_in_kb: 64
batch_size_fail_threshold_in_kb: 640
unlogged_batch_across_partitions_warn_threshold: 10
# broadcast_address: 1.2.3.4
# listen_on_broadcast_address: false
# initial_token:
# num_tokens: 128
# allocate_tokens_for_local_replication_factor: 3
partitioner: org.apache.cassandra.dht.Murmur3Partitioner
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800

auto_bootstrap

この設定はデフォルトの構成からは削除されました。

• true - この設定により、シードでない新しいノードが適切なデータを自動的に自身に移行します。
• false - データのないフレッシュなクラスターを初期化する場合

ヒント: 「DataStax Enterpriseクラスターを初期化する」を参照してください。

設定しない場合、内部デフォルトはtrueです。

デフォルト：なし

batch_size_warn_threshold_in_kb

マルチ・パーティション・バッチ・サイズがキロバイト単位のこの値を上回った際、警告メッセージをログに記録するしきい値です。

注意: このしきい値を上げると、ノードが不安定になる可能性があります。

デフォルト： 64

batch_size_fail_threshold_in_kb

この値を上回るマルチ・パーティション・バッチで、失敗に対するしきい値とログの警告。デフォルト値はbatch_size_warn_threshold_in_kbの10倍の値です。

デフォルト： 640

unlogged_batch_across_partitions_warn_threshold

LOGGEDタイプでないバッチがこの制限値よりも多くのパーティションにまたがっている場合、WARNメッセージをログに記録するしきい値です。

デフォルト：10

broadcast_address

マルチ・リージョンのEC2デプロイでネットワーク外または複数のリージョンにわたり、このノードが他のノードへのブロードキャストに使用するパブリックIPアドレス。このプロパティをコメントアウトした場合、ノードはlisten_addressと同じIPアドレスまたはホスト名を使用します。ノードは、単一ノードまたは単一データ・センター・インストール、あるいはプライベート通信とパブリック通信の自動切り替えをサポートしているEC2ベースのネットワークでは、個別のbroadcast_addressを必要としません。複数の物理ネットワーク・インターフェイスを持つノードや、すべてのノードがそれぞれのプライベートIPアドレスを使用して他のノードにアクセスできるとは限らないその他のトポロジーのノードには、個別にlisten_addressとbroadcast_addressを設定する必要があります。特殊な構成については、listen_addressの説明を参照してください。

デフォルト：listen_address

listen_on_broadcast_address

ノードが両方のインターフェイスで通信できるようになるかどうか。

• true - このノードが複数の物理ネットワーク・インターフェイスを使用している場合、broadcast_addressに一意のIPアドレスを設定します。
• false - Amazon EC2のように、パブリック・ネットワークとプライベート・ネットワーク間で自動的にルーティングするネットワーク上にノードがある場合

ヒント: 「listen_address」を参照してください。

デフォルト：false

initial_token

連続する範囲を開始するためのトークン。個々のノードがリング空間で厳密に1つの連続する範囲を所有する、トークンごとに1つのノードが提供されるアーキテクチャーの場合はこのプロパティを設定します。このプロパティの設定はnum_tokensに優先します。

お使いのインストールでvnodeを使用していない場合、またはこのノードのnum_tokensを1に設定しているか、コメントアウトしている場合、プロダクション・クラスターを初めてセットアップするときと、容量を追加するときは、initial_token値を設定する必要があります。「トークンの生成」を参照してください。

このパラメーターは、スナップショットからの復元などの特殊なケースに限り、num_tokens（vnode）とともに使用します。

デフォルト：1（無効）

num_tokens

仮想ノード（vnode）トークン・アーキテクチャーを定義します。

注: データ・センター内の全ノードで、同じトークン・アーキテクチャーがある必要があります。

• 1 - レガシー互換性では、vnodeを無効にして、1トークンを使用します。
• 2～128の数字 - この仮想ノード（vnode）に割り当てるトークン範囲数を決定します。値が大きいと、データとワークロードが均一に分散される確率が増加します。
  制約事項: DataStaxでは、DSE Searchと共にvnodeを使用しないように推奨しています。ただし、DSE Searchと共にvnodeを使用することに決めた場合は、8個を超えるvnodeを使用しないようにし、allocate_tokens_for_local_replication_factorオプションが cassandra.yaml ファイルで環境に合わせて正しく構成されていることを確認してください。
  注意: vnodeの使用は、クラスターのパフォーマンスに影響を与える可能性があります。DataStaxでは、vnodeをプロダクション環境で有効にする前に構成をテストすることをお勧めしています。

  トークン番号がデータ・センター内のノード間で変わる場合、vnodeロジックはデータ・センター内の他のノードに比例して範囲の数を割り当てます。一般的に、すべてのノードが同じ能力のハードウェアを持っている場合、各ノードは同じnum_tokens値になります。

デフォルト：1（無効）

トークン範囲ごとに単一のノードがある状況からvnodeに既存のクラスターを移行するには、「既存のプロダクション・クラスターでの仮想ノードの有効化」を参照してください。

allocate_tokens_for_local_replication_factor

• データ・センター内のキースペースのRF- RFの推奨されるアルゴリズムによる割り当てと、このノードのnum_tokensをトリガーします。

  アルゴリズムの割り当ては、目標とするキースペース・レプリケーション係数を使用して、ワークロード・バランスを最適化します。DataStaxでは、トークン数を8に設定してワークロードをノード間に約10%の差異で分散させることを推奨しています。割り当てアルゴリズムは、指定されているRFに対して、データ・センター内のノードにレプリケートされる負荷を最適化するようにトークンを選択しようとします。各ノードに割り当てられる負荷は、vnodeの数の比率に近くなります。

  注: 割り当てアルゴリズムは、Murmur3PartitionerパーティショナーとRandomPartitionerパーティショナーでのみサポートされています。Murmur3Partitionerは、新しいクラスター用のデフォルトのパーティション分割ストラテジであり、新しいクラスターではほとんどの場合に適しています。
• commented out - ランダム選択アルゴリズムを使用して、トークン範囲をランダムに割り当てます。
  注: 時間の経過と共に、ランダム選択アルゴリズムを使用するデータ・センター内の負荷の分散が不均等になります。DataStaxは、割り当てアルゴリズムだけの使用を推奨しています。

デフォルト：コメントアウト（ランダム選択アルゴリズムを使用）

「仮想ノード（vnode）の構成」を参照し、セットアップ手順については、「vnodeが有効化されたクラスターに追加」または「クラスターにデータ・センターを追加」を参照してください

partitioner

クラスター内のすべてのノードに行を（パーティション・キー別に）配布するクラスです。クラス・パス内にあるものであれば、独自のものも含めて、任意のIPartitionerを使用できます。新しいクラスターについては、デフォルトのパーティショナーを使用してください。

後方互換性を維持するため、DataStax Enterpriseには以下のパーティショナーが用意されています。

• RandomPartitioner
• ByteOrderedPartitioner（廃止予定）
• OrderPreservingPartitioner（廃止予定）

重要: DSEにバンドルされているパーティショナー実装以外は使用しないでください。

ヒント: 「パーティショナー」を参照してください。

デフォルト： org.apache.cassandra.dht.Murmur3Partitioner

tracetype_query_ttl

クエリーのロギング・プロセス中に使用される異なるトレース・タイプに対するTTL。

デフォルト：86400

tracetype_repair_ttl

リペアのロギング・プロセス中に使用される異なるトレース・タイプに対するTTL。

デフォルト：604800

高度な自動バックアップの設定

auto_snapshot: true

auto_snapshot

キースペースのTRUNCATEを行う前やテーブルを削除する前に、データのスナップショットを取得するかどうか。データ喪失を回避するために、DataStaxではデフォルトの設定を使用することを強く推奨します。auto_snapshotをfalseに設定すると、TRUNCATEまたは削除の際にデータが失われます。

デフォルト：true

Global row properties

column_index_cache_size_in_kb: 2
# row_cache_class_name: org.apache.cassandra.cache.OHCProvider
row_cache_size_in_mb: 0
row_cache_save_period: 0
# row_cache_keys_to_save: 100

テーブルの作成時または変更時に、キャッシング・パラメーターの設定により、そのテーブルの行キャッシュを有効または無効にすることができます。その他の行とキャッシュの調整と構成のオプションは、グローバル（ノード）レベルで設定されます。データベースはこれらの設定を使用し、全体のワークロードと特定のテーブル使用量に基づいて、ノードの各テーブルに対して自動的にメモリーを分配します。これらのキャッシュを保存する期間もグローバルに構成できます。

column_index_cache_size_in_kb

（BIG形式のSSTableにのみ適用）データベースがパーティション・キー・キャッシュ内に格納するパーティションのすべてのインデックス・エントリーの合計サイズのしきい値。パーティションのすべてのインデックス・エントリーの合計サイズがこの容量を上回ると、このパーティションのエントリーはパーティション・キー・キャッシュに配置されなくなります。

デフォルト：2

row_cache_class_name

使用する行キャッシュ・プロバイダーのクラス名。有効な値：

• org.apache.cassandra.cache.OHCProvider - 完全なオフヒープ
• org.apache.cassandra.cache.SerializingCacheProvider - 部分的なオフヒープ、以前のリリースで使用可能

重要: DSEにバンドルされている行キャッシュ・プロバイダー実装以外は使用しないでください。

設定しない場合、デフォルトはorg.apache.cassandra.cache.OHCProvider（完全なオフヒープ）です。

デフォルト：コメントアウト（org.apache.cassandra.cache.OHCProvider）

row_cache_size_in_mb

メモリー内の行キャッシュの最大サイズ。行キャッシュを使用すると時間を節約できますが、行全体が含まれるため多くの容量を使用します。行キャッシュは、ホット行か、または静的行のみで使用してください。サイズを減らすと、起動時に最もホットなキーが読み込まれないことがあります。

• 0 - 行キャッシングは無効
• MB - メモリー内の行キャッシュの最大サイズ

デフォルト：0（無効）

row_cache_save_period

行をキャッシュに保存する期間（秒）。キャッシュはsaved_caches_directoryに保存されます。この設定は、row_cache_size_in_mbで説明したとおり、用法が限られています。

デフォルト：0（無効）

row_cache_keys_to_save

行キャッシュから保存するキーの数。すべてのキーが保存されます。

デフォルト：コメントアウト（100）

カウンター・キャッシュのプロパティ

counter_cache_size_in_mb:
counter_cache_save_period: 7200
# counter_cache_keys_to_save: 100

カウンター・キャッシュは、ホットなカウンター・セルのカウンター・ロックの競合を軽減させるのに役立ちます。RF = 1の場合、カウンター・キャッシュ・ヒットがあると、データベースは全体を書き込む前に読み取りをスキップします。RF > 1の場合も、カウンター・キャッシュ・ヒットがあるとロック保持期間が短縮されるため、ホットなカウンター・セルの更新に役立ちますが、読み取り全体をスキップすることはできません。ローカルな（クロック、カウント）カウンター・セルのタプルのみがメモリー内に保持され、カウンター全体は保持されないため、比較的負担が少なくて済みます。

counter_cache_size_in_mb

値を設定しない場合、ヒープの最小値2.5%と50メガバイト（MB）の小さい方が使用されます。お使いのシステムでカウンター削除を実施し、小さいgc_grace_secondsを使用する場合は、カウンター・キャッシュを無効にしてください。無効にするには、0に設定します。

デフォルト：calculated

counter_cache_save_period

データベースがカウンター・キャッシュを保存するまでの秒単位の時間（キーのみ）データベースはキャッシュをsaved_caches_directoryに保存します。

デフォルト：7200（2時間）

counter_cache_keys_to_save

カウンター・キャッシュから保存するキーの数。設定しない場合、データベースはすべてのキーを保存します。

デフォルト：コメントアウト（無効、すべてのキーを保存）

トゥームストーンの設定

tombstone_warn_threshold: 1000
                                tombstone_failure_threshold: 100000

パーティションの内部または各パーティションにわたってスキャンを実行するとき、トゥームストーンをコーディネーターに返せるように、トゥームストーンがメモリー内に維持されている必要があります。コーディネーターがトゥームストーンを使用することで、削除済みの行について他のレプリカが確実に認識できるようになります。大量のトゥームストーンを生成するワークロードは、パフォーマンス問題の原因となり、サーバーのヒープを使い果たしてしまうことがあります。この影響を理解した上でスキャンするトゥームストーンの数を増やす場合にのみ、これらのしきい値を調整してください。StorageServiceMBeanを使用して、実行中にもこれらのしきい値を調整できます。

tombstone_warn_threshold

クエリーがこの数字より多くのトゥームストーンをスキャンした場合に警告が生成されます。

デフォルト：1000

tombstone_failure_threshold

クエリーがこの数字より多くのトゥームストーンをスキャンした場合、クエリーが中断されます。

デフォルト： 100000

ネットワーク・タイムアウトの設定

read_request_timeout_in_ms: 5000
range_request_timeout_in_ms: 10000
aggregated_request_timeout_in_ms: 120000
write_request_timeout_in_ms: 2000
counter_write_request_timeout_in_ms: 5000
cas_contention_timeout_in_ms: 1000
truncate_request_timeout_in_ms: 60000
request_timeout_in_ms: 10000
# cross_dc_rtt_in_ms: 0

read_request_timeout_in_ms

デフォルト：5000。タイムアウトする前に、コーディネーターが読み取り操作の完了を待つ時間。

range_request_timeout_in_ms

デフォルト：10000。タイムアウトする前に、コーディネーターがシーケンシャル・スキャンまたはインデックス・スキャンの完了を待つ時間。

aggregated_request_timeout_in_ms

コーディネーターがシーケンシャル・スキャンまたはインデックス・スキャンの完了を待つ時間。許容可能な最低値は、10 msです。このタイムアウトは、SELECT、COUNT(*)、MIN(x)といった集計されたクエリーには適用されません。

デフォルト：120000（2分）

write_request_timeout_in_ms

ローカル・データ・センターの1つ以上のノードにおいて、コーディネーターが書き込み要求の完了を待つ時間。許容可能な最低値は、10 msです。

ヒント: 「ヒンテッド・ハンドオフ、書き込みパス中のリペアの説明」を参照してください。

デフォルト：2000（2秒）

counter_write_request_timeout_in_ms

タイムアウトする前に、コーディネーターがカウンター書き込みの完了を待つ時間。

デフォルト：5000（5秒）

cas_contention_timeout_in_ms

コーディネーターが、共通の行に対する他の操作と競合するCAS（compare-and-set）操作をリトライし続ける時間。この時間内にコーディネーターが操作を完了できない場合、操作は中断されます。

デフォルト：1000（1秒）

truncate_request_timeout_in_ms

タイムアウトする前に、コーディネーターがTRUNCATE（テーブルから全データを削除）操作の完了を待つ時間。デフォルト値を大きくすると、データを削除する前にスナップショットを取得することができます。auto_snapshotが無効の場合（非推奨）、この時間を短縮できます。

デフォルト：60000（1分）

request_timeout_in_ms

その他のさまざまな操作のデフォルトのタイムアウト値。許容可能な最低値は、10 msです。

ヒント: 「ヒンテッド・ハンドオフ、書き込みパス中のリペアの説明」を参照してください。

デフォルト：10000

cross_dc_rtt_in_ms

リモート・データ・センターのノードだけが関連する要求に対して、データ・センター全体のタイムアウトを増加させる量（write_request_timeout_in_ms + cross_dc_rtt_in_ms）。この設定は、ヒント圧力を抑えることを目的としています。

ヒント: DataStaxでは、複数のデータ・センターのデプロイにおける読み取りと書き込み要求に対して、LOCAL_*の整合性レベル（CL）を使用することを推奨しています。これは、QUORUMなどのCLを満たす際にリモート・ノードが選ばれている場合に発生する可能性があるタイムアウトを回避するためです。

デフォルト：コメントアウト（0）

slow_query_log_timeout_in_ms

デフォルト：500。ノードがスロー・クエリーのログへの記録を開始するまでの時間。クエリーがこの値を上回ると、スロー・クエリーを示す集計されたログ・メッセージが生成されます。無効にするには、0に設定します。

Inter-node settings

storage_port: 7000
cross_node_timeout: false
# internode_send_buff_size_in_bytes:
# internode_recv_buff_size_in_bytes:
internode_compression: dc
inter_dc_tcp_nodelay: false

storage_port

ノード間通信用のポート。セキュリティ上のベスト・プラクティスに従ってください。このポートをインターネット上で公開しないでください。ファイアウォール・ルールを適用します。

ヒント: 「DataStax Enterpriseポートのセキュリティ保護」を参照してください。

デフォルト： 7000

cross_node_timeout

要求のタイムアウトを正確に測定するためのノード間での操作タイムアウト情報の交換を有効にするかどうか。このプロパティが無効になっている場合、レプリカはコーディネーターによって要求がレプリカに即座に転送されたと見なします。このため、過負荷の状況では、すでにタイムアウトしている要求を処理する余分な時間が必要になります。

注意: このプロパティを有効にする前に、NTP（Network Time Protocol）がインストールされ、ノード間で時刻が同期していることを確認してください。

デフォルト：false

internode_send_buff_size_in_bytes

ノード間呼び出し用の送信ソケット・バッファー・サイズ（バイト）。

ヒント: 「TCPの設定」を参照してください。

送信ソケット・バッファー・サイズとinternode_recv_buff_size_in_bytesは、net.core.wmem_maxによって制限されています。このプロパティが設定されていない場合、net.ipv4.tcp_wmemによってバッファー・サイズが決定されます。詳細については、man tcpを実行し、以下を参照ください。

• /proc/sys/net/core/wmem_max
• /proc/sys/net/core/rmem_max
• /proc/sys/net/ipv4/tcp_wmem
• /proc/sys/net/ipv4/tcp_wmem

デフォルト：設定されていません

internode_recv_buff_size_in_bytes

ノード間呼び出し用の受信ソケット・バッファー・サイズ（バイト）。

デフォルト：設定されていません

internode_compression

ノード間のトラフィックを圧縮するかどうかを制御します。有効な値：

• all - すべてのトラフィックを圧縮します。
• dc - データ・センター間のトラフィックのみ圧縮します。
• none - 圧縮なし。

デフォルト： dc

inter_dc_tcp_nodelay

データ・センター間の通信用に、tcp_nodelayを有効にするかどうか。無効になっている場合、ネットワークはサイズが大きいネットワーク・パケットを少数、送信します。これはTCPプロトコルのオーバーヘッドを低減します。ただし、inter_dc_tcp_nodelayを無効にすると、データ・センターを横断する応答がブロックされ、レイテンシーが増加する場合があります。

デフォルト：false

ネイティブ転送（CQLバイナリー・プロトコル）

start_native_transport: true
native_transport_port: 9042
# native_transport_port_ssl: 9142
# native_transport_max_frame_size_in_mb: 256
# native_transport_max_concurrent_connections: -1
# native_transport_max_concurrent_connections_per_ip: -1
native_transport_address: localhost
# native_transport_interface: eth0
# native_transport_interface_prefer_ipv6: false
# native_transport_broadcast_address: 1.2.3.4
native_transport_keepalive: true

start_native_transport

ネイティブ・トランスポート・サーバーを有効または無効にします。

デフォルト：true

native_transport_port

CQLネイティブ・トランスポートがクライアントをリッスンするポート。セキュリティ上の理由から、このポートをインターネット上で公開しないでください。必要に応じてファイアウォールを設定します。

デフォルト：9042

native_transport_max_frame_size_in_mb

許可されるフレーム・サイズの最大値。これよりも大きいフレーム（要求）は無効として拒否されます。

デフォルト：256

native_transport_max_concurrent_connections

同時クライアント接続の最大数。

デフォルト：-1（無制限）

native_transport_max_concurrent_connections_per_ip

ソースIPアドレスごとの同時クライアント接続の最大数。

デフォルト：-1（無制限）

native_transport_address

空白のままにする場合、ノードに構成されているホスト名構成を使用します。listen_addressとは異なりこの値を0.0.0.0に設定することができますが、native_transport_broadcast_addressを0.0.0.0以外の値に設定する必要があります。

注: native_transport_addressまたはnative_transport_interfaceを設定します。両方は設定できません。

デフォルト：localhost

native_transport_interface

IPの別名使用はサポートされていません。

注: native_transport_addressまたはnative_transport_interfaceを設定します。両方は設定できません。

デフォルト： eth0

native_transport_interface_prefer_ipv6

インスタンスを名前で指定する際は、IPv4またはIPv6を使用します。

• false - 最初のIPv4アドレスを使用します。
• true - 最初のIPv6アドレスを使用します。

1つのアドレスだけを使用する場合、この設定に関係なく、そのアドレスが選択されます。

デフォルト：コメントアウト（false）

native_transport_broadcast_address

ドライバーおよび他のDSEノードにブロードキャストするためのネイティブ・トランスポート・アドレス。0.0.0.0に設定することはできません。

• blank - native_transport_addressの値に設定されます
• IP_address - native_transport_addressが、0.0.0.0に設定されている場合

デフォルト：コメントアウト（1.2.3.4）

native_transport_keepalive

キープアライブをネイティブ接続で有効にするかどうか。

デフォルト：true

高度な障害検知の設定

# gc_log_threshold_in_ms: 200
# gc_warn_threshold_in_ms: 1000
# otc_coalescing_strategy: DISABLED
# otc_coalescing_window_us: 200
# otc_coalescing_enough_coalesced_messages: 8

gc_log_threshold_in_ms

INFOレベルのログ・メッセージのしきい値。ロギングを最小化するように調整します。

デフォルト：コメントアウト（200）

gc_warn_threshold_in_ms

GCの一時停止のしきい値。GCがこの間隔よりも長く一時停止すると、WARNレベルでログに記録されます。デフォルトでは、GCが200 msよりも長く一時停止するとINFOレベルでログに記録されます。

ヒント: 「ロギングの構成」を参照してください。

デフォルト：コメントアウト（1000）

otc_coalescing_strategy

同じデータ・センターのノードへの送信TCP接続のために、複数のネットワーク・メッセージを単一パケットに結合するストラテジ。DataStax開発者のブログの投稿「メッセージの結合によるパフォーマンスの倍増」を参照してください。

重要: DSEにバンドルされているストラテジ実装以外は使用しないでください。

サポートされているストラテジは、

• FIXED
• MOVINGAVERAGE
• TIMEHORIZON
• DISABLED

デフォルト：コメントアウト（DISABLED）

otc_coalescing_window_us

同じデータ・センターにあるメッセージをノードに結合するまで待機する時間（マイクロ秒）。

• FIXEDストラテジでは、最初のメッセージを受信してから結合されるメッセージと共に送信されるまでの時間です。
• MOVING平均では、結合されるメッセージが平均して着信していなければならない最大待機時間と期間です。

デフォルト：コメントアウト（200）

otc_coalescing_enough_coalesced_messages

同じデータ・センター内のノードに対するメッセージ数のしきい値。この値を上回る場合、メッセージを結合しないでください。この値は2より大きく、128未満である必要があります。

デフォルト：コメントアウト（8）

seed_gossip_probability

ゴシップの各ラウンド中に、ゴシップ・メッセージがシード・ノードに送信される時間（パーセント）。クラスター全体でゴシップの伝搬を変更する時間を短縮します。

デフォルト：1.0（100%）

バック・プレッシャーの設定

back_pressure_enabled: false
                                back_pressure_strategy:
                                - class_name: org.apache.cassandra.net.RateBasedBackPressure
                                parameters:
                                - high_ratio: 0.90
                                factor: 5
                                flow: FAST

back_pressure_enabled

コーディネーターが、レプリカに送信される各ミューテーションに、指定されたバック・プレッシャー・ストラテジを適用するかどうか。

デフォルト：false

back_pressure_strategy

新しいストラテジを追加するには、org.apache.cassandra.net.BackpressureStrategyを実装し、Map<String, Object>を受け入れるパブリック・コンストラクターを指定します。

重要: DSEにバンドルされているストラテジ実装以外は使用しないでください。

class_name

デフォルトのclass_nameは、受信したミューテーション応答と送信したミューテーション要求の比率を使用します。

デフォルト： org.apache.cassandra.net.RateBasedBackPressur

high_ratio

送信したミューテーションがこの値を下回ると、受信速度に応じて速度制限され、速度制限は係数に従い減少します（以下で説明します）。この値を上回ると、速度制限は係数に従い増加します。

デフォルト： 0.90

factor

1～10の数字。バックプレッシャーが、この値を下回ると、受信速度に応じて速度制限され、速度制限は所定係数に従い減少します。この値を上回ると、速度制限は所定の係数に従い増加します。

デフォルト：5

flow

速度制限を適用するフロー速度。

• FAST - 最も高速のレプリカ速度に速度制限されます
• SLOW - 最も低速のレプリカ速度に速度制限されます

デフォルト： FAST

dynamic_snitch_badness_threshold

低パフォーマンスのノードからクライアント要求を別のノードに動的にルーティングするためのパフォーマンスしきい値。具体的には、低パフォーマンスのノードの状態がどの程度悪化すると動的スニッチが他のレプリカを優先するかを制御します。値を0.2にすると、そのノードの応答時間が最高パフォーマンスのノードよりも20%低下するまで、データベースが静的スニッチ値を継続して使用します。このしきい値に達するまで、受信した要求は最も近いレプリカ（スニッチで決定される）に静的にルーティングされます。

デフォルト：0.1

dynamic_snitch_reset_interval_in_ms

すべてのノード・スコアをリセットする時間間隔。これにより、不良ノードを復元できます。

デフォルト：600000

dynamic_snitch_update_interval_in_ms

ノード・スコアを計算する間のミリ秒単位の時間間隔。スコアの計算はCPUに負担がかかるので、この間隔を減らす際には注意してください。

デフォルト：100

ヒンテッド・ハンドオフのオプション

hinted_handoff_enabled: true
# hinted_handoff_disabled_datacenters:
#    - DC1
#    - DC2
max_hint_window_in_ms: 10800000 # 3 hours
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
hints_directory: /var/lib/cassandra/hints
hints_flush_period_in_ms: 10000
max_hints_file_size_in_mb: 128
#hints_compression:
#   - class_name: LZ4Compressor
#     parameters:
#         -
batchlog_replay_throttle_in_kb: 1024
# batchlog_endpoint_strategy: random_remote

hinted_handoff_enabled

ヒンテッド・ハンドオフを有効または無効にします。ヒントは、利用不能だったノードを対象に書き込みをリプレイする必要があることを示します。コーディネーター・ノードのヒント・ファイルにヒントが書き込まれます。

• false - ヒンテッド・ハンドオフを有効にしないでください
• true - hinted_handoff_disabled_datacentersで指定されているデータ・センターを除き、全体のヒンテッド・ハンドオフを有効にします

デフォルト：true

hinted_handoff_disabled_datacenters

ヒンテッド・ハンドオフを実行しないデータ・センターのブラックリスト。特定のデータ・センターでヒンテッド・ハンドオフを無効にするには、その名前をリストに追加します。

デフォルト：コメントアウト

max_hint_window_in_ms

応答しないノードに対してヒントが生成される最大時間。この時間の経過後は、そのノードが復帰して応答するまで、新しいヒントは生成されません。復帰後にノードが再度ダウンすると、新しい間隔が開始されます。この設定により、ノードがオンラインに復帰したときに、突然リソースを要求し、クラスター内の残りのノードが大量のヒンテッド書き込みをリプレイしようとするのを防止できます。

ヒント: 「障害検知と復旧について」を参照してください。

デフォルト：10800000（3時間）

hinted_handoff_throttle_in_kb

配信スレッドあたりの最大トラフィック量（キロバイト/秒）。この速度は、クラスター内のノードの数に比例して低下します。たとえば、クラスター内に2つのノードがある場合、各配信スレッドで最大速度を使用します。3つある場合は、2つのノードが同時にヒントを配信することが予想されるため、各ノードは最大値の半分に抑制します。

注: この制限を適用すると、internode_compressionまたはhints_compressionが有効になっている場合でも、計算されたヒント送信率は圧縮されていないヒント・サイズに基づきます。

デフォルト：1024

hints_flush_period_in_ms

内部バッファーからディスクにヒントをフラッシュするまで、待機する時間（ミリ秒）。

デフォルト：10000

max_hints_delivery_threads

ヒントの配信に使用するスレッド数。マルチ・データ・センター・デプロイの場合、データ・センター間の受け渡しは一般的に低速のため、この数を増やすことを検討してください。

デフォルト：2

max_hints_file_size_in_mb

1つのヒント・ファイルの最大サイズ（メガバイト）。

デフォルト：128

hints_compression

ヒント・ファイルの圧縮形式。サポートされている圧縮形式は、LZ、Snappy、Deflateです。設定しない場合、データベースはヒント・ファイルを圧縮しません。

デフォルト：LZ4Compressor

batchlog_replay_throttle_in_kb

ヒントのリプレイ用の合計最大スロットル（KB/秒）。スロットリングは、クラスター内のノード数に比例して低くなります

デフォルト：1024

batchlog_endpoint_strategy

バッチログ・ストレージ・エンドポイントを選ぶストラテジ。

• random_remote - デフォルト。純粋なランダムです。可能な場合、ローカル・ラックを防ぎます。以前のリリースと同じ動作。
• dynamic_remote - DynamicEndpointSnitchを使用して、バッチログ・ストレージ・エンドポイントを選択します。可能な場合、ローカル・ラックを防ぎます。このストラテジでは、random_remoteと同じ可用性保証が用意されていますが、DynamicEndpointSnitchに応じて最速のエンドポイントを選択します。DynamicEndpointSnitchは、読み取りは追跡しますが、書き込みは追跡しません。書き込み専用、または大半は書き込み、ワークロードは、このストラテジから利益は得られない可能性があります。注：このストラテジは、dynamic_snitchが有効でない場合、random_remoteに戻ります。
• dynamic - random_remote or dynamic_remoteよりも低い可用性保証が用意されているローカル・ラックが除外されていない点を除き、ほとんどdynamic_remoteと同じです。注：このストラテジは、dynamic_snitchが有効でない場合、random_remoteに戻ります。

デフォルト： random_remote

セキュリティ・プロパティ

DSE Advanced Security（DSE拡張セキュリティ）は、意図的な攻撃やユーザー・エラーによる潜在的な危険に対してDataStax Enterprise（DSE）データベースを強化します。構成プロパティには、認証と権限管理、パーミッション、ロール、転送中のデータと保存されたデータの暗号化、データ監査が含まれます。DSE Unified Authenticationには、認証、権限付与、ならびにロール管理が用意されています。DSE Unified Authenticationを有効にするには、dse.yamlで追加の構成が必要です。「DSE Unified Authentication（DSE統合認証）の構成」を参照してください。

authenticator: com.datastax.bdp.cassandra.auth.DseAuthenticator
# internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
authorizer: com.datastax.bdp.cassandra.auth.DseAuthorizer
role_manager: com.datastax.bdp.cassandra.auth.DseRoleManager
system_keyspaces_filtering: false
roles_validity_in_ms: 120000
# roles_update_interval_in_ms: 120000
permissions_validity_in_ms: 120000
# permissions_update_interval_in_ms: 120000

authenticator

認証のバックエンド。サポートされているオーセンティケーターは、Kerberos、LDAP、内部認証など、複数の認証スキームを持つ外部認証用のDseAuthenticatorのみです。DseAuthenticator以外のオーセンティケーターは、廃止予定であり、サポートされていません。他のオーセンティケーターを使用する場合、一部のセキュリティ機能が正常に動作しない場合があります。dse.yamlの「authentication_options」を参照してください。

重要: DSEにバンドルされている認証実装以外は使用しないでください。

デフォルト： com.datastax.bdp.cassandra.auth.DseAuthenticator

internode_authenticator

ピア・ノードから、安全な接続を有効にするためのノード間の認証バックエンド。

重要: DSEにバンドルされている認証実装以外は使用しないでください。

デフォルト： org.apache.cassandra.auth.AllowAllInternodeAuthenticator

authorizer

権限管理のバックエンド。DseAuthorizer以外のオーソライザーはサポートされていません。DseAuthorizerは、DSE固有のリソースに関する、強化されたパーミッション管理機能をサポートしています。DseAuthorizer以外のオーソライザーは廃止予定であり、サポートされていません。他のオーソライザーを使用している場合、一部のセキュリティ機能が正常に動作しない場合があります。dse.yamlの「権限管理オプション」を参照してください。

重要: DSEにバンドルされている権限実装以外は使用しないでください。

デフォルト： com.datastax.bdp.cassandra.auth.DseAuthorizer

system_keyspaces_filtering

システム・キースペースのフィルタリングを有効にするかどうかで、ユーザーはシステム内の行に関するスキーマ情報にアクセスしたり、この情報とアクセス権があるsystem_schemaキースペースだけを表示することができます。

重要: セキュリティ要件およびユーザー・パーミッションが適用されます。適切なユーザー・パーミッションが付与されてから、この機能を有効にします。キースペースのDESCRIBEパーミッションをロールに付与する必要があります。パーミッションを付与しない場合、キーボードが見つかりませんでしたというエラーが表示されます。

GRANT DESCRIBE ON KEYSPACE keyspace_name
TO ROLE role_name;

ヒント: 「キースペースとテーブルへのアクセスを管理する」と「セキュリティ・キースペースのレプリケーション係数を構成する」を参照してください。

デフォルト：false

role_manager

DSE Role Manager（DSEロール・マネージャー）は、CassandraRoleManagerによってサポートされているLDAPロールと内部ロールをサポートしています。ロール・オプションは、dse_security keyspaceに格納されます。DSE Role Manager（DSEロール・マネージャー）を使用する場合は、dse_securityキースペースのレプリケーション係数を大きくしてください。DseAuthorizer以外のロール・マネージャーは廃止予定であり、サポートされていません。他のロール・マネージャーを使用している場合、一部のセキュリティ機能が正常に動作しない場合があります。

重要: DSEにバンドルされているロール・マネージャー実装以外は使用しないでください。

デフォルト： com.datastax.bdp.cassandra.auth.DseRoleManager

roles_validity_in_ms

ロール・キャッシュの有効期間（ミリ秒）。ユーザーに割り当てられているロールのリストをキャッシュする時間を指定します。ユーザーは、直接割り当てられたり、継承（別のロールに付与されたロール）したりすることで、複数のロールを持つ場合があります。ロール階層の複雑さ、ロール変更に対する許容範囲、環境内のノード数、クラスターのアクティビティー・レベルなどに基づいて、この設定を調整します。

パーミッションのフェッチは高負荷操作になる場合があり、この設定を使うことで柔軟性が得られます。認証セッションで付与されたロールは、AuthenticatedUserにキャッシュされます。指定された時間を過ぎると、ロールの有効性が再度チェックされます。DseAuthenticatorの使用時に内部認証が有効でない場合、自動的に無効になります。

• 0 - ロール・キャッシングは無効
• milliseconds - ユーザーに割り当てられているロールのリストをキャッシュする時間

デフォルト：120000（2分）

roles_update_interval_in_ms

ロール・キャッシュの更新間隔を有効にします。この間隔を過ぎると、キャッシュ・エントリーを更新できるようになります。次回アクセス時に、非同期の再読み込みがスケジュールされ、再読み込みが完了するまで古い値が返されます。roles_validity_in_msがゼロではない場合、こちらもゼロ以外の値でなければなりません。設定しない場合、デフォルトはroles_validity_in_msと同じ値です。

デフォルト：コメントアウト（120000）

permissions_validity_in_ms

パーミッション・クエリーがパフォーマンスに及ぼす影響を管理するために、キャッシュ内のパーミッションが有効と見なされる期間。パーミッションのフェッチはリソースを多く消費する場合があります。セキュリティの許容範囲に合わせてキャッシュの有効期間を設定します。このキャッシュは、標準認証と行レベル・アクセス制御（RLAC）キャッシュに使用されます。キャッシュが完全に有効なのは短い期間です。

• 0 - パーミッション・キャッシングは無効
• milliseconds - 実行時間（単位はミリ秒）

注意: REVOKEは、キャッシュされたパーミッションを自動的には無効にしません。パーミッションは、次回更新された際に無効になります。

デフォルト：120000（2分）

permissions_update_interval_in_ms

標準認証キャッシュと行レベル・アクセス制御（RLAC）キャッシュの更新間隔を設定します。この間隔を過ぎると、キャッシュ・エントリーを更新できるようになります。次回アクセス時に、非同期の再読み込みがスケジュールされ、再読み込みが完了するまで古い値が返されます。permissions_validity_in_msがゼロではない場合、roles_update_interval_in_msもゼロ以外の値でなければなりません。設定しない場合、デフォルトはpermissions_validity_in_msと同じ値です。

デフォルト：コメントアウト（2000）

permissions_cache_max_entries

標準認証キャッシュと行レベル・アクセス制御（RLAC）キャッシュで保持されるエントリーの最大数。デフォルト値1000の場合、RLACパーミッション・キャッシュは最大で1000のエントリーを保持でき、標準認証キャッシュも最大で1000のエントリーを保持できます。このオプションは両方のキャッシュに適用されます。行レベル・アクセス制御（RLAC）の設定も行う場合にパーミッション・キャッシュのサイズを指定するには、以下の式を使用します。

numRlacUsers * numRlacTables + 100

このオプションがcassandra.yamlに含まれていない場合は、手動で入力して1000以外の値を使用します。「DSE Unified Authentication（DSE統合認証）の有効化」を参照してください。

デフォルト：設定されていません（1000）

ノード間暗号化オプション

ノード間の暗号化では、クラスター内のノード間で転送されるデータをSSLを使用して保護します。

server_encryption_options:
    internode_encryption: none
    keystore: resources/dse/conf/.keystore
    keystore_password: cassandra
    truststore: resources/dse/conf/.truststore
    truststore_password: cassandra
    # More advanced defaults below:
    # protocol: TLS
    # algorithm: SunX509
    # keystore_type: JKS
    # truststore_type: JKS
    # cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
    # require_client_auth: false
    # require_endpoint_verification: false

server_encryption_options

ノード間暗号化オプション有効にする場合、キーを生成して、適切なキーの場所とトラストストアの場所およびパスワードを指定する必要があります。カスタムの暗号化オプションはサポートされていません。

ヒント: これらのオプションで使用するパスワードは、キーストアおよびトラストストアの生成時に使用したパスワードと一致する必要があります。これらのファイルの生成手順については、「JSSEで使用するキーストアの作成」を参照してください。

ヒント: 「ノード間接続用にSSLを構成する」を参照してください。

internode_encryption

認証、キー交換、およびデータ転送の暗号化にTLS_RSA_WITH_AES_128_CBC_SHA暗号化スイートを使用するノード間通信用の暗号化オプション。（連邦情報処理標準）FIPS 140準拠モードで実行している場合は、TLS_DHE_RSA_WITH_AES_128_CBC_SHAなど、DHE/ECDHE暗号を使用してください。

• all -すべてのノード間通信を暗号化します
• none - 暗号化は行いません
• dc -データ・センター間のトラフィックを暗号化します（サーバーのみ）
• rack - ラック間のトラフィックを暗号化します（サーバーのみ）

デフォルト： none

keystore

DSEインストール・ディレクトリからの相対パス、またはJava keystore（JKS）の絶対パスは、Java Secure Socket Extension（JSSE）との使用に適しています。これはSecure Sockets Layer（SSL）とTransport Layer Security（TLS）の各プロトコルのJava版です。このキーストアには送信メッセージの暗号化に使用される秘密鍵が含まれます。

デフォルト：resources/dse/conf/.keystore

keystore_password

キーストア用のパスワード。これは、キーストアおよびトラストストアの生成時に使用したパスワードと一致する必要があります。

デフォルト：cassandra

truststore

DSEインストール・ディレクトリからの相対パス、またはリモート・サーバーの認証に必要な信頼できる証明書を含むトラストストアの絶対パス。

デフォルト：resources/dse/conf/.truststore

truststore_password

トラストストア用のパスワード。

デフォルト：cassandra

protocol

デフォルト：コメントアウト（TLS）

algorithm

デフォルト：コメントアウト（SunX509）

keystore_type

有効なタイプは、JKS、JCEKS、PKCS12、またはPKCS11です。ファイルベースのキーストアの場合、PKCS12を使用します。

デフォルト：コメントアウト（JKS）

truststore_type

有効なタイプは、JKS、JCEKS、PKCS12、またはPKCS11です。

デフォルト：コメントアウト（JKS）

cipher_suites

サポートされている暗号：

• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

デフォルト：コメントアウト

require_client_auth

ノードツーノード（ノード間）暗号化のための証明書認証を有効にするかどうか。設定しない場合、デフォルトはfalseです。

デフォルト：コメントアウト（false）

require_endpoint_verification

接続先のホストと証明書のホスト名が一致することを確認するかどうか。設定しない場合、デフォルトはfalseです。

デフォルト：コメントアウト（false）

クライアントとノード間の暗号化のオプション

client_encryption_options:
    enabled: false
    # If enabled and optional is set to true, encrypted and unencrypted connections over native transport are handled.
    optional: false
    keystore: resources/dse/conf/.keystore
    keystore_password: cassandra
    # require_client_auth: false
    # Set trustore and truststore_password if require_client_auth is true
    # truststore: resources/dse/conf/.truststore
    # truststore_password: cassandra
    # More advanced defaults below:
    # protocol: TLS
    # algorithm: SunX509
    # keystore_type: JKS
    # truststore_type: JKS
    # cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]

client_encryption_options

クライアントとノード間の暗号化を有効にするかどうか。キーを生成して、適切なキーの場所とトラストストアの場所およびパスワードを指定する必要があります。DataStax Enterpriseに使用できるカスタムの暗号化オプションはありません。

詳細設定は以下のとおりです。

enabled

クライアントとノード間の暗号化を有効にするかどうか。

デフォルト：false

optional

クライアント暗号化が有効な場合は、セキュアでない接続を使用できるかどうか。

デフォルト：false

keystore

DSEインストール・ディレクトリからの相対パス、またはJava keystore（JKS）の絶対パスは、Java Secure Socket Extension（JSSE）との使用に適しています。これはSecure Sockets Layer（SSL）とTransport Layer Security（TLS）の各プロトコルのJava版です。このキーストアには送信メッセージの暗号化に使用される秘密鍵が含まれます。

デフォルト：resources/dse/conf/.keystore

keystore_password

キーストア用のパスワード。

デフォルト：cassandra

require_client_auth

ノードツーノード暗号化のための証明書認証を有効にするかどうか。

デフォルト：コメントアウト（false）

truststore

DSEインストール・ディレクトリからの相対パス、またはリモート・サーバーの認証に必要な信頼できる証明書を含むトラストストアの絶対パス。

注: トラストストアのパスワードおよびパスは、require client authがtrueに設定されている場合のみ必要です。

デフォルト：resources/dse/conf/.truststore

truststore_password

トラストストア用のパスワード。これは、キーストアおよびトラストストアの生成時に使用したパスワードと一致する必要があります。

注: トラストストアのパスワードおよびパスは、require client authがtrueに設定されている場合のみ必要です。

デフォルト：cassandra

protocol

デフォルト：コメントアウト（TLS）

algorithm

デフォルト：コメントアウト（SunX509）

keystore_type

有効なタイプは、JKS、JCEKS、PKCS12、またはPKCS11です。ファイルベースのキーストアの場合、PKCS12を使用します。

デフォルト：コメントアウト（JKS）

truststore_type

有効なタイプは、JKS、JCEKS、PKCS12、またはPKCS11です。

デフォルト：コメントアウト（JKS）

cipher_suites

サポートされている暗号：

• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

デフォルト：コメントアウト

透過的なデータ暗号化オプション

transparent_data_encryption_options

後方互換性を維持するため、DataStax Enterpriseはこのオプションのみサポートしています。DSEを使用する場合、dse.yamlでデータ暗号化オプションを構成してください。「透過的なデータ暗号化オプション」を参照してください。

TDEプロパティは以下のとおりです。

• enabled: （デフォルト：false）
• chunk_length_kb: （デフォルト：64）
• cipher: options:
  • AES
  • CBC
  • PKCS5Padding
• key_alias: testing:1
• iv_length: 16
  注: iv_lengthは、デフォルトのcassandra.yamlファイルでコメントアウトされています。暗号がAESに設定されている場合、コメントの解除のみ。値は16（バイト）でなければなりません。
• key_provider:
  • class_name: org.apache.cassandra.security.JKSKeyProvider

    パラメーター：

    • keystore: conf/.keystore
    • keystore_password: cassandra
    • store_type: JCEKS
    • key_password: cassandra

SSLポート

ssl_storage_port: 7001
native_transport_port_ssl: 9142

ssl_storage_port

暗号化された通信用のSSLポート。encryption_optionsで有効にしていない限り使用されません。セキュリティ上のベスト・プラクティスに従ってください。このポートをインターネット上で公開しないでください。ファイアウォール・ルールを適用します。

デフォルト： 7001

native_transport_port_ssl

暗号化された通信で、CQLネイティブ・トランスポートがクライアントをリッスンする専用のSSLポート。セキュリティ上の理由から、このポートをインターネット上で公開しないでください。必要に応じてファイアウォールを設定します。

• commented out (disabled) - native_transport_portは、すべてのトラフィックを暗号化します
• port number different than native_transport_port - native_transport_port_ssl用の暗号を使用し、native_transport_port は暗号化しない状態を維持し、号化されていないトラフィックと暗号化されているトラフィックの両方を使用します

デフォルト：9142

ユーザー定義関数（UDF）のプロパティ

enable_user_defined_functions: false
enable_scripted_user_defined_functions: false
enable_user_defined_functions_threads: true
user_defined_function_warn_micros: 500
user_defined_function_fail_micros: 10000
user_defined_function_warn_heap_mb: 200
user_defined_function_fail_heap_mb: 500
user_function_timeout_policy: die

enable_user_defined_functions

Cassandraデーモン内部で実行されるコードで、ユーザー定義関数（UDF）を有効にするかどうか。UDFはサーバー側で実行されるため、セキュリティ上のリスクを伴います。UDFは、実行可能なコードを管理するためにサンドボックスで実行されます。DataStaxブログの記事「ユーザー定義関数」を参照してください。

• true - 有効になっています。コード言語として、Javaをサポートしています。エンドレス・ループとメモリー・リークを検出します。
• false - 無効になっています。

デフォルト：false （無効）

enable_scripted_user_defined_functions

UDFで、JavaScript言語の使用を有効にするかどうか。スクリプトされたUDFは、UDFよりもパフォーマンスが劣り、ヒープ上にさらに多くのガーベージをもたらします。

• true - 有効になっています。コード言語としてのJavaに加えて、JavaScriptを許可します。
• false - 無効になっています。コード言語としてのJavaのみを許可します。

注: enable_user_defined_functionsが、falseの場合、この設定は影響を与えません。

デフォルト：false

enable_user_defined_functions_threads

非同期JavaScript UDFの実行に対するサンドボックスを有効にするかどうか。Java UDFには適用されません。

• true - 有効になっています。一度に実行できる関数のインスタンスは1つだけです。非同期の実行により、UDFを長時間または永遠に実行して、クラスターを不安定化するのを防ぎます。
• false - 無効になっています。同じ関数の複数のインスタンスを同時に実行することができます。
  注意: 非同期UDFの実行を無効にすると、暗黙的にJavaセキュリティ・マネージャーを無効にします。クラスターの不安定化を招く恐れがある、長時間または永遠に実行するJavaScipt UDFの読み取りタイムアウトを監視する必要があります。

デフォルト：true

user_defined_function_warn_micros

ミリ秒単位のしきい値（CPU時間）。UDFを長時間実行して、値を上回ると、警告がログに記録され、クライアントに送信されます。Java UDFは常に警告を生成します。スクリプトされたUDFは、enable_user_defined_functions_threadsが、trueに設定されている場合に限り、警告をログに記録します。

デフォルト：500

user_defined_function_fail_micros

ミリ秒単位のしきい値（CPU時間）。致命的なUDFランタイム状況が検出され、このしきい値を上回る場合、UDFは停止します。Java UDFは常に例外をスローし、停止します。スクリプトされたUDFは、enable_user_defined_functions_threadsが、trueに設定されている場合に限り、例外をスローし停止します。

デフォルト：10000

user_defined_function_warn_heap_mb

ヒープ割り当て用のしきい値（MB）。この値を上回ると、警告がログに記録され、クライアントに送信されます。Java UDFは常に警告を生成します。スクリプトされたUDFは、enable_user_defined_functions_threadsが、trueに設定されている場合に限り、警告をログに記録します。

デフォルト：200

user_defined_function_fail_heap_mb

ヒープ割り当て用のしきい値（MB）。このしきい値を上回ると、UDFは停止します。

• Java UDFは失敗し、安全に停止します。Java UDFは常に例外をスローします。
• スクリプトされたUDFは、enable_user_defined_functions_threadsが、trueに設定されている場合に限り、停止し例外をスローします。

デフォルト：500

user_function_timeout_policy

スクリプトされたUDFが、user_defined_function_fail_microsのしきい値を上回ると、アクションを定義します。enable_user_defined_functions_threadsがtrueに設定されている場合に限り、適用されます。

• die - Cassandraデーモンをシャットダウンする前に、クライアントに警告を生成します
• die_immediate - Cassandraデーモンを即座にシャットダウンし、クライアントが警告を受け取るのを効率的に防ぎます。
• ignore - 警告をログに記録しますが、何も実行しないでください。記録しますが、何のアクションも起こしません。DataStaxでは、プロダクション環境において、このオプションを推奨しません。

デフォルト：die

連続ページング・オプション

continuous_paging:
    max_concurrent_sessions: 60
    max_session_pages: 4
    max_page_size_mb: 8
    max_local_query_time_ms: 5000
    client_timeout_sec: 600
    cancel_timeout_sec: 5
    paused_check_interval_ms: 1

continuous_paging

要求された際、継続的にページをクライアントにプッシュする際の連続ページングを調整するオプション。

• 使用最大メモリー：

  max_concurrent_sessions ⨉ max_session_pages ⨉ max_page_size_mb

  デフォルト： calculated (60 ⨉ 4 ⨉ 8 = 1920 MB)

ガイダンス

• memtableとSSTableが連続ページング・クエリーで使用されるため、memtableのフラッシュとコンパクションを行うことができずSSTableを削除できない最大期間を定義できます。
• スレッドがセッションより少ない場合、他のセッションがスワップアウトされるまでセッションを実行できません。
• 分散クエリー（CL > ONEまたは非ローカル・データ）は各ページの後にスワップアウトされますが、CL = ONEのローカル・クエリーはmax_local_query_time_msの経過後にスワップアウトされます。

max_concurrent_sessions

同時セッションの最大数。この値を超えてセッションが追加されると拒否され、追加できないことを示すエラーが発生します。

デフォルト：60

max_session_pages

各セッションでバッファー可能なページの最大数。クライアントがソケットから読み取っていない場合、プロデューサー・スレッドはmax_session_pagesをプリペアした後、ブロックされます。

デフォルト：4

max_page_size_mb

ページの最大サイズ（MB）。個々のCQL行がこの値より大きい場合、ページはこの値より大きくなる可能性があります。

デフォルト：8

max_local_query_time_ms

ローカルの連続クエリーを実行する最大時間。このしきい値を超えると、セッションはスワップアウトされ、再スケジュールされます。スワップと再スケジュールにより、リソースが解放されてmemtableがフラッシュされるのを防ぎ、max_threads < max_concurrent_sessionsの場合の妥当性が確保されます。テーブルの書き込みワークロードが高く、連続ページング要求がある場合は、調整を検討してください。

デフォルト：5000

client_timeout_sec

クライアントが読み取っておらず、サーバー・キューがフルの場合、クライアントがさらにページを要求するためにサーバーが待機する時間（秒単位）。

デフォルト：600

cancel_timeout_sec

一時停止セッションを再開可能か確認する際、待機する時間。連続ページングセッションは、バックプレッシャーまたはバックプレッシャーの更新で、さらならるページの要求をしないため、一時停止します。

デフォルト：5

paused_check_interval_ms

セッションの一時停止時、連続ページング・セッションを再開可能か確認する際、待機する時間（秒単位）。

デフォルト：1

障害検知の設定

# phi_convict_threshold: 8

phi_convict_threshold

指数スケール上の障害検知機能の感度。通常、この設定を調整する必要はありません。

ヒント: 「障害検知と復旧について」を参照してください。

設定しない場合、内部値は8です。

デフォルト：コメントアウト（8）

メモリー・リーク検知の設定

#leaks_detection_params:
#  sampling_probability: 0
#  max_stacks_cache_size_mb: 32
#  num_access_records: 0
#  max_stack_depth: 30

sampling_probability

指定されたリソースについて追跡されるサンプリング確率。追跡されたリソースについては、「nodetool leaksdetection」を参照してください。

• 0 - 追跡を無効デフォルト。
• 1 - 常に追跡を有効
• 0～1の数字 - リソースをランダムに追跡する時間の割合。たとえば、0.5と指定した場合、時間の50%でリソースが追跡されます。

注意: 追跡を行うと、アクセスのたびにスタック・トレース収集に大きな負担が掛かり、ヒープ・スペースを消費します。追跡を有効にする場合は、必ず、DataStaxサポートの指示を受けてください。

デフォルト：コメントアウト（0）

max_stacks_cache_size_mb

コール・スタック・トレース用のキャッシュ・サイズを設定します。リークしたリソースのデバッグ、およびヒープ・メモリーの使用にはスタック・トレースが使用されます。最大スタック・キャッシュ・サイズをMB単位で設定することによって、各リソース専用のヒープ・メモリーの量を設定します。

デフォルト：コメントアウト（32）

num_access_records

リソースにアクセスした際に維持するスタック・トレースの平均数を設定します。平均数を設定します。現在、キャッシュ内のチャンクに対してのみサポートされています。

デフォルト：コメントアウト（0）

max_stack_depth

回収したスタック・トレースの深さを設定します。パラメーターが設定された時点から収集されたスタック・トレースの深さのみ変更します。スタックが深いほど、一意性が高くなるため、深さを上げる場合は、stacks_cache_size_mbを増やす必要があります。

デフォルト：コメントアウト（30）