GPDB · 特性分析· GreenPlum FTS 机制

简介:

前言

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物理核的机器上进行了测试,重计算的场景,性能程线性提升。 目前并行计算支
5690 0
|
SQL 存储 NoSQL
MSSQL · 特性分析 · 列存储技术做实时分析
摘要 数据分析指导商业行为的价值越来越高,使得用户对数据实时分析的要求变得越来越高。使用传统RDBMS数据分析架构,遇到了前所未有的挑战,高延迟、数据处理流程复杂和成本过高。这篇文章讨论如何利用SQL Server 2016列存储技术做实时数据分析,解决传统分析方法的痛点。 传统RDBMS数据分析 在过去很长一段时间,企业均选择传统的关系型数据库做OLAP和Data Warehouse工作。这一
3637 0
|
缓存 关系型数据库 数据库
MySQL · 引擎特性 · B+树并发控制机制的前世今生
前言 B+树是1970年Rudolf Bayer教授在《Organization and Maintenance of Large Ordered Indices》一文中提出的[1]。它采用多叉树结构,降低了索引结构的深度,避免传统二叉树结构中绝大部分的随机访问操作,从而有效减少了磁盘磁头的寻道次数,降低了外存访问延迟对性能的影响。
1486 0
|
NoSQL
MongoDB · 引擎特性 · 事务实现解析
MongoDB 4.0 引入的事务功能,支持多文档ACID特性,例如使用 mongo shell 进行事务操作 > s = db.getMongo().startSession() session { "id" : UUID("3bf55e90-5e88-44aa-a59e-a30f777f1d89") } > s.
2083 0
|
SQL MySQL 关系型数据库
MySQL · 引擎特性 · Group Replication内核解析之二
背景 前文已经介绍了MySQL的Group Replication的实现机制和原理,本文就Group Replication的具体实现进行详细的阐述,以更深入的理解Group Replication的机制,在实践中更好的应用Group Replication,提升应用系统的可用性,优化其性能。
1704 0
|
SQL 关系型数据库 索引
HybridDB · 最佳实践 · HybridDB 数据合并的方法与原理
引言 刚开始使用HybridDB的用户,有个问的比较多的问题:如何快速做数据“合并”(Merge)?所谓“合并”,就是把数据新版本更新到HybridDB中。如果数据已经存在,则将它们替换为新版本;如果不存在,将它们插入数据库中。一般是离线的做这种数据合并,例如每天一次批量把数据更新到HybridDB中。也有客户需要实时的更新,即做到分钟级甚至秒级延迟。这里我们介绍一下HybridDB中数据合并的
3033 0
|
关系型数据库
GPDB · 特性分析· Greenplum 备份架构
Greenplum是分布式数据库,这为备份带来了一些困难。其本身提供了一个工具是gpcrondump,对其二进制备份工具gp_dump做了一些封装,而gp_dump则是对pg_dump做了封装,在每个节点上执行pg_dump完成数据的备份。在其每个节点的行为上,与PG类似,但其分布式的架构,则有值得了解的地方。 备份方法 GP备份的工具gpcrondump是一个Python脚本,是对gp_du
2769 0
|
关系型数据库 MySQL 索引
MySQL · 特性分析 · 5.7 代价模型浅析
代价模型 mysql 5.7代价计算相对之前的版本有较大的改进。例如 代价模型参数可以动态配置,可以适应不同的硬件 区分考虑数据在内存和在磁盘中的代价 代价精度提升为浮点型 jion计算时不仅要考虑condition,还要考虑condition上的filter,具体参见参数condition_fanout_filter 5.7 在代价类型上分为io,cpu和memory, 5.7
1829 0
|
存储 NoSQL
MongoDB · 特性分析· Sharding原理与应用
MongoDB Sharded Cluster 原理 如果你还不了解 MongoDB Sharded cluster,可以先看文档认识一下 中文简介:MongoDB Sharded cluster架构原理 英文汇总:https://docs.mongodb.com/manual/sharding/ 什么时候考虑用 Sharded cluster? 当你考虑使用 Sharded
1897 0

相关实验场景

更多