Cassandra物化视图未配置表及批量建表、Repair异常问题求助

我来帮你拆解下遇到的这几个问题，都是Cassandra和express-cassandra配合时常见的坑，咱们逐个解决：

一、表创建到20张就停滞，需多次重启才能完成 #

这个问题主要是集群schema同步延迟或者express-cassandra并发创建过载导致的，试试下面的方案：

• 调整express-cassandra的schema同步配置，在你的连接配置里增加这两个参数，给集群足够的时间同步schema：

  const models = require('express-cassandra');
  models.setDirectory( __dirname + '/models').bind(
      {
          clientOptions: {
              contactPoints: ['seed1-ip', 'seed2-ip'],
              localDataCenter: 'datacenter1',
              // 新增以下配置
              max_schema_agreement_wait: 60000, // 等待schema同步的最长时间，单位毫秒
              schema_sync_retries: 10 // 同步失败后的重试次数
          },
          ormOptions: {
              createKeyspace: true,
              createTable: true
          }
      },
      function(err) {
          if(err) console.error(err);
          else console.log('Schema synced');
      }
  );
  

• 分批次创建表：不要一次性让express-cassandra加载70张表的定义，比如先加载20张，等schema同步完成后（可以通过nodetool describecluster确认所有节点schema版本一致），再加载下一批表的定义。
• 检查Cassandra集群的schema复制策略：确保system_schema的复制策略是SimpleStrategy且replication_factor等于你的节点数，或者用NetworkTopologyStrategy适配你的数据中心，避免schema同步卡顿。

二、访问物化视图提示InvalidRequest: Error from server: code=2200 [Invalid query] message="unconfigured table ..." #

这个问题大概率是物化视图的schema没有在所有节点同步完成，或者创建顺序/定义有问题，解决步骤：

• 先手动验证物化视图定义：在cqlsh里执行你express-cassandra中定义的物化视图创建语句，比如：

  CREATE MATERIALIZED VIEW mykeyspace.my_mv AS
  SELECT id, name FROM mykeyspace.mytable
  WHERE id IS NOT NULL AND name IS NOT NULL
  PRIMARY KEY (name, id);
  

  如果执行报错，说明你的物化视图定义有语法或逻辑问题（比如主键字段不能为null、依赖表不存在等），先修正定义。
• 确保express-cassandra开启了物化视图自动创建：在ormOptions里加上create_materialized_views: true：

  ormOptions: {
      createKeyspace: true,
      createTable: true,
      create_materialized_views: true // 开启物化视图自动创建
  }
  

• 调整创建顺序：在你的模型定义中，确保基础表的定义在对应的物化视图之前，因为物化视图依赖基础表，express-cassandra加载模型的顺序会影响创建顺序。
• 强制同步schema：如果确认物化视图已经创建，但部分节点没同步，在每个节点上执行nodetool refresh，或者重启节点让schema同步。

三、执行repair时提示无法连接在线节点（nodetool status显示UN） #

UN状态只代表节点在 gossip 协议里在线，但repair依赖JMX和节点间的内部通信端口，问题出在网络连通性或JMX配置：

• 检查端口连通性：确保所有节点之间开放了以下端口：
  • 7000：Cassandra内部通信端口（非SSL）
  • 7199：JMX端口（repair用这个端口）
    可以用telnet <节点IP> 7199和telnet <节点IP> 7000测试，如果不通，排查防火墙、安全组或者网络路由问题。
• 检查Cassandra配置：确认所有节点的cassandra.yaml里的listen_address是集群内可达的IP（不要用localhost，除非是单节点），rpc_address设置正确，确保节点之间能互相访问。
• 指定节点执行repair：试试直接指定节点IP执行repair，比如：

  nodetool repair -host <目标节点IP> mykeyspace
  

  如果还是不行，检查目标节点的cassandra-env.sh里的JMX配置，确保JVM_OPTS中包含正确的JMX端口配置：

  JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.port=7199"
  JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.rmi.port=7199"
  JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.host=<节点IP>"
  

• 尝试全量repair：如果增量repair有问题，试试nodetool repair -full mykeyspace，不过全量repair耗时较长，建议在业务低峰期执行。

内容的提问来源于stack exchange，提问作者Patiss