cassandra.yaml構成ファイル

cassandra.yamlファイルは、DataStax Enterpriseの主要な構成ファイルです。

cassandra-topology.properties

cassandra-topology.propertiesファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/dse/cassandra/cassandra-topology.properties
tarボール・インストール installation_location/resources/cassandra/conf/cassandra-topology.properties

cassandra-rackdc.properties

cassandra-rackdc.propertiesファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/dse/cassandra/cassandra-rackdc.properties
tarボール・インストール installation_location/resources/cassandra/conf/cassandra-rackdc.properties

cassandra.yaml

cassandra.yamlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/dse/cassandra/cassandra.yaml
tarボール・インストール installation_location/resources/cassandra/conf/cassandra.yaml

dse.yaml

dse.yamlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/dse/dse.yaml
tarボール・インストール installation_location/resources/dse/conf/dse.yaml

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

重要: cassandra.yamlファイルでプロパティを変更したら、ノードを再起動して変更を有効にする必要があります。

構文

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

  • リテラル・デフォルト値は、literalに表示されているとおりです。
  • 計算値は、calculatedに表示されているとおりです。
  • 未定義のデフォルト値は、デフォルト: なしに表示されているとおりです。
  • 内部的に定義されたデフォルト値は説明されています。
    注: デフォルト値は、内部で定義したり、コメントアウトしたり、cassandra.yamlファイルのその他のプロパティに実行依存を持たせることが可能です。さらに、コメントアウトされた一部の値が実際のデフォルト値と一致していない場合があります。コメントアウトされた値は、デフォルト値に代わる推奨値です。

構成

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

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

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

cluster_name: 'Test Cluster'
listen_address: localhost
# listen_interface: wlan0
# listen_interface_prefer_ipv6: false
ヒント:DataStax Enterpriseクラスターを初期化する」を参照してください。
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の構成時に頻繁に使用されるプロパティ。

最初にノードを開始する前に、DataStaxでは要件を慎重に精査することを推奨します。

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

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 size2048

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 size2048

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

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

デフォルト:false

snapshot_before_compaction
各コンパクションの前にスナップショットを取得するかどうか。スナップショットは、データ形式に変更がある場合のデータのバックアップに役立ちます。
重要: このオプションの使用には注意してください。データベースは古いスナップショットを自動的にクリーンアップしません。
ヒント:コンパクションの構成」を参照してください。

デフォルト:false

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

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

調整プロパティの実行には以下が含まれます。

コミット・ログの設定

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
ヒント: 一般的なコンパクションの設定セクションの「compaction_throughput_mb_per_sec」と「コンパクションの構成」も参照してください。
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
tpc_cores
TPCイベント・ループの数。設定しない場合、デフォルトはコアの数(マシン上のプロセッサー)マイナス1です。大半のワークロードは、調整しないでください。DataStaxでは、この値を変更する前に、DataStaxサービス・チームにご相談いただくことを推奨しています。
重要: DSE Searchワークロードのみ:tpc_coresをデフォルトから、物理CPUの数に変更します。「インデックス作成のパフォーマンスの構成と調整」を参照してください。

デフォルト:コメントアウト(number of cores -1

tpc_io_cores
非同期ディスクの読み取りで使用するtpc_coresの数。
重要: 調整しないでください。DataStaxでは、この値を変更する前に、DataStaxサービス・チームにご相談いただくことを推奨しています。

デフォルト:コメントアウト(min(io_global_queue_depth/4, tpc_cores)

io_global_queue_depth
AIOが有効時に(SSDのデフォルト)、読み取りで使用するグローバルIOキューの深さ。所定のディスク・セットアップ用のfioツールで明らかになった設定最適なキューの深さ。
重要: 調整しないでください。DataStaxでは、この値を変更する前に、DataStaxサービス・チームにご相談いただくことを推奨しています。

デフォルト:128

NodeSyncパラメーター

nodesync:
    rate_in_kb: 1024
デフォルトでは、NodeSyncサービスはすべてのノードで実行されます。
ヒント: nodetool nodesyncserviceコマンドを使用して、NodeSyncサービスを管理します。
ヒント:レートの設定」を参照してください。
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を使用して、実行中にもこれらのしきい値を調整できます。

ヒント: DataStax開発者のブログの投稿「Cassandraのアンチパターン:キューと、キューに似たデータセット」を参照してください。
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
ヒント:SSLポート」内の「native_transport_port_ssl」も参照してください。
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
ヒント・ファイルの圧縮形式。サポートされている圧縮形式は、LZSnappyDeflateです。設定しない場合、データベースはヒント・ファイルを圧縮しません。

デフォルト: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

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

クライアントとノード間の暗号化は、クライアント・コンピューターからデータベース・クラスターに転送中のデータをSSL(Secure Sockets Layer)を使用して保護し、クライアントとコーディネーター・ノードの間にセキュアなチャネルを確立します。
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]
ヒント:クライアントとノードを接続するためのSSLの構成」を参照してください。
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 authtrueに設定されている場合のみ必要です。

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

truststore_password
トラストストア用のパスワード。これは、キーストアおよびトラストストアの生成時に使用したパスワードと一致する必要があります。
注: トラストストアのパスワードおよびパスは、require client authtrueに設定されている場合のみ必要です。

デフォルト: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
ヒント:DataStax Enterpriseポートのセキュリティ保護」を参照してください。
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