外部cronのようなツールなしでPostgresqlで繰り返しタスクを実行する方法は?


41

ストアドプロシージャを定期的に呼び出したいです。Oracleでは、このためのジョブを作成します。Postgresqlは外部ツール(cronなど)とPgAgentを使用することで、これをうまく模倣できることがわかりました。

外部ツールを使用しない「内部」の代替手段をご存知ですか?

  • pgAgentのコマンドラインに保存されているパスワードに関するセキュリティ上の懸念を回避したい。
  • パスワードを隠すための追加のシステム構成を避けたい(~/.pgpass)。

Postgresql 8.3
Linux RedHat 64ビット


pgAgentまたはcrontabを使用できない理由を追加できますか?具体的にはどの機能が欠けている..
WrinkleFree

@Rohan私は質問を更新しました
ステファン

回答:


30

(執筆時点で)すぐにリリースされるPostgreSQL 10または8.3のような古いリリースではない現在のPostgreSQL 9.6を実行していても、組み込みのタスクスケジューラはありません。

PgAgentや外部cronジョブなどが必要です。便利な回避策はありません。

9.3で導入されたバックグラウンドワーカー機能により、後のリリースでPgAgentなどのツールをPostgreSQLコアに移動できるようになるはずですが、まだ実行されていません。9.3でも、cronまたはpgagentを実行する必要があります。

少数の人々がバックグラウンドワーカーベースのスケジューラに取り組んでおり、それを支援する機能を提供するパッチがいくつかあります。しかし、PostgreSQL 10の時点では、まだ良質で広く採用されているスケジューラはなく、ほとんどの人はcron / msタスクスケジューラなどを使用しています。

バージョンポリシーもご覧ください。廃止されサポートされていないリリースを実行しています。


Please take a look at the version policy、Postgresqlのアップグレードはオプションではありません。
ステファン

2
@Alexある時点でアップグレードする必要があり、それは難しくなるだけです。ところで、8.3ポイントのリリースは何ですか?いくつの重要なバグ修正が欠落していますか?それとも、少なくとも8.3.23ですか?とはいえ、必要な機能は次の9.3リリースでも存在しないと説明しましたが、追加を許可するための土台の一部が追加されています。
クレイグリンガー

上司と話をします:)
ステファン

1
@Alex良いアイデア:-)。少なくとも8.3.23への更新を早急に行ってから、新しいリリースへのアップグレード計画の作業を開始してください。この問題を解決することはできませんが、将来の痛みを軽減することは非常に良い考えです。私がサポートしている顧客の数は、彼らが最新の状態にとどまるなら決してなかったであろう問題を抱えていることは驚くべきことです。キックのためだけに新しいバージョンをリリースするわけではありません;-)。各.0バージョンのリリースノートを読み、対処する必要があるかもしれないことに関するガイダンスを確認し、アップグレードに関するマニュアルを読んでください。あなたの唯一の可能性の痛みのポイントであるstandard_conforming_stringsbytea_output
クレイグリンガー

クレイグ、pg_cronについてどう思いますか?
メーメット

21

PostgreSQL 9.5以降、pg_cron拡張機能を使用できます。これは、PostgreSQLに共有ライブラリとしてロードされます。

設定後、ジョブの作成は非常に簡単です。

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

これにより、指定されたcronスケジュールに従ってdeleteコマンドが実行されます。@rebootサーバーの再起動時にジョブをスケジュールすることもできます。ホットスタンバイを昇格すると、pg_cronは自動的にジョブの実行を開始します。

.pgpassを使用する代わりに、pg_hba.confでcronユーザーにlocalhostアクセスを提供できます。


-1

あなたは本当に、本当にこれをしたくありません。Postgresはオペレーティングシステムではなく、データベースサーバーです。データベースがスケジュールされたタスクの実行をサポートしている場合でも、そのようなデータベースを悪用することはあまり良い考えではありません。

パスワードやその他のものを設定したくない場合は、簡単に解決できます。代わりに信頼またはident認証を使用してローカルUnixソケット接続をセットアップし、そのユーザーとしてcronjobを実行します。

初期設定では、通常、postgresはシステムユーザーpostgresを設定してdbサーバーを実行します。通常、このシステムユーザーはローカルUNIXソケット経由で接続するときに信頼認証を使用してローカルサーバーに接続できるように事前構成されています。ストアドプロシージャをスーパーユーザー権限で実行したくない場合は、cronジョブをpostgresシステムユーザーとして実行し、ローカルソケットに接続してからロール切り替えることができます。

デフォルト設定では、これを行うことができます:

$ sudo -u postgres crontab -e

エディターで、次のようにcrontabエントリーに追加します。

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

/path/to/run_stored_procedure.shファイルでは、単にpsqlを使用してストアプロシージャを呼び出すだけです

#!/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
「そのようなデータベースを悪用するのは本当に良い考えではありません」 なぜそれが悪用だと思いますか?さまざまな主流のRDBMSには同じようなアプローチがある傾向があり、それほどひどいとは思いません。また、OSにアクセスできない場合は、crontabが不足しています。
dezso
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.