Làm cách nào để chạy các tác vụ định kỳ trên Postgresql mà không cần một công cụ giống như cron bên ngoài?


41

Tôi muốn gọi một thủ tục được lưu trữ một cách thường xuyên. Trên Oracle, tôi sẽ tạo một công việc cho việc này. Tôi đã thấy rằng Postgresql có thể bắt chước điều này tốt bằng cách sử dụng một công cụ bên ngoài (cron, v.v.) và PGAgent.

Bạn có biết một giải pháp thay thế "nội bộ" không liên quan đến công cụ bên ngoài không?

  • Tôi muốn tránh những lo ngại về bảo mật với mật khẩu được lưu trữ trên dòng lệnh của pgAgent.
  • Tôi muốn tránh mọi cấu hình hệ thống bổ sung để ẩn mật khẩu ( ~/.pgpass).

Postgresql 8.3
Linux RedHat 64 bit


Bạn có thể thêm lý do tại sao bạn không thể sử dụng pgAgent hoặc crontab? cụ thể là những tính năng nào còn thiếu ..
WrinkleFree

@Rohan Tôi đã cập nhật câu hỏi của mình
Stephan

Bài đăng dường như đã được sao chép và dán vào stackoverflow.com/q/16958625/398670
Craig Ringer

Câu trả lời:


30

Ngay cả khi bạn đang chạy phiên bản sắp phát hành (tại thời điểm viết) PostgreQuery 10 hoặc PostgreQuery 9.6 hiện tại không phải là một bản phát hành cổ xưa như 8.3, vẫn không có bộ lập lịch tác vụ tích hợp.

Một cái gì đó như PGAgent hoặc công việc cron bên ngoài là bắt buộc, không có cách giải quyết thuận tiện.

Tính năng nhân viên nền được giới thiệu trong 9.3 sẽ hy vọng cho phép một công cụ như PGAgent được chuyển vào lõi PostgreQuery trong bản phát hành sau, nhưng nó vẫn chưa được thực hiện. Ngay cả vào ngày 9.3, bạn vẫn phải chạy cron hoặc pgagent.

Một vài người đang làm việc trên các trình lập lịch dựa trên nhân viên nền, và có một số bản vá sắp tới sẽ cung cấp các phương tiện để giúp đỡ với điều đó. Nhưng kể từ PostgreSQL 10 vẫn không có chất lượng tốt, bộ lập lịch được chấp nhận rộng rãi và hầu hết mọi người sử dụng bộ lập lịch tác vụ cron / ms / v.v.

Xin hãy xem chính sách phiên bản , quá; bạn đang chạy một bản phát hành lỗi thời và không được hỗ trợ.


Please take a look at the version policy, nâng cấp Postgresql không phải là một lựa chọn.
Stephan

2
@Alex Bạn sẽ phải nâng cấp vào một lúc nào đó, và nó sẽ chỉ trở nên khó khăn hơn. Bằng cách nào phát hành 8.3 điểm? Có bao nhiêu sửa lỗi đáng kể mà bạn đang thiếu? Hay bạn ít nhất là vào ngày 8.3,23? Điều đó nói rằng, như tôi đã giải thích tính năng bạn muốn không tồn tại ngay cả trong phiên bản 9.3 sắp tới, mặc dù một số nền tảng để cho phép bổ sung đã được thêm vào.
Craig Ringer

Tôi sẽ nói chuyện với sếp của mình :)
Stephan

1
@Alex Ý kiến ​​hay :-). Ở mức tối thiểu cập nhật lên 8.3,23, sau đó bắt đầu thực hiện các kế hoạch nâng cấp lên bản phát hành mới hơn. Nó sẽ không giải quyết được câu hỏi này, nhưng đó là một ý tưởng rất tốt để cứu vãn nỗi đau trong tương lai. Số lượng khách hàng tôi hỗ trợ, những người gặp vấn đề mà họ sẽ không bao giờ có nếu họ duy trì hiện tại là đáng kinh ngạc. Chúng tôi không phát hành phiên bản mới chỉ dành cho đá ;-). Đọc ghi chú phát hành cho mỗi phiên bản .0 để được hướng dẫn về những điều bạn có thể cần phải xử lý và đọc hướng dẫn về nâng cấp. Điểm đau duy nhất của bạn là standard_conforming_stringsbytea_output.
Craig Ringer

Craig, bạn nghĩ gì về pg_cron?
mehmet

21

Kể từ PostgreQuery 9.5, bạn có thể sử dụng tiện ích mở rộng pg_cron , được tải dưới dạng thư viện dùng chung vào PostgreQuery.

Sau khi thiết lập nó, việc tạo một công việc khá đơn giản:

SELECT cron.schedule('30 3 * * 6', $$DELETE FROM events WHERE event_time < now() - interval '1 week'$$);

Điều này sẽ chạy lệnh xóa theo lịch trình cron được chỉ định. Bạn cũng có thể sử dụng @rebootđể lên lịch công việc khi máy chủ khởi động lại và pg_cron sẽ tự động bắt đầu chạy các công việc nếu bạn quảng cáo chế độ chờ nóng.

Thay vì sử dụng .pgpass, bạn có thể cung cấp quyền truy cập localhost cho người dùng cron trong pg_hba.conf.


-1

Bạn thực sự, thực sự không muốn làm điều này. Postgres không phải là một hệ điều hành, nó là một máy chủ cơ sở dữ liệu. Ngay cả khi cơ sở dữ liệu hỗ trợ chạy các tác vụ theo lịch trình, thì thực sự không nên lạm dụng cơ sở dữ liệu như vậy.

Nếu mối quan tâm của bạn là bạn không muốn thiết lập mật khẩu và nội dung, điều đó thật dễ giải quyết. Thay vào đó, hãy thiết lập kết nối ổ cắm Unix cục bộ bằng xác thực hoặc xác thực danh tính , chạy cronjob của bạn với tư cách là người dùng đó.

Trong cấu hình bên ngoài của nó, thông thường các postgres sẽ thiết lập người dùng hệ thống postgresđể chạy máy chủ db và người dùng hệ thống này thường được cấu hình sẵn để nó có thể kết nối với máy chủ cục bộ bằng xác thực tin cậy khi kết nối qua ổ cắm unix cục bộ. Bạn có thể chạy cronjob của mình với tư cách là người dùng hệ thống postgres, kết nối với ổ cắm cục bộ và sau đó chuyển đổi vai trò nếu bạn không muốn quy trình được lưu trữ của mình chạy với đặc quyền superuser.

Trong thiết lập mặc định, bạn chỉ có thể làm điều này:

$ sudo -u postgres crontab -e

Trong trình chỉnh sửa, thêm vào mục crontab như vậy:

0    0    *     *    * bash /path/to/run_stored_procedure.sh

và trong tệp /path/to/run_stored_procedure.sh của bạn, bạn chỉ cần sử dụng psql để gọi thủ tục lưu trữ của bạn

#!/usr/bin/env bash
psql my_db_name <<END
    SET ROLE limited_user;
    SELECT my_stored_proc();
    SELECT 1 FROM my_stored_proc();
END

1
'Thực sự không nên lạm dụng cơ sở dữ liệu như vậy' Tại sao bạn nghĩ rằng đó là lạm dụng? Các RDBMS chính thống khác nhau có xu hướng có cách tiếp cận tương tự và tôi không nghĩ nó rất khủng khiếp. Ngoài ra, nếu bạn không có quyền truy cập vào HĐH, bạn sẽ thiếu crontab.
dezso
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.