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

目录
相关文章
|
存储 SQL Cloud Native
深入了解云原生数据库CockroachDB的概念与实践
作为一种全球领先的分布式SQL数据库,CockroachDB以其高可用性、强一致性和灵活性等特点备受关注。本文将深入探讨CockroachDB的概念、设计思想以及实践应用,并结合实例演示其在云原生环境下的优越表现。
|
SQL 缓存 运维
PostgreSQL 事务号回卷分析
## XID 定义 xid 是个啥东西?xid 就是 PostgreSQL 里面的事务号,每个事物都会分配一个 xid。PostgreSQL 数据中每个元组头部都会保存着 插入 或者 删除 这条元组的事务号,即 xid,然后内核通过这个 xid 进行元组的可见性判断。简单理解,比如有两个事务,xid1=200,xid2=201,那么 xid1 中只能看到 t_xmin 200 的元组。 ```c
|
Java 关系型数据库 数据库连接
greenplum驱动都有哪几个
【5月更文挑战第23天】greenplum驱动都有哪几个
453 4
|
关系型数据库 PostgreSQL
【一文搞懂PGSQL】5. 流复制
PostgreSQL流复制架构支持多种常见配置,包括基本的主从复制、结合PGPool-II的读写分离以及使用repmgr实现高可用性。基础环境中,主节点与备用节点分别位于不同IP。配置涵盖创建复制用户、调整核心参数以支持流复制,并确保归档与日志功能正常工作。从节点需通过备份恢复并配置为待机模式,以实现数据同步。此外,还介绍了如何验证复制状态及手动切换主从节点的方法,以及同步复制参数的配置细节。
|
SQL druid Java
解决 ‘The last packet successfully received from the server was xxx milliseconds ago‘ 问题
解决 ‘The last packet successfully received from the server was xxx milliseconds ago‘ 问题
6818 0
|
关系型数据库 数据库 SQL
Greenplum 的一次紧急恢复
Greenplum的一次非常规恢复方法
2850 0
|
缓存 监控 前端开发
前端性能监控:从Lighthouse到Real User Monitoring
**前端性能监控关乎用户体验。Lighthouse是自动化审计工具,评估网页性能、最佳实践、可访问性等,通过CLI或Chrome DevTools使用。RUM则实时监控用户与网站互动,收集性能数据。两者结合,从开发到生产环境,全面优化前端性能,包括资源加载、代码优化、网络性能和用户体验。使用Lighthouse和RUM数据,结合CI/CD,持续改进并设定性能预算,采用SSR、Service Worker、Code Splitting等高级策略,确保高性能和用户满意度。**
341 2
|
安全 Java 网络安全
对象存储oss使用问题之使用oss上服务器后显示服务异常如何解决
《对象存储OSS操作报错合集》精选了用户在使用阿里云对象存储服务(OSS)过程中出现的各种常见及疑难报错情况,包括但不限于权限问题、上传下载异常、Bucket配置错误、网络连接问题、跨域资源共享(CORS)设定错误、数据一致性问题以及API调用失败等场景。为用户降低故障排查时间,确保OSS服务的稳定运行与高效利用。
2027 0
|
监控 关系型数据库 数据库
Greenplum csvlog(日志数据)检索、释义(gp_toolkit.gp_log*)
标签 PostgreSQL , Greenplum , csvlog , gp_toolkit 背景 由于GP为分布式数据库,当查看它的一些日志时,如果到服务器上查看,会非常的繁琐,而且不好排查问题。
2769 0
下一篇
开通oss服务