最醉红楼--成江东@盛大在线 http://www.goziwa.com 又一个 WordPress 博客 Fri, 10 Sep 2010 10:07:18 +0000 http://wordpress.org/?v=2.9 en hourly 1 [转]Tokyo Tyrant&Tokyo Cabinet运维方案 http://www.goziwa.com/?p=1060 http://www.goziwa.com/?p=1060#comments Fri, 10 Sep 2010 10:07:18 +0000 学无涯 http://www.goziwa.com/?p=1060 http://www.codytan.com/2010/03/22/ttserveryunweifangan/ note：示例数据库目录 /data/ttserver * 配置TTserver服务器的启动脚本 安装ttserver后默认在/usr/local/sbin目录下有ttserv[......]

from: http://www.codytan.com/2010/03/22/ttserveryunweifangan/

note：示例数据库目录 /data/ttserver

* 配置TTserver服务器的启动脚本

安装ttserver后默认在/usr/local/sbin目录下有ttservctl启动脚本示例，建议copy到具体ttserver数据存放的目录（一个机器可能有多个ttserver服务器，分开便于配置和管理）
cp /usr/local/sbin/ttservctl /data/ttserver/

配置启动脚本ttservctl ,
vim /data/ttserver/ttservctl
如：
# configuration variables
basedir=”/data/ttserver” #数据库目录
port=”8888″ #ttserver端口
ulimsiz=”256m” #对单个ulog文件限制，超过将新建一个文件
sid=1 #server id不能重复
mhost=”remotehost1″ #master的地址
mport=”8888″ #master端口
extfile=”$basedir/ext.lua” #lua扩展脚本文件，默认ttservctl没有这项，如果要使用lua扩展请加上，
#并在启动脚本下面的逻辑代码中增加相应判断。
rtsfile=”$basedir/rts” #replication的时间记录文件
dbname=”$basedir/database.tch#bnum=bucket数量#xmsiz=最大使用内存”
#数据库名称及优化参数（“#”后面参数，根据需求配置，bnum推荐为记录数0.5-4倍，xmsiz理论上越大性能越好，默认64M，也可以使用默认配置，去掉“#”后面参数即可）

启动ttserver服务器：./ttservctl start ； 关闭ttserver服务器：./ttservctl stop ;

note:可以放入rc.local中, ttserver启动脚本如果错误会有提示，也可以检查端口是否启用来确定ttserver的启动是否成功

* TTserver的监控

监控命令：tcrmgr inform -st -port 服务器使用的端口 监控服务地址
监控程序提供数据项包括：内存使用，数据文件大小,读写次数，未命中key数量等，由cacti定时读取实现监控
示例地址：http://…/cacti/graph.php?action=view&rra_id=all&local_graph_id=1050
增加磁盘io监控，iotop （iotop要求linux内核2.6.20以上）

note：具体阀值可以设定iotop占总量的80%

* TTserver的备份

全量热备份

备份命令为：tcrmgr copy -port 1978 localhost dpath.tch.xxxxx (其中xxxxx为备份时间)
根据业务需求及数据库运行状态决定备份的频度,全量热备时数据库库会写锁定，读不受影响。全量备份需记录备份时间点以提供replication恢复时所用，时间记录点精确的微妙，可记录到备份文件名中，如backup.tch.1259474040630024。

示例备份脚本：
[ -n "$1" ] || { echo “input port number”; exit; }
[ -n "$2" ] || { echo “input backup dir”; exit; }

backup_date=`date +%s%N`
backup_date=`expr $backup_date / 1000`
tcrmgr copy -port ${1} localhost ${2}/backup_${1}.tch.${backup_date}
echo “back up finish! ${2}/backup_${1}.tch.${backup_date}”

增量备份ulog
ttserver产生的ulog在”$basedir/ulog”目录，设置了ulimsiz后会按文件尺寸进行切割并按数据升序命名，可以根据备份的频度，按ulog文件最后修改时间，备份到ulog最大命名数字的前一个文件，同时也需记录备份时间，可将时间记录在打包备份的文件名中，如backup_ulog.1259474040630024.tar.gz, 和全量备份一样，精确到微秒。

note：全量备份速度和服务器情况有关，基本接近直接copy速度

* TTserver的恢复

使用replication恢复
根据备份方案中数据库全量备份方法得到的备份库，如backup.tch.xxxxxx ,
echo xxxxxx > “$basedir/rts” 写入备份时间点，即恢复时间点
cp backup.tch.xxxxx database_name.tch
启动: ./ttservctl start
恢复的库会根据时间点去master库同步数据，实现恢复

使用日志增量恢复

先使用前一个全量备份的数据库文件作为基数据库，下线要整理的ttserver。

清空原来的日志，然后解压，再cp 备份的ulog文件 $basedir/ulog/ ，
echo xxxxxx > “$basedir/rts” 写入备份时间点（压缩文件名中包含），即恢复时间点

单独启动ttserver ： ttserver database_name.tch
从日志恢复：tcrmgr restore -port port -rcc localhost ulog
ctrl+c停掉ttserver，然后使用 ./ttservctl start 启动，master结构重新建立

note:日志增量恢复环节应避免受其他ttserver的服务器影响，如可以使用一个不使用的端口进行恢复，这样数据也不会影响到其他服务器，恢复后再用原来的启动脚本启动，形成原来的dual master结构

* TTserver优化

定期优化，整理数据文件碎片，优化命令：
tcrmgr optimize -port port host

note：整理时会锁库，读写都锁定

* 备注
基于dual master的结构具有较高的可靠性，dual master其实就是实时的热备方案，所以在备份频度和广度上是否可以适当宽松一些？建议每天备份全量即可，增量的日志一直留在服务器上，但是日志的分割尺寸要根据业务和恢复的粒度来确定。

]]> http://www.goziwa.com/?feed=rss2&p=1060 0 [转]淘宝开源Key/Value结构数据存储系统Tair技术剖析 http://www.goziwa.com/?p=1054 http://www.goziwa.com/?p=1054#comments Fri, 10 Sep 2010 07:54:11 +0000 学无涯 http://www.goziwa.com/?p=1054 http://www.infoq.com/cn/articles/taobao-tair Tair是由淘宝网自主开发的Key/Value结构数据存储系统，在淘宝网有着大规模的应用。您在登录淘宝、查看商品详情页面或者在淘江湖和好友“捣浆糊”的时候，都在直接或间接地和Tair交互。 Tair于20[......]

原文:http://www.infoq.com/cn/articles/taobao-tair

Tair是由淘宝网自主开发的Key/Value结构数据存储系统，在淘宝网有着大规模的应用。您在登录淘宝、查看商品详情页面或者在淘江湖和好友“捣浆糊”的时候，都在直接或间接地和Tair交互。

Tair于2010年6月30号在淘宝开源平台上正式对外开源，本文较详细地介绍了Tair提供的功能及其实现的细节，希望对大家进一步了解Tair有所帮助。

Tair的功能

Tair是一个Key/Value结构数据的解决方案，它默认支持基于内存和文件的两种存储方式，分别和我们通常所说的缓存和持久化存储对应。

Tair除了普通Key/Value系统提供的功能，比如get、put、delete以及批量接口外，还有一些附加的实用功能，使得其有更广的适用场景，包括：

  • Version支持>
  • 原子计数器
  • Item支持

Version支持

Tair中的每个数据都包含版本号，版本号在每次更新后都会递增。这个特性有助于防止由于数据的并发更新导致的问题。

比如，系统有一个value为“a,b,c”，A和B同时get到这个value。A执行操作，在后面添加一个d，value为“a,b,c,d”。B执行操作添加一个e，value为”a,b,c,e”。如果不加控制，无论A和B谁先更新成功，它的更新都会被后到的更新覆盖。

Tair无法解决这个问题，但是引入了version机制避免这样的问题。还是拿刚才的例子，A和B取到数据，假设版本号为10，A先更新，更新成功后，value为”a,b,c,d”，与此同时，版本号会变为11。当B更新时，由于其基于的版本号是10，服务器会拒绝更新，从而避免A的更新被覆盖。B可以选择get新版本的value，然后在其基础上修改，也可以选择强行更新。

原子计数器

Tair从服务器端支持原子的计数器操作，这使得Tair成为一个简单易用的分布式计数器。

Item支持

Tair还支持将value视为一个item数组，对value中的部分item进行操作。比如有个key的value为[1,2,3,4,5]，我们可以只获取前两个item，返回[1,2]，也可以删除第一个item，还支持将数据删除，并返回被删除的数据，通过这个接口可以实现一个原子的分布式FIFO的队列。

Tair的内部结构

图 1 Tair整体架构图

一个Tair集群主要包括client、configserver和dataserver 3个模块。Configserver通过和dataserver的心跳（HeartBeat）维护集群中可用的节点，并根据可用的节点，构建数据的在集群中的分布信息（见下文的对照表）。Client在初始化时，从configserver处获取数据的分布信息，根据分布信息和相应的dataserver交互完成用户的请求。Dataserver负责数据的存储，并按照configserver的指示完成数据的复制和迁移工作。

数据的分布

分布式系统需要解决的一个重要问题便是决定数据在集群中的分布策略，好的分布策略应该能将数据均衡地分布到所有节点上，并且还应该能适应集群节点的变化。Tair采用的对照表方式较好地满足了这两点。

对照表的行数是一个固定值，这个固定值应该远大于一个集群的物理机器数，由于对照表是需要和每个使用Tair的客户端同步的，所以不能太大，不然同步将带来较大的开销。我们在生产环境中的行数一般为1023 。

对照表简介

下面我们看对照表是怎么完成数据的分布功能的，为了方便，我们这里假设对照表的行数为6。最简单的对照表包含两列，第一列为hash值，第二列为负责该hash值对应数据的dataserver节点信息。比如我们有两个节点192.168.10.1和192.168.10.2，那么对照表类似：

0 192.168.10.1
1 192.168.10.2
2 192.168.10.1
3 192.168.10.2
4 192.168.10.1
5 192.168.10.2

当客户端接收到请求后，将key的hash值和6取模，然后根据取模后的结果查找对照表。比如取模后的值为3，客户端将和192.168.10.2通信。

对照表如何适应节点数量的变化

我们假设新增了一个节点——192.168.10.3，当configserver发现新增的节点后，会重新构建对照表。构建依据以下两个原则：

  1. 数据在新表中均衡地分布到所有节点上。
  2. 尽可能地保持现有的对照关系。

更新之后的对照表如下所示：

0 192.168.10.1
1 192.168.10.2
2 192.168.10.1
3 192.168.10.2
4 192.168.10.3
5 192.168.10.3

这里将原本由192.168.10.1负责的4和192.168.10.2负责的5交由新加入的节点192.168.10.3负责。

如果是节点不可用，则相当于上述过程反过来，道理是一样的。

多备份的支持

Tair支持自定义的备份数，比如你可以设置数据备份为2，以提高数据的可靠性。对照表可以很方便地支持这个特性。我们以行数为6，两个节点为例，2个备份的对照表类似：

0 192.168.10.1 192.168.10.2
1 192.168.10.2 192.168.10.1
2 192.168.10.1 192.168.10.2
3 192.168.10.2 192.168.10.1
4 192.168.10.1 192.168.10.2
5 192.168.10.2 192.168.10.1

第二列为主节点的信息，第三列为辅节点信息。在Tair中，客户端的读写请求都是和主节点交互，所以如果一个节点不做主节点，那么它就退化成单纯的备份节点。因此，多备份的对照表在构建时需要尽可能保证各个节点作为主节点的个数相近。

当有节点不可用时，如果是辅节点，那么configserver会重新为其指定一个辅节点，如果是持久化存储，还将复制数据到新的辅节点上。如果是主节点，那么configserver首先将辅节点提升为主节点，对外提供服务，并指定一个新的辅节点，确保数据的备份数。

多机架和多数据中心的支持

对照表在构建时，可以配置将数据的备份分散到不同机架或数据中心的节点上。Tair当前通过设置一个IP掩码来判断机器所属的机架和数据中心信息。

比如你配置备份数为3，集群的节点分布在两个不同的数据中心A和B，则Tair会确保每个机房至少有一份数据。假设A数据中心包含两份数据时，Tair会尽可能将这两份数据分布在不同机架的节点上。这可以减少整个数据中心或某个机架发生故障是数据丢失的风险。

轻量级的configserver

从Tair的整体架构图上看，configserver很类似传统分布式集群中的中心节点。整个集群服务都依赖于configserver的正常工作。

但Tair的configserver却是一个轻量级的中心节点，在大部分时候，configserver不可用对集群的服务是不造成影响的。

Tair用户和configserver的交互主要是为了获取数据分布的对照表，当client获取到对照表后，会cache这张表，然后通过查这张表决定数据存储的节点，所以请求不需要和configserver交互，这使得Tair对外的服务不依赖configserver，所以它不是传统意义上的中心节点。

configserver维护的对照表有一个版本号，每次新生成表，该版本号都会增加。当有数据节点状态发生变化（比如新增节点或者有节点不可用了）时，configserver会根据当前可用的节点重新生成对照表，并通过数据节点的心跳，将新表同步给数据节点。

当客户端请求数据节点时，数据节点每次都会将自己的对照表的版本号放入response中返回给客户端，客户端接收到response后，会将数据节点返回的版本号和自己的版本号比较，如果不相同，则主动和configserver通信，请求新的对照表。

所以客户端也不需要和configserver保持心跳，以便及时地更新对照表。这使得在正常的情况下，客户端不需要和configserver通信，即使configserver不可用了，也不会对整个集群的服务造成大的影响。

仅有当configserver不可用，此时有客户端需要初始化，那么客户端将取不到对照表信息，这将使得客户端无法正常工作。

DataServer内部结构

DataServer负责数据的物理存储，并根据configserver构建的对照表完成数据的复制和迁移工作。DataServer具备抽象的存储引擎层，可以很方便地添加新存储引擎。DataServer还有一个插件容器，可以动态地加载/卸载插件。

图 2 DataServer的内部结构示意图

抽象的存储引擎层

Tair的存储引擎有一个抽象层，只要满足存储引擎需要的接口，便可以很方便地替换Tair底层的存储引擎。比如你可以很方便地将bdb、tc甚至MySQL作为Tair的存储引擎，而同时使用Tair的分布方式、同步等特性。

Tair默认包含两个存储引擎：mdb和fdb。

mdb是一个高效的缓存存储引擎，它有着和memcached类似的内存管理方式。mdb支持使用share memory，这使得我们在重启Tair数据节点的进程时不会导致数据的丢失，从而使升级对应用来说更平滑，不会导致命中率的较大波动。

fdb是一个简单高效的持久化存储引擎，使用树的方式根据数据key的hash值索引数据，加快查找速度。索引文件和数据文件分离，尽量保持索引文件在内存中，以便减小IO开销。使用空闲空间池管理被删除的空间。

自动的复制和迁移

为了增强数据的安全性，Tair支持配置数据的备份数。比如你可以配置备份数为3，则每个数据都会写在不同的3台机器上。得益于抽象的存储引擎层，无论是作为cache的mdb，还是持久化的fdb，都支持可配的备份数。

当数据写入一个节点（通常我们称其为主节点）后，主节点会根据对照表自动将数据写入到其他备份节点，整个过程对用户是透明的。

当有新节点加入或者有节点不可用时，configserver会根据当前可用的节点，重新build一张对照表。数据节点同步到新的对照表时，会自动将在新表中不由自己负责的数据迁移到新的目标节点。迁移完成后，客户端可以从configserver同步到新的对照表，完成扩容或者容灾过程。整个过程对用户是透明的，服务不中断。

插件容器

Tair还内置了一个插件容器，可以支持热插拔插件。

插件由configserver配置，configserver会将插件配置同步给各个数据节点，数据节点会负责加载/卸载相应的插件。

插件分为request和response两类，可以分别在request和response时执行相应的操作，比如在put前检查用户的quota信息等。

插件容器也让Tair在功能方便具有更好的灵活性。

Tair的未来

我们将Tair开源，希望有更多的用户能从我们开发的产品中受益，更希望依托社区的力量，使Tair有更广阔的发展空间。

Tair开源后，有很多用户关心我们是否会持续维护这个项目。我们将Tair开源后，淘宝内部已经不再有私有的Tair分支，所有的开发和应用都基于开源分支。Tair在淘宝有非常广的应用，我们内部有一个团队，专门负责Tair的开发和维护，相信我们会和社区一起，将Tair越做越好。

有很多用户在淘宝开源平台上申请加入Tair项目，加入项目在我们的开源平台上意味着成为项目的提交者，可以向代码库直接提交代码。所以我们暂时还没有批准外部用户加入，我们将在大家对Tair有更深入的了解后和社区一起决定是否批准加入项目的申请，在此之前，如果你有对代码的改进，欢迎使用patch的方式提交给我们，我们将在review后决定是否合并到代码库。

希望我们能和社区一起，将Tair做成一个真正对大家都有帮助的项目。

关于作者

若海，真名余刚，淘宝网核心系统研发部工程师，Tair的主要作者之一，当前的方向是大型分布式缓存和存储解决方案。

]]> http://www.goziwa.com/?feed=rss2&p=1054 0 [转]MongoDB Indexing and Query Optimizer http://www.goziwa.com/?p=1052 http://www.goziwa.com/?p=1052#comments Thu, 09 Sep 2010 09:59:27 +0000 学无涯 http://www.goziwa.com/?p=1052 注：
————
db.collection.find({ “field” : { $gt: value } } ); // greater than : field > value
db.collection.find({ “field” : { $lt: value } } ); // less than : field < value
db.collection.find({ “field” : { $gte: value } } ); // greater than or equal to : field >= value
db.collection.find({ “field” : { $lte: value } } ); // less than or equal to : field <= value

$ne for “not equals”.

The $in operator is analogous to the SQL IN modifier, allowing you to specify an array of possible matches.
db.collection.find( { “field” : { $in : array } } );

The $mod operator allows you to do fast modulo queries to replace a common case for where clauses. For example, the following $where query:
db.things.find( “this.a % 10 == 1″)
can be replaced by:
db.things.find( { a : { $mod : [ 10 , 1 ] } } )

————

db.createCollection(“c”);

db.c.insert({x:33,y:45});
db.c.insert({x:31,y:27});
db.c.insert({x:3,y:415});

db.c.find({x:{$in:[3,31]}})
{ “_id” : ObjectId(“4c886fa79ca71035adf0c772″), “x” : 31, “y” : 27 }
{ “_id” : ObjectId(“4c886fa79ca71035adf0c773″), “x” : 3, “y” : 415 }
db.c.insert({x:{a:1,b:4},y:415});
db.c.insert({x:{a:1},y:3});

db.c.find({‘x.a’:1});    # using index {‘x.a’:1}
{ “_id” : ObjectId(“4c88727a9ca71035adf0c774″), “x” : { “a” : 1, “b” : 4 }, “y” : 415 }
{ “_id” : ObjectId(“4c8873e49ca71035adf0c776″), “x” : { “a” : 1 }, “y” : 3 }

db.c.find({x:{a:1}});    # using index {x:1}      
{ “_id” : ObjectId(“4c8873e49ca71035adf0c776″), “x” : { “a” : 1 }, “y” : 3 }

db.c.find({x:{$gte:3,$lte:5}});
{ “_id” : ObjectId(“4c886fa79ca71035adf0c773″), “x” : 3, “y” : 415 }
db.c.insert({x:’abc’,y:415});
db.c.insert({x:’bac’,y:3});

db.c.find({x:/^a/});    # 使用索引来判断是否是字符串或正则表达式
{ “_id” : ObjectId(“4c8877159ca71035adf0c777″), “x” : “abc”, “y” : 415 }

db.c.count({x:3})
1

db.c.distinct({y:3})
[ ]

db.c.update({x:3},{$set: {y:97}} ); 
db.c.remove({x:2});

db.c.find({x:null}); # 使用x索引

db.c.insert({y:222});
db.c.find({x:null});              
{ “_id” : ObjectId(“4c887b8a9ca71035adf0c779″), “y” : 222 }

db.c.find({x:{$exists:true}});   # 无法用索引，1.6版会修正

db.c.find({“x”:[1,10]});  # 空??

db.c.find().sort({x:1});
db.c.find().sort({x:-1});

db.c.find({x:{$gt:4}}).sort({x:-1});
{ “_id” : ObjectId(“4c886fa79ca71035adf0c771″), “x” : 33, “y” : 45 }
{ “_id” : ObjectId(“4c886fa79ca71035adf0c772″), “x” : 31, “y” : 27 }

db.c.find({}).sort({‘x.a’:1}) 

db.c.find({x:3,y:97})     # 使用索引{x:1,y:1}
{ “_id” : ObjectId(“4c886fa79ca71035adf0c773″), “x” : 3, “y” : 97 }

db.c.find().sort({x:1,y:1});

db.c.find({x:3}).sort({y:1});

# 索引无效
db.c.find({x:{$ne:3}});
db.c.find({x:{$mod:[10,1]}}); # 索引只是用来找数字

db.c.find({x:{$not:/a/}});

# 索引优化
db.c.find({x:2,y:3}).hint({y:1});
Thu Sep  9 15:23:41 assertion userassert:bad hint ns:test.c query:{ query: { x: 2.0, y: 3.0 }, $hint: { y: 1.0 } }
error: { “$err” : “bad hint” }

db.c.ensureIndex({y:1});

db.c.find({x:2,y:3}).hint($natural:1});    # 绕过索引

# 内存为何如此重要
内存基本使用
全部索引在内存
部分在内存

# 创建索引
_id:1 索引自动建立

db.c.ensureIndex({x:1},{background:true});   # 仍然会影响性能

db.c.ensureIndex({x:1},{unique:true})

# 清除索引

db.system.indices.find({ns:’db.c’});

db.c.dropIndex({x:1})
db.collection.dropIndexes();
db.c.reIndex()

]]> http://www.goziwa.com/?feed=rss2&p=1052 0 [转]schema design with mongodb http://www.goziwa.com/?p=1050 http://www.goziwa.com/?p=1050#comments Thu, 09 Sep 2010 05:22:51 +0000 学无涯 http://www.goziwa.com/?p=1050 http://www.slideshare.net/mongosf/schema-design-with-mongodb-dwight-merriman 什么是面向文档 json 对象 非关系 非oodb 数据库架构!=程序架构 术语 行->json文档 表->collections i[......]

http://www.slideshare.net/mongosf/schema-design-with-mongodb-dwight-merriman

什么是面向文档
json 对象
非关系
非oodb
数据库架构!=程序架构

术语
行->json文档
表->collections
indexes->index
连接->嵌入和linking

选择架构
查询更容易
查询更快
有利于原子性
有利于分片

关键问题：嵌入 vs link
包含相关性：嵌入
嵌入=预连接
Links:客户端/服务器周转
On a close call,嵌入,使用丰富文档
注意4MB对象限制，很专制但是使你注意设计

use test
db.createCollection(“order”)

db.order.insert(
{‘user_id’ : ‘6589′, ‘items’ :
[
{'code':'rbk-432','name':'高性能mysql','price':49},
{'code':'rbk-431','name':'高性能mssql','price':23}
],
‘address’:{
’street’:'huguang road’,
‘city’:’sh’,
’state’:’sh’,
‘zip’:'200001′
},
total:72
}
)

db.order.insert(
{‘user_id’ : ‘6519′, ‘items’ :
[
{'code':'spk-432','name':'oracle调优','price':49},
{'code':'rbk-432','name':'高性能mysql','price':23}
],
‘address’:{
’street’:'huguang road’,
‘city’:’sh’,
’state’:’sh’,
‘zip’:'200001′
},
total:72
}
)

db.order.ensureIndex({‘items.code’:1});

db.order.find({‘items.code’ : ‘rbk-432′});

db.order.find({created_at: {‘$gt’:last_week},create_at: {‘$lt’:today}}).sort({‘total’:-1});

db.order.update({‘user_id’:'6519′},{‘$push’:{‘items’:
{‘code’:’spk-432′,’name’:'真爱无敌’,'price’:100}
}}
);

db.order.update(
{‘user_id’:'6519′,’items.code’:'rbk-432′},
{‘$set’:{‘items.$.quantity’:2}}
);
map = ” function()
{emit(this['address']['zip'],{total:this.total})
}”

reduce =
function(key,values) {
var sum=0;
values.forEach(function(doc){
sum+=doc.total;
}

return {total:sum};
}”

db.orders.mapReduce(map,reduce,{out:’order_totals’})

{_id:…}
应该是唯一的
不变的
理想状态，不重用（删除，插入）
ObjectID类型适合分片

mongodb.org/display/docs/trees+in+mongodb

单表继续工作良好
> t.find()
{ type:’irregular-shape’, area:99 }
{ type:’circle’, area:3.14, radius:1 }
{ type:’square’, area:4, d:2 }
{ type:’rect’, area:8, x:2, y:4 }
> t.find( { radius : { $gt : 2.0 } } )
> t.ensureIndex( { radius : 1 } ) // fine
一行实际完整树
{
comments: [
{by: "mathias", text: "...",
replies: []}
{by: “eliot”, text: “…”,
replies: [
{by: "mike", text: "...", replies: []}
]}
]
}

ps:mongoDB的collection相当于关系数据库里的table，document相当于table里面的row

优点:
取一页只需一条记录
整个树都在一个磁盘上的一个位置
很容易看到整个结构

缺点:
难查询
难返回部分结果
4M的限制

父链接
> t = db.tree1;
> t.find()
{ “_id” : 1 }
{ “_id” : 2, “parent” : 1 }
{ “_id” : 3, “parent” : 1 }
{ “_id” : 4, “parent” : 2 }
{ “_id” : 5, “parent” : 4 }
{ “_id” : 6, “parent” : 4 }
> // find children of node 4
> t.ensureIndex({parent:1})
> t.find( {parent : 4 } )
{ “_id” : 5, “parent” : 4 }
{ “_id” : 6, “parent” : 4 }
// 难以得到所有层级
Array of Ancestors
> t = db.mytree;
> t.find()
{ “_id” : “a” }
{ “_id” : “b”, “ancestors” : [ "a" ], “parent” : “a” }
{ “_id” : “c”, “ancestors” : [ "a", "b" ], “parent” : “b” }
{ “_id” : “d”, “ancestors” : [ "a", "b" ], “parent” : “b” }
{ “_id” : “e”, “ancestors” : [ "a" ], “parent” : “a” }
{ “_id” : “f”, “ancestors” : [ "a", "e" ], “parent” : “e” }
{ “_id” : “g”, “ancestors” : [ "a", "b", "d" ], “parent” : “d” }
> t.ensureIndex( { ancestors : 1 } )
> // 找到b的所有子孙:
> t.find( { ancestors : ‘b’ })
{ “_id” : “c”, “ancestors” : [ "a", "b" ], “parent” : “b” }
{ “_id” : “d”, “ancestors” : [ "a", "b" ], “parent” : “b” }
{ “_id” : “g”, “ancestors” : [ "a", "b", "d" ], “parent” : “d” }
> // 得到f的所有祖先:
> anc = db.mytree.findOne({_id:’f'}).ancestors
[ "a", "e" ]
> db.mytree.find( { _id : { $in : anc } } )
{ “_id” : “a” }
{ “_id” : “e”, “ancestors” : [ "a" ], “parent” : “a” }

原子性
在行级别的原子性
$operators
比较和交换

> t=db.inventory
> s = t.findOne( {sku:’abc’} )
> –s.qty;
> t.update({_id:s._id, qty:qty_old}, s);
> db.getLastError()
{“err” : , “updatedExisting” : true , “n” : 1 , “ok” : 1} // it worked

测试：
———————————————
db.createCollection(“inventory”)
db.inventory.insert({sku:’abc’,qty:50});
t=db.inventory
s=t.findOne({sku:’abc’})
> –s.qty;
49
> –s.qty;
48

> t.update({_id:s._id},s);           
> db.inventory.find();                   
{ “_id” : ObjectId(“4c8849d89ca71035adf0c770″), “sku” : “abc”, “qty” : 48 }

———————————————-
> t=db.inventory
> s = t.findOne( {sku:’abc’} )
> –s.qty;
> t.update({_id:s._id, qty:qty_old}, s);
> db.getLastError()
{“err” : , “updatedExisting” : true , “n” : 1 , “ok” : 1} // it worked
Oops?

 t=db.inventory – Better
 s = t.findOne( {sku:’abc’} )
 obj_old = Object.extend({}, s);
 –s.qty;
 // t.update({_id:s._id, qty:qty_old}, s);
 t.update( obj_old , s);
 print( db.getLastError().ok ? “worked” : “try again” );
Compare and Swap – versions
update( { _id : myid, ver : last_ver },
{ $set : { x : “abc”, y : 99 },
$inc : { ver : 1 }
} )

测试
——————-
t.update(
{
sku : “abc”,
qty : {$gt:0}
},
{
$set : { qty : 10 }
}
,
{
$inc : { qty : -1 }
}
)

t.update(
{
sku : “abc”,
qty : {$gt:0}
},
{
$inc : { qty : -1 }
}
)
——————

Of course, don’t both doing CAS when you don’t have to
> t.update( { sku : “abc”,
qty : {$gt:0} },
{ $inc : { qty : -1 } }
)

db.getLastError()
{ “updatedExisting” : true , “n” : 1 , “ok” : 1 }
{ “updatedExisting” : false , “n” : 0 , “ok” : 1 }

> t=db.inventory
> s = t.findOne( {sku:’abc’} )
> –s.qty;
> t.update({_id:s._id, qty:qty_old}, s);
> db.getLastError()
{“err” : , “updatedExisting” : true , “n” : 1 , “ok” : 1} // it worked

> t=db.inventory
> s = t.findOne( {sku:’abc’} )
> –s.qty;
> t.update({_id:s._id, qty:qty_old}, s);
> db.getLastError()
{“err” : , “updatedExisting” : true , “n” : 1 , “ok” : 1} // it worked

Sharding and Schemas
Shard key selection
Restrictions on unique indexes
Consider using may collections when that is natural
10 SN

Other Considerations
Cappedcollections

Questions?
Get involved with the MongoDB project!
Coding, drivers, frameworks, documentation, translation, consulting, evangelism, suggestions, vote on jira…spread the word.

]]> http://www.goziwa.com/?feed=rss2&p=1050 0 关于盗梦空间的几点说明 http://www.goziwa.com/?p=1044 http://www.goziwa.com/?p=1044#comments Tue, 07 Sep 2010 16:28:19 +0000 学无涯 http://www.goziwa.com/?p=1044 晚上和她一起去正大的渝乡人家吃了饭，然后八点过几分进入电影院，没有看到开头。

1，中国什么时候有正宗的科幻电影，除了霹雳贝贝和长江七号以外？

2，中国人缺少幻想力了吗？除了西游记以外？

3，想起了二十年前中国人写的七重外壳(王晋康) ，大家有兴趣可以找来看看，可见中国人其实也不缺少幻想力，算起来还比电影多一层，也是因为这部小说，让我对电影的感觉打了不少折扣

4，中国的导演舍得用几亿拍古装片，没有勇气拍一部未来片？

5，以为是imax 3D的，原来只是imax屏幕，不是3D的，有点失望

6，音响非常好，吓到我几次

7，细节的确值得玩味，比如镜子的出现，比如三个图腾，色子，棋子，砣罗，以及国外有人指出的戒指

8，我觉得自己做过梦中梦，也是就二层的梦，但三层的肯定没有

9，有时候阶段性的有一段时间感觉自己活在梦里一样，随之又慢慢淡忘这种感觉

10，以后应该会得看，再观察一下细节

11，另，有一男配角是和莎莫的500天的男主角，这下想不火也难了

]]> http://www.goziwa.com/?feed=rss2&p=1044 1 mongodb 1.6 replica set 测试 http://www.goziwa.com/?p=1040 http://www.goziwa.com/?p=1040#comments Tue, 07 Sep 2010 02:16:59 +0000 学无涯 http://www.goziwa.com/?p=1040 在192.168.0. 10.129.128.16 10.129.128.17 上分别执行

mkdir /usr/local/mongodb/repldata

/usr/local/mongodb/bin/mongod –replSet replone –dbpath /usr/local/mongodb/repldata –port 20001 > /usr/local/mongodb/log/repl.log &

config = {_id: ‘replone’, members: [
                          {_id: 0, host: '192.168.0.:20001'},
                          {_id: 1, host: '10.129.128.16:20001'},
                          {_id: 2, host: '10.129.128.17:20001'}]
           }

rs.initiate(config);

rs.status();

db.runCommand( { addshard : “replone/192.168.0.:20001,10.129.128.16:20001,10.129.128.17:20001″ } );

db.isMaster();
# 更新配置
new_config = {_id: ‘replone’, members: [
                          {_id: 0, host: '192.168.0.:20001'},
                          {_id: 1, host: '10.129.128.16:20001'},
                          {_id: 2, host: '10.129.128.17:20001'}]
           }

use local
old_config = db.system.replset.findOne();
new_config.version = old_config.version + 1;

use admin
db.runCommand({replSetReconfig: new_config});

# 发现数据分布不太均衡
db.app.stats();
{
        “sharded” : true,
        “ns” : “test.app”,
        “count” : 13848261,
        “size” : 1107861136,
        “avgObjSize” : 80.00001848607562,
        “storageSize” : 1576738304,
        “nindexes” : 3,
        “nchunks” : 49,
        “shards” : {
                “shard0000″ : {
                        “ns” : “test.app”,
                        “count” : 2835007,
                        “size” : 226800640,
                        “avgObjSize” : 80.0000282186252,
                        “storageSize” : 338897408,
                        “numExtents” : 17,
                        “nindexes” : 3,
                        “lastExtentSize” : 63943168,
                        “paddingFactor” : 1,
                        “flags” : 1,
                        “totalIndexSize” : 601818176,
                        “indexSizes” : {
                                “_id_” : 245023680,
                                “credate_-1″ : 224239680,
                                “appid_1″ : 132554816
                        },
                        “ok” : 1
                },
                “shard0001″ : {
                        “ns” : “test.app”,
                        “count” : 2835188,
                        “size” : 226815056,
                        “avgObjSize” : 80.00000564336474,
                        “storageSize” : 334808832,
                        “numExtents” : 17,
                        “nindexes” : 3,
                        “lastExtentSize” : 62325760,
                        “paddingFactor” : 1,
                        “flags” : 1,
                        “totalIndexSize” : 590111680,
                        “indexSizes” : {
                                “_id_” : 210296832,
                                “credate_-1″ : 242885568,
                                “appid_1″ : 136929280
                        },
                        “ok” : 1
                },
                “shard0002″ : {
                        “ns” : “test.app”,
                        “count” : 3097112,
                        “size” : 247769024,
                        “avgObjSize” : 80.00002066441252,
                        “storageSize” : 409599744,
                        “numExtents” : 18,
                        “nindexes” : 3,
                        “lastExtentSize” : 74790912,
                        “paddingFactor” : 1,
                        “flags” : 1,
                        “totalIndexSize” : 630678464,
                        “indexSizes” : {
                                “_id_” : 211451904,
                                “credate_-1″ : 260400064,
                                “appid_1″ : 158826496
                        },
                        “ok” : 1
                },
                “shard0003″ : {
                        “ns” : “test.app”,
                        “count” : 4263251,
                        “size” : 341060160,
                        “avgObjSize” : 80.00001876502228,
                        “storageSize” : 409599744,
                        “numExtents” : 18,
                        “nindexes” : 3,
                        “lastExtentSize” : 74790912,
                        “paddingFactor” : 1,
                        “flags” : 1,
                        “totalIndexSize” : 733636480,
                        “indexSizes” : {
                                “_id_” : 234980288,
                                “credate_-1″ : 301417408,
                                “appid_1″ : 197238784
                        },
                        “ok” : 1
                },
                “shard0004″ : {
                        “ns” : “test.app”,
                        “count” : 817703,
                        “size” : 65416256,
                        “avgObjSize” : 80.0000195670066,
                        “storageSize” : 83832576,
                        “numExtents” : 13,
                        “nindexes” : 3,
                        “lastExtentSize” : 17845760,
                        “paddingFactor” : 1,
                        “flags” : 1,
                        “totalIndexSize” : 137977856,
                        “indexSizes” : {
                                “_id_” : 42622976,
                                “credate_-1″ : 55492608,
                                “appid_1″ : 39862272
                        },
                        “ok” : 1
                }
        },
        “ok” : 1
}
在primary上执行
> db.app.find({“appid”:39}).count();
260748

# 关闭

ps -ef|grep mongo
root     10534     1  0 Sep06 ?        00:03:22 /usr/local/mongodb/bin/mongod –replSet replone –dbpath /usr/local/mongodb/repldata –port 20001
root     29885 29226  0 09:38 pts/6    00:00:00 grep mongo
[root@localhost bin]# kill 10534

# 第一台日志
Tue Sep  7 09:38:52 got kill or ctrl c or hup signal 15 (Terminated), will terminate after current cmd ends
Tue Sep  7 09:38:52 [interruptThread] now exiting
Tue Sep  7 09:38:52  dbexit:

Tue Sep  7 09:38:52 [interruptThread]    shutdown: going to close listening sockets…
Tue Sep  7 09:38:52 [interruptThread]    going to close listening socket: 10
Tue Sep  7 09:38:52 [interruptThread]    going to close listening socket: 11
Tue Sep  7 09:38:52 [interruptThread]    going to close listening socket: 12
Tue Sep  7 09:38:52 [interruptThread]    going to close listening socket: 13
Tue Sep  7 09:38:52 [interruptThread]    shutdown: going to flush oplog…
Tue Sep  7 09:38:52 [interruptThread]    shutdown: going to close sockets…
Tue Sep  7 09:38:52 [interruptThread]    shutdown: waiting for fs preallocator…
Tue Sep  7 09:38:52 [interruptThread]    shutdown: closing all files…
Tue Sep  7 09:38:52      closeAllFiles() finished

Tue Sep  7 09:38:52 [interruptThread]    shutdown: removing fs lock…
Tue Sep  7 09:38:52 [conn2] end connection 127.0.0.1:47350
Tue Sep  7 09:38:52  dbexit: really exiting now

ERROR: Client::shutdown not called: slaveTracking
Tue Sep  7 09:38:52 [conn68] end connection 10.129.128.17:51354
Tue Sep  7 09:38:52 [conn67] end connection 10.129.128.16:46189

# 第二台日志
Tue Sep  7 09:39:05 [conn58] end connection 192.168.0.:49170
Tue Sep  7 09:39:05 [rs_sync] replSet syncThread: 10278 dbclient error communicating with server
Tue Sep  7 09:39:05 [conn9] end connection 10.129.128.13:42299
Tue Sep  7 09:39:05 [ReplSetHealthPollTask] replSet info 192.168.0.:20001 is now down (or slow to respond)
Tue Sep  7 09:39:06 [rs Manager] replSet info electSelf 1
Tue Sep  7 09:39:06 [rs Manager] replSet PRIMARY
Tue Sep  7 09:39:06 [conn60] end connection 10.129.128.13:48465
Tue Sep  7 09:39:07 [conn59] end connection 10.129.128.13:48458
Tue Sep  7 09:39:07 [initandlisten] connection accepted from 10.129.128.13:41080 #61
Tue Sep  7 09:39:08 [conn61] insert test.app 106ms
Tue Sep  7 09:39:08 [conn61] insert test.app 103ms
Tue Sep  7 09:39:08 [initandlisten] connection accepted from 10.129.128.13:41084 #62
Tue Sep  7 09:39:09 [initandlisten] connection accepted from 10.129.128.13:41088 #63
Tue Sep  7 09:39:16 [initandlisten] connection accepted from 10.129.128.17:58700 #64
Tue Sep  7 09:39:29 [conn7] end connection 10.129.128.13:42295
Tue Sep  7 09:39:42 [conn61] insert test.app 147ms
Tue Sep  7 09:39:51 [conn61] insert test.app 152ms
Tue Sep  7 09:39:59 [initandlisten] connection accepted from 10.129.128.13:41092 #65
Tue Sep  7 09:40:11 [conn64] getmore local.oplog.rs cid:3504933112664086473 getMore: { ts: { $gte: new Date(5513980079480242292) } }  bytes:1652 nreturned:12 4188ms
Tue Sep  7 09:40:16 [conn64] getmore local.oplog.rs cid:3504933112664086473 getMore: { ts: { $gte: new Date(5513980079480242292) } }  bytes:20 nreturned:0 4054ms
Tue Sep  7 09:40:19 [conn64] getmore local.oplog.rs cid:3504933112664086473 getMore: { ts: { $gte: new Date(5513980079480242292) } }  bytes:20 nreturned:0 3238ms
Tue Sep  7 09:40:23 [conn64] getmore local.oplog.rs cid:3504933112664086473 getMore: { ts: { $gte: new Date(5513980079480242292) } }  bytes:156 nreturned:1 3482ms
Tue Sep  7 09:40:28 [conn64] getmore local.oplog.rs cid:3504933112664086473 getMore: { ts: { $gte: new Date(5513980079480242292) } }  bytes:20 nreturned:0 4331ms
# 第三台日志
Tue Sep  7 09:38:41 [rs_sync] replSet syncThread: 10278 dbclient error communicating with server
Tue Sep  7 09:38:42 [conn80] end connection 192.168.0.:55860
Tue Sep  7 09:38:42 [conn11] end connection 10.129.128.13:59654
Tue Sep  7 09:38:42 [ReplSetHealthPollTask] replSet info 192.168.0.:20001 is now down (or slow to respond)
Tue Sep  7 09:38:42 [conn79] replSet info voting yea for 1
Tue Sep  7 09:38:43 [conn83] end connection 10.129.128.13:51543
Tue Sep  7 09:38:43 [rs Manager] replSet not trying to elect self as responded yea to someone else recently
Tue Sep  7 09:38:43 [conn82] end connection 10.129.128.13:51536
Tue Sep  7 09:38:43 [initandlisten] connection accepted from 10.129.128.13:53129 #84
Tue Sep  7 09:38:45 [initandlisten] connection accepted from 10.129.128.13:53133 #85
Tue Sep  7 09:38:45 [initandlisten] connection accepted from 10.129.128.13:53137 #86
Tue Sep  7 09:38:52 [rs_sync] replSet SECONDARY
Tue Sep  7 09:39:05 [conn9] end connection 10.129.128.13:59650
Tue Sep  7 09:39:35 [initandlisten] connection accepted from 10.129.128.13:53141 #87

# 第二台接管了
# 关闭第一台之前
> db.app.find({“appid”:39}).count();
Tue Sep  7 09:30:58 uncaught exception: count failed: { “errmsg” : “not master”, “ok” : 0 }

# 关闭第一台之后
> use test
switched to db test
> db.app.find({“appid”:39}).count();
263797
# 关闭第二台之后

# 第二台日志
Tue Sep  7 09:47:56 got kill or ctrl c or hup signal 15 (Terminated), will terminate after current cmd ends
Tue Sep  7 09:47:56 [interruptThread] now exiting
Tue Sep  7 09:47:56  dbexit:

Tue Sep  7 09:47:56 [interruptThread]    shutdown: going to close listening sockets…
Tue Sep  7 09:47:56 [interruptThread]    going to close listening socket: 10
Tue Sep  7 09:47:56 [interruptThread]    going to close listening socket: 11
Tue Sep  7 09:47:56 [interruptThread]    going to close listening socket: 12
Tue Sep  7 09:47:56 [interruptThread]    going to close listening socket: 13
Tue Sep  7 09:47:56 [interruptThread]    shutdown: going to flush oplog…
Tue Sep  7 09:47:56 [interruptThread]    shutdown: going to close sockets…
Tue Sep  7 09:47:56 [interruptThread]    shutdown: waiting for fs preallocator…
Tue Sep  7 09:47:56 [interruptThread]    shutdown: closing all files…
Tue Sep  7 09:47:56 [conn57] got request after shutdown()
Tue Sep  7 09:47:56 [conn3] end connection 127.0.0.1:39589
ERROR: Client::shutdown not called: slaveTracking
Tue Sep  7 09:47:57      closeAllFiles() finished

Tue Sep  7 09:47:57 [interruptThread]    shutdown: removing fs lock…
Tue Sep  7 09:47:57  dbexit: really exiting now

# 第三台日志
Tue Sep  7 09:47:32 [rs_sync] replSet syncThread: 10278 dbclient error communicating with server
Tue Sep  7 09:47:35 [conn90] end connection 10.129.128.13:35571
Tue Sep  7 09:47:37 [conn84] end connection 10.129.128.13:53129
Tue Sep  7 09:47:37 [initandlisten] connection accepted from 10.129.128.13:35575 #91
Tue Sep  7 09:47:38 [conn87] end connection 10.129.128.13:53141
Tue Sep  7 09:47:39 [conn91] end connection 10.129.128.13:35575
Tue Sep  7 09:47:39 [initandlisten] connection accepted from 10.129.128.13:35580 #92
Tue Sep  7 09:47:39 [initandlisten] connection accepted from 10.129.128.13:35585 #93
Tue Sep  7 09:47:41 [conn92] end connection 10.129.128.13:35580
Tue Sep  7 09:47:41 [initandlisten] connection accepted from 10.129.128.13:35590 #94
Tue Sep  7 09:47:42 [conn93] end connection 10.129.128.13:35585
Tue Sep  7 09:47:43 [conn94] end connection 10.129.128.13:35590
Tue Sep  7 09:47:43 [initandlisten] connection accepted from 10.129.128.13:35596 #95
Tue Sep  7 09:47:46 [conn95] end connection 10.129.128.13:35596
Tue Sep  7 09:47:46 [initandlisten] connection accepted from 10.129.128.13:35601 #96
Tue Sep  7 09:47:46 [initandlisten] connection accepted from 10.129.128.13:35606 #97
Tue Sep  7 09:47:47 [initandlisten] connection accepted from 10.129.128.13:35611 #98
Tue Sep  7 09:47:48 [conn96] end connection 10.129.128.13:35601
Tue Sep  7 09:47:48 [initandlisten] connection accepted from 10.129.128.13:35616 #99
Tue Sep  7 09:47:48 [conn97] end connection 10.129.128.13:35606
Tue Sep  7 09:47:49 [conn98] end connection 10.129.128.13:35611
Tue Sep  7 09:47:50 [conn99] end connection 10.129.128.13:35616
Tue Sep  7 09:47:50 [initandlisten] connection accepted from 10.129.128.13:35621 #100
Tue Sep  7 09:47:52 [conn100] end connection 10.129.128.13:35621
Tue Sep  7 09:47:52 [initandlisten] connection accepted from 10.129.128.13:35626 #101
Tue Sep  7 09:47:54 [conn101] end connection 10.129.128.13:35626
Tue Sep  7 09:47:54 [initandlisten] connection accepted from 10.129.128.13:35631 #102
Tue Sep  7 09:47:55 [initandlisten] connection accepted from 10.129.128.13:35636 #103
Tue Sep  7 09:47:56 [conn102] end connection 10.129.128.13:35631
Tue Sep  7 09:47:56 [initandlisten] connection accepted from 10.129.128.13:35641 #104
Tue Sep  7 09:47:57 [conn103] end connection 10.129.128.13:35636
Tue Sep  7 09:47:58 [conn104] end connection 10.129.128.13:35641
Tue Sep  7 09:47:58 [initandlisten] connection accepted from 10.129.128.13:35646 #105
Tue Sep  7 09:48:00 [conn105] end connection 10.129.128.13:35646
Tue Sep  7 09:48:00 [initandlisten] connection accepted from 10.129.128.13:35651 #106
Tue Sep  7 09:48:02 [conn106] end connection 10.129.128.13:35651
Tue Sep  7 09:48:02 [initandlisten] connection accepted from 10.129.128.13:35656 #107
Tue Sep  7 09:48:04 [initandlisten] connection accepted from 10.129.128.13:35661 #108
Tue Sep  7 09:48:04 [conn107] end connection 10.129.128.13:35656
Tue Sep  7 09:48:04 [initandlisten] connection accepted from 10.129.128.13:35666 #109
Tue Sep  7 09:48:06 [conn108] end connection 10.129.128.13:35661
Tue Sep  7 09:48:06 [conn109] end connection 10.129.128.13:35666
Tue Sep  7 09:48:06 [initandlisten] connection accepted from 10.129.128.13:35671 #110
Tue Sep  7 09:48:08 [conn110] end connection 10.129.128.13:35671
Tue Sep  7 09:48:08 [initandlisten] connection accepted from 10.129.128.13:35676 #111
Tue Sep  7 09:48:08 [initandlisten] connection accepted from 10.129.128.13:35681 #112

# 在mongos上执行
> db.app.stats();         
{
        “sharded” : true,
        “assertion” : “dbconnectionpool: connect failed replone/192.168.0.:20001,10.129.128.16:20001,10.129.128.17:20001 : connect failed to set replone/192.168.0.:20001,10.129.128.16:20001,10.129.128.17:20001″,
        “assertionCode” : 11002,
        “errmsg” : “db assertion failure”,
        “ok” : 0
}
# 查看mongos日志
Tue Sep  7 09:37:22 [conn8] trying reconnect to 192.168.0.:20001
Tue Sep  7 09:37:22 [conn8] reconnect 192.168.0.:20001 failed couldn’t connect to server 192.168.0.:20001}
Tue Sep  7 09:37:22 [conn8] MessagingPort say send() errno:9 Bad file descriptor 192.168.0.:20001
Tue Sep  7 09:37:22 [conn8] trying reconnect to 10.129.128.16:20001
Tue Sep  7 09:37:22 [conn8] reconnect 10.129.128.16:20001 failed couldn’t connect to server 10.129.128.16:20001}
Tue Sep  7 09:37:22 [conn8] MessagingPort say send() errno:9 Bad file descriptor 10.129.128.16:20001
Tue Sep  7 09:37:23 [conn8] MessagingPort say send() errno:9 Bad file descriptor 192.168.0.:20001
Tue Sep  7 09:37:23 [conn8] checkmaster: caught exception 192.168.0.:20001 socket exception
Tue Sep  7 09:37:23 [conn8] MessagingPort say send() errno:9 Bad file descriptor 10.129.128.16:20001
Tue Sep  7 09:37:23 [conn8] checkmaster: caught exception 10.129.128.16:20001 socket exception
Tue Sep  7 09:37:24 [conn8] checkmaster: 10.129.128.17:20001 { ismaster: false, secondary: true, hosts: [ "10.129.128.17:20001", "10.129.128.16:20001", "192.168.0.:20001" ], ok: 1.0 }
DBException in process: dbconnectionpool: connect failed replone/192.168.0.:20001,10.129.128.16:20001,10.129.128.17:20001 : connect failed to set replone/192.168.0.:20001,10.129.128.16:20001,10.129.128.17:20001

# 再启动第一台
Tue Sep  7 09:55:05 [initandlisten] waiting for connections on port 20001
Tue Sep  7 09:55:06 [websvr] web admin interface listening on port 21001
Tue Sep  7 09:55:06 [startReplSets] replSet can’t get local.system.replset config from self or any seed (yet)
Tue Sep  7 09:55:06 [initandlisten] connection accepted from 10.129.128.13:43597 #1
Tue Sep  7 09:55:07 [initandlisten] connection accepted from 10.129.128.13:43601 #2
Tue Sep  7 09:55:07 [initandlisten] connection accepted from 10.129.128.17:50440 #3
Tue Sep  7 09:55:07 [initandlisten] connection accepted from 10.129.128.13:43606 #4
Tue Sep  7 09:55:08 [conn1] end connection 10.129.128.13:43597
Tue Sep  7 09:55:08 [initandlisten] connection accepted from 10.129.128.13:43610 #5
Tue Sep  7 09:55:09 [conn2] end connection 10.129.128.13:43601
Tue Sep  7 09:55:09 [conn4] end connection 10.129.128.13:43606
Tue Sep  7 09:55:10 [conn5] end connection 10.129.128.13:43610
Tue Sep  7 09:55:10 [initandlisten] connection accepted from 10.129.128.13:43614 #6
Tue Sep  7 09:55:11 [initandlisten] connection accepted from 10.129.128.13:43618 #7
Tue Sep  7 09:55:12 [conn6] end connection 10.129.128.13:43614
Tue Sep  7 09:55:12 [initandlisten] connection accepted from 10.129.128.13:43622 #8
Tue Sep  7 09:55:13 [conn7] end connection 10.129.128.13:43618
Tue Sep  7 09:55:14 [conn8] end connection 10.129.128.13:43622
Tue Sep  7 09:55:14 [initandlisten] connection accepted from 10.129.128.13:43627 #9
Tue Sep  7 09:55:16 [initandlisten] connection accepted from 127.0.0.1:52018 #10
Tue Sep  7 09:55:16 [rs Manager] replSet can’t see a majority, will not try to elect self
Tue Sep  7 09:55:16 [conn9] end connection 10.129.128.13:43627
Tue Sep  7 09:55:16 [initandlisten] connection accepted from 10.129.128.13:43632 #11
Tue Sep  7 09:55:17 [conn3] replSet info voting yea for 2
Tue Sep  7 09:55:18 [ReplSetHealthPollTask] replSet info 10.129.128.17:20001 is now up
Tue Sep  7 09:55:23 [initandlisten] connection accepted from 10.129.128.13:43637 #12
Tue Sep  7 09:55:34 [rs_sync] replSet SECONDARY
Tue Sep  7 09:55:39 [initandlisten] connection accepted from 10.129.128.13:43641 #13
Tue Sep  7 09:55:39 [initandlisten] connection accepted from 10.129.128.13:43646 #14

# mongos 日志
Tue Sep  7 09:41:18 [Balancer] trying reconnect to 10.129.128.16:20001
Tue Sep  7 09:41:18 [Balancer] reconnect 10.129.128.16:20001 failed couldn’t connect to server 10.129.128.16:20001}
Tue Sep  7 09:41:18 [Balancer] MessagingPort say send() errno:9 Bad file descriptor 10.129.128.16:20001

Tue Sep  7 09:49:04 [conn8] SHARD PROBLEM** shard is too big, but can’t split: ns:test.app at: shard0000:192.168.0.:20000 lastmod: 3|1 min: { appid: 50 } max: { appid: MaxKey }
Tue Sep  7 09:41:24 [conn8] ERROR: splitIfShould failed: did you call done already
Tue Sep  7 09:41:25 [conn8] ERROR: splitIfShould failed: did you call done already
Tue Sep  7 09:41:25 [conn8] ERROR: splitIfShould failed: did you call done already
Tue Sep  7 09:41:26 [conn8] ERROR: splitIfShould failed: did you call done already
Tue Sep  7 09:41:27 [conn8] ERROR: splitIfShould failed: did you call done already

# 第三台日志
Tue Sep  7 09:59:13 [ReplSetHealthPollTask] replSet info 192.168.0.:20001 is now up
Tue Sep  7 09:59:13 [rs Manager] replSet info electSelf 2
Tue Sep  7 09:59:13 [rs Manager] replSet PRIMARY
Tue Sep  7 09:59:15 [initandlisten] connection accepted from 192.168.0.:34007 #367
Tue Sep  7 09:59:30 [conn367] getmore local.oplog.rs cid:1376686932421715188 getMore: { ts: { $gte: new Date(5513985237735964768) } }  bytes:20 nreturned:0 3864ms
Tue Sep  7 09:59:34 [conn367] getmore local.oplog.rs cid:1376686932421715188 getMore: { ts: { $gte: new Date(5513985237735964768) } }  bytes:20 nreturned:0 3331ms
Tue Sep  7 09:59:46 [conn361] insert test.app 146ms
Tue Sep  7 10:00:03 [conn367] getmore local.oplog.rs cid:1376686932421715188 getMore: { ts: { $gte: new Date(5513985237735964768) } }  bytes:17292 nreturned:127 3153ms

# 第一台日志
Tue Sep  7 09:59:17 [initandlisten] connection accepted from 10.129.128.17:52303 #16
Tue Sep  7 09:59:22 [conn16] end connection 10.129.128.17:52303
Tue Sep  7 09:59:23 [rs Manager] replSet info not electing self, we are not freshest
Tue Sep  7 09:59:24 [initandlisten] connection accepted from 10.129.128.17:52308 #17
Tue Sep  7 09:59:24 [conn17] replSet info voting yea for 2
Tue Sep  7 09:59:26 [rs_sync] replSet SECONDARY
# 在mongos上执行
db.app.stats();
{
        “sharded” : true,
        “ns” : “test.app”,
        “count” : 14283754,
        “size” : 1142700592,
        “avgObjSize” : 80.00001904261303,
        “storageSize” : 1666487296,
        “nindexes” : 3,
        “nchunks” : 49,
        “shards” : {
                “shard0000″ : {
                        “ns” : “test.app”,
                        “count” : 2929950,
                        “size” : 234396080,
                        “avgObjSize” : 80.00002730422021,
                        “storageSize” : 338897408,
                        “numExtents” : 17,
                        “nindexes” : 3,
                        “lastExtentSize” : 63943168,
                        “paddingFactor” : 1,
                        “flags” : 1,
                        “totalIndexSize” : 614302784,
                        “indexSizes” : {
                                “_id_” : 250733504,
                                “credate_-1″ : 229105728,
                                “appid_1″ : 134463552
                        },
                        “ok” : 1
                },
                “shard0001″ : {
                        “ns” : “test.app”,
                        “count” : 2931296,
                        “size” : 234503696,
                        “avgObjSize” : 80.00000545833652,
                        “storageSize” : 334808832,
                        “numExtents” : 17,
                        “nindexes” : 3,
                        “lastExtentSize” : 62325760,
                        “paddingFactor” : 1,
                        “flags” : 1,
                        “totalIndexSize” : 602178496,
                        “indexSizes” : {
                                “_id_” : 216047616,
                                “credate_-1″ : 249193408,
                                “appid_1″ : 136937472
                        },
                        “ok” : 1
                },
                “shard0002″ : {
                        “ns” : “test.app”,
                        “count” : 3201895,
                        “size” : 256151664,
                        “avgObjSize” : 80.00001998816326,
                        “storageSize” : 409599744,
                        “numExtents” : 18,
                        “nindexes” : 3,
                        “lastExtentSize” : 74790912,
                        “paddingFactor” : 1,
                        “flags” : 1,
                        “totalIndexSize” : 641024960,
                        “indexSizes” : {
                                “_id_” : 217669632,
                                “credate_-1″ : 264397760,
                                “appid_1″ : 158957568
                        },
                        “ok” : 1
                },
                “shard0003″ : {
                        “ns” : “test.app”,
                        “count” : 4368056,
                        “size” : 349444576,
                        “avgObjSize” : 80.00002197774022,
                        “storageSize” : 499348736,
                        “numExtents” : 19,
                        “nindexes” : 3,
                        “lastExtentSize” : 89748992,
                        “paddingFactor” : 1,
                        “flags” : 1,
                        “totalIndexSize” : 753092480,
                        “indexSizes” : {
                                “_id_” : 241263552,
                                “credate_-1″ : 308716480,
                                “appid_1″ : 203112448
                        },
                        “ok” : 1
                },
                “shard0004″ : {
                        “ns” : “test.app”,
                        “count” : 852557,
                        “size” : 68204576,
                        “avgObjSize” : 80.00001876707364,
                        “storageSize” : 83832576,
                        “numExtents” : 13,
                        “nindexes” : 3,
                        “lastExtentSize” : 17845760,
                        “paddingFactor” : 1,
                        “flags” : 1,
                        “totalIndexSize” : 115040256,
                        “indexSizes” : {
                                “_id_” : 44949504,
                                “credate_-1″ : 44302336,
                                “appid_1″ : 25788416
                        },
                        “ok” : 1
                }
        },
        “ok” : 1
}

第三台的数据在增长中
> db.app.count();
849280
> db.app.count();
874358
此时已经可以写入数据了，就是说如果只有一台的时候，会无法写入数据。

# 启动第二台

# 日志
Tue Sep  7 10:06:00 MongoDB starting : pid=19527 port=20001 dbpath=/usr/local/mongodb/repldata 64-bit
Tue Sep  7 10:06:00 db version v1.6.1, pdfile version 4.5
Tue Sep  7 10:06:00 git version: c5f5f9a4f3b515dfd5272d373093fd4fd58c95d9
Tue Sep  7 10:06:00 sys info: Linux domU-12-31-39-06-79-A1 2.6.21.7-2.ec2.v1.2.fc8xen #1 SMP Fri Nov 20 17:48:28 EST 2009 x86_64 BOOST_LIB_VERSION=1_41
Tue Sep  7 10:06:02 [initandlisten] waiting for connections on port 20001
Tue Sep  7 10:06:02 [websvr] web admin interface listening on port 21001
Tue Sep  7 10:06:03 [initandlisten] connection accepted from 127.0.0.1:59008 #1
Tue Sep  7 10:06:03 [rs Manager] replSet can’t see a majority, will not try to elect self
Tue Sep  7 10:06:03 [initandlisten] connection accepted from 10.129.128.17:34502 #2
Tue Sep  7 10:06:04 [initandlisten] connection accepted from 192.168.0.:56396 #3
Tue Sep  7 10:06:05 [ReplSetHealthPollTask] replSet info 10.129.128.17:20001 is now up
Tue Sep  7 10:06:05 [ReplSetHealthPollTask] replSet info 192.168.0.:20001 is now up
Tue Sep  7 10:06:06 [rs_sync] replSet SECONDARY

]]> http://www.goziwa.com/?feed=rss2&p=1040 0 [转]MySQL’s binary log结构简介 http://www.goziwa.com/?p=1036 http://www.goziwa.com/?p=1036#comments Fri, 03 Sep 2010 03:21:07 +0000 学无涯 http://www.goziwa.com/?p=1036
  • Replication:在master端开启binary log后,binary log记录所有数据库的改动,然后slave端获得这个binary log文件内容,就可以在slave端进行同样的操作,使master和sla[......]

    • binary log,是mysql中一个非常重要的部分,其主要作用有两个:

    • Replication:在master端开启binary log后,binary log记录所有数据库的改动,然后slave端获得这个binary log文件内容,就可以在slave端进行同样的操作,使master和slave保持一致.这是binary log的一个非常重要的用途.
    • 备份:在某个时间点a作了一次备份,然后利用binary log记录从这个时间点a后的所有对数据库的改动,然后下一次还原的时候,利用时间点a的备份文件和这个binary log文件,就可以将数据还原至最新时点.

    本文简单介绍binary log的结构.
    注:本文中,”binary log”是指整体,包括所有binlog文件和binlog index文件,而”binlog”,是指单独的某个二进制日志文件,”binlog index”,就是指二进制日志索引文件.

    一.开启binary log功能
    在my.cnf文件中添加:

    log-bin=master-bin
log-bin-index=master-bin.index

    log-bin是指定以后生成的各个binlog文件的前缀,在这里我们设为master-bin,因此以后生成的binlog文件将会是:

    master-bin.000001
master-bin.000002
......

    而log-bin-index则是指定binlog index文件的名称,这里我们设为master-bin.index.

    二.Binary log的结构和组织
    1.每个binlog记录的是一个个事件,是对数据库产生变动了的事件,例如一条update语句,而select语句一般不会写入binlog,因为它对数据库不产生变动.,在这里我们简称这些事件为”event”.注意不要和mysql的stored routines中的event混淆.
    2.binlog index文件只有一个,它记录的是所有binlog的文件名称,引用”MySQL High Availability”中的图来表述各个binlog文件和binlog index文件之间的关系:

    binlog_01

    再实例查看一下,在某个存放了binlog文件的目录下:

    [zhouminjun.pt@xxxx data]$ ls -l
-rw-rw---- 1 zhouminjun.pt users      973 Aug 23 17:06 mysql-bin.000001
-rw-rw---- 1 zhouminjun.pt users      106 Aug 23 17:07 mysql-bin.000002
-rw-rw---- 1 zhouminjun.pt users      324 Aug 23 17:08 mysql-bin.000003
-rw-rw---- 1 zhouminjun.pt users      598 Aug 23 21:01 mysql-bin.000004
-rw-rw---- 1 zhouminjun.pt users      149 Aug 24 08:36 mysql-bin.000005
-rw-rw---- 1 zhouminjun.pt users     3249 Aug 24 13:25 mysql-bin.000006
-rw-rw---- 1 zhouminjun.pt users      114 Aug 24 08:36 mysql-bin.index

[zhouminjun.pt@xxxx data]$ cat mysql-bin.index
./mysql-bin.000001
./mysql-bin.000002
./mysql-bin.000003
./mysql-bin.000004
./mysql-bin.000005
./mysql-bin.000006

    可以看到,binlog index文件其实就是很简单的记录当前所有binlog的文件名,每行一个.当你使用”RESET MASTER”、”FLUSH LOGS”这类命令时,binlog index文件也会相应变动.

    3.再看看binlog文件,binlog文件是二进制的,直接打开是不可阅读的.有两种方法阅读其中的内容:
    a.在客户端中使用”show binlog events”查看:

    mysql> show binlog events\G;
*************************** 1. row ***************************
   Log_name: mysql-bin.000005
        Pos: 4
 Event_type: Format_desc
  Server_id: 1
End_log_pos: 106
       Info: Server ver: 5.1.49-debug-log, Binlog ver: 4
*************************** 2. row ***************************
   Log_name: mysql-bin.000005
        Pos: 106
 Event_type: Rotate
  Server_id: 1
End_log_pos: 149
       Info: mysql-bin.000006;pos=4
2 rows in set (0.00 sec)

    可以看到，当前有两条event,下面解释下各个字段的意义:
    Log_name:这个event所在的binlog名称.这里是在mysql-bin.000005
    Pos:这个event在当前binlog中的位置
    Event_type:这个event的类型,类型是有很多,当前这个是Format_desc类型
    Server_id:这个event是在哪个server上发生的.注意在replication中,这个server id记录的是master端的server id.
    End_log_pos:下一个event的位置.因此当前这个event的长度是End_log_pos-Pos.
    Info:直观的可读的关于本条event的信息.

    在刚才查看binlog的时候,里面有两条event,第一条类型是Format_desc,第二条是Rotate:

    Format_desc:这是每一个binlog文件的头,是每一个binlog文件必有的第一个event,在这个event中,记录了一些诸如binary log格式版本,产生这个event的mysql server版本等等.

    Rotate:一般来说,这是每个binlog文件的结束event.有如下情况(我在5.1.49-debug-log上已测):
    1.当你使用”flush logs”命令时,mysql会自动在当前正在使用的binlog文件末尾加上这个rotate事件,然后就不再使用这个binlog了,同时会创建一个新的binlog文件,然后自动在新创建的这个binlog中加上一个Format_desc event,并且更新binlog index(将这个新创建的binlog文件名添加进入).
    2.每次重启mysqld(通过mysqladmin关闭,再手动重启)的时候,mysql也会关闭当前binlog,并且写入一个Stop event(注意不是rotate event),然后再启动的时候会按照上面一样,创建新的binlog文件并作相关工作.
    3.通过kill命令直接杀死掉mysql,这个时候发生没有任何event写入.

    其他还有很多event类型，最常见的可能就是Query了，update、delete等操作都是Query类型.通常一个update操作在binlog文件中会产生好几个event,因为为了保证主从一致,需要确保很多外部因素的一致.
    在这里我们引入一个分组的概念:除了format_desc和rotate,其他的event我们往往可以对其进行分组,对于事务型数据库来说，往往认为一个事务就是一个分组，对于非事务型数据库和类似create、alter这类语句来说,一条语句本身就是一个分组.
    那么通常,一个分区内的语句要么全都执行,要么全都不执行,在replication中,如果slave在执行一个分组内的某条语句时,mysql突然中断了,那么mysql会重新从头开始这个分组,而非从中断点继续.这就能很好的保证了事务的原则.

    这里有一点要说明的是,用show binlog events命令查看的永远是binlog index文件中的第一个binlog文件内容,一般来说是master-bin.000001文件,要查看其他binlog文件需要使用:

    show binlog events in 'mysql-bin.000003';

    查看mysql目前正在写哪个binlog文件可以先执行”show master status\G;”查看.

    b.使用mysql自带的工具mysqlbinlog,比如对于一个经历了正常启动,再正常关闭(mysqladmin shutdown)的binlog来说,用mysqlbinlog查看:

    [zhouminjun.pt@xxxxx data]$ mysqlbinlog mysql-bin.000007
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#100825 19:19:30 server id 1  end_log_pos 106   Start: binlog v 4, server v 5.1.49-debug-log created 100825 19:19:30 at startup
ROLLBACK/*!*/;
BINLOG '
Qvx0TA8BAAAAZgAAAGoAAAAAAAQANS4xLjQ5LWRlYnVnLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABC/HRMEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC
'/*!*/;
# at 106
#100825 19:20:12 server id 1  end_log_pos 125   Stop
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

    用mysqlbinlog查看binlog可能比乱一点.但是能查看到更多的内容.
    每个event都是以类似下面两行开始:

    # at 267
#100825 11:57:57 server id 1  end_log_pos 335   Query   thread_id=99    exec_time=0     error_code=0
    第一行的267代表这个event的起始位的位置.

    第二行的100825 11:57:57代表这个event开始执行的时间(对于replication来说,无论在master的binlog中还是slave的relay-log中,值是相同的,都是指在master端开始执行的时间),100825是指10年8月25.
    接着是master的server id.
    end_log_pos指的是下一个event的起始位置,注意这个值如果是在replication中的relay-log中,那这个值是直接从master处搬过来的,因此对于relay-log来说有可能是不准的.
    thread_id就是执行这个event的线程id.
    exec_time对于master端的binlog来说是执行这个event所花费的时间,对slave端的relay-log来说,这个值是slave端执行这个event结束的时间减去master端开始执行这个event的时间,因此在一些情况下，我们还能根据这个值大概分析出slave落后于master的时间.

    原文:http://saw-unix.com/2010/08/mysqls-binary-log_details.html

    ]]> http://www.goziwa.com/?feed=rss2&p=1036 1 [转]浅谈数据库系统中的cache http://www.goziwa.com/?p=1033 http://www.goziwa.com/?p=1033#comments Fri, 03 Sep 2010 01:13:56 +0000 学无涯 http://www.goziwa.com/?p=1033 Cache和Buffer是两个不同的概念，简单的说，Cache是加速“读”，而buffer是缓冲“写”，前者解决读的问题，保存从磁盘上读出的数据，后者是解决写的问题，保存即将要写入到磁盘上的数据。在很多情况下，这两个名词并没有严格区分，常常把读写混合类型称为buffer cache，本文后续的论述中，统一称为cache。

    Oracle中的log buffer是解决redo写入的问题，而data buffer cache则解决data block的读写问题。对于Oracle来说，如果IO没有在SGA中命中，都会发生物理IO，Oracle并不关心底层存储的类型，可能是一套存储系统，可能是本地磁盘，可能是RAID 10，也可能是RAID 5，可能是文件系统，也可能是裸设备，或是ASM。总之，Oracle把底层的存储系统称为存储子系统。

    在存储系统中，cache几乎无处不在（在后面的论述中，我们统称为cache），文件系统有cache，存储有cache，RAID控制器上有cache，磁盘上也有cache。为了提高性能，Oracle的一个写操作，很有可能写在存储的cache上就返回了，如果这时存储系统发生问题，Oracle如何来保证数据一致性的问题。

    Oracle数据库最重要的特性是：Write ahead logging，在data block在写入前，必须保证首先写入redo log，在事务commit时，同时必须保证redo log被写入。Oracle为了保证数据的一致性，对于redo log采用了direct IO，Direct IO会跳过了OS上文件系统的cache这一层。但是，OS管不了存储这一层，虽然跳过了文件系统的cache，但是依然可能写在存储的cache上。

    一般的存储都有cache，为了提高性能，写操作在cache上完成就返回给OS了，我们称这种写操作为write back，为了保证掉电时cache中的内容不会丢失，存储都有电池保护，这些电池可以供存储在掉电后工作一定时间，保证cache中的数据被刷入磁盘，不会丢失。不同于UPS，电池能够支撑的时间很短，一般都在30分钟以内，只要保证cache中的数据被写入就可以了。存储可以关闭写cache，这时所有的写操作必须写入到磁盘才返回，我们称这种写操作为write throuogh，当存储发现某些部件不正常时，存储会自动关闭写cache，这时写性能会下降。

    RAID卡上也有cache，一般是256M，同样是通过电池来保护的，不同于存储的是，这个电池并不保证数据可以被写入到磁盘上，而是为cache供电以保护数据不丢失，一般可以支撑几天的时间。还有些RAID卡上有flash cache，掉电后可以将cache中的内容写入到flash cache中，保证数据不丢失。如果你的数据库没有存储，而是放在普通PC机的本地硬盘之上的，一定要确认主机中的RAID卡是否有电池，很多硬件提供商默认是不配置电池的。当然，RAID卡上的cache同样可以选择关闭。

    磁盘上的cache，一般是16M-64M，很多存储厂商都明确表示，存储中磁盘的cache是禁用的，这也是可以理解的，为了保证数据可靠性，而存储本身又提供了非常大的cache，相比较而言，磁盘上的cache就不再那么重要。SCSI指令中有一个FUA(Force Unit Access)的参数，设置这个参数时，写操作必须在磁盘上完成才可以返回，相当于禁用了磁盘的写cache。虽然没有查证到资料，但是我个人认为一旦磁盘被接入到RAID控制器中，写cache就会被禁用，这也是为了数据可靠性的考虑，我相信存储厂商应该会考虑这个问题。

    至此，我们可以看到Oracle的一个物理IO是经历了一系列的cache之后，最终被写入到磁盘上。cache虽然可以提高性能，但是也要考虑掉电保护的问题。关于数据的一致性，是由Oracle数据库，操作系统和存储子系统共同来保证的。

    原文:http://www.hellodba.net/2010/08/db-storage.html

    ]]> http://www.goziwa.com/?feed=rss2&p=1033 0     mysql 复制出错解决方法 http://www.goziwa.com/?p=1029 http://www.goziwa.com/?p=1029#comments Thu, 02 Sep 2010 08:23:11 +0000 学无涯 http://www.goziwa.com/?p=1029 中午正准备去吃饭,收到大量报警,10.xx.xx.xx- MySQL Replication [slave_lag] is still below threshold of 0 with -1

    麻烦了,复制中断了,赶紧回办公室,连上服务器

    show slave status

    显示

    *************************** 1. row ***************************
                   Slave_IO_State: Waiting for master to send event
                      Master_Host: 10.xx.xx.xx
                      Master_User: repl
                      Master_Port: 3306
                    Connect_Retry: 60
                  Master_Log_File: 100025.000377
              Read_Master_Log_Pos: 261910
                   Relay_Log_File: 100026-relay-bin.001279
                    Relay_Log_Pos: 243970
            Relay_Master_Log_File: 100025.000377
                 Slave_IO_Running: Yes
                Slave_SQL_Running: No
                  Replicate_Do_DB:
              Replicate_Ignore_DB:
               Replicate_Do_Table:
           Replicate_Ignore_Table:
          Replicate_Wild_Do_Table:
      Replicate_Wild_Ignore_Table:
                       Last_Errno: 1062
                       Last_Error: Error ‘Duplicate entry ‘31bc63deb64211dfbfb1002655d7deb0-’ for key ‘PRIMARY” on

    query. Default database: ‘test’. Query: ‘INSE
    RT INTO d_twitter.t_twitter_user (user_id,content,mood,release_time,type,tags,source_desc,ip,attachment,mood_id)

    values (”,’添加了照片印象  \”在\” http://t.
    sdo.com/photo/index.php?r=album/view/uid/1183155325/id/661/image/5649′,’0′,’2010-09-02

    11:24:47′,’2′,”,”,’1034744164′,’a:3:{s:5:\”title\”;s:25:\”5649-11831
    55325-8_260.jpg\”;s:12:\”original_url\”;s:64:\”http://photo.staticsdo.com/a1/36/92/49/5649-1183155325-

    8_260.jpg\”;s:12:\”contract_url\”;s:64:\”http://photo.s
    taticsdo.com/a1/36/92/49/5649-1183155325-8_260.jpg\”;}’,'31bc63deb64211dfbfb1002655d7deb0′)’
                     Skip_Counter: 0
              Exec_Master_Log_Pos: 243828
                  Relay_Log_Space: 262404
                  Until_Condition: None
                   Until_Log_File:
                    Until_Log_Pos: 0
               Master_SSL_Allowed: No
               Master_SSL_CA_File:
               Master_SSL_CA_Path:
                  Master_SSL_Cert:
                Master_SSL_Cipher:
                   Master_SSL_Key:
            Seconds_Behind_Master: NULL
    Master_SSL_Verify_Server_Cert: No
                    Last_IO_Errno: 0
                    Last_IO_Error:
                   Last_SQL_Errno: 1062
                   Last_SQL_Error: Error ‘Duplicate entry ‘31bc63deb64211dfbfb1002655d7deb0-’ for key ‘PRIMARY” on

    query. Default database: ‘test’. Query: ‘INSE
    RT INTO d_twitter.t_twitter_user (user_id,content,mood,release_time,type,tags,source_desc,ip,attachment,mood_id)

    values (”,’添加了照片印象  \”在\” http://t.
    sdo.com/photo/index.php?r=album/view/uid/1183155325/id/661/image/5649′,’0′,’2010-09-02

    11:24:47′,’2′,”,”,’1034744164′,’a:3:{s:5:\”title\”;s:25:\”5649-11831
    55325-8_260.jpg\”;s:12:\”original_url\”;s:64:\”http://photo.staticsdo.com/a1/36/92/49/5649-1183155325-

    8_260.jpg\”;s:12:\”contract_url\”;s:64:\”http://photo.s
    taticsdo.com/a1/36/92/49/5649-1183155325-8_260.jpg\”;}’,'31bc63deb64211dfbfb1002655d7deb0′)’

    同时收到错误日志报警

    100902 11:28:46 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with “SLAVE START”. We stopped at log ‘100001.000389′ position 437802

    使用命令SHOW BINLOG EVENTS in ‘100001.000389′ from 437802\G;

    可以看到中断点之后的events,明显的有若干语句的 user_id为”值,说明程序有异常,和开发人员联系后,确认程序有问题,已经修正了.

    现在就是需要跳过这些错误,恢复复制.

    如果错误是连续的,其实可以用

    STOP SLAVE;

    SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 15;

    START SLAVE;

    这样的语句,跳过所有的出错语句,但一般来说错误都是不连续的,就是中间夹杂着正确的语句,在语句比较少的情况下,可以

    STOP SLAVE;

    SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

    START SLAVE;

    一行行跳过

    如果出错的语句比较多,最好修改my.cnf,加入

    slave-skip-errors =1062,1032

    或

    slave-skip-errors =all

    不过修改后,需要重启服务,不能动态修改,这是比较不好的地方

    当然还有一种方法就是,如果使用了中间代理层比如amoeba,可以将原来的读写分离的两台机器,都改为读写其中一台机器,以避免复制中断造成的读写不同步.

    ]]> http://www.goziwa.com/?feed=rss2&p=1029 0     MongoDB 1.6 auto sharding 测试 http://www.goziwa.com/?p=1015 http://www.goziwa.com/?p=1015#comments Wed, 01 Sep 2010 09:45:10 +0000 学无涯 http://www.goziwa.com/?p=1015 1.6版终于发布了,据说sharding可以用于生产环境了,那就让我们来测试一下吧
    MongoDB 1.6 is a drop-in replacement for 1.4. To upgrade, simply shutdown mongod then restart with the new binaries.
    Sharding
    Sharding is now production-ready, making MongoDB horizontally scalable, with no single point of failure. A single instance of mongod can now be upgraded to a distributed cluster with zero downtime when the need arises.

    Sharding Tutorial
    Sharding Documentation
    Upgrading a Single Server to a Cluster
    Replica Sets
    Replica sets, which provide automated failover among a cluster of n nodes, are also now available.

    Plese note that replica pairs are now deprecated; we strongly recommend that replica pair users upgrade to replica sets.

    Replica Set Tutorial
    Replica Set Documentation
    Upgrading Existing Setups to Replica Sets
    Other Improvements
    The w option (and wtimeout) forces writes to be propagated to n servers before returning success (this works especially well with replica sets)
    $or queries
    Improved concurrency
    $slice operator for returning subsets of arrays
    64 indexes per collection (formerly 40 indexes per collection)
    64-bit integers can now be represented in the shell using NumberLong
    The findAndModify command now supports upserts. It also allows you to specify fields to return
    $showDiskLoc option to see disk location of a document
    Support for IPv6 and UNIX domain sockets
     

    第零步：安装
    cd /root/upload

    curl http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-1.6.1.tgz > mongo.tgz

    tar xzf mongo.tgz

    mv mongodb-linux-x86_64-1.6.1 /usr/local/mongodb

    ————————————————————

    3db:192.168.0.15 192.168.0.16 192.168.0.17
    1config:192.168.0.14
    1mongos:192.168.0.13

    第一步：在三台db服务器分别启动mongod进程 First, start up a couple _mongod_s to be your shards.

    mkdir /usr/local/mongodb/data
    mkdir /usr/local/mongodb/log

    /usr/local/mongodb/bin/mongod –shardsvr –dbpath /usr/local/mongodb/data –port 20000 > /usr/local/mongodb/log/shard.log &

    cat /usr/local/mongodb/log/shard.log
    第二步：在一台config服务器启动mongod进程 Now you need a configuration server and mongos:
    mkdir /usr/local/mongodb/config
    mkdir /usr/local/mongodb/log

    /usr/local/mongodb/bin/mongod –configsvr –dbpath /usr/local/mongodb/config –port 20000 > /usr/local/mongodb/log/configdb.log &

    cat /usr/local/mongodb/log/configdb.log

    第三步：启动mongos进程，为方便测试，块大小设置为1M，不要在生产环境中这样设置
    mkdir /usr/local/mongodb/log

    /usr/local/mongodb/bin/mongos –configdb 192.168.0.14:20000 –chunkSize 1 > /usr/local/mongodb/log/mongos.log &

    cat /usr/local/mongodb/log/mongos.log

    第四步：建立集群 Setting up the Cluster
    # We need to run a few commands on the shell to hook everything up. Start the shell, connecting to the mongos process (at localhost:27017 if you followed the

    steps above).
    # To set up our cluster, we’ll add the two shards (a and b).

    /usr/local/mongodb/bin/mongo

    use admin

    # 添加服务器
    db.runCommand( { addshard : “192.168.0.15:20000″ } )
    { “shardadded” : “shard0000″, “ok” : 1 }

    db.runCommand( { addshard : “192.168.0.16:20000″ } )
    { “shardadded” : “shard0001″, “ok” : 1 }

    db.runCommand( { addshard : “192.168.0.17:20000″ } )
    { “shardadded” : “shard0001″, “ok” : 1 }

    # 设置database和collection的分区键 Now you need to tell the database that you want to spread out your data at a database and collection level. You have to

    give the collection a key (or keys) to partition by.This is similar to creating an index on a collection.

    db.runCommand( { enablesharding : “test” } )
    {“ok” : 1}

    db.runCommand( { shardcollection : “test.app”, key : {appid : 1} } )
    {“ok” : 1}
    第五步：查看信息Administration To see what’s going on in the cluster, use the config database.

    use config

    show collections

    # 查看
    db.printShardingStatus();

    db.runCommand({listshards:1})

    # 查看数据分布
    db.app.stats();

    第六步：安装php驱动
    sudo pecl install mongo

    第七步：运行php脚本
    vi test.php

    <?php

    //连接localhost:27017
    $conn = new Mongo();

    //选择数据库test
    $db = $conn->test;

    //选择结果集
    $collection = $db->app;

    for($i=1;$i<10000000;$i++){

    $data1 = mktime(0,0,0,1,1,1950);
    $data2 = mktime(0,0,0,1,1,2000);
    $rand_time = rand($data1,$data2);
    $credate=date(“Y-m-d H:i:s”,$rand_time);

    $userid= rand(100000000,900000000);

    $appid= rand(1,50);
    //新增
    $new = array(‘appid’ => $appid, ‘userid’ => $userid, ‘credate’ => $credate);
    $collection->insert($new);
    }

    ?>

    php test.php

    发现在初期,分布不均匀,第一台DB上有100多万条,而第2,3台上各有30万条,20万条。

    从db.printShardingStatus()也可以看出来，以下是几个时间的对比:

    然后在500Ｗ数据以后，config server挂了，查看日志：

    Wed Sep  1 17:17:43 got kill or ctrl c or hup signal 1 (Hangup), will terminate after current cmd ends
    Wed Sep  1 17:17:43 [interruptThread] now exiting
    Wed Sep  1 17:17:43  dbexit:

    Wed Sep  1 17:17:43 [interruptThread]    shutdown: going to close listening sockets…
    Wed Sep  1 17:17:43 [interruptThread]    going to close listening socket: 6
    Wed Sep  1 17:17:43 [interruptThread]    going to close listening socket: 7
    Wed Sep  1 17:17:43 [interruptThread]    going to close listening socket: 8
    Wed Sep  1 17:17:43 [interruptThread]    going to close listening socket: 9
    Wed Sep  1 17:17:43 [interruptThread]    shutdown: going to flush oplog…
    Wed Sep  1 17:17:43  flushing op log and files

    Wed Sep  1 17:17:43 [interruptThread]    shutdown: going to close sockets…
    Wed Sep  1 17:17:43 [interruptThread]    shutdown: waiting for fs preallocator…
    Wed Sep  1 17:17:43 [interruptThread]    shutdown: closing all files…
    Wed Sep  1 17:17:43      closeAllFiles() finished

    Wed Sep  1 17:17:43 [interruptThread]    shutdown: removing fs lock…
    Wed Sep  1 17:17:43  dbexit: really exiting now

    增加一台服务器测试

    mkdir /usr/local/mongodb/data

    /usr/local/mongodb/bin/mongod –shardsvr –dbpath /usr/local/mongodb/data –port 20001 > /usr/local/mongodb/log/shard.log &

    /usr/local/mongodb/bin/mongo

    use admin

    db.runCommand( { addshard : “10.129.128.13:20001″ } )

    一段时间后看发现数据已经变为

     test.app chunks:
                            { “appid” : { $minKey : 1 } } –>> { “appid” : 1 } on : shard0003 { “t” : 34000, “i” : 0 }
                            { “appid” : 1 } –>> { “appid” : 3 } on : shard0003 { “t” : 31000, “i” : 0 }
                            { “appid” : 3 } –>> { “appid” : 4 } on : shard0003 { “t” : 33000, “i” : 0 }
                            { “appid” : 4 } –>> { “appid” : 5 } on : shard0003 { “t” : 36000, “i” : 0 }
                            { “appid” : 5 } –>> { “appid” : 6 } on : shard0003 { “t” : 39000, “i” : 0 }
                            { “appid” : 6 } –>> { “appid” : 7 } on : shard0003 { “t” : 37000, “i” : 0 }
                            { “appid” : 7 } –>> { “appid” : 8 } on : shard0003 { “t” : 40000, “i” : 0 }
                            { “appid” : 8 } –>> { “appid” : 9 } on : shard0002 { “t” : 6000, “i” : 0 }
                            { “appid” : 9 } –>> { “appid” : 10 } on : shard0002 { “t” : 7000, “i” : 0 }
                            { “appid” : 10 } –>> { “appid” : 11 } on : shard0003 { “t” : 42000, “i” : 0 }
                            { “appid” : 11 } –>> { “appid” : 12 } on : shard0002 { “t” : 9000, “i” : 0 }
                            { “appid” : 12 } –>> { “appid” : 13 } on : shard0001 { “t” : 10000, “i” : 0 }
                            { “appid” : 13 } –>> { “appid” : 14 } on : shard0002 { “t” : 11000, “i” : 0 }
                            { “appid” : 14 } –>> { “appid” : 15 } on : shard0001 { “t” : 12000, “i” : 0 }
                            { “appid” : 15 } –>> { “appid” : 16 } on : shard0002 { “t” : 13000, “i” : 0 }
                            { “appid” : 16 } –>> { “appid” : 17 } on : shard0001 { “t” : 14000, “i” : 0 }
                            { “appid” : 17 } –>> { “appid” : 18 } on : shard0002 { “t” : 15000, “i” : 0 }
                            { “appid” : 18 } –>> { “appid” : 19 } on : shard0001 { “t” : 16000, “i” : 0 }
                            { “appid” : 19 } –>> { “appid” : 20 } on : shard0002 { “t” : 17000, “i” : 0 }
                            { “appid” : 20 } –>> { “appid” : 21 } on : shard0001 { “t” : 18000, “i” : 0 }
                            { “appid” : 21 } –>> { “appid” : 22 } on : shard0002 { “t” : 19000, “i” : 0 }
                            { “appid” : 22 } –>> { “appid” : 23 } on : shard0001 { “t” : 20000, “i” : 0 }
                            { “appid” : 23 } –>> { “appid” : 25 } on : shard0002 { “t” : 21000, “i” : 0 }
                            { “appid” : 25 } –>> { “appid” : 26 } on : shard0001 { “t” : 22000, “i” : 0 }
                            { “appid” : 26 } –>> { “appid” : 27 } on : shard0002 { “t” : 23000, “i” : 0 }
                            { “appid” : 27 } –>> { “appid” : 28 } on : shard0001 { “t” : 24000, “i” : 0 }
                            { “appid” : 28 } –>> { “appid” : 29 } on : shard0002 { “t” : 25000, “i” : 0 }
                            { “appid” : 29 } –>> { “appid” : 30 } on : shard0001 { “t” : 26000, “i” : 0 }
                            { “appid” : 30 } –>> { “appid” : 31 } on : shard0002 { “t” : 27000, “i” : 0 }
                            { “appid” : 31 } –>> { “appid” : 32 } on : shard0001 { “t” : 30000, “i” : 2 }
                            { “appid” : 32 } –>> { “appid” : 33 } on : shard0001 { “t” : 42000, “i” : 1 }
                            { “appid” : 33 } –>> { “appid” : 34 } on : shard0001 { “t” : 29000, “i” : 0 }
                            { “appid” : 34 } –>> { “appid” : 35 } on : shard0002 { “t” : 40000, “i” : 1 }
                            { “appid” : 35 } –>> { “appid” : 36 } on : shard0003 { “t” : 32000, “i” : 0 }
                            { “appid” : 36 } –>> { “appid” : 37 } on : shard0003 { “t” : 35000, “i” : 0 }
                            { “appid” : 37 } –>> { “appid” : 38 } on : shard0003 { “t” : 38000, “i” : 0 }
                            { “appid” : 38 } –>> { “appid” : 39 } on : shard0003 { “t” : 41000, “i” : 0 }
                            { “appid” : 39 } –>> { “appid” : 40 } on : shard0000 { “t” : 3000, “i” : 181 }
                            { “appid” : 40 } –>> { “appid” : 41 } on : shard0000 { “t” : 3000, “i” : 182 }
                            { “appid” : 41 } –>> { “appid” : 42 } on : shard0000 { “t” : 5000, “i” : 12 }
                            { “appid” : 42 } –>> { “appid” : 43 } on : shard0000 { “t” : 6000, “i” : 1 }
                            { “appid” : 43 } –>> { “appid” : 44 } on : shard0000 { “t” : 3000, “i” : 184 }
                            { “appid” : 44 } –>> { “appid” : 45 } on : shard0000 { “t” : 6000, “i” : 2 }
                            { “appid” : 45 } –>> { “appid” : 46 } on : shard0000 { “t” : 41000, “i” : 1 }
                            { “appid” : 46 } –>> { “appid” : 47 } on : shard0000 { “t” : 4000, “i” : 108 }
                            { “appid” : 47 } –>> { “appid” : 48 } on : shard0000 { “t” : 4000, “i” : 109 }
                            { “appid” : 48 } –>> { “appid” : 49 } on : shard0000 { “t” : 4000, “i” : 110 }
                            { “appid” : 49 } –>> { “appid” : 50 } on : shard0000 { “t” : 5000, “i” : 1 }
                            { “appid” : 50 } –>> { “appid” : { $maxKey : 1 } } on : shard0000 { “t” : 3000, “i” : 1 }
                    test.people chunks:
                            { “name” : { $minKey : 1 } } –>> { “name” : { $maxKey : 1 } } on : shard0000 { “t” : 1000, “i” : 0 }

    数据已经进行了重新分布

    现在的问题是,重新分布的触发条件是什么,大规模重新分布比如加入新的服务器会不会对线上业务产生影响?

    ]]> http://www.goziwa.com/?feed=rss2&p=1015 0