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

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

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

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

• btrfs文件系统
• 淘宝图片存储与CDN系统[转]
• 开源的淘宝
• 武汉校园招聘归来
• 淘宝网2010年校园招聘启航
• MySQL还能走多远?

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

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

在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)

• Cassandra运维之道 v0.2
• Cassandra运维之道
• Cassandra之Token
• Cassandra Commitlog
• Cassandra存储机制
• MySQL命令行的几个用法(续二)

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

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

最近一位同事在美国参加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

• 厦门outing
• 淘宝图片存储与CDN系统[转]
• 开源的淘宝
• linux上大量tcp端口处于TIME_WAIT的问题
• MySQL还能走多远?
• MSN上的闲聊

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

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

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

• Cassandra运维之道
• Cassandra之Token
• Cassandra Commitlog
• Cassandra存储机制
• Cassandra 0.7 值得期待
• NoSQL，关系数据库终结者？

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

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

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

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

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

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

• 安昌古镇与乔波冰雪世界
• 2010，风生水起
• 往事不会随风-记我的2009
• 签证是个体力活
• 拥抱变化
• 日全食

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

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

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

• 开源的淘宝
• 厦门outing
• btrfs文件系统
• 武汉校园招聘归来
• 淘宝网2010年校园招聘启航
• 淘宝2009校园招聘

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

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

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

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

Tair总体架构图(refer):

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

谨以此帖，猛顶淘蝌蚪。

• 淘宝图片存储与CDN系统[转]
• 厦门outing
• btrfs文件系统
• 武汉校园招聘归来
• 淘宝网2010年校园招聘启航
• 淘宝2009校园招聘

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

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

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

• Perl自定义模块的路径包含问题
• 编写Perl模块
• 如何在AIX中编译Perl
• 如何让Perl脚本同时只运行一个实例
• 使用Perl发送邮件
• 在Crontab中调度Perl程序的环境变量问题

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

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

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

• Cassandra运维之道 v0.2
• Cassandra之Token
• Cassandra Commitlog
• Cassandra存储机制
• Cassandra 0.7 值得期待
• NoSQL，关系数据库终结者？

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

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

有一个多月没有更新过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

• Cassandra运维之道 v0.2
• Cassandra运维之道
• Cassandra Commitlog
• Cassandra存储机制
• Cassandra 0.7 值得期待
• NoSQL，关系数据库终结者？

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

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

在数据库技术大会上，做了《构建高可用数据库监控系统》的分享以后，很多朋友对北斗如何实现表的DML次数监控有兴趣，会上因为时间的原因，我只是说有系统视图可以查到这个信息，因此有了本文，可以稍微详细一点来说明是如何实现的。

我说的系统视图，具体指的是dba_tab_modifications/all_tab_modifications/user_tab_modifications，这几个视图收集了表自从上一次分析之后的DML累积次数。但是要注意，考虑到性能的影响，Oracle并不是实时统计这个数据的，在Oracle9i之前，约3个小时SMON进程会刷新一次数据，而Oracle9i以后这个时间间隔变成了15分钟。

因此以较高的频率来实时监控这个表的话，得到的并不是当前的准确数据。Oracle在dbms_stat包中提供了一个过程来手动刷新统计数据，假如在一天的业务低峰期采集一次数据的话，可以先执行该过程，就能得到较为准确的数据。但是，不建议在业务高峰期执行该过程。

exec DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO;

在Oracle10g之前，必须手工开启表的monitoring属性，才会将DML统计信息收集到这个视图中。可以通过dba_tables.monitoring列查看表是否已经开启了监控。关于这个变化，可以参考Metalink ID 252597.1

alter table test monitoring;

Oracle10g之后，只要statistics_level是TYPICAL（默认）或者ALL，就能自动收集信息了，即使给表设置为nomonitoring也不能阻止，这个表的属性已经被废弃了。

desc dba_tab_modifications
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 TABLE_OWNER                                        VARCHAR2(30)
 TABLE_NAME                                         VARCHAR2(30)
 PARTITION_NAME                                     VARCHAR2(30)
 SUBPARTITION_NAME                                  VARCHAR2(30)
 INSERTS                                            NUMBER
 UPDATES                                            NUMBER
 DELETES                                            NUMBER
 TIMESTAMP                                          DATE
 TRUNCATED                                          VARCHAR2(3)
 DROP_SEGMENTS                                      NUMBER

• tbstat:实时监控数据库统计状态的小工具
• 使用Oracle正则表达式监控应用到数据库的连接情况
• 遭遇Oracle11gR2 ASM文件无法扩展的Bug
• 数据库技术大会PPT：构建高可用数据库监控系统
• dstat:一款简单直观的os实时监控工具
• 使用jpgraph绘制数据库监控图形

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

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

在一个11gR2+ASM的环境中，因为产生了大量归档，导致控制文件需要扩展，结果数据库报错：

Errors in file /opt/oracle/diag/rdbms/test/test/trace/test_arc0_11146.trc:
ORA-00202: control file: '+DATA/control01.ctl'
ORA-17505: ksfdrsz:1 Failed to resize file to size 1920 blocks
ORA-15061: ASM operation not supported [41]
Control file expansion from 1600 blocks to 1920 blocks denied by OS

这是ASM的一个bug 8898852，可以在Oracle Support上找到对应的小patch，经过验证可以解决该问题。该patch已经包含在前两天刚发布的ASM的PSU中，只需要安装该PSU即可。

从目前我们使用11gR2的一些经验来看，bug还是比较多，尤其是一些影响比较大的bug，还是让人对11gR2无法完全放心，只能在特定的环境，和有足够容错方案的环境中，才能冒着风险来试用。

除了这个ASM文件不能扩展，有几个从10.2.0.4升级到11.2.0.1的库，在switchover中碰到了两次ORA-600 [ktbdchk1: bad dscn]，出现问题后无法执行DML，非常严重的一个问题，并且暂时还没有好的办法解决，只能通过重建有问题的表的方式绕过，因为两次都是在切换后出现，初步推断是Active Data Guard带来的bug，开了SR和Oracle扯了很久，还在继续研究中。

据说Oracle 11.2.0.2将在年中发布，希望这个新的版本能更稳定些吧。

4月份，Oracle11.2.0.1的PSU和ASM(Grid Infrastructure)的第一个PSU都已经发布了，如果需要在产品环境中使用，建议这些PSU都打上吧

注：该表格摘自My Oracle Support Note: 854428.1l

• 遭遇Oracle11g第一个bug
• Oracle 11gR2 for Linux正式发布
• rebuild index online的锁机制浅析(续)
• Oracle12G将不再支持裸设备？
• ASM如何识别磁盘
• Oracle数据库如何识别ASM磁盘组

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

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

最近发现几个监控用的脚本在连接监控数据库的时候偶尔会连不上，报错：

 Couldn't connect to host:3306/tcp: IO::Socket::INET: connect: Cannot assign requested address

查看了一下发现系统中存在大量处于TIME_WAIT状态的tcp端口

$netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 50013
ESTABLISHED 27
SYN_RECV 1

由于要监控的主机太多，监控的agent可能在短时间内创建大量连接到监控数据库(MySQL)并释放造成的。在网上查阅了一些tcp参数的相关资料，最后通过修改了几个系统内核的tcp参数缓解了该问题：

#vi /etc/sysctl.conf

net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

#sysctl -p

其中：
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

修改完成并生效后，系统中处于TIME_WAIT状态的tcp端口数量迅速下降到100左右：

$netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 82
ESTABLISHED 36

简单记录于此，备忘。

• btrfs文件系统
• 在64位Linux上安装MemCached
• Linux中如何让进程在后台运行
• Linux中如何将文件dump成16进制值
• Redhat Linux如何设置用户默认属性
• Oracle10.2.0.4 Linux64版本监听存在多个子进程

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

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

这两天在北京参加IT168组织的2010数据库技术大会，应该说这次大会非常的成功，场场爆满。见到了很多老朋友，认识了更多的新朋友，不亦乐乎。

今天下午第一场，我分享了一个关于数据库监控系统的topic，开场时话筒出现了些小插曲，加上发现PPT不是我后来提交给大会的最新版本，当时就有点发懵，汗就开始往外冒了。看来以后要多多练习提高演讲的水平和临场的应变控制能力了。希望我结巴的话语不至于让大家感到门票白买了。就数据库监控这个话题本身而言，我相信大部分DBA应该都是有兴趣，并且也是有自己的一些心得的，因此，我带来这个主题，一个重要的目的，是希望能起到抛砖引玉的作用，希望能有更多的DBA能去关注这方面，并且一起交流分享如何把数据库监控做到极致。如果有对数据库监控感兴趣，有想法的朋友，也非常的欢迎来杭州，和我们一起来把这个产品做得更好，或许真有一天能做成产品开源出来也是可能的。

下面是新版本的PPT，和大会上大家看到的可能有一点区别，大家如果对数据库监控有什么建议，欢迎指教。

• Oracle如何监控表的DML次数
• dstat:一款简单直观的os实时监控工具
• tbstat:实时监控数据库统计状态的小工具
• 使用jpgraph绘制数据库监控图形
• 使用Oracle正则表达式监控应用到数据库的连接情况
• 如何监控MemCached的状态

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

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

上一篇blog中，大致介绍了一下Cassandra的存储机制，通过将最新的写操作放在内存中的Memtable，然后定期刷新到磁盘持久化为SSTable，Cassandra将随机写操作转换成了顺序写操作，这可以提升IO性能。

最新写入的脏数据是在内存Memtable表中，因此必须有机制来确保异常情况下，能够将内存中的数据恢复出来。和关系型数据库系统一样，Cassandra也是采用的先写日志再写数据的方式，其日志称之为Commitlog。

和Memtable/SSTable不一样的是，Commitlog是server级别的，不是Column Family级别的。每个Commitlog文件的大小是固定的，称之为一个Commitlog Segment，目前版本(0.5.1)中，这个大小是128MB，这是硬编码在代码(src\java\org\apache\cassandra\db\Commitlog.java)中的。当一个Commitlog文件写满以后，会新建一个的文件。当旧的Commitlog文件不再需要时，会自动清除。

每个Commitlog文件(Segment)都有一个固定大小（大小根据Column Family的数目而定）的CommitlogHeader结构，其中有两个重要的数组，每一个Column Family在这两个数组中都存在一个对应的元素。其中一个是位图数组(BitSet dirty)，如果Column Family对应的Memtable中有脏数据，则置为1，否则为0，这在恢复的时候可以指出哪些Column Family是需要利用Commitlog进行恢复的。另外一个是整数数组(int[] lastFlushedAt)，保存的是Column Family在上一次Flush时日志的偏移位置，恢复时则可以从这个位置读取Commitlog记录。通过这两个数组结构，Cassandra可以在异常重启服务的时候根据持久化的SSTable和Commitlog重构内存中Memtable的内容，也就是类似Oracle等关系型数据库的实例恢复。

当Memtable flush到磁盘的SStable时，会将所有Commitlog文件的dirty数组对应的位清零，而在Commitlog达到大小限制创建新的文件时，dirty数组会从上一个文件中继承过来。如果一个Commitlog文件的dirty数组全部被清零，则表示这个Commitlog在恢复的时候不再需要，可以被清除。因此，在恢复的时候，所有的磁盘上存在的Commitlog文件都是需要的。

参考文章：
[1].http://wiki.apache.org/cassandra/ArchitectureCommitLog

• Cassandra运维之道 v0.2
• Cassandra运维之道
• Cassandra之Token
• Cassandra存储机制
• Cassandra 0.7 值得期待
• NoSQL，关系数据库终结者？

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

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

在2009年兴起的NoSQL运动中，Cassandra是其中重要的一个分布式key-value数据库产品，由Facebook在2008年开源，目前是Apache的顶级项目。最近twitter的一篇声明，表示将从MySQL迁移到Cassandra，更让其声名大振。Cassandra是结合了Google Bigtable的数据模型和Amazon Dynamo高可用框架的一个产品。其数据模型可以参考张瑞的blog。

值得说一下的是Cassandra的存储机制，也是借鉴了Bigtable的设计，采用Memtable和SSTable的方式。和关系数据库一样，Cassandra在写数据之前，也需要先记录日志，称之为commitlog，然后数据才会写入到Column Family对应的Memtable中，并且Memtable中的内容是按照key排序好的。Memtable是一种内存结构，满足一定条件后批量刷新到磁盘上，存储为SSTable。这种机制，相当于缓存写回机制(Write-back Cache)，优势在于将随机IO写变成顺序IO写，降低大量的写操作对于存储系统的压力。SSTable一旦完成写入，就不可变更，只能读取。下一次Memtable需要刷新到一个新的SSTable文件中。所以对于Cassandra来说，可以认为只有顺序写，没有随机写操作。

因为SSTable数据不可更新，可能导致同一个Column Family的数据存储在多个SSTable中，这时查询数据时，需要去合并读取Column Family所有的SSTable和Memtable，这样到一个Column Family的数量很大的时候，可能导致查询效率严重下降。因此需要有一种机制能快速定位查询的Key落在哪些SSTable中，而不需要去读取合并所有的SSTable。Cassandra采用的是Bloom Filter算法，通过多个hash函数将key映射到一个位图中，来快速判断这个key属于哪个SSTable。关于Bloom Filter，有兴趣的可以去看看参考文章4,5和6。

为了避免大量SSTable带来的性能影响，Cassandra也提供一种定期将多个SSTable合并成一个新的SSTable的机制，因为每个SSTable中的key都是已经排序好的，因此只需要做一次合并排序就可以完成该任务，代价还是可以接受的。所以在Cassandra的数据存储目录中，可以看到三种类型的文件，格式类似于：

• Column Family Name-序号-Data.db
• Column Family Name-序号-Filter.db
• Column Family Name-序号-index.db

其中Data.db文件是SSTable数据文件，SSTable是Sorted Strings Table的缩写，按照key排序后存储key/value键值字符串。index.db是索引文件，保存的是每个key在数据文件中的偏移位置，而Filter.db则是Bloom Filter算法生产的映射文件。

参考文章：
[1].http://wiki.apache.org/cassandra/ArchitectureOverview
[2].http://wiki.apache.org/cassandra/MemtableSSTable
[3].http://wiki.apache.org/cassandra/ArchitectureSSTable
[4].http://blog.csdn.net/jiaomeng/archive/2007/01/27/1495500.aspx
[5].http://www.hellodba.net/2009/04/bloom_filter.html
[6].http://www.googlechinablog.com/2007/07/bloom-filter.html
[7].http://labs.google.com/papers/bigtable.html

• Cassandra运维之道 v0.2
• Cassandra运维之道
• Cassandra之Token
• Cassandra Commitlog
• Cassandra 0.7 值得期待
• CAP原理与最终一致性

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

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

CAP原理(CAP Theorem)

在足球比赛里，一个球员在一场比赛中进三个球，称之为帽子戏法(Hat-trick)。在分布式数据系统中，也有一个帽子原理(CAP Theorem)，不过此帽子非彼帽子。CAP原理中，有三个要素：

• 一致性(Consistency)
• 可用性(Availability)
• 分区容忍性(Partition tolerance)

CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。

当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。

最终一致性(eventually consistent)

对于一致性，可以分为从客户端和服务端两个不同的视角。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

最终一致性根据更新数据后各进程访问到数据的时间和方式的不同，又可以区分为：

• 因果一致性。如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。
• “读己之所写（read-your-writes）”一致性。当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。
• 会话（Session）一致性。这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统的保证不会延续到新的会话。
• 单调（Monotonic）读一致性。如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。
• 单调写一致性。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。

上述最终一致性的不同方式可以进行组合，例如单调读一致性和读己之所写一致性就可以组合实现。并且从实践的角度来看，这两者的组合，读取自己更新的数据，和一旦读取到最新的版本不会再读取旧版本，对于此架构上的程序开发来说，会少很多额外的烦恼。

从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。对于分布式数据系统：

• N — 数据复制的份数
• W — 更新数据是需要保证写完成的节点数
• R — 读取数据的时候需要读取的节点数

如果W+R>N，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库，N=2,W=2,R=1，则不管读的是主库还是备库的数据，都是一致的。

如果W+R<=N，则是弱一致性。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。

对于分布式系统，为了保证高可用性，一般设置N>=3。不同的N,W,R组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。

• 如果N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性。
• 如果N=R,W=1，只需要一个节点写入成功即可，写性能和可用性都比较高。但是读取其他节点的进程可能不能获取更新后的数据，因此是弱一致性。这种情况下，如果W<(N+1)/2，并且写入的节点不重叠的话，则会存在写冲突

参考文章：
[1].http://devblog.streamy.com/2009/08/24/cap-theorem/
[2].http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
[3].http://www.allthingsdistributed.com/2008/12/eventually_consistent.html
[4].http://www.infoq.com/cn/news/2008/01/consistency-vs-availability

• Cassandra存储机制
• 用Amoeba构架MySQL分布式数据库环境
• 遭遇Oracle11gR2 ASM文件无法扩展的Bug
• 使用zlib输出gzip格式的文件
• 流年不利，万事小心
• 结束就是开始，两年一个轮回

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

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

在oschina上闲逛，发现一款不错的os实时监控工具dstat，整合了vmstat, iostat, ifstat, netstat等常见os监控工具的优点，输出的结果简单直观，并且结果可以保存到csv文件，这样再写一个简单的perl脚本，就能将os的主要监控信息一次性全部抓取出来，保存到监控数据库中用于分析展示。试用了一下觉得非常不错，因此在这里分享一下这个用python写的工具。

$dstat
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
  2   0  98   0   0   0|  80k   54k|   0     0 | 335B  381B|1297  1301
 22   2  74   0   0   2|   0   416k| 621k  219k|   0     0 |1158    26k
 23   3  72   0   0   2|  64k  484k|  11k   11k|   0     0 |1109    30k
 21   3  75   0   0   2|4096B  416k|  77k   77k|   0     0 |2104    25k
 29   4  66   0   0   2|   0  1240k| 996k  425k|   0     0 |1350    28k

$dstat -ta --output osstat.csv
-----time----- ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
  date/time   |usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
05-02 11:37:08|  2   0  98   0   0   0|  80k   54k|   0     0 | 335B  381B|1297  1301
05-02 11:37:09| 16   4  78   0   0   3|   0  1404k|1478k  939k|   0     0 |4316    33k
05-02 11:37:10| 20   2  76   0   0   2|   0  1144k|1109k  828k|   0     0 |5653    28k
05-02 11:37:11| 13   2  83   0   0   2|   0   588k|2590k 1684k|   0     0 |4256    23k

$dstat -h
Usage: dstat [-afv] [options..] [delay [count]]
Versatile tool for generating system resource statistics

Dstat options:
  -c, --cpu              enable cpu stats
     -C 0,3,total           include cpu0, cpu3 and total
  -d, --disk             enable disk stats
     -D total,hda           include hda and total
  -g, --page             enable page stats
  -i, --int              enable interrupt stats
     -I 5,eth2              include int5 and interrupt used by eth2
  -l, --load             enable load stats
  -m, --mem              enable memory stats
  -n, --net              enable network stats
     -N eth1,total          include eth1 and total
  -p, --proc             enable process stats
  -s, --swap             enable swap stats
     -S swap1,total         include swap1 and total
  -t, --time             enable time/date output
  -T, --epoch            enable time counter (seconds since epoch)
  -y, --sys              enable system stats
  --ipc                  enable ipc stats
  --lock                 enable lock stats
  --raw                  enable raw stats
  --tcp                  enable tcp stats
  --udp                  enable udp stats
  --unix                 enable unix stats

  -M stat1,stat2         enable external stats
     --mods stat1,stat2

  -a, --all              equals -cdngy (default)
  -f, --full             expand -C, -D, -I, -N and -S discovery lists
  -v, --vmstat           equals -pmgdsc -D total

  --integer              show integer values
  --nocolor              disable colors (implies --noupdate)
  --noheaders            disable repetitive headers
  --noupdate             disable intermediate updates
  --output file          write CSV output to file

  delay is the delay in seconds between each update
  count is the number of updates to display before exiting
  The default delay is 1 and count is unspecified (unlimited)

• Oracle如何监控表的DML次数
• 数据库技术大会PPT：构建高可用数据库监控系统
• tbstat:实时监控数据库统计状态的小工具
• 使用jpgraph绘制数据库监控图形
• 使用Oracle正则表达式监控应用到数据库的连接情况
• 如何监控MemCached的状态

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

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

PostgreSQL也支持逻辑备库和物理备份两种方式。物理备份可以和Oracle一样实现联机热备份，并且同样也需要将数据库设置为归档模式。

逻辑备份

PostgreSQL提供了pg_dump/pg_dumpall两个程序可以用来将数据dump成文本文件，实现数据的逻辑备份。使用不同的参数，可以将数据dump成PostgreSQL专用的数据格式(生成copy语句)或者标准SQL语句(生成insert语句)格式。恢复只需要简单的使用psql将文件执行一遍即可。另外也可以使用pg_restore工具来恢复数据。

利用pg_dump备份test数据库(只有一张test表)，包括重建表的DDL语句，授权语句等所有信息，生成copy格式的文件：

$ ./pg_dump test
--
-- PostgreSQL database dump
--
SET statement_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET escape_string_warning = off;
SET search_path = public, pg_catalog;
SET default_tablespace = '';
SET default_with_oids = false;
--
-- Name: test; Type: TABLE; Schema: public; Owner: postgres; Tablespace:
--
CREATE TABLE test (
    i integer
);
ALTER TABLE public.test OWNER TO postgres;
--
-- Data for Name: test; Type: TABLE DATA; Schema: public; Owner: postgres
--
COPY test (i) FROM stdin;
1
2
\.
--
-- Name: public; Type: ACL; Schema: -; Owner: postgres
--
REVOKE ALL ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON SCHEMA public FROM postgres;
GRANT ALL ON SCHEMA public TO postgres;
GRANT ALL ON SCHEMA public TO PUBLIC;
--
-- PostgreSQL database dump complete
--

利用pg_dump备份test库，只保存数据，insert语句格式：

[postgres@dbconsole bin]$ ./pg_dump --inserts -a test
--
-- PostgreSQL database dump
--
SET statement_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET escape_string_warning = off;
SET search_path = public, pg_catalog;
--
-- Data for Name: test; Type: TABLE DATA; Schema: public; Owner: postgres
--
INSERT INTO test VALUES (1);
INSERT INTO test VALUES (2);
--
-- PostgreSQL database dump complete
--

物理备份

和Oracle一样，物理备份可以分为冷备份和热备份。冷备份就是将数据库实例关闭，然后直接复制data目录的所有文件，恢复时只需要将文件copy到data目录，无须利用日志(WAL–Write-Ahead Logging）进行恢复。而热备份，则需要利用日志将数据库恢复到一致状态，因此需要先将数据库置于归档模式。

PostgreSQL归档模式使用参数archive_mode控制，这是一个静态参数，修改postgresql.conf文件，加入如下参数，然后重启生效：

archive_mode = on
archive_command = 'cp "%p" /u01/postgresql/arch/"%f"'
archive_timeout = 600

postgres=# show archive_mode;
 archive_mode
--------------
 on
(1 row)

由于postgresql没有归档进程，因此归档是通过外部命令(OS)完成的，archive_command用于指定该外部命令，具体格式请参考文档。如果是linux归档到本地，使用cp即可，如果是到远程，则可以使用scp或者rsync。archive_timeout强制N秒以后进行一次归档，这个和Oracle的archive_lag_target参数的作用一样。当然也可以手工进行日志切换：

postgres=# select pg_switch_xlog();
 pg_switch_xlog
----------------
 0/7000000
(1 row)

热备份前，需要先将数据库置于备份状态，这一点和Oracle的手工也备份也是一样的。该命令会导致一次checkpoint，可能在业务高峰期会带来一些压力和风险，因此备份还是需要安排在业务低谷期间执行比较稳妥。

postgres=# select pg_start_backup('test_backup');
 pg_start_backup
-----------------
 0/8000020
(1 row)

然后在os层面将data目录进行复制备份。完成后，再取消备份状态，该命令同时会执行一次日志切换，并进行归档，以保证热备份期间的日志都已经归档，保证恢复数据库到一致状态的所有日志都能从归档中找到：

postgres=# select pg_stop_backup();
 pg_stop_backup
----------------
 0/8000088
(1 row)

备份完成后，可以在归档目录找到一个记录了本次备份信息的文件：

$ more 000000010000000000000008.00000020.backup
START WAL LOCATION: 0/8000020 (file 000000010000000000000008)
STOP WAL LOCATION: 0/8000088 (file 000000010000000000000008)
CHECKPOINT LOCATION: 0/8000020
START TIME: 2010-02-03 12:24:57 CST
LABEL: test_backup
STOP TIME: 2010-02-03 12:24:59 CST

PostgreSQL官方并没有提供和Oracle的rman一样的备份工具，不过因为PostgreSQL是开源的数据库，因此也有一个开源的工具pg_rman可以使用，从命令行来看功能已经非常强大，暂时还没有测试，有兴趣的可以研究一下。

pg_rman [ OPTIONS ] { init | backup | restore | show [ DATE | timeline ] |
 validate [ DATE ] | delete DATE }

• PostgreSQL安装
• PostgreSQL简介
• Redhat Linux网卡配置与绑定
• Oracle 9i和10g在create index和rebuild index的统计信息的区别
• Cognos Planning安装完成
• Oracle10g：如何以DBA身份登陆iSQL*Plus

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

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

PostgreSQL8.x版本的安装已经非常的简单了。EnterpriseDB制作了一键安装的版本，包括FreeBSD/Linux/Mac OS X/Solaris/Windows平台都有。不过即使使用源码编译，也非常的简单。各个版本的源码可以点这里下载。

创建os用户

#useradd -g dba postgres
#su - postgres

编译

$tar -zxvf postgresql-8.4.2.tar.gz
$cd postgresql-8.4.2
$./configure --prefix=/OPT/postgresql --enable-profiling
--with-blocksize=8 --with-wal-blocksize=8
$make && make install

其中with-blocksize指定数据块大小，默认8k，with-wal-blocksize指定日志块大小，默认也是8k。更多编译配置选项，可以通过./configure –help查看。

初始化database，注意PostgreSQL在服务端不支持GBK编码。

$cd /opt/postgresql/bin
$ ./initdb --encoding=utf8 -D /opt/postgresql/data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale en_US.UTF-8.
The default text search configuration will be set to "english".

creating directory /opt/postgresql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 32MB
creating configuration files ... ok
creating template1 database in /opt/postgresql/data/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating conversions ... ok
creating dictionaries ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the -A option the
next time you run initdb.

Success. You can now start the database server using:

    ./postgres -D /opt/postgresql/data
or
    ./pg_ctl -D /opt/postgresql/data -l logfile start

初始化完成后，会在 /opt/postgresql/data目录生成数据库的文件，至此，软件安装完毕，数据库创建完毕。

启动数据库

./pg_ctl -D /opt/postgresql/data/ -l /opt/postgresql/log/alert.log start

启动后，可以发现PostgreSQL实例一共运行了5个进程

$ ps -ef | grep postgres
postgres 17572     1  0 16:41 pts/2    00:00:00 /opt/postgresql/bin/postgres
-D /opt/postgresql/data
postgres 17574 17572  0 16:41 ?        00:00:00 postgres: writer process
postgres 17575 17572  0 16:41 ?        00:00:00 postgres: wal writer process
postgres 17576 17572  0 16:41 ?        00:00:00 postgres: autovacuum launcher process
postgres 17577 17572  0 16:41 ?        00:00:00 postgres: stats collector process
postgres 18679 20791  0 16:47 pts/2    00:00:00 grep postgres

其中wal writer process是日志写进程。

• PostgreSQL备份
• PostgreSQL简介
• Yupoo新版及纪念墙计划
• Perl的English模块
• OOW2009美国行:大会第二天
• 说说10g rman的catalog命令

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

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