GPDB · 特性分析· GreenPlum FTS 机制

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介: 前言 FTS(Fault Tolerance Serve)是GreenPlum中的故障检测服务,是保证GP高可用的核心功能。GreenPlum的Segment的健康检测及HA是由GP Master实现的,GP Master上面有个专门的进程–FTS进程,它可以快速检测到Primary或者Mirro

前言

FTS(Fault Tolerance Serve)是GreenPlum中的故障检测服务,是保证GP高可用的核心功能。GreenPlum的Segment的健康检测及HA是由GP Master实现的,GP Master上面有个专门的进程–FTS进程,它可以快速检测到Primary或者Mirror是否挂掉,并及时作出Primary/Mirror 故障切换。如果FTS挂掉了,Master将会重新fork出来一个FTS进程。

screenshot

FTS实现原理

GP Master上面的FTS进程每隔60s(时间可以配置)向Primary或者Mirror发送心跳包,Primary和Mirror收到心跳包后返回它们的当前状态,FTS进程心跳包的发送状态和Segment返回状态更新元信息和作出故障切换。因为Segment可能很多,为了加快检测速度,FTS是多线程的,默认16个线程。

screenshot

实现检测方法的源码大致如下:

	while (!probeGetIpAddr(&probeInfo) ||
	       !probeOpenSocket(&probeInfo) ||
	       !probeMarkSocketNonBlocking(&probeInfo) ||
	       !probeConnect(&probeInfo) ||
	       !probeSend(&probeInfo) ||
	       !probeReceive(&probeInfo) ||
	       !probeProcessResponse(&probeInfo))
	{
		probeClose(&probeInfo);
		if (retryCnt == gp_fts_probe_retries)
		{
			write_log("FTS: failed to probe segment (content=%d, dbid=%d) after trying %d time(s), "
					  "maximum number of retries reached.",
					  probeInfo.segmentId,
					  probeInfo.dbId,
					  retryCnt);
			break;
		}

		/* sleep for 1 second to avoid tight loops */
		pg_usleep(USECS_PER_SEC);
		retryCnt++;
		//other code
	}

Segment检测及故障切换

GP Master首先会检测Primary状态,如果Primary不可连通,那么将会检测Mirror状态,Primary/Mirror状态总共有4种:

  1. Primary活着,Mirror活着。GP Master探测Primary成功之后直接返回,进行下一个Segment检测;
  2. Primary活着,Mirror挂了。GP Master探测Primary成功之后,通过Primary返回的状态得知Mirror挂掉了(Mirror挂掉之后,Primary将会探测到,将自己变成ChangeTracking模式),这时候更新Master元信息,进行下一个Segment检测;
  3. Primary挂了,Mirror活着。GP Master探测Primary失败之后探测Mirror,发现Mirror是活着,这时候更新Master上面的元信息,同时使Mirror接管Primary(故障切换),进行下一个Segment检测;
  4. Primary挂了,Mirror挂了。GP Master探测Primary失败之后探测Mirror,Mirror也是挂了,直到重试最大值,结束这个Segment的探测,也不更新Master元信息了,进行下一个Segment检测。

screenshot

参数配置

gp_fts_probe_threadcount

用来故障检测的线程数量,默认为16。

gp_fts_probe_interval

两次检测的时间间隔,默认为60s。如果一次检测时间使用10s,那么剩余50s将会sleep;如果超过60s,将会直接进入下一次检测。

gp_fts_probe_timeout

检测Segment超时时间,默认值: 20。

gp_fts_probe_retries

检测Segment失败重试次数,如果超过这个次数,将会认为当前节点挂掉,默认值: 5。

gp_segment_connect_timeout

Prmary和Mirror文件同步允许连接Mirror最大超时时间,如果达到这个超时时间,Primary将会认为Mirror挂掉了,默认值: 180s。

总结

通过GreenPlum FTS机制学习,可以了解部分MPP架构高可用原理。同时根据自身的业务,合理地配置FTS参数,保障GP高可用。

目录
相关文章
|
并行计算 关系型数据库 测试技术
PgSQL · 特性分析 · PostgreSQL 9.6 让多核并行起来
背景 经过多年的酝酿(从支持work process到支持动态fork共享内存,再到内核层面支持并行计算),PostgreSQL 的多核并行计算功能终于在2016年发布的9.6版本中正式上线,为PG的scale up能力再次拔高一个台阶,标志着开源数据库已经攻克了并行计算的难题。 相信有很多小伙伴已经开始测试了。 在32物理核的机器上进行了测试,重计算的场景,性能程线性提升。 目前并行计算支
5422 0
|
关系型数据库 数据库 PostgreSQL
PgSQL · 特性分析 · 浅析PostgreSQL 中的JIT
--- title: PgSQL · 特性分析 · 浅析PostgreSQL 中的JIT author: 卓刀 --- ## 背景 估计很多同学看过之前的月报[PgSQL · 特性分析· JIT 在数据仓库中的应用价值](http://mysql.taobao.org/monthly/2016/11/10/),对JIT(just in time)和LLVM(Low Level Vir
2653 0
|
存储 NoSQL
MongoDB · 引擎特性 · 复制集原理
复制集简介 Mongodb复制集由一组Mongod实例(进程)组成,包含一个Primary节点和多个Secondary节点,Mongodb Driver(客户端)的所有数据都写入Primary,Secondary从Primary同步写入的数据,以保持复制集内所有成员存储相同的数据集,提供数据的高可用。
1534 0
|
SQL 关系型数据库 索引
HybridDB · 最佳实践 · HybridDB 数据合并的方法与原理
引言 刚开始使用HybridDB的用户,有个问的比较多的问题:如何快速做数据“合并”(Merge)?所谓“合并”,就是把数据新版本更新到HybridDB中。如果数据已经存在,则将它们替换为新版本;如果不存在,将它们插入数据库中。一般是离线的做这种数据合并,例如每天一次批量把数据更新到HybridDB中。也有客户需要实时的更新,即做到分钟级甚至秒级延迟。这里我们介绍一下HybridDB中数据合并的
2961 0
|
SQL 存储 NoSQL
MSSQL · 特性分析 · 列存储技术做实时分析
摘要 数据分析指导商业行为的价值越来越高,使得用户对数据实时分析的要求变得越来越高。使用传统RDBMS数据分析架构,遇到了前所未有的挑战,高延迟、数据处理流程复杂和成本过高。这篇文章讨论如何利用SQL Server 2016列存储技术做实时数据分析,解决传统分析方法的痛点。 传统RDBMS数据分析 在过去很长一段时间,企业均选择传统的关系型数据库做OLAP和Data Warehouse工作。这一
3585 0
|
关系型数据库
GPDB · 特性分析· Greenplum 备份架构
Greenplum是分布式数据库,这为备份带来了一些困难。其本身提供了一个工具是gpcrondump,对其二进制备份工具gp_dump做了一些封装,而gp_dump则是对pg_dump做了封装,在每个节点上执行pg_dump完成数据的备份。在其每个节点的行为上,与PG类似,但其分布式的架构,则有值得了解的地方。 备份方法 GP备份的工具gpcrondump是一个Python脚本,是对gp_du
2703 0
|
SQL 关系型数据库 测试技术
PgSQL · 特性分析 · PostgreSQL 9.6 如何把你的机器掏空
背景 PostgreSQL 在向和纵向的扩展能力在开源数据库中一直处于非常领先的地位,例如今年推出的9.6,内置了sharding的功能,同时在scale-up的能力也有非常明显的提升,特别是在多核与高并发处理这块。 社区有同学在128核的机器上测试tpc-b的select only模式可以达到几百万的qps,机器的CPU资源被吃光光。 天下大势,分久必合,合久必分。谈了这么多年的shardi
6058 0
|
NoSQL Java 测试技术
MongoDB · 特性分析 · 网络性能优化
从 C10K 说起 对于高性能即时通讯技术(或者说互联网编程)比较关注的开发者,对C10K问题(即单机1万个并发连接问题)应该都有所了解。『C10K』概念最早由 Dan Kegel 发布于其个人站点,即出自其经典的《The C10K problem》一文[1]。 于是FreeBSD推出了kqueue,Linux推出了epoll,Windows推出了IOCP。这些操作系统提供的功能就是为了解决C1
4299 0
|
存储 NoSQL
MongoDB · 特性分析· Sharding原理与应用
MongoDB Sharded Cluster 原理 如果你还不了解 MongoDB Sharded cluster,可以先看文档认识一下 中文简介:MongoDB Sharded cluster架构原理 英文汇总:https://docs.mongodb.com/manual/sharding/ 什么时候考虑用 Sharded cluster? 当你考虑使用 Sharded
1837 0
|
存储 关系型数据库 MySQL
MySQL · 特性分析 · MyRocks简介
RocksDB是facebook基于LevelDB实现的,目前为facebook内部大量业务提供服务。经过facebook大量工作,将RocksDB作为MySQL的一个存储引擎移植到MySQL,称之为MyRocks。 经过两年的发展,MyRocks已经比较成熟(RC阶段),现已进入了facebook MySQL的主分支了。MyRocks是开源的,参见git 。 下面对MyRocks做一个简单介绍,
2689 0