Cassandra 中的高可用性
High Availability in Cassandra
1) 我有 5 个节点集群 (172.30.56.60, 172.30.56.61, 172.30.56.62, 172.30.56.63, 172.30.56.129)
2) 我创建了一个键空间，复制因子为 3
写入一致性为 3，我在 table 中插入了一行，分区为“1”，如下所示，
插入用户 (user_id, user_name, user_phone) VALUES(1,'ram', 9003934069);
3) 我使用 nodetool getendpoints 实用程序验证了数据的位置，并观察到数据被复制到三个节点 60、129 和 62。
./nodetool getendpoints keyspacetest user 1
172.30.56.60
172.30.36.129
172.30.56.62
4) 现在，如果我关闭节点 60，Cassandra 需要将现有数据传输到 '1,'ram', 9003934069' 到剩余节点（传输到 61 或 63）以将 RF 保持为“3”？
但是 Cassandra 没有这样做，这是否意味着如果节点 60、129 和 62 出现故障，我将无法读取/写入 [=44= 中分区“1”下的任何数据] 'user' ?
问题 1：所以即使我有 5 个节点的集群，如果它所在的数据/分区出现故障，集群就没用了吗？
问题 2：如果两个节点关闭（示例：60 和 129 关闭）仍然有 61,62 和 63 开启并且 运行，但我无法在分区中写入任何数据 ' 1' 与写入一致性 = 3，为什么会这样？因为我能够写入写入一致性 = 1 的数据，所以这再次表示分区的数据将仅在集群中的预定义节点中可用，没有重新分区的可能性？
如果我的问题的任何部分不清楚，请告诉我，我想澄清一下。
4) Now If I bring down the node 60, Cassandra needs to transfer the
existing data to '1,'ram', 9003934069' to the remaining node (to
either 61 or 63) to maintain the RF as '3'?
这不是 Cassandra 的工作方式 - 复制因子 'only' 声明要将 Cassandra 数据的多少副本存储在不同节点的磁盘上。 Cassandra 以数学方式从您的节点中形成一个环。每个节点负责一系列所谓的令牌（基本上是分区键组件的哈希）。您的复制因子为 3 意味着数据将存储在负责您的数据令牌的节点和环中接下来的两个节点上。
更改环形拓扑非常复杂，根本不会自动完成。
1) 我有 5 个节点集群 (172.30.56.60, 172.30.56.61, 172.30.56.62, 172.30.56.63, 172.30.56.129)
2) 我创建了一个复制因子为 3 的键空间
将一致性写为 3，我在 table 中插入了一行，分区为“1”，如下所示，
插入用户 (user_id, user_name, user_phone) VALUES(1,'ram', 9003934069);
3) 我使用 nodetool getendpoints 实用程序验证了数据的位置，并观察到数据被复制到三个节点 60、129 和 62。
./nodetool getendpoints keyspacetest 用户 1
172.30.56.60
172.30.36.129
172.30.56.62
4）现在如果我关闭节点 60，Cassandra 需要将现有数据传输到“1，'ram'，9003934069”到剩余节点（传输到 61 或 63）以将 RF 保持为“3”？
但是 Cassandra 没有这样做，这是否意味着如果节点 60、129 和 62 出现故障，我将无法读取/写入 [=108= 中分区“1”下的任何数据] 'user' ?
Ques 1 : So even If I have 5 node cluster, If the data / partiton
where it resides goes down, the cluster is useless?
没有。另一方面是一致性级别——您可以在其中定义在您的写入和读取请求被视为成功之前必须确认多少节点。上面你还采用了 CL=3 和 RF=3——这意味着所有持有副本的节点都必须响应并且需要在线。如果单个节点宕机，您的请求将一直失败（如果您的集群更大，比如 6 个节点，那么三个在线的可能是 'right' 用于某些写入的节点）。
但 Cassandra 具有可调整的一致性（请参阅 http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html 处的文档）。
例如，您可以选择 QUORUM。然后需要(replication factor/2)+1个节点进行查询。在您的情况下 (3/2)+1=1+1=2 个节点。如果您确实需要一致的数据，那么 QUORUM 是完美的，因为在任何情况下，至少有一个参与您请求的节点将在写入和读取之间重叠并拥有最新数据。现在一个节点可以关闭，一切仍然有效。
但是：
Ques 2 : If two nodes are down (Example : 60 and 129 is down) still
61,62 and 63 are up and running, but I am not able to write any data
in the partition '1' with the write consistency = 3, Why it is so?
Where as I am able to write the data with the write consistency = 1 so
this again says the data for the partition will be available only in
the predefined nodes in cluster, No possibility for repartitioning?
看上面 - 这就是解释。用于写入一致性的 CL=1 将成功，因为一个节点仍然在线并且您只请求一个节点来确认您的写入。
当然复制因子也不是一点用都没有。即使选择了较低的一致性级别，写入也会复制到所有可用节点，但您不必在客户端等待它。如果一个节点在短时间内（默认 3 小时）停机，协调器将存储错过的写入并在节点再次出现并且您的数据再次完全复制时重播它们。
如果节点停机时间较长，则有必要 运行 nodetool repair 并让集群重建一致的状态。无论如何，这应该作为维护任务定期完成，以保持您的集群健康 - 由于 network/load 问题可能会错过写入，并且删除可能会造成墓碑，这可能会很痛苦。
并且您可以在集群中删除或添加节点（如果这样做，一次只需添加一个），Cassandra 会为您重新分区您的环。
如果删除在线节点可以将其上的数据流式传输给其他节点，则可以删除离线节点但其上的数据将没有足够的副本，因此 nodetool repair 必须是 运行.
添加节点会将新的令牌范围分配给新节点，并自动将数据流式传输到您的新节点。但是不会为您删除源节点的现有数据（保证您的安全），因此添加节点后 nodetool cleanup 是您的朋友。
Cassandra根据CAP定理选择A(vailable)和P(artition tolerant)。
（参见 https://en.wikipedia.org/wiki/CAP_theorem）。因此，您无法在任何时候保持一致性 - 但 QUORUM 通常绰绰有余。
监控您的节点，不要太害怕节点故障 - 它只是在磁盘死机或网络丢失时发生，但请为此设计您的应用程序。
更新：在您丢失数据或查询之前，由用户选择您的集群可能发生的情况。如果需要，您可以使用更高的复制因子（RF=7 和 CL.QUROUM 容忍 3 的丢失）and/or 即使在不同位置的多个数据中心，以防丢失整个数据中心（这在现实生活中发生，想想网络丢失）。
下面关于 https://www.ecyrd.com/cassandracalculator/ 的评论：
簇大小 3
复制因子 2
写等级 2
阅读 1 级
您的读取是一致的：当然，您的写入请求需要得到所有副本的确认。
在不影响应用程序的情况下，您可以在没有节点丢失的情况下幸存下来：见上文，RF=2 和 WC=2 请求任何时候所有节点都需要响应写入.因此，对于写入，您的应用程序将受到影响，对于读取，一个节点可能会关闭。
你可以在 1 个节点丢失的情况下幸存下来而不会丢失数据：因为数据被写入 2 个副本，你只能从一个节点读取，如果一个节点关闭，你仍然可以从另一个。
你真的每次都从 1 个节点读取: RC=1 请求你的读取由一个副本提供服务 - 所以第一个确认读取的将执行，如果一个节点关闭并不重要，因为另一个节点可以确认您的阅读。
你真的每次都在写2个节点: WC=2请求每次写入都会被两个副本确认——这也是你的副本数例子。所以写入数据时需要所有节点都在线。
每个节点拥有 67% 的数据：只是一些数学运算 ;)
使用这些设置，您无法在写入集群时不受节点丢失的影响而不受影响。但是你的数据是在两个副本上写入磁盘的——所以如果你丢失了一个副本，你的数据仍然在另一个副本上，并从死节点中恢复。
1) 我有 5 个节点集群 (172.30.56.60, 172.30.56.61, 172.30.56.62, 172.30.56.63, 172.30.56.129)
2) 我创建了一个键空间，复制因子为 3
写入一致性为 3，我在 table 中插入了一行，分区为“1”，如下所示，
插入用户 (user_id, user_name, user_phone) VALUES(1,'ram', 9003934069);
3) 我使用 nodetool getendpoints 实用程序验证了数据的位置，并观察到数据被复制到三个节点 60、129 和 62。
./nodetool getendpoints keyspacetest user 1
172.30.56.60
172.30.36.129
172.30.56.62
4) 现在，如果我关闭节点 60，Cassandra 需要将现有数据传输到 '1,'ram', 9003934069' 到剩余节点（传输到 61 或 63）以将 RF 保持为“3”？
但是 Cassandra 没有这样做，这是否意味着如果节点 60、129 和 62 出现故障，我将无法读取/写入 [=44= 中分区“1”下的任何数据] 'user' ?
问题 1：所以即使我有 5 个节点的集群，如果它所在的数据/分区出现故障，集群就没用了吗？
问题 2：如果两个节点关闭（示例：60 和 129 关闭）仍然有 61,62 和 63 开启并且 运行，但我无法在分区中写入任何数据 ' 1' 与写入一致性 = 3，为什么会这样？因为我能够写入写入一致性 = 1 的数据，所以这再次表示分区的数据将仅在集群中的预定义节点中可用，没有重新分区的可能性？
如果我的问题的任何部分不清楚，请告诉我，我想澄清一下。
4) Now If I bring down the node 60, Cassandra needs to transfer the existing data to '1,'ram', 9003934069' to the remaining node (to either 61 or 63) to maintain the RF as '3'?
这不是 Cassandra 的工作方式 - 复制因子 'only' 声明要将 Cassandra 数据的多少副本存储在不同节点的磁盘上。 Cassandra 以数学方式从您的节点中形成一个环。每个节点负责一系列所谓的令牌（基本上是分区键组件的哈希）。您的复制因子为 3 意味着数据将存储在负责您的数据令牌的节点和环中接下来的两个节点上。
更改环形拓扑非常复杂，根本不会自动完成。
1) 我有 5 个节点集群 (172.30.56.60, 172.30.56.61, 172.30.56.62, 172.30.56.63, 172.30.56.129)
2) 我创建了一个复制因子为 3 的键空间 将一致性写为 3，我在 table 中插入了一行，分区为“1”，如下所示，
插入用户 (user_id, user_name, user_phone) VALUES(1,'ram', 9003934069);
3) 我使用 nodetool getendpoints 实用程序验证了数据的位置，并观察到数据被复制到三个节点 60、129 和 62。
./nodetool getendpoints keyspacetest 用户 1 172.30.56.60 172.30.36.129 172.30.56.62 4）现在如果我关闭节点 60，Cassandra 需要将现有数据传输到“1，'ram'，9003934069”到剩余节点（传输到 61 或 63）以将 RF 保持为“3”？
但是 Cassandra 没有这样做，这是否意味着如果节点 60、129 和 62 出现故障，我将无法读取/写入 [=108= 中分区“1”下的任何数据] 'user' ?
Ques 1 : So even If I have 5 node cluster, If the data / partiton where it resides goes down, the cluster is useless?
没有。另一方面是一致性级别——您可以在其中定义在您的写入和读取请求被视为成功之前必须确认多少节点。上面你还采用了 CL=3 和 RF=3——这意味着所有持有副本的节点都必须响应并且需要在线。如果单个节点宕机，您的请求将一直失败（如果您的集群更大，比如 6 个节点，那么三个在线的可能是 'right' 用于某些写入的节点）。
但 Cassandra 具有可调整的一致性（请参阅 http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html 处的文档）。
例如，您可以选择 QUORUM。然后需要(replication factor/2)+1个节点进行查询。在您的情况下 (3/2)+1=1+1=2 个节点。如果您确实需要一致的数据，那么 QUORUM 是完美的，因为在任何情况下，至少有一个参与您请求的节点将在写入和读取之间重叠并拥有最新数据。现在一个节点可以关闭，一切仍然有效。
但是：
Ques 2 : If two nodes are down (Example : 60 and 129 is down) still 61,62 and 63 are up and running, but I am not able to write any data in the partition '1' with the write consistency = 3, Why it is so? Where as I am able to write the data with the write consistency = 1 so this again says the data for the partition will be available only in the predefined nodes in cluster, No possibility for repartitioning?
看上面 - 这就是解释。用于写入一致性的 CL=1 将成功，因为一个节点仍然在线并且您只请求一个节点来确认您的写入。
当然复制因子也不是一点用都没有。即使选择了较低的一致性级别，写入也会复制到所有可用节点，但您不必在客户端等待它。如果一个节点在短时间内（默认 3 小时）停机，协调器将存储错过的写入并在节点再次出现并且您的数据再次完全复制时重播它们。
如果节点停机时间较长，则有必要 运行 nodetool repair 并让集群重建一致的状态。无论如何，这应该作为维护任务定期完成，以保持您的集群健康 - 由于 network/load 问题可能会错过写入，并且删除可能会造成墓碑，这可能会很痛苦。
并且您可以在集群中删除或添加节点（如果这样做，一次只需添加一个），Cassandra 会为您重新分区您的环。
如果删除在线节点可以将其上的数据流式传输给其他节点，则可以删除离线节点但其上的数据将没有足够的副本，因此 nodetool repair 必须是 运行.
添加节点会将新的令牌范围分配给新节点，并自动将数据流式传输到您的新节点。但是不会为您删除源节点的现有数据（保证您的安全），因此添加节点后 nodetool cleanup 是您的朋友。
Cassandra根据CAP定理选择A(vailable)和P(artition tolerant)。 （参见 https://en.wikipedia.org/wiki/CAP_theorem）。因此，您无法在任何时候保持一致性 - 但 QUORUM 通常绰绰有余。
监控您的节点，不要太害怕节点故障 - 它只是在磁盘死机或网络丢失时发生，但请为此设计您的应用程序。
更新：在您丢失数据或查询之前，由用户选择您的集群可能发生的情况。如果需要，您可以使用更高的复制因子（RF=7 和 CL.QUROUM 容忍 3 的丢失）and/or 即使在不同位置的多个数据中心，以防丢失整个数据中心（这在现实生活中发生，想想网络丢失）。
下面关于 https://www.ecyrd.com/cassandracalculator/ 的评论：
簇大小 3
复制因子 2
写等级 2
阅读 1 级
您的读取是一致的：当然，您的写入请求需要得到所有副本的确认。
在不影响应用程序的情况下，您可以在没有节点丢失的情况下幸存下来：见上文，RF=2 和 WC=2 请求任何时候所有节点都需要响应写入.因此，对于写入，您的应用程序将受到影响，对于读取，一个节点可能会关闭。
你可以在 1 个节点丢失的情况下幸存下来而不会丢失数据：因为数据被写入 2 个副本，你只能从一个节点读取，如果一个节点关闭，你仍然可以从另一个。
你真的每次都从 1 个节点读取: RC=1 请求你的读取由一个副本提供服务 - 所以第一个确认读取的将执行，如果一个节点关闭并不重要，因为另一个节点可以确认您的阅读。
你真的每次都在写2个节点: WC=2请求每次写入都会被两个副本确认——这也是你的副本数例子。所以写入数据时需要所有节点都在线。
每个节点拥有 67% 的数据：只是一些数学运算 ;)
使用这些设置，您无法在写入集群时不受节点丢失的影响而不受影响。但是你的数据是在两个副本上写入磁盘的——所以如果你丢失了一个副本，你的数据仍然在另一个副本上，并从死节点中恢复。