當使用cqlsh執行刪除時，Cassandra NoHostAvailableException

Question

我們有一個包含7個節點的集羣，我們使用datastax java驅動程序連接到集羣。問題是，我不斷得到NoHostAvailableException這樣的：

造成的： com.datastax.driver.core.exceptions.NoHostAvailableException：所有 主機（S）試了查詢失敗（嘗試：/172.31。 7.243：9042 （com.datastax.driver.core.exceptions.DriverException：嘗試獲取可用連接的 超時（您可能需要增加每個主機連接的驅動程序號 ）），/172.31.7.245:9042 （com.datastax.driver.core.exceptions.DriverException：嘗試獲取可用連接的 超時（您可能需要增加 驅動程序的p號呃主機連接）），/172.31.7.246:9042 （com.datastax.driver.core.exceptions.DriverException：嘗試獲取可用連接的 超時（您可能需要增加每個主機連接的驅動器號碼 ）），/172.31.7.247:9042, /172.31.7.232:9042，/172.31.7.233:9042，/172.31.7.244:9042 [只有 顯示前3個主機的錯誤，請使用getErrors（）獲取更多詳細信息]）

所有節點均達到：

UN 172.31.7.244 152.21 GB 256  14.5% 58abea69-e7ba-4e57-9609-24f3673a7e58 RAC1 
UN 172.31.7.245 168.4 GB 256  14.5% bc11b4f0-cf96-4ca5-9a3e-33cc2b92a752 RAC1 
UN 172.31.7.246 177.71 GB 256  13.7% 8dc7bb3d-38f7-49b9-b8db-a622cc80346c RAC1 
UN 172.31.7.247 158.57 GB 256  14.1% 94022081-a563-4042-81ab-75ffe4d13194 RAC1 
UN 172.31.7.243 176.83 GB 256  14.6% 0dda3410-db58-42f2-9351-068bdf68f530 RAC1 
UN 172.31.7.233 159 GB  256  13.6% 01e013fb-2f57-44fb-b3c5-fd89d705bfdd RAC1 
UN 172.31.7.232 166.05 GB 256  15.0% 4d009603-faa9-4add-b3a2-fe24ec16a7c1 RAC1 

，但他們兩個都高CPU負載，especia lly 232，因爲我在該節點中使用cqlsh進行大量刪除。

我知道刪除生成墓碑，但在集羣中有7個節點，我認爲所有主機都不可訪問是正常的。

我們爲java連接配置是：

com.datastax.driver.core.Cluster cluster = null; 
     //Get contact points 
     String[] contactPoints=this.environment.getRequiredProperty(CASSANDRA_CLUSTER_URL).split(","); 
     cluster = com.datastax.driver.core.Cluster.builder() 
      .addContactPoints(contactPoints)) 
      .withCredentials(this.environment.getRequiredProperty(CASSANDRA_CLUSTER_USERNAME), 
       this.environment.getRequiredProperty(CASSANDRA_CLUSTER_PASSWORD)) 
       .withQueryOptions(new QueryOptions() 
       .setConsistencyLevel(ConsistencyLevel.QUORUM)) 
       .withLoadBalancingPolicy(new TokenAwarePolicy(new RoundRobinPolicy())) 
       .withRetryPolicy(new LoggingRetryPolicy(DowngradingConsistencyRetryPolicy.INSTANCE)) 
       .withPort(Integer.parseInt(this.environment.getRequiredProperty(CASSANDRA_CLUSTER_PORT))) 
       .build(); 

     Metadata metadata = cluster.getMetadata(); 
     for (Host host : metadata.getAllHosts()) { 
      LOG.info("Datacenter: "+host.getDatacenter()+"; Host: "+host.getAddress()+"; DC: "+host.getDatacenter()+"\n"); 
     } 

和接觸點是：

172.31.7.244,172.31.7.243,172.31.7.245,172.31.7.246,172.31.7.247

任何人都知道我可以如何解決這個問題？或者至少有任何人有關於如何處理這種情況的暗示？

更新：如果我得到錯誤信息withe.getErrors（）我得到：

/172.31.7.243:9042=com.datastax.driver.core.OperationTimedOutException：[/172.31.7.243:9042 ]操作超時， /172.31.7.244:9042=com.datastax.driver.core.OperationTimedOutException：[/172.31.7.244:9042]操作超時， /172.31.7.245:9042=com.datastax.driver.core .OperationTimedOutException：[/172.31.7.245:9042]操作超時， /172.31.7.246:9042=com.datastax.driver.core.OperationTimedOutException：[/172.31.7.246:9042]操作超時， /172.31.7.247 ：9042 = com.datastax.driver.core.Operati onTimedOutException：[/172.31.7.247:9042]操作超時}

UPDATE：

• 密鑰空間的複製因子爲3。

• 對於使用與CQL查詢不同的文件中運行它們的刪除林：

  cqlsh ip_node_1 -f腳本1.duplicates cqlsh ip_node_1 -f腳本2.duplicates cqlsh ip_node_1 -f腳本-3。重複 ...

• 我沒有指定任何一致性級別，所以使用默認的一個是一個。

• 先前的每個文件包含刪除這樣的：

DELETE FROM keyspace_name.search WHERE idline1 = 837和idline2 = 841和PARTID = 8558和id = 18c04c20-8a3a-11e5-9e20- 0025905a2ab2;

• 和列家族是：

CREATE TABLE搜索（ idline1 BIGINT， idline2 BIGINT， PARTID INT， ID UUID， 場3 INT， 字段4 INT， 字段5 INT， field6 int， field7 int， field8 int， field9 double， field10 bigint， field11 bigint， field12 BIGINT， field13布爾， field14布爾， field15 INT， field16 BIGINT， field17 INT， field18 INT， field19 INT， field20 INT， field21 UUID， field22布爾， PRIMARY KEY（（idline1 ，idline2，PARTID），ID） ）WITH bloom_filter_fp_chance = 0.010000 AND 緩存= 'KEYS_ONLY' AND 評論= AND dclocal_read_repair_chance = 0.000000 AND gc_grace_seconds '與線之間的SNP表'= 0 AND index_inter VAL = 128和 read_repair_chance = 0.100000 AND replicate_on_write = '真' AND populate_io_cache_on_flush = '假' AND default_time_to_live = 0 AND speculative_retry = '99 .0PERCENTILE 'AND memtable_flush_period_in_ms = 0 AND 壓實= { '類'：' SizeTieredCompactionStrategy'} AND compression = {'sstable_compression'：'LZ4Compressor'};

CREATE INDEX search_partid ON search（partid）;

CREATE INDEX search_field8 ON search（field8）;

UPDATE（18-03-2016）：

後刪除開始執行，我發現的一些節點的CPU增加了很多：

我檢查該節點上的進程，只有cassandra正在運行，但消耗了大量的CPU。剩下的節點幾乎不使用cpu。

UPDATE（04-04-2016）：我不知道它是否相關。我檢查了很多CPU（接近96％）和活動活動保持在1.6％的節點（僅使用10個已分配的3 GB）。

Checing線程池統計：

nodetool tpstats 池名稱活躍待完成封鎖了所有的時間封鎖 ReadStage 0 0 20042001 0 0 RequestResponseStage 0 0 149365845 0 0 MutationStage 32 117720 181498576 0 0 ReadRepairStage 0 0 799373 0 0 ReplicateOnWriteStage 0 0 13624173 0 0 GossipStage 0 0 5580503 0 0 CacheCleanupExecutor 0 0 0 0 0 AntiEntropyStage 0 0 3 2173 0 0 MigrationStage 0 0 9 0 0 MemtablePostFlusher 0 0 45044 0 0 MemoryMeter 0 0 9553 0 0 FlushWriter 0 0 9425 0 18 ValidationExecutor 0 0 15980 0 0 MiscStage 0 0 0 0 0 PendingRangeCalculator 0 0 7 0 0 CompactionExecutor 0 0 1293147 0 0 commitlog_archiver 0 0 0 0 0 InternalResponseStage 0 0 0 0 0 HintedHandoff 0 0 273 0 0

消息類型掉落 RANGE_SLICE 0 READ_REPAIR 0 PAGED_RANGE 0 BINARY 0 閱讀0 突變0 _TRACE 0 REQUEST_RESPONSE 0 COUNTER_MUTATION 0

我意識到懸而未決的突變級增長，但活躍值保持不變，可能是這個問題？

Answer 1

我看到您的數據模型有兩個問題。

• 您使用兩個二級索引。一個在分區鍵的字段上。我不知道cassandra在這種情況下的表現如何。最糟糕的情況是，即使你使用完整的分區鍵（就像在你的例子中刪除）cassandra在二級索引中進行查找。在這種情況下，這意味着完整的羣集掃描，因爲二級索引僅存儲在每個分區中。由於只有部分分區鍵被索引，因此cassandra不知道索引信息位於哪個分區上。這種行爲至少會解釋超時。

• 你說過，你刪除了特定分區中的很多行。這也是一個問題。對於每個刪除cassandra創建一個墓碑。越多的墓碑，讀取越慢。這遲早會導致超時或異常（我相信cassandra會在達到1000個墓碑時發出警告，並在達到10000個墓碑時拋出異常）。順便說一句。這些墓碑也是在二級索引中創建的。默認情況下，cassandra將在執行壓縮時刪除gc_grace_seconds（默認10天）後的墓碑。你可以改變每個表的屬性。這些表格屬性的更多信息可以在這裏找到：Table Properties

我認爲第一點可能是超時的原因。