Cassandra学习笔记(二)

=============== 2012-11-21 ====================

在上次的尝试中, 虽然启动了3个节点, 但是, 他们却并不位于一个DataCenter之中, 这点可以在运行nodetool ring时看出. 因为此时返回的始终只是本机节点, 3台机器上都是这种结果.

根据conf/cassandra.yaml的注释, 当有多个节点时, seed_provider域中的seeds应当修改为多个IP地址的列表, 而不是单台机器的IP地址, 于是乎, 我就这三台机器的seeds的值变为一样的, 即3台机器的IP地址列表:

[winter@machine1 conf]$ vi cassandra.yaml
seed_provider:
    # Addresses of hosts that are deemed contact points.
    # Cassandra nodes use this list of hosts to find each other and learn
    # the topology of the ring.  You must change this if you are running
    # multiple nodes!
    - class_name: org.apache.cassandra.locator.SimpleSeedProvider
      parameters:
          # seeds is actually a comma-delimited list of addresses.
          # Ex: ",,"
          - seeds: "192.168.1.3,192.168.1.4,192.168.1.5"

同时, 修改每个节点的conf/cassandra-rackdc.properties
使他们dc都属于DC1, 而rack分别属于RAC1, RAC2, RAC3
并且将三个节点的conf/cassandra-topology.properties都修改为:
192.168.1.3=DC1:RAC1
192.168.1.4=DC1:RAC2
192.168.1.5=DC1:RAC3
最后在修改conf/cassandra.yaml, 把snitch修改成为 GossipingPropertyFileSnitch

之后重启3个节点, 再用nodetool -p 7199在每台机器上运行, 得到的结果都一样, 即3台机器已经组成了一个datacenter:

[winter@bdbcn6 conf]$ nodetool -p 7199 ring
Note: Ownership information does not include topology, please specify a keyspace.
Address         DC          Rack        Status State   Load            Owns                Token
                                                                                           151544589300239137868155804034961160037
192.168.1.3  DC1         RAC1        Up     Normal  49.81 KB        32.16%              36122555281987200757283794162054006973
192.168.1.4  DC1         RAC2        Up     Normal  48.24 KB        4.22%               43301602692991554742024505757145779017
192.168.1.5  DC1         RAC3        Up     Normal  39 KB           63.62%              151544589300239137868155804034961160037

此时在一台机器上创建keyspace DEMO, 在其他两个节点上就可以看到了. 同样的, 在keyspace DEMO下创建Users的column family也可以成功, 并且也通过了gossip协议 replicate到了另外两个节点上. 但是, 但运行GettingStarted中的用于向Users设置数据的命令时, 抛出下列异常:

[default@DEMO] set Users[1111][name] = '1221';
null
UnavailableException()
        at org.apache.cassandra.thrift.Cassandra$insert_result.read(Cassandra.java:15982)
        at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
        at org.apache.cassandra.thrift.Cassandra$Client.recv_insert(Cassandra.java:797)
        at org.apache.cassandra.thrift.Cassandra$Client.insert(Cassandra.java:781)
        at org.apache.cassandra.cli.CliClient.executeSet(CliClient.java:909)
        at org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:222)
        at org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:219)
        at org.apache.cassandra.cli.CliMain.main(CliMain.java:346)

根据 和

该问题似乎是因为, 在replication的环境中, 创建keyspace应该要设置placement_strategy和strategy_options, 尤其是要在strategy中设置replication_factor. 于是, 我就又创建一个keyspace(KEYSPACE1), 并且设置placement_strategy为: org.apache.cassandra.locator.SimpleStrategy , 而在strategy_options中将replication_factor设置为3. 这些具体含义我还没有去看, 但是按照文档所言, 这样做是能工作的.

而后重新在KEYSPACE中创建一个column family 'Table1', 并且向Table1中输入数据, 结果果然成功了, 而后在另外两个节点上检查, 发现果然在此节点上的数据已经通过gossip replicate到另外两个节点上了.

实际上, 使用GossipingPropertyFileSnitch并不要求一定要有cassandra-topology.properties, 因为注释说cassandra-topology.properties 实际上是为了PropertyFileSnitch的迁移, 所以, 我又找了一台机器. 在这台机器上将cassandra-topology.properties内容清空, 只设置cassandra-rackdc.properties的内容为:
dc=DC1
rack=RAC2
而后同样使用GossipingPropertyFileSnitch, 而把seeds设置为两台机器的IP地址(本新机器和另外某台机器). 启动后用nodetool ring在各台机器上运行, 得到一下结果:

winter@bdbcn10:~/tools/apache-cassandra-1.1.6/conf$ nodetool ring
Note: Ownership information does not include topology, please specify a keyspace.
Address         DC          Rack        Status State   Load            Owns                Token
                                                                                           151544589300239137868155804034961160037
192.168.1.3  DC1         RAC1        Up     Normal  40.75 KB        32.16%              36122555281987200757283794162054006973
192.168.1.4  DC1         RAC2        Up     Normal  52.36 KB        4.22%               43301602692991554742024505757145779017
192.168.1.6   DC1         RAC2        Up     Normal  39.46 KB        38.58%              108944715007630684863130516504081237314
192.168.1.5  DC1         RAC3        Up     Normal  47.85 KB        25.04%              151544589300239137868155804034961160037

可见新加入节点已经被加入datacenter, 同时说明, seeds不需要列出全部的机器地址, 只要列出其中一台就可以了. 其他的机器可以通过自动学习得到.  同时说明cassandra-rackdc.properties在GossipingPropertyFileSnitch才是真正需要的.

在新节点上运行cassandra-cli, 来检查KEYSPACE1中Table1的内容, 也得到所需结果, 证明replication的发生.

起初我以为replication_factor:3中,3是表示备份的数目, 但是当我另外用replication_factor:2创建一个keyspace KEYSPACE2,并且建立column family, 向其中输入数据后, 依然在另外3台机器上看到这个数据. 并且更加诡异的是, 注释中提到, cassandra尽量保证不将相同的数据放入相同的rack中, 而我两台同属于RAC2的机器上都看到KEYSPACE2中的相同数据.

如果注释所言没错的话, 猜测也许cassandra-cli并不是完全从本地取出数据的, 也许有些数据本身就是cassandra-cli通过gossip协议获得的, 即使cassandra-cli看到了数据, 也不证明数据来自于本地存储. 猜测如此, 但具体实现还得做更进一步的研究了.