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高可用。

目录
相关文章
|
5月前
|
运维 关系型数据库 MySQL
PolarDB产品使用问题之Federated引擎有哪些基本概念和术语概述
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。
|
并行计算 关系型数据库 测试技术
PgSQL · 特性分析 · PostgreSQL 9.6 让多核并行起来
背景 经过多年的酝酿(从支持work process到支持动态fork共享内存,再到内核层面支持并行计算),PostgreSQL 的多核并行计算功能终于在2016年发布的9.6版本中正式上线,为PG的scale up能力再次拔高一个台阶,标志着开源数据库已经攻克了并行计算的难题。 相信有很多小伙伴已经开始测试了。 在32物理核的机器上进行了测试,重计算的场景,性能程线性提升。 目前并行计算支
5642 0
|
SQL 存储 NoSQL
MSSQL · 特性分析 · 列存储技术做实时分析
摘要 数据分析指导商业行为的价值越来越高,使得用户对数据实时分析的要求变得越来越高。使用传统RDBMS数据分析架构,遇到了前所未有的挑战,高延迟、数据处理流程复杂和成本过高。这篇文章讨论如何利用SQL Server 2016列存储技术做实时数据分析,解决传统分析方法的痛点。 传统RDBMS数据分析 在过去很长一段时间,企业均选择传统的关系型数据库做OLAP和Data Warehouse工作。这一
3620 0
|
SQL 自然语言处理 关系型数据库
|
关系型数据库 数据库 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
2824 0
|
SQL 关系型数据库 索引
HybridDB · 最佳实践 · HybridDB 数据合并的方法与原理
引言 刚开始使用HybridDB的用户,有个问的比较多的问题:如何快速做数据“合并”(Merge)?所谓“合并”,就是把数据新版本更新到HybridDB中。如果数据已经存在,则将它们替换为新版本;如果不存在,将它们插入数据库中。一般是离线的做这种数据合并,例如每天一次批量把数据更新到HybridDB中。也有客户需要实时的更新,即做到分钟级甚至秒级延迟。这里我们介绍一下HybridDB中数据合并的
3007 0
|
关系型数据库
GPDB · 特性分析· Greenplum 备份架构
Greenplum是分布式数据库,这为备份带来了一些困难。其本身提供了一个工具是gpcrondump,对其二进制备份工具gp_dump做了一些封装,而gp_dump则是对pg_dump做了封装,在每个节点上执行pg_dump完成数据的备份。在其每个节点的行为上,与PG类似,但其分布式的架构,则有值得了解的地方。 备份方法 GP备份的工具gpcrondump是一个Python脚本,是对gp_du
2737 0
|
SQL 关系型数据库 测试技术
PgSQL · 特性分析 · PostgreSQL 9.6 如何把你的机器掏空
背景 PostgreSQL 在向和纵向的扩展能力在开源数据库中一直处于非常领先的地位,例如今年推出的9.6,内置了sharding的功能,同时在scale-up的能力也有非常明显的提升,特别是在多核与高并发处理这块。 社区有同学在128核的机器上测试tpc-b的select only模式可以达到几百万的qps,机器的CPU资源被吃光光。 天下大势,分久必合,合久必分。谈了这么多年的shardi
6132 0
|
存储 缓存 关系型数据库
PgSQL · 代码浅析 · PostgreSQL 可靠性分析
背景 PostgreSQL 可靠性与大多数关系数据库一样,都是通过REDO来保障的。 群里有位童鞋问了一个问题,为什么PostgreSQL的REDO块大小默认是8K的,不是512字节。 这位童鞋提问的理由是,大多数的块设备扇区大小是512字节的,512字节可以保证原子写,而如果REDO的块大于512字节,可能会出现partial write。 那么PostgreSQL的redo(wal) 块
2434 0
|
存储 NoSQL
MongoDB · 特性分析· Sharding原理与应用
MongoDB Sharded Cluster 原理 如果你还不了解 MongoDB Sharded cluster,可以先看文档认识一下 中文简介:MongoDB Sharded cluster架构原理 英文汇总:https://docs.mongodb.com/manual/sharding/ 什么时候考虑用 Sharded cluster? 当你考虑使用 Sharded
1872 0
下一篇
无影云桌面