cqlsh alter table 期间的 OperationTimedOut答案

【问题标题】：OperationTimedOut during cqlsh alter tablecqlsh alter table 期间的 OperationTimedOut
【发布时间】：2015-12-06 22:18:41
【问题描述】：

我在 cqlsh 中运行 alter table 命令时收到 OperationTimedOut 错误。这怎么可能？既然这只是一个表元数据更新，那么这个操作不应该几乎立即运行吗？

具体来说，这是我的 cqlsh 会话的摘录

cqlsh:metric> alter table metric with gc_grace_seconds = 86400;
OperationTimedOut: errors={}, last_host=sandbox73vm230

指标表当前的 gc_grace_seconds 为 864000。我在 2 节点集群和 6 节点 2 数据中心集群中看到了这种行为。我的节点似乎总体上可以正常通信（例如，我可以插入一个并从另一个读取）。这是完整的表定义（一个 cyanite 0.1.3 架构，带有 DateTieredCompactionStrategy、集群和缓存更改）：

CREATE TABLE metric.metric (
    tenant text,
    period int,
    rollup int,
    path text,
    time bigint,
    data list<double>,
    PRIMARY KEY ((tenant, period, rollup, path), time)
) WITH CLUSTERING ORDER BY (time ASC)
    AND bloom_filter_fp_chance = 0.01
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
    AND comment = ''
    AND compaction = {'timestamp_resolution': 'SECONDS', 'class': 'org.apache.cassandra.db.compaction.DateTieredCompactionStrategy'}
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND dclocal_read_repair_chance = 0.0
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = 'NONE';

【问题讨论】：

在一天结束时，它是一个更新，如果网络足够慢，仍然会发生超时，但这是一个有趣的问题。
我会相信网络超时理论，但是这个 alter table 语句在两个完全独立的集群中的多次尝试中始终超时。并且我所有简单的 dml 命令始终如一地完成而没有问题。我不得不想象它所做的不仅仅是更新元数据，我只是不知道它在做什么或如何解决这个问题。

标签： cassandra cqlsh

【解决方案1】：

我现在意识到这个问题已经很老了，你可能已经找到答案或者继续前进，但想发布这个以防其他人偶然发现它。

默认cqlsh 请求超时为10 秒。您可以通过将 --request-timeout 选项设置为允许 ALTER TABLE 运行完成的某个值来启动 cqlsh 来调整此设置，例如：

cqlsh --request-timeout=1000000

【讨论】：