LinuxEye - Linux系统教程

LinuxEye - Linux系统教程

当前位置: 主页 > Linux教程 >

greenplum维护过程中的一些经验谈

时间:2013-06-15 11:52来源:blog.osdba.net 编辑:admin 点击:
1. 如果能用greenplum3.3.X,就不要使用greenplum4.X。 原因: a. greenplum4.x看起当primary节点出现问题时,可以切换到mirror节点,继续提供服务,当mirror节点恢复后,可以做增量同步。增量同步
1. 如果能用greenplum3.3.X,就不要使用greenplum4.X。
原因: a. greenplum4.x看起当primary节点出现问题时,可以切换到mirror节点,继续提供服务,当mirror节点恢复后,可以做增量同步。增量同步是一个大的亮点。
但实际上,greenplum4.x大量的的bug导致的的不稳定完全抵消了这个优点。当机器内存紧张时,mirror经常与主库不同步。而每次不同步后要做停库恢复,当数据库比较大的时候(如50T以上时),每次同步的时候经常需要2个小时以上。
同时greenplum4.x的primary节点与mirror节点是通过物理块同步的。如果因为软件bug把主库搞挂了,那么即使切换
到备库上,备库也一样起不来。而greenplum3.3.x是通过逻辑同步的,也就是把DML和DDL同时发到primary和mirror执行,这样即使软件有bug导致primary起不来,切换到mirror还是可以起来的。

2. 当GP4.X 由于如内存耗尽等原因hang了之后,停数据库时,最好不好直接使用gpstop -af命令直接停整个数据库,按下面的步骤将安全很多:
a. 每一步,先停master: gpstop -amf,或gpstop -am -M immediate
b. 再启动master: gpstart -am
c. 最后再gpstop -af
这个操作的核心是先把master给停掉。在greenplum异常hang住后,如果按标准的gpstop -af,很可能出现数据不一致,数据库无法启动的问题,这可能是greenplum的bug,我就遇到几次这样的问题,停库后,数据库无法启动,报一些xlog错误的问题,让EMC的专家上来也无法把数据库搞起来,还好我们在文件系统上有快照,最后把文件系统闪回到2个小时前的快照上,数据库才正常打开。后来使用这个操作步骤,这个问题就再也没有也现过。

3. 关于GP的分区表
a. GP宣称支持无限级分区,但实际上使用中,最好只用一级分区。另对小表最好就不要做分区了。GP本身就是在机器间做了数据水平拆分了,所以使用一级分区后,单个表的大小就不会很大。在greenplum和PostgreSQL中,分区实际上并不是真正的分区,而是通过表继承来实现的。每个分区实际上是一个单独的表,而每个表都是一个单独的文件,当访问这个表时,即使只访问其中一个分区,但在生成执行计划过程,greenplum会这个分区表所有分区的文件,还会地每个分区表做pg_relation_size()操作,这样就会变得很慢。
b. 如果是一张包括几百个分区的分区表,如果业务逻辑可以直接查询分区表,那么直接查询分区表吧,这样会快很多,原因同上。
   例表:mytable,分区键为mydate,下面的SQL
   select * from mytable where mydate='2012-03-08'
   换成:
   select * from mytable_1_prt_p20120308;
   则性能会更好。
c. 尽量不要有空分区,原因同上。

4. 关于GP的统计信息
由于greenplum执行SQL的方法是先在master上把执行计划生成好,
然后再发到底下的各个segment节点上执行,所以一般情况下统计信息只在master上有用,而在segment没有太大用处。
GP是由下面的两个参数为控制统计信息的收集的
gp_autostats_mode
gp_autostats_on_change_threshold
gp_autostats_mode参数可以取的值有三个:
none
on_change
on_no_stats
当设置为“none”为禁止收集统计信息,而设置为"on change"时,当一条DML执行后影响的行数超过gp_autostats_on_change_threshold参数
指定的值时,会执行完这条DML后再自动执行一个analyze 的操作来收集表的统计信息。
当设置为“no_no_stats“时,执行完DML语句后,发现这张表没有统计信息,会自动执行analyze 来收集这张表的统计信息。
greenplum4.x的analyze的执行方法与greenplum3.x的方法是完全不一样的。
greenplum3.x的方法是把analyze 语句直接发到各个segment上。
而greenplum4.x的analyze实际上是在master上直接执行很多个收集统计信息的SQL来收集统计信息的。
从实际的使用中看,greenplum3.x的方法的性能好,而greenplum4.x的性能比较差。原因是greenplum4.x在master上发SQL,
这些SQL由于有group,所以会发数据重分析,即使数据很小,重分布总是会需要更长的时间,而greenplum3.X是把analyze语句直接发到segment上,
没有重分布,因而性能要好很多。
所以对于greenplum4.x上,如果你有大量的运行时间在1分钟以下的SQL,你会发现大量的时间消耗在收集统计信息上。
为了降低这一部分的消耗,你可以需要在建表时就明确把一些不需要收集统计信息的更去除掉,如下所示:
create table test(id int, name text,note text);
上面是已知道表列note不需出现在join列上,也不会出现在where语句的过滤条件下,因为可以把这个列设置为不收集统计信息:

alter table test alter note SET STATISTICS 0;

由此可见greenplum4.X收集统计信息的方法也是一个看上下很美感,实际上很差的方法,

转载请保留固定链接: http://www.linuxeye.com/Linux/1759.html

------分隔线----------------------------
标签:greenplum
栏目列表
推荐内容