Greenplum高可用及实测

高可用方案

1.1 master高可用

master镜像是通过把primary master对应的standby master放置到不同的物理主机实现的。正常情况下只有primary master接受用户连接请求,standby master通过gpsyncagent进程(运行在standby master上)利用事务日志保持与primary master的同步。由于master上不存放任何用户数据,存放在其中的表不会频繁更新,因此同步是实时的。standby master所在主机除了复制进程外,没有正式master服务运行。当primary出现故障,standby master日志复制进程停止,可以手动激活standby master,使它切换成primary master。需要在primary与standby之上再加一层负载均衡或者VIP,应用在master切换后才可以不修改连接配置继续访问数据库。

1.2 segment高可用

segment级别的镜像是通过把primary segment对应的mirror segment放置到不同的物理主机实现的。正常情况下,只有primary segment的instance处于工作状态,所有primary segment上的变化通过文件块的复制技术拷贝到mirror segment。因此,存放mirror segment的主机上只有复制用的进程,而不存在mirror segment instance。一旦primary segment出现故障,mirror segment的复制进程停止,并启动instance,保证数据库的操作继续。

segment的故障检测是通过后台进程ftsprobe实现的,并可以进行自动容错,不需要DBA进行干预。ftsprobe的检测间隔是通过global服务参数gp_fts_probe_interval进行定义的,默认值是1分钟,通常这个参数的设置应该与参数gp_segment_connect_timeout保持一致。一旦ftsprobe进程发现primary segment出现故障,它会在数据字典中标记该segment已经停止。只有管理员对其进行恢复后,才会改变状态。

如果系统没有进行segment级别的镜像,当出现segment故障后,整个系统都将脱机,直到恢复故障segment后,才可以重新启动。

高可用搭建及测试

2.1 master高可用搭建

2.1.1 创建standby

1、在master上执行:

gpinitstandby -s lzk-8 -P 2345

2、并在终端中设置standby的数据目录:

Enter standby filespace location for filespace pg_system (default: NA):

> /data0/master_standby/gpseg-1

如出现如下提示,则表示创建成功

gpinitstandby:lzk-8:greenplum-[INFO]:-Successfully created standby master on lzk-8

2.1.2 手动切换

  1. 单独停止master

在master上执行:

gpstop -m

  • 启动standby

在standby上执行

gpactivatestandby -d $MASTER_DATA_DIRECTORY

2.1.3 master崩溃测试

  1. 模拟master崩溃

在master上

kill -9 所有master进程

此时活跃的客户端连接被断开,segments上正在执行的进程并不会停止,继续执行。standby不会自动进行切换,无法连接GPDB服务。

  • 启动standby

在standby上执行:

gpactivatestandby -d $MASTER_DATA_DIRECTORY

启动后,可以在新的端口及IP上接受新的连接。segments上遗留的进程执行完后不会进行提交,而是回滚。

2.1.4 测试结论

  1. 在master崩溃时尚未提交的所有事物都会失败。
  2. Greenplum本身并不会监控master的健康状态及异常恢复。所以集群恢复服务时间取决于发现异常后手动启动standby的时间。

2.2 segment高可用搭建

2.2.1 创建mirrors

1、在master上执行

gpaddmirrors -o mirror_config

会生成一个参考的配置文件,可自行修改

$ cat mirror_config

filespaceOrder=

mirror0=0:lzk-8:56000:57000:58000:/data0/mirror/gpseg0

mirror1=1:lzk-8:56001:57001:58001:/data0/mirror/gpseg1

2、创建mirror,执行:

gpaddmirrors -i mirror_config

如出现如下提示,则表示创建成功:

gpssd-[INFO]:-Mirror segments have been added; data synchronization is in progress.

gpssd-[INFO]:-Data synchronization will continue in the background.

gpssd-[INFO]:-

gpssd-[INFO]:-Use  gpstate -s  to check the resynchronization progress.

可以使用gpstate -s查看同步进度

2.2.2 segment崩溃测试

  1. 模拟segment崩溃

在一个segment上

kill -9 所有segment进程

此时正在执行的sql语句会报错失败,但是连接正常,可以继续使用。同时其他正常segment上正在执行的进程也会退出。异常segment对应的mirror会自动接管,并转为primary。使用gpstate可以看到warning:

[WARNING]:-Total primary segment failures (at master)                = 1

如当前正在执行的sql语句并没有涉及到全部segment,则不涉及到的segment崩溃不会导致当前sql失败。

  • 修复异常的primary segment

执行gprecoverseg

此时异常的primary以mirror身份加入集群,并同步最新的segment数据。primary与mirror身份目前是互换的,如果采用机器间互相备份的方式会影响性能。所以正常后需要恢复原来的身份。

恢复节点原来的身份:

执行gprecoverseg -r

2.2.3 测试结论

  1. segment崩溃时正在运行的事物会全部失败。
  2. mirror会自动接管服务而无需人工干预,接管过程中会有几秒的不可用时间;执行gprecoverseg操作时会有不可用时间,表现为语句执行卡顿;执行gprecoverseg -r操作时需要重启segment,所以也会有不可用时间,表现为语句执行报错。

集群扩容

3.1 创建新增segment

  1. 将新加入的host写入hostfile文件中
  2. 自动生成扩容配置文件

gpexpand -f ./etc/hostfile -D lzk,并输入需要增加的节点数及data目录

成功会生成类似配置文件:gpexpand_inputfile_20171211_153009

  • 看一下配置文件内容,可根据需要手动调整:cat gpexpand_inputfile_20171211_153009

lzk-8:lzk-8:50002:/data3/data2/gpseg2:4:2:p

lzk-8:lzk-8:50003:/data4/data2/gpseg3:5:3:p

  • 初始化新的segment

gpexpand -i gpexpand_inputfile_20171211_153009 -D lzk

3.2 数据重分布

  1. 可以查询gpexpand中的数据表来查看需要重分布的表及优先级
  2. 执行重分布命令,-d表示启动重分布命令后持续执行的时间

gpexpand -d 01:00:00 -D lzk

  • 全部完成后清除重分布使用的schema:gpexpand

gpexpand -c -D lzk

3.3 测试结论

重分布过程中严重影响数据库性能,故需必须要在业务闲时进行,如数据量非常大可以通过-d命令控制执行的时间段。集群只能扩容不能进行缩容,如一定要缩容需要进行数据导出、导入。

MySQL到Greenplum迁移分析

数据类型对比

  MySQL PostgreSQL comments
数值类型 TINYINT SMALLINT gp中无zerofill属性及unsigned类型,所以为了数据不越界需使用大一精度的数据类型匹配
SMALLINT SMALLINT
MEDIUMINT INTEGER
INT|INTEGER INTEGER
BIGINT BIGINT
TINYINT UNSIGNED SMALLINT
SMALLINT UNSIGNED INTEGER
MEDIUMINT UNSIGNED INTEGER
INT UNSIGNED BIGINT
BIGINT UNSIGNED NUMERIC(20)
BIT BIT
FLOAT REAL
FLOAT UNSIGNED DOUBLE PRECISION
DOUBLE|REAL|DOUBLE PRECISION DOUBLE PRECISION
DECIMAL|DEC|NUMERIC|FIXED NUMERIC
字符类型 CHAR CHARACTER|CHAR  
VARCHAR CHARACTER VARYING|VARCHAR  
TINYTEXT TEXT  
TEXT TEXT  
MEDIUMTEXT TEXT  
LONGTEXT TEXT  
BINARY|CHAR BYTE BYTEA  
VARBINARY BYTEA  
TINYBLOB BYTEA  
BLOB BYTEA  
MEDIUMBLOB BYTEA  
LONGBLOB BYTEA  
时间类型 DATE DATE  
TIME TIME  
YEAR  
DATETIME TIMESTAMP  
TIMESTAMP TIMESTAMP  
其他类型 BOOL|BOOLEAN BOOLEAN  
ENUM CREATE TYPE … AS ENUM  
SET  

语法对比

2.1 limit

MySQL:

or

 

Greenplum:

2.2 replace

MySQL:

Greenplum:

不支持该语法,需要使用函数实现,例:

2.3 insert into … on duplicate key update

MySQL:

Greenplum:

不支持该语法,需要使用函数实现,例:

2.4 select … into outfile

MySQL:

Greenplum:

2.5 自增列

MySQL:

列加auto_increment属性,例:create table a(id int auto_increment primary key)

获取当前值:select last_insert_id()

 

Greenplum:

字段类型使用serial,例:create table a(id serial primary key)

获取当前值:select currval(‘a_id_seq’)

2.6 注释

MySQL:

使用#或–

Greenplum:

使用–

2.7 执行存储过程

MySQL:

Greenplum:

Greenplum并无存储过程,使用函数代替,所以执行:

常用函数对比

3.1 时间函数

3.1.1 时间转字符串

MySQL:date_format()

例:select date_format(now(),’%Y%m%d%H%i%s’)

Greenplum:to_char()

例:select to_char(now(), ‘YYYYMMDDHH24MISS’)

3.1.2 字符串转时间

MySQL:str_to_date()

例:select str_to_date(‘20171120′,’%Y%m%d%H%i%s’)

Greenplum:to_date(),to_timestamp()

例:select to_date(‘20171120’, ‘YYYYMMDD’)

select to_date(‘20171120’, ‘YYYYMMDDHH24MISS’)

3.1.3 时间计算

MySQL:date_add()

例:select date_add(now(), interval 2 day)

Greenplum:直接计算

例:select now() + interval ‘2 day’

3.2 字符函数

3.2.1 空字符串处理

MySQL:ifnull

例:select ifnull(null,‘default’)

Greenplum:coalesce

例:select coalesce(null,‘default’)

3.2.2 字符串拼接

MySQL:concat()

例:select concat(‘abc’,‘def’)

Greenplum:||

例:select ‘abc’||’def’

数据迁移

Greenplum数据导入3种方式:

4.1 COPY命令

COPY需要经过master,仅建议在小数据量时使用。无法并行导入,在大量数据导入时效率很低,不过多介绍。

例:COPY tablea FROM ‘/data/tablea_data’;

4.2 使用外部表

外部表以及4.3中的gpload都需要使用gpfdist服务。

gpfdist是Greenplum自带的一个并行文件服务,原理如下图:

gpfdist为每个segment提供并行读写数据文件的服务。

 

1、先启动gpfdist服务,例:

-d 指定数据目录 -p指定服务端口 -l 指定日志文件

将数据文件放入该目录下

2、创建外部表,例:

  • 从外部表导入数据,例:

或者先创建,后导入:

4.3 gpload

通过配置yaml控制文件来进行数据导入,同样依赖gpfdist服务。

例:

1、编辑a.yml文件

2、进行导入:

 

MySQL Test Suite使用

MySQL自动测试套件(The MySQL Test Suite)用于对MySQL程序进行测试,包括各种功能与存储引擎。包含于MySQL与MariaDB版本代码中,位于mysql-test目录下。总体测试脚本为mysql-test-run.pl。该perl脚本通过调用各种已有的测试脚本,将测试结果与预置的result文件做对比来判断测试是否通过。(任何一点差异都会导致测试失败,包括预期之外的warning)

一、主要目录介绍

    • include
包含.inc文件,用于测试开始时判断是否满足测试条件,在测试用通过source命令引入
如hava_innodb.inc:

如不满足,则会跳过需要该验证的测试。

    • suite
包含所有测试suite,每一个suite为一个测试用例集,具体用例集在2节介绍
    • t
1、测试文件
例:1st.test

上面内容即为1st这个测试用例的测试脚本

 2、配置文件
例:innodb_bug53674-master.opt
–loose-innodb-locks-unsafe-for-binlog –binlog-format=mixed
为该测试需要的特殊配置项
3、脚本文件,在测试开始之前执行的脚本
例:rpl_misc_functions-slave.sh
rm -f $MYSQLTEST_VARDIR/master-data/test/rpl_misc_functions.outfile
    • r
结果文件,判断是否通过的依据
使用上面的例子:1st.result

执行完1st用例会严格比对该文件。完全一致则测试通过。

    • std_date
有些测试需要用到一些标准数据。
    • var
测试默认使用该文件夹下的my.cnf文件

二、测试用例集

./mysql-test-run.pl不带任何参数表示执行所有测试用例集。使用—suite=suitename来指定单独执行suitename目录下的所有测试用例。
测试用例集包括:

 

三、主要参数

force:默认情况下,只要遇到一个用例出错,测试程序就会退出,在指定force的情况下,测试程序会继续执行下面的测试(但是最多发现10个错误还是会退出)
suite:指定使用的测试suite
do-test:会以输入的字符串进行匹配用例执行
skip-test:会以输入的字符串进行匹配跳过用例执行
big-test:执行标记为big的测试用例。因为用例较大、耗时较长,标记为big的用例默认不会执行。输入两遍big-test则只执行标记为big的测试用例
recored:重新生成结果文件
mysqld:传递启动参数给mysqld,每个参数需要分别指定一个mysqld
其他还有很多选项,可以使用./mtr –help查看
如果需要在服务启动前执行一些脚本,可以写在 t/testname.sh文件中,由mtr自动执行。

四、测试举例

例1:
可以看出共完成12个测试用例,全部通过。1个用例必须在debug模式下测试,所以跳过。测试过程中服务重启3次。测试默认使用16000-16019端口。
例2:

每个测试结束前,mtr会检索error日志,如果发现warning或error,则测试失败。

再来看两个失败用例:
(截取部分日志)

分析日志可以看出是在测试过程中在错误日志中发现了warnings/errors。原因是使用了废弃的参数innodb_locks_unsafe_for_binlog导致warning。

找到并修改配置文件:innodb_bug53674-master.opt
将–loose-innodb-locks-unsafe-for-binlog –binlog-format=mixed
修改为:–transaction-isolation=READ-COMMITTED –binlog-format=mixed
重新测试:

不再有warning,测试通过。