假设我们有一套数据量庞大的前台系统需要从MySQL上转到Hbase上，比较粗糙的数据同步方法有：
1、将整个前台系统变为只读
2、全量dump MySQL数据
3、将MySQL数据导入到Hbase上
4、将前台系统切换到Hbase上，并打开更新
该方案比较简单，易于维持数据一致性，但是缺点是影响了所有用户的写入，并且时间过长。
用户体验看起来比较友好的数据同步方法有：
1、全量dump某个时间点之前的数据，并记录期间的增量日志A
2、apply日志A内的数据，并记录期间的增量日志B
3、apply日志B内的数据，并记录期间的增量日志C
4、不断重复第3步，直到日志C足够小
5、将整个前台系统变为只读，apply日志C内的数据
6、将前台系统切换到Hbase上，并打开更新
该方案实现比较复杂，迭代日志的做法看起来没完没了，而且容易引起少部分用户数据不一致。但是只读的时间非常短，大部分用户都能在数据同步期间自由使用应用。
Read more…
在MongoDB 1.6.4的使用过程中，我们发现当文件系统cache用尽的时候MongoDB的写入性能会有非常大的波动。更为致命的是，偶尔还会发生持续20-30秒的写入阻塞。虽然MongoDB的设计非常先进，但是稳定性一直是我们头痛的一个问题。带着疑问我们参加了Mongo北京开发者聚会，会上10gen的工程师Alvin Richards建议测试一下MongoDB 1.8，据说在写锁上有所改进。
回到杭州后，我们在Redhat 6.0上重做了MongoDB 1.6.4和1.8.0-rc0的对比测试。测试的结果如下图所示：
这两张图的横坐标是时间轴（每个点代表10秒钟），纵坐标是插入速度（代表10秒内的平均速度）。
测试逻辑如下：
1、在zyy库下建立一个名为test的collection
2、在test的k字段上建立索引
3、开启测试程序并打点。该测试程序将开启10个线程对test进行并发写入。k由uuid调用生成，长度为37字节；v长度为1k。
从测试结果上看，MongoDB 1.8.0相对于1.6.4在写入性能上有所改进。首先，1.6.4除了预分配文件造成性能下降外，写入性能偶尔还会长时间降到0。而1.8.0基本没有出现写入性能降到0的情况，性能的最低点在于预分配文件。其次，从性能的稳定性上看，1.8.0的波动显然没有1.6.4那么夸张。在InnoDB做的类似测试也会出现类似波动，但是性能最低点不会降到MongoDB那么低。
总体而言，MongoDB 1.8.0-rc从功能和性能上都有所改进。期待release版本和新的存储引擎中。
具体测试代码见此：
http://pastie.org/1645946
之前介绍了MySQL如何避免使用swap的四个方法。这里需要补充一下原理和实现机制，对于Linux api不感兴趣的同学可以直接跳过。
一、操作系统设置swap的目的
程序运行的一个必要条件就是足够的内存，而内存往往是系统里面比较紧张的一种资源。为了满足更多程序的要求，操作系统虚拟了一部分内存地址，并将之映射到swap上。对于程序来说，它只知道操作系统给自己分配了内存地址，但并不清楚这些内存地址到底映射到物理内存还是swap。
物理内存和swap在功能上是一样的，只是因为物理存储元件的不同（内存和磁盘），性能上有很大的差别。操作系统会根据程序使用内存的特点进行换入和换出，尽可能地把物理内存留给最需要它的程序。但是这种调度是按照预先设定的某种规则的，并不能完全符合程序的需要。一些特殊的程序（比如MySQL）希望自己的数据永远寄存在物理内存里，以便提供更高的性能。于是操作系统就设置了几个api，以便为调用者提供“特殊服务”。
二、Linux提供的几个api
1、mlockall()和munlockall()
这一对函数，可以让调用者的地址空间常驻物理内存，也可以在需要的时候将此特权取消。mlockall()的flag位可以是MCL_CURRENT和MCL_FUTURE的任意组合，分别代表了“保持已分配的地址空间常驻物理内存”和“保持未来分配的地址空间常驻物理内存”。对于Linux来说，这对函数是非常霸道的，只有root用户才有权限调用。
2、shmget()和shmat()
这一对函数，可以向操作系统申请使用大页内存（Large Page）。大页内存的特点是预分配和永驻物理内存，因为使用了共享内存段的方式，page table有可能会比传统的小页分配方式更小。对于多进程共享内存的程序（比如ORACLE），大页内存能够节省很多page table开销；而对于MySQL来说，性能和资源开销都没有显著变化，好处就在于减少了内存地址被映射到swap上的可能。至于为什么是减少，而不是完全避免，之后再讲解。
Read more…
Linux有很多很好的内存、IO调度机制，但是并不会适用于所有场景。对于DBA来说Linux比较让人头疼的一个地方是，它不会因为MySQL很重要就避免将分配给MySQL的地址空间映射到swap上。对于频繁进行读写操作的系统而言，数据看似在内存而实际上在磁盘是非常糟糕的，响应时间的增长很可能直接拖垮整个系统。这篇blog主要讲讲我们作为DBA，怎样尽量避免MySQL惨遭swap的毒手。
Read more…
Recent Comments