NinGoo.net

厦门outing

NinGoo — Sat, 28 Aug 2010 23:07:14 +0800

8.14～8.16，技术保障部厦门outing。算起来这是到到淘宝以后的第三次大部门outing，一次临安，一次安吉，这次总算是跨出了浙江省的范围，来到美丽的海边城市厦门。来回都是动车，六个小时的车程，100多人的队伍，打牌聊天，到也不觉旅途的漫长。

淘宝DBA团队有了更多的新成员，难得的在鼓浪屿留下一张合影，可惜的是还有几位没能聚齐。

虽然鼓浪屿上的建筑各具特色，夏门大学的校园风景怡人，南普陀的放生池乌龟成群，不过厦门的大海有点让人失望。

当然，海水一般，海鲜还是不一般的，15号晚上去了传说中的小眼镜，生意好得出奇，在外面露天排号差不多一个小时才轮到，好在味道还是对得起传说中的大名的。路上还有个小插曲，因为人多，需要打两辆车，另外几个同事打的一辆出租车，一说去小眼镜，师傅说小眼镜没空位，就被赶下车了，囧。厦门这边的服务水平有待提高，一不小心就可能碰个钉子。

Related Articles

PermLink: http://www.ningoo.net/html/2010/xiamen_outing.html

Add Comments(0) | Follow NinGoo@Twitter | Google Reader

Cassandra 0.7 值得期待

NinGoo — Thu, 26 Aug 2010 10:32:22 +0800

Author:NinGoo posted on NinGoo.net

在Cassandra的wiki上，很早就有0.7的一些特性描述，其中很有些吸引人，而8月13号Cassandra 0.7 beta1版本终于发布了，这里可以下载。

个人比较关心的几个主要的新特性：

1. Key Space和Column Family定义可以在线增改，不再需要停集群修改配置文件了。
2. 支持secondary index，可以对column建索引，通过接口get_indexed_slices实现针对column的查询。
3. 支持truncate一个column family。
4. 可以针对keyspace设置replica_placement_strategy和replication_factor。
5. Row cache提升了8倍的读性能。之前版本的测试中，Cassandra写性能令人印象深刻，读性能则不如人意。
6. 支持hadoop格式的输出，可以使得数据仓库更容易从Cassandra中抽取数据。

另外，配置文件从xml改成了yaml格式的，读起来更顺畅些。代码里还有很多细节的改进，有时间需要慢慢去看了。期待0.7版本尽快GA。

0.7.0
=====

Features
--------
    - Row keys are now bytes: keys stored by versions prior to 0.7.0 will be
      returned as UTF-8 encoded bytes. OrderPreservingPartitioner and
      CollatingOrderPreservingPartitioner continue to expect that keys contain
      UTF-8 encoded strings, but RandomPartitioner no longer expects strings.
    - A new ByteOrderedPartitioner supports bytes keys with arbitrary content,
      and orders keys by their byte value.
    - Truncate thrift method allows clearing an entire ColumnFamily at once
    - DatacenterShardStrategy is ready for use, enabling
      ConsitencyLevel.DCQUORUM and DCQUORUMSYNC.  See comments in
      `cassandra.yaml.`
    - row size limit increased from 2GB to 2 billion columns
    - Hadoop OutputFormat support
    - Streaming data for repair or node movement no longer requires
      anticompaction step first
    - keyspace is per-connection in the thrift API instead of per-call
    - optional round-robin scheduling between keyspaces for multitenant
      clusters
    - dynamic endpoint snitch mitigates the impact of impaired nodes
    - significantly faster reads from row cache
    - introduced IntegerType that is both faster than LongType and
      allows integers of both less and more bits than Long's 64

Configuraton
------------
    - Configuration file renamed to cassandra.yaml and log4j.properties to
      log4j-server.properties
    - Added 'bin/config-converter' to convert existing storage-conf.xml or
      cassandra.xml files to a cassandra.yaml file. When executed, it will
      create a cassandra.yaml file in any directory containing a matching
      xml file.
    - The ThriftAddress and ThriftPort directives have been renamed to
      RPCAddress and RPCPort respectively.
    - The keyspaces defined in cassandra.yaml are ignored on startup as a
      result of CASSANDRA-44.  A JMX method has been exposed in the
      StorageServiceMBean to force a schema load from cassandra.yaml. It
      is a one-shot affair though and you should conduct it on a seed node
      before other nodes. Subsequent restarts will load the schema from the
      system table and attempts to load the schema from YAML will be ignored.
      You shoud only have to do this for one node since new nodes will receive
      schema updates on startup from the seed node you updated manually.
    - EndPointSnitch was renamed to RackInferringSnitch.  A new SimpleSnitch
      has been added.
    - RowWarningThresholdInMB replaced with in_memory_compaction_limit_in_mb
    - GCGraceSeconds is now per-ColumnFamily instead of global
    - Configuration of DatacenterShardStrategy is now a part of the keyspace
      definition using the strategy_options attribute.
      The datacenter.properties file is no longer used.

JMX
---
    - StreamingService moved from o.a.c.streaming to o.a.c.service
    - GMFD renamed to GOSSIP_STAGE
    - {Min,Mean,Max}RowCompactedSize renamed to {Min,Mean,Max}RowSize
      since it no longer has to wait til compaction to be computed

Thrift API
----------
    - Row keys are now 'bytes': see the Features list.
    - The return type for login() is now AccessLevel.
    - The get_string_property() method has been removed.
    - The get_string_list_property() method has been removed.

Other
-----
    - If extending AbstractType, make sure you follow the singleton pattern
      followed by Cassandra core AbstractType extensions.
      e.g. BytesType has a variable called 'instance' and an empty constructor
      with default access

0.7.0-beta1
 * sstable versioning (CASSANDRA-389)
 * switched to slf4j logging (CASSANDRA-625)
 * access levels for authentication/authorization (CASSANDRA-900)
 * add ReadRepairChance to CF definition (CASSANDRA-930)
 * fix heisenbug in system tests, especially common on OS X (CASSANDRA-944)
 * convert to byte[] keys internally and all public APIs (CASSANDRA-767)
 * ability to alter schema definitions on a live cluster (CASSANDRA-44)
 * renamed configuration file to cassandra.xml, and log4j.properties to
   log4j-server.properties, which must now be loaded from
   the classpath (which is how our scripts in bin/ have always done it)
   (CASSANDRA-971)
 * change get_count to require a SlicePredicate. create multi_get_count
   (CASSANDRA-744)
 * re-organized endpointsnitch implementations and added SimpleSnitch
   (CASSANDRA-994)
 * Added preload_row_cache option (CASSANDRA-946)
 * add CRC to commitlog header (CASSANDRA-999)
 * removed multiget thrift method (CASSANDRA-739)
 * removed deprecated batch_insert and get_range_slice methods (CASSANDRA-1065)
 * add truncate thrift method (CASSANDRA-531)
 * http mini-interface using mx4j (CASSANDRA-1068)
 * optimize away copy of sliced row on memtable read path (CASSANDRA-1046)
 * replace constant-size 2GB mmaped segments and special casing for index
   entries spanning segment boundaries, with SegmentedFile that computes
   segments that always contain entire entries/rows (CASSANDRA-1117)
 * avoid reading large rows into memory during compaction (CASSANDRA-16)
 * added hadoop OutputFormat (CASSANDRA-1101)
 * efficient Streaming (no more anticompaction) (CASSANDRA-579)
 * split commitlog header into separate file and add size checksum to
   mutations (CASSANDRA-1179)
 * avoid allocating a new byte[] for each mutation on replay (CASSANDRA-1219)
 * revise HH schema to be per-endpoint (CASSANDRA-1142)
 * add joining/leaving status to nodetool ring (CASSANDRA-1115)
 * allow multiple repair sessions per node (CASSANDRA-1190)
 * add dynamic endpoint snitch (CASSANDRA-981)
 * optimize away MessagingService for local range queries (CASSANDRA-1261)
 * make framed transport the default so malformed requests can't OOM the
   server (CASSANDRA-475)
 * significantly faster reads from row cache (CASSANDRA-1267)
 * take advantage of row cache during range queries (CASSANDRA-1302)
 * make GCGraceSeconds a per-ColumnFamily value (CASSANDRA-1276)
 * keep persistent row size and column count statistics (CASSANDRA-1155)
 * add IntegerType (CASSANDRA-1282)
 * page within a single row during hinted handoff (CASSANDRA-1327)
 * push DatacenterShardStrategy configuration into keyspace definition,
   eliminating datacenter.properties. (CASSANDRA-1066)
 * optimize forward slices starting with '' and single-index-block name
   queries by skipping the column index (CASSANDRA-1338)
 * streaming refactor (CASSANDRA-1189)

Related Articles

PermLink: http://www.ningoo.net/html/2010/cassandra-0-7-beta1.html

Add Comments(0) | Follow NinGoo@Twitter | Google Reader

btrfs文件系统

NinGoo — Sat, 21 Aug 2010 00:08:02 +0800

Author:NinGoo posted on NinGoo.net

最近一位同事在美国参加LSF(Linux Storage and Filesystem Summit)回来，分享了他的总结，非常的精彩。这是一个没有演讲、没有照片、没有录像的讨论为主的会议，因此参会者基本上都是比较资深的Linux内核和文件系统的开发者，参加这个讨论会的有不少中国人（华人），相比起我们这些只是理解使用某个数据库产品的DBA来说，这是值得我们敬仰的一群人。也许在不远的将来，淘宝的DBA团队也不仅仅是一个维护某种数据库产品的团队，也能在开源数据库领域内贡献自己的力量，这也正是我们接下来招聘的思路所在。淘宝DBA团队，也已经建立了开源数据库研究小组，当前主要是MySQL/InnoDB，如果你是一位优秀的c/c++开发者，如果你对MySQL/InnoDB等开源数据库在大规模大并发量的网站应用有兴趣，如果你想有一天，能够为开源数据库提供Patch，欢迎加入我们，不管之前你有没有DBA经验，也不管你还是个应届毕业生（我的邮箱jiangfeng # taobao.com，你懂的）。

扯远了，这里我想说的是，从这个报告我注意到了btrfs文件系统。前一段时间，也一直在考虑，在Linux上部署MySQL数据库，究竟什么样的文件系统会比较适合？或者说什么文件系统适合不同的数据库环境？之前的思路，更多的集中在xfs, ext4等已经比较熟悉的文件系统上，上周去北京出差的时候，本来还想找前面的这位同事探讨一下ext4是否适合在数据库产品环境中部署，而当时他正好在美国参加LSF，因此也错过了机会。不过从他的这个总结来看，ext4已经达到了产品级别的稳定性，应该可以尝试，接下来可能会安排一些测试，这是后话。

对于btrfs，简单的从字面来理解，就是以B-Tree作为组织元数据的数据结构，相比于ext2/ext3使用线性表来保存目录等结构，好处在于查找，插入和删除操作都很高效。btrfs另外一个比较重要的特性是基于extent来分配管理文件空间，而不是传统的block。看到这里，作为DBA，其实可以很明显的看到，这和Oracle数据库组织管理数据的思路何其一致(如果寻根问祖，发现这个btrfs根本就是由Oracle最初在2007年开放出来的项目，本是同根生啊)。关于btrfs更详细的信息，可以参考这里，还有这里。另外，btrfs对于目前热点的SSD磁盘也提供了特别的支持，因此被认为是Linux未来文件系统的趋势所在，虽然目前还是开发版本，但值得关注。

实际上可以做一个简单的类比，就能对btrfs有一个更加感性的认识，可以将btrfs看作是Linux版本的ZFS，其设计思路和特性，很多都是借鉴自ZFS，其主要特性如下：

Copy on Write
Extent based file storage (2^64 max file size)
Space efficient packing of small files
Space efficient indexed directories
Dynamic inode allocation
Writable snapshots
Subvolumes (separate internal filesystem roots)
Object level mirroring and striping
Checksums on data and metadata (multiple algorithms available)
Compression
Integrated multiple device support, with several raid algorithms
Online filesystem check
Very fast offline filesystem check
Efficient incremental backup and FS mirroring
Online filesystem defragmentation

Related Articles

PermLink: http://www.ningoo.net/html/2010/btrfs_file_system.html

Add Comments(4) | Follow NinGoo@Twitter | Google Reader

Cassandra运维之道 v0.2

NinGoo — Fri, 13 Aug 2010 23:07:16 +0800

Author:NinGoo posted on NinGoo.net

最近几个尝试性的Cassandra应用中碰到了一些问题，在查找问题的过程中发现之前有些理解不到位，或者有偏差遗漏的地方，在v0.1的基础上，修改补充了小部分内容。从实际应用来看，Cassandra节点的稳定性还有很多工作要做，而实际系统的运维也还有很多的细节需要逐步规范下来。此PPT中有错漏或者待补充完善的地方，也欢迎大家指正。

Cassandra运维之道 v0.2

View more presentations from seaman ning.

Related Articles

PermLink: http://www.ningoo.net/html/2010/cassandra_operationsv0-2.html

Add Comments(0) | Follow NinGoo@Twitter | Google Reader

驾照到手

NinGoo — Sat, 03 Jul 2010 23:12:41 +0800

Author:NinGoo posted on NinGoo.net

昨天下午去车管所拿驾照，晚上战战兢兢的把车开回了家。今天一大早的被人抓壮丁，从城西到三墩到余杭到城西再杀回余杭最后回城西吃晚饭，一口气开了超过100公里，嗯，有点太猛了^_^

其实去年四月份就过了理论考试，但一直拖着没去练车，直到今年三月才花了一个星期的晚上把移库练了一下，本来准备三月底考试，但今天杭州考驾照的人太多了，没报上名，然后四月份休假10天去了一趟泰国。这一拖，就把桩考和场考拖到了六月五号。场地之前没练过，考试前两天在考试中心直接练了两天，有点紧张的是从六月一号开始杭州要考百米加减挡，虽然练了半天，不过心里一点底也没有。

幸运的是，考试时车上四人，两个起伏路，一个曲线行驶，而我则是直角转弯，把最容易过的项目都凑到一辆车上了。然后是安排路考，因为中间端午节早早的安排了去西塘休闲游，本来教练准备给我报17号的路考，拖到了30号，杯具的是，这一拖居然抽到了夜考，而且城西繁华路段之一的古墩路，下午六点多的下班高峰期，被我戏称”史上最难路考“，而之前的路训我只去了两次，开了不到一个小时。经此“磨难”，幸运过关后，今天在路上应付繁忙的路况，反倒能应付自如了。

场考和路考中，和我同一辆车训练的，都是平时开得最好的两个人没过，技术不能代表一切，安全第一啊。

Related Articles

PermLink: http://www.ningoo.net/html/2010/get_my_dirver_license.html

Add Comments(4) | Follow NinGoo@Twitter | Google Reader

淘宝图片存储与CDN系统[转]

NinGoo — Fri, 02 Jul 2010 13:19:39 +0800

Author:NinGoo posted on NinGoo.net

转载一个PPT，演讲者是淘宝核心系统研发部负责人，LVS开发者，淘宝开源平台的推动者，章文嵩(@wensong)博士。另据不可靠消息，PPT中提到的海量图片存储系统TFS，将于9月份在淘蝌蚪上开源。

淘宝图片存储与Cdn系统

View more presentations from guiwuu.

Related Articles

PermLink: http://www.ningoo.net/html/2010/tfs_cdn_ppt_from_wensong.html

Add Comments(1) | Follow NinGoo@Twitter | Google Reader

开源的淘宝

NinGoo — Wed, 30 Jun 2010 21:01:35 +0800

Author:NinGoo posted on NinGoo.net

非常低调的，淘宝开源平台今天上线了。并且一款重量级的产品在平台上正式开源：Tair。

Tair是淘宝内部广泛使用的核心分布式缓存系统，在数据库前面承担了大量的访问压力，基本上你能想到的电子商务网站访问压力较大的应用场景中，都有Tair的缓存发挥力量的地方。非常期待Tair开源以后能有更多优秀的开发者加入，让Tair能够更加健壮的发展，这样作为DBA，我们的日子就可以过得更轻松一点了，毕竟大压力的互联网应用中，缓存为王。

Tair总体架构图(refer):

Tair只是一个开始，接下来，淘宝更多的核心底层与具体业务逻辑无关的产品将陆续开源，从今天开始，淘宝将是一个开源的淘宝，希望有一天，DBA也能为这个开源平台贡献一份力量。

谨以此帖，猛顶淘蝌蚪。

Related Articles

PermLink: http://www.ningoo.net/html/2010/taobao_code_open_source.html

Add Comments(2) | Follow NinGoo@Twitter | Google Reader

Perl的English模块

NinGoo — Tue, 29 Jun 2010 19:57:10 +0800

Author:NinGoo posted on NinGoo.net

Perl中有很多以$开头的特殊变量，如果使用得当，可以写出简洁高效的代码，但对于阅读代码来说就带来了一些困扰。因此Perl内置了名为English的模块，对这些特殊变量定义了英文别名，记录于此备查。

special variable	alias
miscellaneous
`$_`	`$ARG`
`@_`	`@ARG`
`$"`	`$LIST_SEPARATOR`
`$;`	`$SUBSCRIPT_SEPARATOR` or `$SUBSEP`
regular expression or matching
`$&`	`$MATCH`
$`	`$PREMATCH`
`$'`	`$POSTMATCH`
`$+`	`$LAST_PAREN_MATCH`
input
`$.`	`$INPUT_LINE_NUMBER` or `$NR`
`$/`	`$INPUT_RECORD_SEPARATOR` or `$RS`
output
`$\|`	`$OUTPUT_AUTOFLUSH`
`$,`	`$OUTPUT_FIELD_SEPARATOR` or `$OFS`
`$\`	`$OUTPUT_RECORD_SEPARATOR` or `$ORS`
formats
`$%`	`$FORMAT_PAGE_NUMBER`
`$=`	`$FORMAT_LINES_PER_PAGE`
`$_`	`$FORMAT_LINES_LEFT`
`$~`	`$FORMAT_NAME`
`$^`	`$FORMAT_TOP_NAME`
`$:`	`$FORMAT_LINE_BREAK_CHARACTERS`
`$^L`	`$FORMAT_FORMFEED`
error status
`$?`	`$CHILD_ERROR`
`$!`	`$OS_ERROR` or `$ERRNO`
`$@`	`$EVAL_ERROR`
process information
`$$`	`$PROCESS_ID` or `$PID`
`$<`	`$real_user_id` or `$UID`
`$>`	`$EFFECTIVE_USER_ID` or `$EUID`
`$(`	`$REAL_GROUP_ID` or `$GID`
`$)`	`$EFFECTIVE_GROUP_ID` or `$EGID`
`$0`	`$PROGRAM_NAME`
internal variables
`$] or $^V`	`$PERL_VERSION`
`$^A`	`$ACCUMULATOR`
`$^D`	`$DEBUGGING`
`$^F`	`$SYSTEM_FD_MAX`
`$^I`	`$INPLACE_EDIT`
`$^O`	`$OSNAME`
`$^P`	`$PERLDB`
`$^T`	`$BASETIME`
`$^W`	`$WARNING`
`$^X`	`$EXECUTABLE_NAME`

Related Articles

PermLink: http://www.ningoo.net/html/2010/perl_english_module.html

Add Comments(0) | Follow NinGoo@Twitter | Google Reader

Cassandra运维之道

NinGoo — Wed, 23 Jun 2010 21:43:40 +0800

Author:NinGoo posted on NinGoo.net

对于传统的关系数据库Oracle/MySQL等，NoSQL一个相当大的不足是文档资料的缺失。相对而言，Cassandra还能找到不少资料，这个ppt是我根据网上一些资料，结合这几天浏览了一点源代码的一些理解，整理的一个普及资料。名字起的有点大，可能有点地方理解有偏差，权当这是version 0.1吧，接下来一些产品会开始使用Cassandra，结合实际的运维经验，希望能逐步形成类似最佳实践的操作手册。

Cassandra运维之道

View more presentations from seaman ning.

Related Articles

PermLink: http://www.ningoo.net/html/2010/cassandra_operations.html

Add Comments(3) | Follow NinGoo@Twitter | Google Reader

Cassandra之Token

NinGoo — Sat, 12 Jun 2010 13:36:22 +0800

Author:NinGoo posted on NinGoo.net

有一个多月没有更新过blog了，有点惭愧。不管何种理由，不管工作生活有何种变动，有一些我们内心真正追求的东西，不能放弃。昨天晚上，世界杯大幕拉开，在等待揭幕战的过程中，看了一段Cassandra关于dht部分的源代码。要在生产系统中运维，则数据如何分布不得不做周详细致的考虑。

将Cassandra用于实际的生成环境，一个必须要考虑的关键问题是Token的选择。Token决定了每个节点存储的数据的分布范围，每个节点保存的数据的key在(前一个节点Token，本节点Token]的半开半闭区间内，所有的节点形成一个首尾相接的环，所以第一个节点保存的是大于最大Token小于等于最小Token之间的数据。

根据采用的分区策略的不同，Token的类型和设置原则也有所不同。 Cassandra (0.6版本)本身支持三种分区策略：

RandomPartitioner：随机分区是一种hash分区策略，使用的Token是大整数型(BigInteger)，范围为0~2^127，因此极端情况下，一个采用随机分区策略的Cassandra集群的节点可以达到2^127+1个节点。嗯，为什么是2^127？因为Cassandra采用了MD5作为hash函数，其结果是128位的整数值(其中一位是符号位，Token取绝对值为结果)。采用随机分区策略的集群无法支持针对Key的范围查询。假如集群有N个节点，每个节点的hash空间采取平均分布的话，那么第i个节点的Token可以设置为：

 i * ( 2 ^ 127 / N )

下面的测试程序是从org.apache.cassandra.utils.FBUtilities类抽取出来的计算MD5值的函数，输入任何字符都可以得到其对应的MD5的整数值，利用该值和节点的Token对比即可知道该Key对应的数据归属于哪个节点：

import java.io.*;
import java.util.*;
import java.math.BigInteger;
import java.security.MessageDigest;

class get_md5{
  static final Scanner cin=new Scanner(System.in);

  public static byte[] hash(String type, byte[]... data){
    byte[] result = null;
    try{
      MessageDigest messageDigest = MessageDigest.getInstance(type);
      for(byte[] block : data)
        messageDigest.update(block);
      result = messageDigest.digest();
    }
    catch (Exception e){
      throw new RuntimeException(e);
    }
    return result;
  }

  public static BigInteger hash(String data){
    byte[] result = hash("MD5", data.getBytes());
    BigInteger hash = new BigInteger(result);
    return hash.abs();
  }

  public static void main(String[] args){
    while(cin.hasNext()){
      String str1=cin.next();
      BigInteger a= hash(str1);
      System.out.println(a);
    }
  }
}

D:>java get_md5
ningoo
100335222541762605209205022078301814192
江枫
48295316926871024838894171432474082043

OrderPreservingPartitioner：如果要支持针对Key的范围查询，那么可以选择这种有序分区策略。该策略采用的是字符串类型的Token。每个节点的具体选择需要根据Key的情况来确定。如果没有指定InitialToken，则系统会使用一个长度为16的随机字符串作为Token，字符串包含大小写字符和数字。

CollatingOrderPreservingPartitioner：和OrderPreservingPartitioner一样是有序分区策略。只是排序的方式不一样，采用的是字节型Token，支持设置不同语言环境的排序方式，代码中默认是en_US。

分区策略和每个节点的Token(Initial Token)都可以在storage-conf.xml配置文件中设置：

<Partitioner>org.apache.cassandra.dht.RandomPartitioner</Partitioner>

<InitialToken>10633823966279300000000000000000000000</InitialToken>

节点初始化完成以后，Token值做为元数据会保留在system keyspace中，每次启动会以该值为准，即使再改动配置文件中的InitialToken也不会产生任何影响。

Saved Token found: 10633823966279300000000000000000000000

通过nodetool的ring命令，可以查看集群各个节点的Token，这些Token值最好备份下来，当出现节点彻底顺坏时，可以重新设置同样的Token，确保数据分布可以不受节点损坏的影响。

 nodetool -h test ring
Address       Status     Load          Range                                      Ring
                                       85070591730234600000000000000000000000
192.168.0.1 Up         0 bytes       10633823966279300000000000000000000000     |<--|
192.168.0.2 Up         0 bytes       85070591730234600000000000000000000000     |-->|

PS: 在我的0.6.2的一个测试集群中，使用nodetool时不小心连到了9160端口，结果每次都会把节点搞挂，百试百灵。而且直接telnet到9160端口，随便发送个字符，也会把节点搞崩溃。不知道是我的测试环境的原因，还是Thrift有bug，这样节点的健壮性就有问题了，这个端口只能接受协议格式内的信息。对Java和Thrift都不太了解，把这个问题抛出来，希望有大牛能帮忙找到原因。

Update：之前贴的nodetool错连9160端口的报错可能有点误导大家，因为jmx用的默认的8080端口，连9160端口jmx报错是正常的，问题是节点不应该崩溃的。看了/var/log/cassandra/system.log中记录的节点错误信息，报的是OOM，Cassandra的java进程都消失了。调整了一下jvm参数，将heap的最小内存从默认的256MB设置到1G(-Xms1G)，还是有同样的问题。另外，我的java环境是jre1.6.0_18。

ERROR [pool-1-thread-1] 2010-06-12 16:49:40,459 CassandraDaemon.java (line 78)
Fatal exception in thread Thread[pool-1-thread-1,5,main]
java.lang.OutOfMemoryError: Java heap space
        at org.apache.thrift.protocol.TBinaryProtocol.readStringBody(TBinaryProtocol.java:296)
        at org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:203)
        at org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:1113)
        at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:253)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

Google了一把这个错误，也有人碰到过，并且发现Thrift确实有类似的bug：
https://issues.apache.org/jira/browse/THRIFT-601

参考文档：
http://wiki.apache.org/cassandra/Operations

Related Articles

PermLink: http://www.ningoo.net/html/2010/cassandra_token.html

Add Comments(4) | Follow NinGoo@Twitter | Google Reader