月份：2017年12月

Greenplum高可用及实测

1 高可用方案

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 高可用搭建及测试

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 集群扩容

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迁移分析

1 数据类型对比

  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 语法对比

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 常用函数对比

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’

4 数据迁移

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，测试通过。