原文地址: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表中删除一条记录。
通过这种方式,我们可以同时处理几千个并行作业的负载,而没有明显的退化–好吧,至少在测试环境中是这样。