在本章中，我们将构建第一个集群，并查看配置Cassandra的可用选项。开箱即用，Cassandra完全没有配置;您可以简单地下载和解压缩，然后执行程序以使用其默认配置启动服务器。然而，使Cassandra成为如此强大的技术的一个原因是它强调可配置性和定制。与此同时，选项的数量一开始可能会让人感到困惑。
我们将关注影响集群中节点行为的Cassandra方面以及分区，故障和复制等元操作。性能调优和安全性是在第12章和第13章中得到自己处理的其他配置主题。
Cassandra集群管理
为了练习构建和配置集群，我们将利用名为Cassandra Cluster Manager或ccm的工具。该工具由Sylvain Lebresne和其他几个贡献者构建，是一组Python脚本，允许您在一台计算机上运行多节点集群。这使您可以快速配置群集，而无需配置其他硬件。
该工具可在GitHub上获得。一个快速入门的方法是使用Git克隆存储库。我们将打开一个终端窗口并导航到我们要创建克隆的目录并运行以下命令：
$ git clone https://github.com/pcmanus/ccm.git
然后我们可以使用管理级权限运行安装脚本：
$ sudo ./setup.py install
我们在这里提供了一个简化的指令视图，用于开始使用ccm。您需要检查网页上的依赖关系以及Windows和MacOS X等平台的特殊说明。由于ccm是一个积极维护的工具，因此这些细节可能会随着时间的推移而发生变化。
一旦安装了ccm，它应该在系统路径上。要获取支持的命令列表，可以键入ccm或ccm -help。如果需要有关特定群集命令的选项的更多信息，请键入ccm -h。在创建和配置集群时，我们将在以下部分中使用其中的几个命令。
您可以深入了解Python脚本文件，以了解有关ccm正在执行的操作的更多信息。您还可以直接从自动化测试套件调用脚本。
创建群集
您可以在一台计算机上运行Cassandra，这在您学习如何读取和写入数据时很适合入门。但Cassandra专门设计用于许多机器的集群，这些机器可以在非常大量的情况下共享负载。在本节中，我们将了解使多个Cassandra实例在一个环中相互通信所需的配置。用于配置群集中每个节点的密钥文件是cassandra.yaml文件，您可以在Cassandra安装下的conf目录中找到该文件。
配置集群的关键值是集群名称，分区程序，告警和种子节点。参与群集的所有节点中的群集名称，分区程序和snitch必须相同。对于整个群集中的每个节点，种子节点并不严格要求完全相同，但这样做是个好主意;我们将立即了解配置的最佳实践。
Cassandra集群的名称是为了防止一个集群中的计算机加入另一个集群，而不希望它们成为其中的一部分。 cassandra.yaml文件中默认集群的名称是“Test Cluster”。您可以通过更新cluster_name属性来更改集群的名称 - 只需确保在要参与此节点的所有节点上完成此操作簇。
如果您已将数据写入现有的Cassandra集群，然后更改集群名称，Cassandra会在尝试在启动时读取数据文件时发出集群名称不匹配错误警告您，然后它将关闭。
让我们尝试使用ccm创建一个集群：
$ ccm create -v 3.0.0 -n 3 my_cluster --vnodes
Downloading http://archive.apache.org/dist/cassandra/3.0.0/
apache-cassandra-3.0.0-src.tar.gz to
/var/folders/63/6h7dm1k51bd6phvm7fbngskc0000gt/T/
ccm-z2kHp0.tar.gz (22.934MB)
24048379 [100.00%]
Extracting /var/folders/63/6h7dm1k51bd6phvm7fbngskc0000gt/T/
ccm-z2kHp0.tar.gz as version 3.0.0 ...
Compiling Cassandra 3.0.0 ...
Current cluster is now: my_cluster
此命令根据我们选择的Cassandra版本创建一个集群 - 在本例中为3.0.0。 该群集名为my_cluster，有三个节点。 我们指定要使用虚拟节点，因为ccm默认创建单个令牌节点。 ccm将我们的集群指定为将用于后续命令的当前集群。 您会注意到ccm下载了请求运行的版本的源并进行编译。 这是因为ccm需要对Cassandra源进行一些小的修改，以支持在一台机器上运行多个节点。 我们也可以使用我们在第3章中下载的源代码副本。如果您想研究创建集群的其他选项，请运行命令ccm create -h。
一旦我们创建了集群，我们就可以看到它是我们集群列表中的唯一集群（并标记为默认集群），我们可以了解它的状态：
$ ccm list
*my_cluster
$ ccm status
Cluster: 'my_cluster'
---------------------
node1: DOWN (Not initialized)
node3: DOWN (Not initialized)
node2: DOWN (Not initialized)
此时，没有任何节点已初始化。 让我们启动我们的集群，然后再次检查状态：
$ ccm start
$ ccm status
Cluster: 'my_cluster'
---------------------
node1: UP
node3: UP
node2: UP
这相当于使用bin / cassandra脚本（或用于包安装的service start cassandra）启动每个单独的节点。 要深入了解单个节点的状态，我们将输入以下命令：
$ ccm node1 status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 127.0.0.1 193.2 KB 256 ? e5a6b739-... rack1
UN 127.0.0.2 68.45 KB 256 ? 48843ab4-... rack1
UN 127.0.0.3 68.5 KB 256 ? dd728f0b-... rack1
这相当于在单个节点上运行命令nodetool status。 输出显示所有节点都已启动并报告正常状态（UN）。 每个节点都有256个令牌，并且没有数据，因为我们还没有插入任何数据。 （为简洁起见，我们稍微缩短了主机ID。）
我们可以运行nodetool ring命令以获取每个节点拥有的令牌列表。 要在ccm中执行此操作，请输入以下命令：
$ ccm node1 ring
Datacenter: datacenter1
==========
Address Rack Status State ... Token
9205346612887953633
127.0.0.1 rack1 Up Normal ... -9211073930147845649
127.0.0.3 rack1 Up Normal ... -9114803904447515108
127.0.0.3 rack1 Up Normal ... -9091620194155459357
127.0.0.1 rack1 Up Normal ... -9068215598443754923
127.0.0.2 rack1 Up Normal ... -9063205907969085747
该命令要求我们指定一个节点。 这不会影响输出; 它只是指示节点nodetool连接到哪个节点以获取环信息。 如您所见，令牌在我们的三个节点中随机分配。 （和以前一样，为简洁起见，我们缩写了输出并省略了Owns和Load列。）
有趣的是，了解ccm所做的配置更改，以便在本地计算机上运行集群。 默认情况下，ccm将群集的元数据和配置文件存储在主目录下名为.ccm的目录中; 它还使用此目录存储您运行的Cassandra版本的源文件。 我们来看看这个目录，看看我们在那里可以找到什么：
$ cd ~/.ccm; ls
CURRENT my_cluster repository
存储库目录包含ccm下载的源。 深入了解my_cluster目录，我们将看到每个节点的目录：
$ cd my_cluster; ls
cluster.conf node1 node2 node3
cluster.conf文件包含我们在创建集群时选择的选项列表。 要查看节点之间不同的配置选项，请尝试使用diff命令比较目录的内容。 例如：
$ cd ~/.ccm/my_cluster
$ diff node1/conf/ node2/conf/
输出突出显示配置文件中的差异，包括用于存储数据的目录，提交日志和输出日志，用于网络通信的侦听和RPC地址，以及为远程管理公开的JMX端口。在我们继续本章的其余部分时，我们将更详细地研究这些设置。
种子节点
集群中的新节点需要所谓的种子节点。种子节点用作其他节点的联系点，因此Cassandra可以了解群集的拓扑结构 - 即主机具有哪些范围。例如，如果节点A充当节点B的种子，则当节点B联机时，它将使用节点A作为从中获取数据的参考点。此过程称为自举或有时自动引导，因为它是Cassandra自动执行的操作。种子节点不会自动引导，因为假定它们将是群集中的第一个节点。
默认情况下，cassandra.yaml文件只有一个种子条目设置为localhost：
- seeds: "127.0.0.1"
要向集群添加更多种子节点，我们只需添加另一个种子元素。 我们可以通过指示节点的IP地址或主机名来将多个服务器设置为种子。 举个例子，如果我们查看一个ccm节点的cassandra.yaml文件，我们会发现以下内容：
- seeds: 127.0.0.1, 127.0.0.2, 127.0.0.3
在生产群集中，这些将是其他主机的IP地址，而不是环回地址。为了确保Cassandra的自举过程的高可用性，每个数据中心至少有两个种子节点被认为是最佳实践。如果在数据中心之间的网络分区期间其中一个本地种子节点发生故障，则这增加了使至少一个种子节点可用的可能性。
您可能已经注意到，如果查看cassandra.yaml文件，种子列表实际上是种子提供程序的更大定义的一部分。 org.apache.cassandra.locator.SeedProvider接口指定必须实现的合同。 Cassandra提供SimpleSeedProvider作为默认实现，它从cassandra.yaml文件加载种子节点的IP地址。
Partitioners
分区程序的目的是允许您指定分区键的排序方式，这对数据在节点中的分布方式有重大影响。它还会影响查询行范围的选项。您可以通过更新cassandra.yaml文件中partitioner属性的值来设置分区程序。您可以使用几种不同的分区程序，我们现在看一下。
将数据插入群集后，无法更改分区程序，因此在偏离默认值之前请务必小心！
Murmur3分区
默认分区程序是org.apache.cassandra.dht.Murmur3Partitioner。 Murmur3Partitioner使用杂音哈希算法生成令牌。这样做的好处是可以在整个群集中均匀地分布密钥，因为分布是随机的。它具有导致低效范围查询的缺点，因为指定范围内的密钥可能被放置在环中的各种不同位置，并且密钥范围查询将以基本上随机的顺序返回数据。
通常，新群集应始终使用Murmur3Partitioner。但是，Cassandra提供了几个较旧的分区程序以实现向后兼容。
随机分区
随机分区程序由org.apache.cassandra.dht.RandomPartitioner实现，是Cassandra在Cassandra 1.1及更早版本中的默认设置。它使用BigIntegerToken并应用MD5加密哈希来确定将键放置在节点环上的位置。虽然RandomPartitioner和Murmur3Partitioner都基于随机散列函数，但RandomPartitioner使用的加密散列要慢得多，这就是为什么Murmur3Partitioner将其替换为默认值。
Order-Preserving Partitioner
保留订单的分区程序由org.apache.cassandra.dht.OrderPreservingPartitioner实现。使用这种类型的分区器，令牌是基于密钥的UTF-8字符串。因此，行按键顺序存储，将数据的物理结构与排序顺序对齐。配置列族以使用顺序保留分区（OPP）允许您执行范围切片。
值得注意的是，OPP对范围查询的效率不如随机分区 - 它只是提供排序。它的缺点是创建一个可能非常不平衡的环，因为实际数据通常不是均匀写入的。例如，考虑在Scrabble游戏中分配给字母的值。 Q和Z很少使用，因此它们具有很高的价值。使用OPP，您最终可能会在某些节点上获得大量数据，而在其他节点上获得的数据则更少。存储大量数据的节点，使得环不平衡，通常被称为热点。由于订购方面，用户有时会被OPP吸引。但是，在实践中使用OPP意味着您的运营团队需要使用nodetool loadbalance或移动操作更频繁地手动重新平衡节点。由于这些因素，不鼓励使用订单保留分区程序。相反，使用索引。
ByteOrderedPartitioner
ByteOrderedPartitioner是一个保持顺序的分区程序，它将数据视为原始字节，而不是像保留顺序的分区程序和整理顺序保留分区程序那样将它们转换为字符串。如果您需要一个不将密钥验证为字符串的订单保留分区程序，建议使用BOP来提高性能。
虽然Murmur3Partitioner随机选择令牌，但它仍然可能对热点敏感;但是，与订单保留分区器相比，问题显着减少。事实证明，为了最小化热点，需要额外的拓扑知识。 3.0中添加了对令牌选择的改进以解决此问题。使用特定键空间的名称在cassandra.yaml中配置allocate_ tokens_ keyspace属性可指示分区程序根据该键空间的复制策略优化令牌选择。这在群集具有单个键空间或所有键空间具有相同复制策略的情况下最有用。从3.0版本开始，此选项仅适用于Murmur3Partitioner。
Snitches
飞贼的工作只是确定相对主机的接近程度。 Snitches收集有关您的网络拓扑的一些信息，以便Cassandra可以有效地路由请求。金色飞贼将弄清楚节点与其他节点的关系。推断数据中心是复制策略的工作。您可以通过更新cassandra.yaml文件中的endpoint_snitch属性来配置要使用的端点snitch实现。
Simple Snitch
默认情况下，Cassandra使用org.apache.cassandra.locator.SimpleSnitch。这个小故障不是机架感知（这个术语我们将在一分钟内解释），这使得它不适合多数据中心部署。如果您选择使用此snitch，则还应该为键空间使用SimpleStrategy复制策略。
Property File Snitch
org.apache.cassandra.locator.PropertyFileSnitch是所谓的机架感知小部件，这意味着它在名为cassandra-topology.properties的标准Java密钥/值属性文件中使用您提供的有关集群拓扑的信息。 cassandra-topology.properties的默认配置如下所示：
# Cassandra Node IP=Data Center:Rack
192.168.1.100=DC1:RAC1
192.168.2.200=DC2:RAC2
10.0.0.10=DC1:RAC1
10.0.0.11=DC1:RAC1
10.0.0.12=DC1:RAC2
10.20.114.10=DC2:RAC1
10.20.114.11=DC2:RAC1
10.21.119.13=DC3:RAC1
10.21.119.10=DC3:RAC1
10.0.0.13=DC1:RAC2
10.21.119.14=DC3:RAC2
10.20.114.15=DC2:RAC2
# default for unknown nodes
default=DC1:r1
在这里，我们看到有三个数据中心（DC1，DC2和DC3），每个数据中心都有两个机架（RAC1和RAC2）。此处未标识的任何节点将被假定为默认数据中心和机架（DC1，r1）。
如果您选择使用此snitch或其他一个支持机架的小部件，则这些机架和数据名称将用于为每个数据中心配置NetworkTopologyStrategy设置以用于密钥空间复制策略。
更新此文件中的值以记录群集中的每个节点，以指定哪个机架包含具有该IP的节点以及它所在的数据中心。虽然如果您希望添加或删除具有某些频率的节点，这似乎很难维护，请记住它是一种替代方案，它可以带来一点灵活性和易维护性，以便为您提供更多控制和更好的运行时性能，因为Cassandra无需弄清楚节点的位置。相反，你只需告诉它们在哪里。
Gossiping Property File Snitch
org.apache.cassandra.locator.GossipingPropertyFileSnitch是另一个机架感知的小故障。数据通过八卦与其他节点交换有关其自己的机架和数据中心位置的信息。机架和数据中心位置在cassandra-rackdc.properties文件中定义。 GossipingPropertyFileSnitch还使用cassandra-topology.properties文件（如果存在）。
Rack Inferring Snitch
org.apache.cassandra.locator.RackInferringSnitch假定群集中的节点以一致的网络方案布局。它通过简单地比较每个节点的IP地址中的不同八位字节来操作。如果两个主机在其IP地址的第二个八位字节中具有相同的值，则确定它们位于同一数据中心。如果两个主机在其IP地址的第三个八位字节中具有相同的值，则确定它们位于同一个机架中。 “决定是”真的意味着Cassandra必须根据您的服务器如何位于不同的VLAN或子网中进行猜测。
Cloud Snitches
Cassandra附带了几个设计用于云部署的小故障：
-
org.apache.cassandra.locator.Ec2Snitch和Ec2MultiRegionSnitch设计用于Amazon的Elastic Compute Cloud（EC2），它是Amazon Web Services（AWS）的一部分。 Ec2Snitch对于单个AWS区域中的部署或区域位于同一虚拟网络上的多区域部署非常有用。 Ec2MultiRegionSnitch专为多区域部署而设计，其中区域通过公共互联网连接。
-
org.apache.cassandra.locator.GoogleCloudSnitch可用于Google Cloud Platform上的一个区域或多个区域。
-
org.apache.cassandra.locator.CloudstackSnitch旨在用于基于Apache Cloudstack项目的公共或私有云部署。
EC2和Google Cloud snitch使用cassandra-rackdc.properties文件，其中机架和数据中心命名约定因环境而异。我们将在第14章重温这些故障。
Dynamic Snitch
正如我们在第6章中讨论的那样，Cassandra使用org.apache.cassandra.locator.DynamicEndpointSnitch包装您选择的snitch，以便为查询选择性能最高的节点。 dynamic_snitch_badness_threshold属性定义用于更改首选节点的阈值。默认值0.1表示首选节点必须比最快节点执行10％以便丢失其状态。动态snitch根据dynamic_snitch_update_interval_in_ms属性更新此状态，并在dynamic_snitch_reset_interval_in_ms属性指定的持续时间内重置其计算。重置间隔应该比更新间隔长得多，因为它是一个更昂贵的操作，但它确实允许节点重新获得其首选状态，而不必证明性能优于不良阈值。
节点配置
除了我们之前讨论过的与集群相关的设置外，还有许多其他属性可以在cassandra.yaml文件中设置。我们将在本章中查看与网络和磁盘使用相关的一些要点，并在第12章和第13章中保存其他一些用于处理的内容。
我们建议您查看适用于您的版本的DataStax文档，该文档提供了有关配置cassandra.yaml文件中各种设置的有用指南。本指南从最常配置的设置构建到更高级的配置选项。
令牌和虚拟节点
默认情况下，Cassandra配置为使用虚拟节点（vnodes）。给定节点将服务的令牌数由num_tokens属性设置。通常，这应保留为默认值（当前为256，但请参阅后面的注释），但可以增加以将更多令牌分配给功能更强的计算机，或者减少将更少的令牌分配给功能较弱的计算机。
许多Cassandra专家已经开始建议将默认的num_tokens从256更改为32.他们认为每个节点有32个令牌可以在令牌范围之间提供足够的平衡，同时需要更少的带宽来维护。在将来的版本中查找对此默认值的可能更改。
要禁用vnode并配置更传统的令牌范围，您首先需要将num_tokens设置为1，或者您也可以完全注释掉该属性。然后，您还需要设置initial_token属性以指示该节点将拥有的标记范围。对于群集中的每个节点，这将是不同的值。
3.0之前的Cassandra版本提供了一个名为令牌生成器的工具，您可以使用该工具计算集群中节点的初始令牌值。例如，让我们为包含三个节点的单个数据中心的集群运行它：
$ cd $CASSANDRA_HOME/tools/bin
$ ./token-generator 3
DC #1:
Node #1: -9223372036854775808
Node #2: -3074457345618258603
Node #3: 3074457345618258602
对于具有多个数据中心的配置，只需提供与每个数据中心中的节点数相对应的多个整数值。 默认情况下，令牌生成器为Murmur3Partitioner生成初始令牌，但它也可以使用–random选项为RandomPartitioner生成令牌。 如果您决定使用初始令牌并且您的版本中没有令牌生成器，则可以在http://www.geroba.com/cassandra/cassandra-token-calculator上找到一个方便的计算器。
通常，强烈建议使用vnodes，因为在添加或删除单令牌节点时需要额外计算令牌和重新平衡群集所需的手动配置步骤。
网络接口
cassandra.yaml文件中有几个属性，这些属性与用于与客户端和其他节点通信的端口和协议方面的节点组网相关：
$ cd ~/.ccm
$ find . -name cassandra.yaml -exec grep -H 'listen_address' {} \;
./node1/conf/cassandra.yaml:listen_address: 127.0.0.1
./node2/conf/cassandra.yaml:listen_address: 127.0.0.2
./node3/conf/cassandra.yaml:listen_address: 127.0.0.3
如果您更喜欢通过接口名称绑定，则可以使用listen_interface属性而不是listen_address。例如，listen_interface = eth0。您可能无法设置这两个属性。
storage_port属性指定用于节点间通信的端口，通常为7000.如果您将在遍历公共网络的网络环境中使用Cassandra，或者在云部署中使用多个区域，则应配置ssl_storage_port（通常为7001）。配置安全端口还需要配置节点间加密选项，我们将在第14章中讨论。
从历史上看，Cassandra支持两种不同的客户端接口：原始Thrift API，也称为远程过程调用（RPC）接口，以及首先在0.8中添加的CQL接口，也称为本机传输。对于2.2版本，默认情况下支持并启用这两个接口。从3.0版本开始，默认情况下禁用Thrift，将来的版本将完全删除。
start_native_transport属性启用或禁用本机传输，默认为true。本机传输使用端口9042，由native_transport_port属性指定。
cassandra.yaml文件包含一组用于配置RPC接口的类似属性。 RPC默认为端口9160，由rpc_port属性定义。如果您有使用Thrift的现有客户端，则可能需要启用此接口。但是，鉴于自1.1以来CQL以其当前形式（CQL3）可用，您应该尽一切努力将客户端升级到CQL。
有一个属性rpc_keepalive，RPC和本机接口都使用它。默认值true表示Cassandra将允许客户端跨多个请求保持连接打开。其他属性可用于限制线程，连接和帧大小，我们将在第12章中介绍。
数据存储
Cassandra允许您配置其各种数据文件存储在磁盘上的方式和位置，包括数据文件，提交日志和已保存的缓存。默认值是Cassandra安装下的数据目录（$ CASSANDRA_HOME / data或％CASSANDRA_HOME％/ data）。较旧的版本和一些Linux软件包发行版使用目录/ var / lib / cassandra / data。
您将从第6章中记得，提交日志用作传入写入的短期存储。当卡桑德拉收到更新时，每个写入值都会以原始顺序文件追加的形式立即写入提交日志。如果关闭数据库或意外崩溃，则提交日志可确保数据不会丢失那是因为下次启动节点时，会重放提交日志实际上，这是唯一一次读取提交日志;。客户从不读它但是对提交日志的正常写入操作会阻塞，因此会损坏性能以要求客户端等待写入完成。提交日志存储在commitlog_directory属性指定的位置。
数据文件表示排序字符串表（SSTables）。与提交日志不同，数据以异步方式写入此文件.SSTables在主要压缩期间定期合并以释放空间。为此，Cassandra将合并键，组合列并删除墓碑。
数据文件存储在data_file_directories属性指定的位置。如果您愿意，可以指定多个值，卡桑德拉会将数据文件均匀地分布在它们之间。这就是卡桑德拉支持“只是一堆磁盘”或JBOD部署的方式，其中每个目录代表不同的磁盘挂载点。
您无需更新的Windows的默认存储文件位置，因为的Windows将自动调整路径分隔符并将它们放在C：\下当然，在真实环境中，如图所示，分别指定它们是个好主意。
对于测试，您可能不需要更改这些位置。但是，在使用旋转磁盘的生产环境中，建议您将数据文件和提交日志存储在不同的磁盘上，以获得最佳性能和可用性。
Cassandra非常强大，可以在没有整个节点关闭的情况下处理一个或多个磁盘的丢失，但是为您提供了几个选项来指定磁盘故障时节点的所需行为。影响数据文件的磁盘故障行为由disk_failure_policy属性指定，而提交日志的故障响应由commit_failure_policy指定。默认行为停止是禁用客户端接口，同时保持活动以通过JMX进行检查。其他选项包括die，它完全停止节点（JVM退出）和ignore，这意味着记录并忽略文件系统错误。建议不要使用ignore。 best_effort的附加选项可用于数据文件，允许对仍可用的磁盘上存储的SSTable进行操作。
启动和JVM设置
到目前为止，我们在本章中花了大部分时间来检查cassandra.yaml文件中的设置，但是我们还应该检查其他配置文件。
Cassandra的启动脚本体现了许多来之不易的逻辑，可以优化各种JVM选项的配置。要查看的密钥文件是环境脚本conf / cassandra.env.sh（或Windows上的conf / cassandra.env.ps1 PowerShell脚本）。此文件包含用于配置JVM版本（如果系统上有多个版本），堆大小和其他JVM选项的设置。除了JMX设置之外，您很少需要更改其默认设置中的大多数选项。环境脚本允许您设置JMX端口并配置远程JMX访问的安全设置。
Cassandra的日志记录配置位于conf / logback.xml文件中。此文件包括日志级别，邮件格式设置和日志文件设置（包括位置，最大大小和轮换）等设置。 Cassandra使用Logback日志框架，您可以在http://logback.qos.ch上了解更多信息。在2.1版本中，日志记录实现已从Log4J更改为Logback。
我们将在第10章和第12章中的JVM内存配置中更详细地研究日志记录和JMX配置。
将节点添加到群集
现在您已了解配置Cassandra集群的每个节点的内容，您已准备好了解如何添加节点。正如我们已经讨论过的，要手动添加新节点，我们需要为新节点配置cassandra.yaml文件以设置种子节点，分区器，告警和网络端口。如果您已选择创建单个令牌节点，则还需要计算新节点的令牌范围并调整其他节点的范围。
因为我们使用的是ccm，所以添加新节点的过程非常简单。我们运行以下命令：
$ ccm add node4 -i 127.0.0.4 -j 7400
这将创建一个新节点node4，其中另一个环回地址和JMX端口设置为7400.要查看此命令的其他选项，可以键入ccm add -h。 现在我们已经添加了一个节点，让我们检查一下我们集群的状态：
$ ccm status
Cluster: 'my_cluster'
---------------------
node1: UP
node3: UP
node2: UP
node4: DOWN (Not initialized)
新节点已添加但尚未启动。 如果再次运行nodetool ring命令，您将看到没有对令牌进行任何更改。 现在我们准备通过键入ccm node4 start来启动新节点（在仔细检查是否启用了额外的环回地址之后）。 如果再次运行nodetool ring命令，您将看到类似于以下内容的输出：
Datacenter: datacenter1
==========
Address Rack Status State ... Token
9218701579919475223
127.0.0.1 rack1 Up Normal ... -9211073930147845649
127.0.0.4 rack1 Up Normal ... -9190530381068170163
...
如果将其与之前的输出进行比较，您会发现一些事情。 首先，令牌已经在所有节点上重新分配，包括我们的新节点。 其次，令牌值已经改变，代表较小的范围。 为了给我们的新节点提供256个令牌（num_tokens），我们现在在集群中总共有1,024个令牌。
我们可以通过检查日志文件来观察node4启动时对其他节点的看法。 在独立节点上，您可能会查看/ var / log / cassandra（或$ CASSANDRA_HOME / logs）中的system.log文件，具体取决于您的配置。 因为我们正在使用ccm，所以我们可以使用一个方便的命令来检查来自任何节点的日志文件。 我们将使用以下命令查看node1日志：ccm node1 showlog。 这将显示类似于标准unix more命令的视图，该命令允许我们翻阅或搜索日志文件内容。 在接近结尾的日志文件中搜索与gossip相关的语句，我们发现以下内容：
INFO [GossipStage:1] 2015-08-24 20:02:24,377 Gossiper.java:1005 –
Node /127.0.0.4 is now part of the cluster
INFO [HANDSHAKE-/127.0.0.4] 2015-08-24 20:02:24,380
OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.4
INFO [SharedPool-Worker-1] 2015-08-24 20:02:24,383
Gossiper.java:970 - InetAddress /127.0.0.4 is now UP
这些语句显示node1与node4成功闲聊，并且node4被认为是up并且是集群的一部分。 此时，引导过程开始将令牌分配给node4，并将与这些令牌相关联的任何数据流式传输到node4。
Dynamic Ring Participation
可以关闭Cassandra集群中的节点并将其恢复，而不会中断群集的其余部分（假设合理的复制因子和一致性级别）。 假设我们已经启动了一个双节点集群，如前面“创建集群”中所述。 我们可能会导致发生错误，从而关闭其中一个节点，然后确保群集的其余部分仍然正常。
我们将使用ccm node4 stop命令将我们的一个节点关闭来模拟这个。 我们可以运行ccm状态来验证节点是否已关闭，然后像我们之前通过命令ccm node1 showlog一样检查日志文件。 检查日志文件，我们会看到如下所示的一些行：
INFO [GossipStage:1] 2015-08-27 19:31:24,196 Gossiper.java:984 -
InetAddress /127.0.0.4 is now DOWN
INFO [HANDSHAKE-/127.0.0.4] 2015-08-27 19:31:24,745
OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.4
现在我们重新启动node4并重新检查node1上的日志。 果然，Cassandra已自动检测到其他参与者已返回群集并再次开始营业：
INFO [HANDSHAKE-/127.0.0.4] 2015-08-27 19:32:56,733 OutboundTcpConnection
.java:494 - Handshaking version with /127.0.0.4
INFO [GossipStage:1] 2015-08-27 19:32:57,574 Gossiper.java:1003 -
Node /127.0.0.4 has restarted, now UP
INFO [SharedPool-Worker-1] 2015-08-27 19:32:57,652 Gossiper.java:970 -
InetAddress /127.0.0.4 is now UP
INFO [GossipStage:1] 2015-08-27 19:32:58,115 StorageService.java:1886 -
Node /127.0.0.4 state jump to normal
node4的状态跳转到正常状态表示它再次成为集群的一部分。 作为最后的检查，我们再次运行status命令，看到该节点已备份：
$ ccm status
Cluster: 'my_cluster'
---------------------
node1: UP
node2: UP
node3: UP
node4: UP
复制策略
虽然我们花了很多时间来了解我们的集群和节点的各种配置选项，但Cassandra还提供了键空间和表的灵活配置。 这些值可以使用cqlsh访问，也可以通过正在使用的客户端驱动程序访问，我们将在第8章中了解。
cqlsh> DESCRIBE KEYSPACE my_keyspace ;
CREATE KEYSPACE my_keyspace WITH replication =
{'class': 'SimpleStrategy',
'replication_factor': '1'} AND durable_writes = true;
durable_writes属性允许您绕过写入密钥空间的提交日志。此值默认为true，表示将在修改时更新提交日志。将值设置为false会增加写入速度，但如果在将数据从memtables刷新到SSTables之前节点出现故障，则还有丢失数据的风险。
选择正确的复制策略很重要，因为策略确定哪些节点负责哪些键范围。这意味着您还要确定哪些节点应该接收哪些写操作，这会对不同情况下的效率产生很大影响。如果您设置群集，使所有写入都转到两个数据中心 - 一个在澳大利亚，一个在弗吉尼亚州的雷斯顿 - 您将看到匹配的性能下降。选择可插拔策略可以提供更大的灵活性，以便您可以根据网络拓扑和需求调整Cassandra。
第一个副本将始终是声明令牌落入范围的节点，但其余的副本将根据您使用的复制策略进行放置。
正如我们在第6章中学到的，Cassandra提供了两种复制策略，SimpleStrategy和NetworkTopologyStrategy。
SimpleStrategy
SimpleStrategy将副本放置在单个数据中心中，其方式是不知道它们在数据中心机架上的位置。这意味着实现理论上很快，但是如果具有给定密钥的下一个节点与其他节点位于不同的机架中则不行。如图7-1所示。
这里发生的是选择环上的下N个节点来保存副本，而策略没有数据中心的概念。图中显示了第二个数据中心，以突出该策略未意识到的事实。
NetworkTopologyStrategy
现在假设您希望在多个中心之间传播复制品，以防其中一个数据中心遭受某种灾难性故障或网络中断。 NetworkTopologyStrategy允许您请求将某些副本放在DC1中，而某些副本放在DC2中。在每个数据中心内，NetworkTopologyStrategy在不同的机架上分发复制副本，因为同一机架（或类似的物理分组）中的节点通常由于电源，冷却或网络问题而同时发生故障。
NetworkTopologyStrategy按如下方式分发副本：根据所选分区器替换第一个副本。通过遍历环中的节点放置后续副本，跳过同一机架中的节点，直到找到另一个机架中的节点。该过程重复进行其他复制，将它们放在单独的机架上。将副本放置在每个机架中后，跳过的节点将用于放置副本，直到满足复制因子。
NetworkTopologyStrategy允许您为每个数据中心指定复制因子。因此，将存储的副本总数等于每个数据中心的复制因子的总和。 NetworkTopologyStrategy的结果如图7-2所示。
细心的观察者会注意到Cassandra实际上有两个额外的复制策略：OldNetworkTopologyStrategy和LocalStrategy。
OldNetworkTopologyStrategy类似于网络拓扑策略，因为它将副本放置在多个数据中心中，但其算法不太复杂。它将第二个副本放置在与第一个，第三个副本位于第一个数据中心的不同机架中的不同数据中心中，以及通过遍历环上的后续节点放置任何剩余的副本。
LocalStrategy保留给Cassandra自己的内部使用。顾名思义，LocalStrategy仅在本地节点上保留数据，并且不会将此数据复制到其他节点。 Cassandra将此策略用于存储有关本地节点和集群中其他节点的元数据的系统密钥空间。
更改复制因子
您可以通过cqlsh或其他客户端更改现有键空间的复制因子。要使更改完全生效，您需要在每个受影响的节点上运行nodetool命令。如果增加群集（或数据中心）的复制因子，请在群集（或数据中心）中的每个节点上运行nodetool repair命令，以确保Cassandra生成其他副本。只要修复需要，一些客户端可能会收到通知，如果数据连接到尚未包含数据的副本，则数据不存在。
如果减少群集（或数据中心）的复制因子，请在群集（或数据中心）中的每个节点上运行nodetool clean命令，以便Cassandra释放与不需要的副本相关联的空间。我们将在第11章中了解有关修复，清理和其他nodetool命令的更多信息。
作为一般准则，您可以预期您的写入吞吐量容量将是节点数除以复制因子。因此，在一个10节点的集群中，通常每秒执行10,000次写入，复制因子为1，如果将复制因子增加到2，则可以期望每秒执行大约5,000次写入。
总结
在本章中，我们研究了如何创建Cassandra集群并向集群添加其他节点。 我们学习了如何通过cassandra.yaml文件配置Cassandra节点，包括设置种子节点，分区器，snitch和其他设置。 我们还学习了如何为键空间配置复制以及如何选择适当的复制策略。
414
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
