暂无图片
暂无图片
1
暂无图片
暂无图片
暂无图片

[译] PG_TIMETABLE V4.4 立即可用!

原创 tinge 2022-05-11
764

原文地址:https://www.cybertec-postgresql.com/en/pg_timetable-v4-4-is-available-immediately/
原文作者:Pavlo Golub

我们的团队很自豪地向大家介绍新的PG_TIMETABLE V4.4版本!

这一次,我们专注于实现一些新的功能,以及提高性能。

我要提醒的是,PG_TIMETABLE作为一个社区项目。所以,你可以为这个项目命名,并向世界介绍它。

REST API

我们在pg_timetable v4.4版本中增加的第一个很酷的功能是提供REST API的网络服务器。现在它只提供两个端点。sql/liveness和/readiness。

GET /liveness总是返回HTTP状态代码200,这只表明pg_timetable正在运行,例如

$ curl -i localhost:8080/liveness HTTP/1.1 200 OK Date: Wed, 09 Feb 2022 15:11:02 GMT Content-Length: 0
复制

当pg_timetable运行时,GET /readiness返回HTTP状态代码200,并且调度器处于主循环处理链中,例如

$ curl -i localhost:8080/readiness HTTP/1.1 200 OK Date: Wed, 09 Feb 2022 15:30:25 GMT Content-Length: 0
复制

如果调度程序连接到数据库,创建数据库模式,或升级数据库,它将返回HTTP状态代码503,即

$ curl -i localhost:8080/readiness HTTP/1.1 503 Service Unavailable Date: Wed, 09 Feb 2022 15:10:48 GMT Content-Length: 0
复制

这对监控是很有用的,例如,执行HTTP健康检查。我们正计划增加更多的端点,以执行启动/停止/重新初始化/重新启动/重新加载,并提供扩展的监测统计数据。

REST API服务器默认是禁用的。你应该使用 --rest-port 命令行参数来激活它。

$ ./pg_timetable --rest-port=8080 --clientname=loader2 postgresql://scheduler@localhost/timetable 2022-02-09 16:36:08.593 [INFO] [port:8080] Starting REST API server... 2022-02-09 16:36:08.867 [INFO] Database connection established 2022-02-09 16:36:08.875 [INFO] Accepting asynchronous chains execution requests... 2022-02-09 16:36:08.880 [INFO] [count:0] Retrieve scheduled chains to run @reboot 2022-02-09 16:36:08.884 [INFO] [count:2] Retrieve interval chains to run ...
复制

版本输出

为了调试和监控的目的,我们在pg_timetable v4.4中增加了详细的版本输出。你应该使用-v, --version命令行参数来强制pg_timetable输出相关的版本信息。

$ pg_timetable.exe -v pg_timetable: Version: 4.4.0 DB Schema: 00381 Git Commit: 52e12177d0025b9b01c737cea06048fc350315f5 Built: 2022-02-07T14:06:57Z
复制

第一行是二进制文件本身的版本,如果是开发构建,则是分支的名称。例如,我们的cybertecpostgresql/pg_timetable Docker镜像的最新标签总是针对主分支构建的,因此输出结果会略有不同。

$ docker run --rm cybertecpostgresql/pg_timetable:latest -v pg_timetable: Version: master DB Schema: 00381 Git Commit: e67c6872ab9aa91a262aab5b75fb76ea51e050b8 Built: 2022-02-07T16:01:25+01:00
复制

⚠️需要注意的是:由于最新的标签是与主分支同步的,你可能希望在生产中使用最新的稳定标签

输出中的数据库模式行表示应用的最新数据库迁移的版本。我们使用引起这些变化的Github问题的ID作为标识符。这有助于快速定位与模式变化相关的历史,例如Issue #381。

Git提交是构建二进制文件所依据的提交,精确的时间被放在最后一行。

重写活动链处理

事实证明,在高负载的系统中,调度器在系统表run_status中插入了太多的行:一条链开始,一条链结束。随着时间的推移,目标表可能包含大量的行,导致内部函数每次调用都会滞后大约2-3秒。这也意味着资源的使用会变得太多。

run_status背后的整个想法是跟踪活动链,所以如果活动数量超过max_instances,调度器就不会运行新的链。

事实上,我们不需要这么详细的表,因为我们已经有了log和execution_log表,其中已经存储了执行链的每一块内容。

另外,这个run_status表被设计得非常复杂,但这使得它可以容纳很多细节。另一方面,管理活动/运行链可以用类似于我们管理活动会话的方式来完成。从逻辑的角度来看,这一点是相同的。所以现在在新版本中,我们不再管理这个复杂的run_status表,而是改用另一个active_chain表。而这个active_chain表背后的想法与我们已经用于会话的active_session表相同。

这个想法本身可以用3个步骤来描述。

  • 1.使其成为unLOGGED,以节省空间,不产生WALs
  • 2.当一个链开始时,向active_chain表添加一行数据
  • 3.当一条链完成或失败时,从active_chain表中删除一条记录。
    通过这种方式,我们可以同时处理几千个并行作业的负载,而没有明显的退化–好吧,至少在测试环境中是这样。
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论

目录
  • REST API
  • 版本输出
  • 重写活动链处理