pg_cron کا استعمال کرتے ہوئے PostgreSQL میں کاموں کو شیڈول کرنے کا طریقہ

ہر بیک اینڈ سسٹم کو آخر کار شیڈول پر چلنے کے لیے کچھ درکار ہوتا ہے۔ پرانے سیشنز کو چھوڑنے کی ضرورت ہے، سمری ٹیبلز کو دوبارہ بنانے کی ضرورت ہے، مادی خیالات کو تازہ کرنے کی ضرورت ہے، اور دیکھ بھال کا کام اس وقت کرنے کی ضرورت ہے جب سب سو رہے ہوں۔

عام جواب ڈیٹا بیس سے باہر کسی چیز تک رسائی حاصل کرنا ہے (سسٹم کرونٹاب، کبرنیٹس کرون جاب، سیلری بٹ ورکر، یا شیڈیولر سروس)۔ یہ سب کام کرتا ہے، لیکن متحرک حصوں کو جوڑتا ہے۔ اب آپ کے پاس انتظام کرنے کے لیے ایک اور سند، نگرانی کے لیے ایک الگ عمل، اور خود بخود چلنا بند کرنے کے لیے ایک اور چیز ہے۔

pg_cron ایک مختلف طریقہ اختیار کرتا ہے۔ پوسٹگری ایس کیو ایل ایکسٹینشن جو کرون اسٹائل شیڈیولر چلاتی ہے۔ اندر ڈیٹا بیس خود۔ جب آپ سادہ ایس کیو ایل کا استعمال کرتے ہوئے کسی کام کو شیڈول کرتے ہیں، تو ڈیٹا بیس ٹاسک کو انجام دیتا ہے اور عمل درآمد کی تاریخ کو ایک ٹیبل میں محفوظ کیا جاتا ہے جس سے کسی دوسرے کی طرح استفسار کیا جا سکتا ہے۔

اس ٹیوٹوریل میں، آپ سیکھیں گے کہ pg_cron کیسے کام کرتا ہے، اسے کیسے انسٹال اور کنفیگر کرنا ہے، اور دیکھ بھال کے حقیقی کاموں کے لیے اسے کیسے استعمال کیا جائے۔ آپ یہ بھی سیکھیں گے کہ کس طرح کاموں کی نگرانی کرنا، اجازتوں کا نظم کرنا، اور یہ تعین کرنا کہ کب pg_cron صحیح ٹول ہے اور کب نہیں۔

انڈیکس

شرائط

مثال کی پیروی کرنے کے لیے، آپ کو ضرورت ہو گی:

• SQL کا بنیادی علم (SELECT، INSERT، UPDATE، DELETE)

• ایک چل رہا ہے PostgreSQL مثال (مثالی طور پر ورژن 13 یا اس سے اوپر، لیکن pg_cron ورژن 10 یا اس سے زیادہ کو سپورٹ کرتا ہے)

• ایکسٹینشن کو انسٹال کرنے کے لیے مثال تک سپر یوزر یا ایڈمنسٹریٹر کی رسائی کی ضرورت ہوتی ہے۔

• SQL کلائنٹ مندرجہ ذیل ہے: psqlpgAdmin یا DBeaver

اگر آپ خود اپنا سرور نہیں چلاتے ہیں تو یہ ٹھیک ہے۔ زیادہ تر نظم شدہ PostgreSQL سروسز pg_cron کو سپورٹ کرتی ہیں، بشمول Amazon RDS، Azure Database for PostgreSQL، Google Cloud SQL، Supabase، اور Neon۔ ہم بعد میں ٹیوٹوریل میں اس کو فعال کرنے کا طریقہ بتائیں گے۔

pg_cron کیا ہے؟

pg_cron ایک اوپن سورس PostgreSQL ایکسٹینشن ہے جسے اصل میں Citus Data ٹیم نے بنایا ہے جو آپ کو واقف کرون نحو کا استعمال کرتے ہوئے SQL کمانڈز کو شیڈول کرنے کی اجازت دیتا ہے۔

سرور پر کرونٹاب اندراجات بنانے کے بجائے، آپ SQL بیانات لکھتے ہیں۔

SELECT cron.schedule(
  'nightly-cleanup',
  '0 3 * * *',
  $$DELETE FROM sessions WHERE expires_at < now()$$
);

یہ واحد بیان PostgreSQL سے کہتا ہے کہ ہر روز صبح 3 بجے میعاد ختم ہونے والے سیشنز چھوڑ دیں۔ کوئی بیرونی عمل، شیل سکرپٹ، یا اضافی اسناد نہیں۔ ٹاسک کی تعریفیں ڈیٹا بیس میں رہتی ہیں اور اگر چاہیں تو ہجرت کے ساتھ ورژن کو کنٹرول کیا جاتا ہے۔

شیڈولر ایک اور توسیع ہے، لہذا کام ڈیٹا بیس کے ساتھ چلتا ہے. کوئی بھی جو رابطہ کر سکتا ہے اور استفسار کر سکتا ہے وہ بالکل دیکھ سکتا ہے کہ کیا شیڈول ہے، یہ آخری بار کب چلا، اور آیا یہ کامیاب رہا یا نہیں۔

pg_cron کیسے کام کرتا ہے۔

جب PostgreSQL pg_cron فعال کے ساتھ شروع ہوتا ہے، توسیع ایک پس منظر کارکن شروع کرتی ہے۔ یہ کارکن ایک کام کرتا ہے: cron.job ایک ٹیبل جس میں تمام طے شدہ کاموں کے ساتھ ان کے نظام الاوقات، کمانڈز، ٹارگٹ ڈیٹا بیس، اور صارف جس کے تحت وہ چلتے ہیں۔

جب کام کا مقررہ وقت آجاتا ہے، کارکن کمانڈ پر عمل کرتا ہے۔ یہ بنیادی طور پر ڈیٹا بیس سے ایک نیا مقامی کنکشن کھول کر کرتا ہے، بالکل اسی طرح جیسے کوئی ایپلی کیشن۔ آپ اسے کنکشن کے بجائے PostgreSQL بیک گراؤنڈ ورکر استعمال کرنے کے لیے بھی کنفیگر کر سکتے ہیں۔ اس کی وضاحت سیٹنگز سیکشن میں کی جائے گی۔

دو اعمال پہلے سے جاننے کے قابل ہیں۔

سب سے پہلے، pg_cron بہت سی چیزیں چلا سکتا ہے۔ مختلف متوازی طور پر کام انجام دیتا ہے، لیکن دو مثالیں نہیں چلاتا۔ ایک ہی ایک وقت میں ایک چیز۔ اگر اگلا مقررہ وقت آنے پر بھی کام چل رہا ہے، تو نیا رن قطار میں انتظار کرے گا اور موجودہ رن مکمل ہوتے ہی شروع ہو جائے گا۔ یہ صفائی کے سست کاموں کو اپنے اوپر بننے سے روکے گا۔

دوسرا، pg_cron اس وقت کام نہیں چلاتا جب سرور ہاٹ اسٹینڈ بائی موڈ میں ہوتا ہے۔ جب سٹریمنگ کی نقل استعمال کرتے ہیں، تو نوکریاں صرف پرائمری پر چلتی ہیں۔ شیڈیولر خود بخود شروع ہو جاتا ہے جب ایک نقل کو فروغ دیا جاتا ہے، لہذا فیل اوور کسی مقررہ کام کے بغیر نہیں ہو سکتا۔

pg_cron کو انسٹال اور کنفیگر کرنے کا طریقہ

خود نظم شدہ سرور پر pg_cron کو ترتیب دینے میں تین مراحل شامل ہیں: پیکیج کو انسٹال کرنا، کنفیگریشن کو اپ ڈیٹ کرنا، اور ایکسٹینشن بنانا۔

مرحلہ 1: پیکج انسٹال کریں۔

آفیشل PostgreSQL apt repository کا استعمال کرتے ہوئے Debian یا Ubuntu پر اپنے PostgreSQL بڑے ورژن سے مماثل پیکیج انسٹال کریں۔ PostgreSQL 17 کے لیے:

sudo apt-get install postgresql-17-cron

پی جی ڈی جی یم ریپوزٹری کا استعمال کرتے ہوئے ریڈ ہیٹ پر مبنی نظام:

sudo yum install pg_cron_17

اگر آپ PostgreSQL 16 یا 18 استعمال کر رہے ہیں تو اس کے مطابق ورژن نمبر تبدیل کریں۔ اگر آپ کے پلیٹ فارم میں کوئی پیکیج نہیں ہے، تو آپ ماخذ سے ایکسٹینشن بھی بنا سکتے ہیں۔

مرحلہ 2: postgresql.conf کو اپ ڈیٹ کریں۔

pg_cron کو پہلے سے لوڈ کرنے کی ضرورت ہے کیونکہ PostgreSQL بوٹ ہونے پر اسے بیک گراؤنڈ ورکر شروع کرنے کی ضرورت ہے۔ اسے اگلی بار شامل کریں۔ shared_preload_libraries آپ کا postgresql.conf:

shared_preload_libraries="pg_cron"

اگر آپ کی سیٹنگز میں پہلے سے ہی کوئی اور لائبریری درج ہے تو pg_cron کو کوما سے الگ کی گئی فہرست میں تبدیل کرنے کے بجائے شامل کریں۔

پہلے سے طے شدہ طور پر، شیڈولر اپنا میٹا ڈیٹا اسٹور کرتا ہے۔ postgres. اگر آپ کی درخواست کسی دوسرے ڈیٹا بیس میں ہے اور آپ وہاں آپریشن کرنا چاہتے ہیں، تو درج ذیل سیٹ کریں:

cron.database_name="app_db"

ایک اور ترتیب جس سے آگاہ ہونا ضروری ہے: pg_cron تمام نظام الاوقات کو بطور ڈیفالٹ GMT کی تشریح کرتا ہے۔ اگر آپ چاہتے ہیں کہ "3am کلین اپ" اصل میں مقامی وقت کے مطابق صبح 3 بجے چلے، تو ٹائم زون کو واضح طور پر سیٹ کریں۔

cron.timezone="Africa/Lagos"

آپ کو ان ترتیبات کے مؤثر ہونے کے لیے سرور کو دوبارہ شروع کرنا ہوگا۔

sudo systemctl restart postgresql

مرحلہ 3: ایک توسیع بنائیں

اپنے کنفیگر کردہ ڈیٹا بیس سے جڑیں۔ cron.database_name ایکسٹینشن کو بطور سپر یوزر بنائیں۔

CREATE EXTENSION pg_cron;

یہ ہے cron سکیما، میٹا ڈیٹا ٹیبلز، اور شیڈولنگ فنکشنز۔ آپ اپنا کام شیڈول کرنے کے لیے تیار ہیں۔

pg_cron ہے نصب فی PostgreSQL مثال کے طور پر ایک ڈیٹا بیس ہے۔ یہ پابندی لگتی ہے، لیکن ایسا نہیں ہے۔ آپ اپنی مثال کے طور پر تمام ڈیٹا بیس پر ملازمتیں چلانا جاری رکھ سکتے ہیں: cron.schedule_in_database()ہم بعد میں اس کا احاطہ کریں گے۔

کاموں کو لنک کرنے کے طریقے پر نوٹس

کیونکہ pg_cron بطور ڈیفالٹ ایک مقامی کنکشن کھولتا ہے۔ pg_hba.conf ہمیں انہیں اجازت دینی چاہیے۔ عام نقطہ نظر مندرجہ ذیل ہے: trust کام کرنے والے صارف کے لوکل ہوسٹ کنکشن کے لیے تصدیق یا پاس ورڈ۔ .pgpass فائل

کنکشن کی توثیق سے مکمل طور پر بچنے کے لیے، pg_cron کو اس کے بجائے بیک گراؤنڈ ورکر استعمال کرنے کو کہیں۔

cron.use_background_workers = on
max_worker_processes = 20

بیک گراؤنڈ ورکر کا استعمال ان کاموں کی تعداد کو محدود کرتا ہے جو بیک وقت چل سکتے ہیں: max_worker_processesلہذا، اگر آپ بہت سارے اوور لیپنگ کاموں کو شیڈول کرتے ہیں، تو اس قدر میں اضافہ کریں۔

منظم ڈیٹا بیس خدمات کے ساتھ pg_cron کا استعمال

اگر آپ ایک منظم سروس استعمال کر رہے ہیں، تو آپ عام طور پر اس میں ترمیم نہیں کر سکتے۔ postgresql.conf اگرچہ براہ راست فراہم کیا جاتا ہے، فراہم کنندگان اپنے میکانزم کے ذریعے انہی ترتیبات کو ظاہر کرتے ہیں۔

• Amazon RDS اور Aurora PostgreSQL: شامل کریں۔ pg_cron کو shared_preload_libraries ڈی بی پیرامیٹر گروپ میں پیرامیٹرز کو حذف کریں، مثال کو دوبارہ شروع کریں، اور درج ذیل کو چلائیں: CREATE EXTENSION pg_cron; بطور صارف rds_superuser. شیڈولر اس پر چلتا ہے: postgres ڈیٹا بیس

• PostgreSQL کے لیے Azure ڈیٹا بیس: pg_cron کو سرور پیرامیٹرز میں فعال کریں (shared_preload_libraries اور azure.extensions)، دوبارہ شروع کریں، اور پھر ایکسٹینشن بنائیں۔

• گوگل کلاؤڈ ایس کیو ایل: ترتیب دینا cloudsql.enable_pg_cron اسے جھنڈا لگائیں، اسے دوبارہ شروع کریں، اور ایکسٹینشن بنائیں۔

• سوپا بیس: ڈیٹا بیس → ایکسٹینشنز کے تحت ڈیش بورڈ میں ایک ٹوگل کے ساتھ pg_cron ایکسٹینشن کو فعال کریں۔

• نیین:pg_cron ایک سپورٹ ایکسٹینشن کے طور پر دستیاب ہے جسے فی پروجیکٹ کی بنیاد پر فعال کیا جا سکتا ہے۔

اس کے بعد آپ جو SQL لکھیں گے وہ ہر جگہ ایک جیسا ہوگا، اور یہ اپیل کا حصہ ہے۔

کرون نحو کا ایک فوری جائزہ

pg_cron کلاسک یونکس کرون کی طرح پانچ فیلڈ شیڈول فارمیٹ استعمال کرتا ہے۔

┌──────────── minute (0–59)
│ ┌────────── hour (0–23)
│ │ ┌──────── day of month (1–31, or $ for the last day)
│ │ │ ┌────── month (1–12)
│ │ │ │ ┌──── day of week (0–6, Sunday = 0)
│ │ │ │ │
* * * * *

نجمہ کا مطلب ہے "کوئی قدر"۔ آپ کوما کے ساتھ اقدار، ہائفن کے ساتھ رینجز، اور سلیش کے ساتھ قدموں میں شامل ہو سکتے ہیں۔ یہاں کچھ شیڈولز ہیں جو آپ مسلسل استعمال کریں گے:

*/5 * * * *    every 5 minutes
0 * * * *      every hour, on the hour
0 3 * * *      every day at 3:00 AM
0 3 * * 1-5    3:00 AM on weekdays
30 1 * * 0     1:30 AM every Sunday
0 0 1 * *      midnight on the 1st of each month

pg_cron معیاری نحو میں دو ایکسٹینشنز بھی شامل کرتا ہے جو کہ ریگولر کرون میں نہیں ہوتا ہے۔

آپ استعمال کر سکتے ہیں $ تاریخ کے شعبوں میں، اس کا مطلب مہینے کا آخری دن ہے۔ معیاری کرون میں اس کا اظہار کرنا واقعی مشکل ہے۔

0 23 $ * *     11:00 PM on the last day of every month

جن کاموں کو فی منٹ میں ایک سے زیادہ بار چلانے کی ضرورت ہے، آپ 1 سے 59 سیکنڈ کے درمیان باقاعدہ وقفہ استعمال کر سکتے ہیں۔

'30 seconds'   every 30 seconds

سیکنڈ کا نحو اکیلا کھڑا ہے اور اسے پانچ فیلڈ فارمیٹ کے ساتھ نہیں ملایا جا سکتا۔

اگر آپ کو اس بارے میں شک ہے کہ شیڈول کا کیا مطلب ہے، crontab.guru سادہ انگریزی میں cron کے تاثرات کا ترجمہ کرتا ہے۔ یاد رکھیں کہ pg_cron آپ کے مقرر کردہ ٹائم زون کی بنیاد پر نظام الاوقات کا جائزہ لیتا ہے۔ cron.timezoneپہلے سے طے شدہ GMT ہے۔

اپنے پہلے کام کا شیڈول کیسے بنائیں

بنیادی خصوصیات یہ ہیں۔ cron.schedule(). یہ دو شکلوں میں آتا ہے: نام اور بے نام۔

آپ کو ایک نامزد فارمیٹ استعمال کرنا چاہیے۔ اس کی وجہ یہ ہے کہ ناموں سے کاموں کو تلاش کرنا، اپ ڈیٹ کرنا اور ہٹانا آسان ہو جاتا ہے۔

SELECT cron.schedule(
  'delete-expired-sessions',                          -- job name
  '0 3 * * *',                                        -- schedule
  $$DELETE FROM sessions WHERE expires_at < now()$$   -- command
);

یہ فنکشن ٹاسک ID واپس کرتا ہے۔

 schedule
----------
        1
(1 row)

کچھ قابل ذکر تفصیلات میں شامل ہیں:

حکم لپیٹ دیا گیا ہے۔ $$ ... $$PostgreSQL میں ڈالر کی قیمت۔ یہ ایس کیو ایل کے اندر واحد کوٹس سے بچنے سے بچتا ہے۔ غیر نقل شدہ کمانڈز کے لیے، سادہ سٹرنگ لٹریلز ٹھیک کام کرتے ہیں۔

کام کالنگ ڈیٹا بیس پر چلتا ہے۔ cron.schedule()جیسا کہ صارف اس صارف کے عام مراعات کا استعمال کرتے ہوئے کال کرتا ہے۔ استحقاق کی بلندی شیڈولر میں پوشیدہ نہیں ہے۔ جب صارفین حذف نہیں کرسکتے ہیں۔ sessionsنوکریوں کا بھی یہی حال ہے۔

اور جب آپ کال کریں گے۔ cron.schedule() ایک بار پھر اسی کام کے نام کے ساتھ، pg_cron ایک ڈپلیکیٹ بنانے کے بجائے موجودہ کام کو اپ ڈیٹ کر دے گا۔ یہ ایک ڈیٹابیس کی منتقلی کے اندر کاموں کی وضاحت کرنے کے لیے مفید ہے تاکہ شیڈول کو غیرمعمولی بنایا جا سکے۔

عملی pg_cron مثال

آئیے ایک ایسا نمونہ دیکھتے ہیں جو حقیقی دنیا کے زیادہ تر استعمالات کا احاطہ کرتا ہے۔ ہر مثال کو براہ راست لاگو کیا جا سکتا ہے.

مثال 1: ہر رات پرانی قطاروں کو صاف کریں۔

میزیں جو عارضی ڈیٹا اکٹھا کرتی ہیں، جیسے سیشنز، ٹوکنز، آڈٹ ایونٹس، اور نوٹیفکیشن لاگز، ہمیشہ کے لیے بڑھیں گے جب تک کہ انہیں صاف نہیں کیا جاتا۔ نائٹ ڈیلیٹ ایک کلاسک پہلا pg_cron کام ہے۔

SELECT cron.schedule(
  'purge-old-events',
  '0 2 * * *',
  $$DELETE FROM events WHERE created_at < now() - interval '90 days'$$
);

ہر رات 2 بجے، 90 دن سے زیادہ پرانی قطاریں ہٹا دی جاتی ہیں۔ اگر آپ کا ٹیبل بڑا ہے تو، بیچ ہر عمل کے وقت کو مختصر رکھنے کے لیے فنکشن کے اندر حذف ہوجاتا ہے، پھر اس کے بجائے فنکشن کو شیڈول کریں۔

مثال 2: ہر گھنٹے ایک مادی منظر کو تازہ کرنا

مادی خیالات مہنگے مجموعوں کو کیش کرنے کا ایک اچھا طریقہ ہیں، لیکن PostgreSQL انہیں خود سے تازہ نہیں کرتا ہے۔ pg_cron اصلاحات:

SELECT cron.schedule(
  'refresh-daily-sales',
  '5 * * * *',
  'REFRESH MATERIALIZED VIEW CONCURRENTLY daily_sales_summary'
);

یہ ہر گھنٹے یا پانچ منٹ پر منظر کو تازہ کر دے گا۔ کہ CONCURRENTLY آپشن ریفریش کے دوران پڑھنے کو جاری رکھنے کی اجازت دیتا ہے جب تک کہ منظر میں منفرد انڈیکس ہو۔

مثال 3: روزانہ خلاصہ ٹیبل بنانا

رول اپ میزیں ایک اور عام نمونہ ہیں۔ ہر ڈیش بورڈ لوڈ پر لاکھوں خام قطاروں کو جمع کرنے کے بجائے، ہم دن میں ایک بار نمبروں کی پہلے سے گنتی کرتے ہیں۔

SELECT cron.schedule(
  'rollup-daily-orders',
  '15 0 * * *',
  $$
  INSERT INTO daily_order_stats (day, order_count, total_amount)
  SELECT created_at::date, count(*), sum(amount)
  FROM orders
  WHERE created_at >= current_date - 1
    AND created_at < current_date
  GROUP BY created_at::date
  ON CONFLICT (day) DO UPDATE
    SET order_count = EXCLUDED.order_count,
        total_amount = EXCLUDED.total_amount
  $$
);

آدھی رات کے 15 منٹ بعد، کل کے آرڈرز کا خلاصہ ایک قطار میں کیا جاتا ہے۔ کہ ON CONFLICT شق آپ کو آپریشن کو محفوظ طریقے سے دوبارہ چلانے کی اجازت دیتی ہے۔ اگر دو بار چلایا جاتا ہے، تو یہ نقل کرنے کے بجائے اوور رائٹ ہو جائے گا۔

مثال 4: ہر 30 سیکنڈ میں ایک کام چلائیں۔

کچھ کاموں کو کرون کی ایک منٹ کی لمبائی سے زیادہ کثرت سے ہونے کی ضرورت ہے۔ یعنی بفر ٹیبل کو فلش کرنا، آؤٹ باکس سے قطاروں کا انتخاب کرنا، ہلکی پھلکی قطاروں کو آگے بڑھانا وغیرہ۔ دوسرا نحو اس کا خیال رکھتا ہے۔

SELECT cron.schedule(
  'process-outbox',
  '30 seconds',
  'CALL process_outbox_batch()'
);

ہماری پچھلی ضمانتیں یاد رکھیں۔ pg_cron اس کام کی دوسری مثال شروع نہیں کرے گا جب کہ پہلی نوکری چل رہی ہے۔ اگر کسی بیچ میں بعض اوقات 45 سیکنڈ لگتے ہیں تو اگلی رن اس پر مہر لگانے کے بجائے اپنی باری کا انتظار کرے گی۔

مثال 5: ہر مہینے کے آخری دن مینٹیننس چلانا

معیاری کرون میں، مہینے کے آخر کے آپریشنز عجیب ہوتے ہیں کیونکہ مہینوں کی لمبائی مختلف ہوتی ہے۔ pg_cron $ اسے معمولی بناتا ہے:

SELECT cron.schedule(
  'month-end-vacuum',
  '0 23 $ * *',
  'VACUUM ANALYZE orders'
);

یہ چلتا ہے۔ VACUUM ANALYZE کو orders براہ کرم مہینے کے آخری دن رات 11 بجے اپنی میز پر بیٹھیں: 28، 29، 30 یا 31 تاریخ۔

کاموں کو دیکھنے اور مانیٹر کرنے کا طریقہ

pg_cron جو کچھ بھی جانتا ہے وہ ان دو جدولوں میں ہے: cron اسکیما کا استعمال کریں اور کسی دوسرے ٹیبل کی طرح اس سے استفسار کریں۔

آنے والے واقعات دیکھنے کے لیے، چیک کریں: cron.job:

SELECT jobid, jobname, schedule, command, active
FROM cron.job;

 jobid |         jobname         |  schedule  |            command             | active
-------+-------------------------+------------+--------------------------------+--------
     1 | delete-expired-sessions | 0 3 * * *  | DELETE FROM sessions WHERE ... | t
     2 | refresh-daily-sales     | 5 * * * *  | REFRESH MATERIALIZED VIEW ...  | t
(2 rows)

یہ دیکھنے کے لیے کہ کام اصل میں کیسے چلتا ہے، استفسار کریں: cron.job_run_details:

SELECT jobid, status, return_message, start_time, end_time
FROM cron.job_run_details
ORDER BY start_time DESC
LIMIT 10;

ہر قطار ایک عمل کو ریکارڈ کرتی ہے، جس میں یہ شامل ہے کہ آیا یہ کامیاب رہا یا نہیں، پیغام واپس آیا، اور اس کے شروع اور ختم ہونے کے عین اوقات۔ ناکام کام دکھائے جاتے ہیں۔ status="failed" ڈیبگنگ اکثر غلطی کے پیغام کے ساتھ شروع اور ختم ہوتی ہے۔

ایک اہم نکتہ یہ ہے: pg_cron خود اس ٹیبل کو صاف نہیں کرتا ہے۔. ایک کام جو ہر 30 سیکنڈ میں چلتا ہے وہ روزانہ تقریباً 3000 قطاریں لکھتی ہے۔ معیاری فکس خوشگوار طور پر تکرار کرنے والا ہے۔ pg_cron کی اپنی تاریخ کو صاف کرنے کے لیے ایک pg_cron کام کا شیڈول بنائیں۔

SELECT cron.schedule(
  'purge-cron-history',
  '0 12 * * *',
  $$DELETE FROM cron.job_run_details
    WHERE end_time < now() - interval '14 days'$$
);

اگر آپ پھانسی کی تاریخ کو بالکل بھی لاگ ان نہیں کرنا چاہتے ہیں، تو سیٹ کریں: cron.log_run = off آپ کی ترتیب میں

کاموں کو اپ ڈیٹ اور ہٹانے کا طریقہ

موجودہ کام کو تبدیل کرنے کے لیے، استعمال کریں: cron.alter_job() صرف وہ پیرامیٹرز جو آپ ٹاسک آئی ڈی کے طور پر پاس کرتے ہیں بدل جائیں گے۔ باقی سب وہی رہے گا.

-- Move job 1 from 3 AM to 4 AM
SELECT cron.alter_job(1, schedule := '0 4 * * *');

-- Pause a job without deleting it
SELECT cron.alter_job(1, active := false);

-- Resume it later
SELECT cron.alter_job(1, active := true);

توقف active := false انڈر ریٹیڈ آپ شور مچانے والے کاموں کو بند کر سکتے ہیں اور کسی واقعے یا بڑے پیمانے پر منتقلی کے دوران تعریف کو کھوئے بغیر انہیں بعد میں واپس کر سکتے ہیں۔

کسی کام کو مستقل طور پر ہٹانے کے لیے، استعمال کریں: cron.unschedule() نام یا شناخت سے:

SELECT cron.unschedule('delete-expired-sessions');
-- or
SELECT cron.unschedule(1);

دونوں واپس آتے ہیں true جب کوئی کام دریافت اور ہٹا دیا جاتا ہے۔

مختلف ڈیٹا بیس پر ملازمتیں کیسے چلائیں۔

یاد رکھیں کہ pg_cron فی مثال کے طور پر ایک ڈیٹا بیس پر انسٹال ہوتا ہے۔ postgres. اگر آپ کی مثال متعدد ڈیٹا بیس کی میزبانی کرتی ہے تو ہر ڈیٹا بیس پر pg_cron انسٹال نہ کریں۔ cron.schedule_in_database():

SELECT cron.schedule_in_database(
  'analytics-nightly-vacuum',
  '0 4 * * *',
  'VACUUM ANALYZE page_views',
  'analytics_db'
);

کام مرکزی طور پر محفوظ کیے جاتے ہیں لیکن اندرونی طور پر چلتے ہیں۔ analytics_db. یہ فنکشن اختیاری صارف نام کو بھی قبول کرتا ہے اگر کام کو ایک مختلف صارف کے طور پر چلنا چاہیے۔ active روکا ہوا جھنڈا بنانے کے لیے ایک جھنڈا متعین کریں۔

یہ پیٹرن تمام شیڈولز کو ایک ڈیٹا بیس میں ایک اسکیما میں رکھ کر آڈیٹنگ کو آسان بناتا ہے۔ SELECT * FROM cron.job تمام واقعات میں تمام طے شدہ کام دکھاتا ہے۔

دوسرے لوگوں کو کاموں کا شیڈول کیسے کرنے دیں۔

پہلے سے طے شدہ طور پر، صرف سپر یوزر ہی شیڈولنگ فنکشنز کو کال کر سکتے ہیں۔ درخواست کے کرداروں کو ان کے اپنے کاموں کا انتظام کرنے کی اجازت دینا cron خاکہ:

GRANT USAGE ON SCHEMA cron TO app_user;

بعد میں اجازت کا ماڈل معقول اور محفوظ ہے۔

• ٹاسک اس صارف کی اجازت کے ساتھ چلتا ہے جس نے ٹاسک کو شیڈول کیا تھا۔

• قطار کی سطح کی سیکیورٹی پالیسی cron.job اس کا مطلب ہے کہ صارفین صرف اپنے کام کو دیکھتے اور اس میں ترمیم کرتے ہیں۔ سپر یوزر سب کچھ دیکھتے ہیں۔

• ہر صارف اپنی قطاریں یہاں سے حذف بھی کر سکتا ہے: cron.job_run_detailsلہذا، پچھلے صفائی کے آپریشن سپر یوزر کے استحقاق کے بغیر کام کرتے ہیں۔

عملی طور پر، ذاتی اکاؤنٹس کے ساتھ کاموں کو شیڈول کرنے کے بجائے طے شدہ کاموں کے لیے ایک سرشار کردار بنانا بہتر ہے۔ اگر انجینئر جس نے تمام نظام الاوقات کی منصوبہ بندی کی تھی وہ چھوڑ دیتا ہے اور اس کردار کو حذف کر دیا جاتا ہے، آپ نہیں چاہتے کہ رات کے وقت کے رول اپ اس کے ساتھ چلیں۔

pg_cron کب استعمال کریں (اور کب اس سے بچیں)

pg_cron چمکتا ہے جب یہ اپنا کام کرتا ہے۔ ڈیٹا بیس آپریشنز. اس کے لیے استعمال کریں:

• ڈیٹا برقرار رکھنے: سیشن، لاگ، ایونٹ، اور ٹوکن ٹیبلز میں پرانی قطاروں کو صاف کریں۔

• تعداد: ایک مادی منظر کو تازہ کرتا ہے اور ایک رول اپ ٹیبل بناتا ہے۔

• برقرار رکھنا: ہدف VACUUM ANALYZEاعدادوشمار کی تعمیر نو، تقسیم کا انتظام (پی جی_پارٹمین کے ساتھ خوبصورتی سے جوڑا)۔

• ہلکا پھلکا پائپ لائن: میزوں کے درمیان قطاریں منتقل کرنا، آؤٹ باکس پیٹرن کو سنبھالنا، نرم حذف شدہ ریکارڈز کی میعاد ختم ہو رہی ہے۔

کامن تھریڈ: پورے آپریشن کا اظہار ایس کیو ایل یا ذخیرہ شدہ طریقہ کار میں کیا جا سکتا ہے اور ڈیٹا بیس سے باہر کسی چیز کو نہیں چھوتا ہے۔

اگر:

• کام کو ایک بیرونی نظام کو کال کرنا چاہیے۔ pg_cron SQL چلاتا ہے۔ یہ HTTP درخواستیں نہیں بھیج سکتا، قطاروں میں نہیں لگا سکتا، یا خود ای میل نہیں بھیج سکتا۔ ان کاموں کا تعلق ایپلیکیشن یا ورک فلو انجن سے ہے۔

• اس میں بلٹ ان دوبارہ کوشش، بیک آف اور اطلاع کی خصوصیات ہونی چاہئیں۔ pg_cron ناکامی کو لاگ کرتا ہے لیکن دوبارہ کوشش نہیں کرتا ہے اور نہ ہی صفحہ کو کال کرتا ہے۔ ایسے ورک فلو کے لیے جنہیں مکمل کرنے کی ضرورت ہے، ٹولز جیسے ایڈہاک یا مناسب ٹاسک کیو پیچیدہ ہو جاتے ہیں۔

• کام بھاری ہے اور کافی وقت لگتا ہے۔ بنیادی OLTP ڈیٹا بیس کے اندر چلنے والی چار گھنٹے کی بیچ کی ملازمتیں CPU، میموری اور تالے کے لیے ایپلی کیشنز کے ساتھ مقابلہ کرتی ہیں۔ اپنے بڑے پیمانے پر حساب کتاب کہیں اور محفوظ کریں۔

• کام پیچیدہ انحصار کی ضرورت ہے. "A کے کامیاب ہونے کے بعد ہی B کو چلائیں، پھر C اور D کو فین آؤٹ کریں" آرکیسٹریشن ہے۔ یہ ایئر فلو ایریا ہے، کرون ایریا نہیں۔

انگوٹھے کا ایک معقول اصول: pg_cron اسے چلانے کے لیے استعمال ہونے والی کرونٹاب اندراج کی جگہ لے لیتا ہے۔ psql -c "..." بھولے ہوئے سرور پر۔ یہ کام کی قطاروں یا ورک فلو آرکیسٹریٹرز کو تبدیل نہیں کرتا ہے۔

pg_cron کاموں کے لیے بہترین طریقے

لفظ کے بہترین معنی میں، یہاں کچھ عادات ہیں جو طے شدہ کام کو بورنگ بناتی ہیں:

تمام پیشوں کے نام بتائیں۔ صرف ID کے ذریعے شناخت شدہ گمنام ملازمتوں کا انتظام 6 ماہ کے بعد مشکل ہے۔ ایک نام بنائیں cron.schedule() Idempotency: ہجرت کے دوران کاموں کو محفوظ طریقے سے بیان کیا جا سکتا ہے۔

اپنا ٹائم زون جان بوجھ کر سیٹ کریں۔ پہلے سے طے شدہ GMT ہے اور سوال "3am کا کام صبح 4 بجے کیوں چلتا ہے؟" یہ گزرنے کی ایک رسم ہے جسے آپ ترتیبات پر جا سکتے ہیں۔ cron.timezone پہلی رات

انفرادی رنز مختصر رکھیں۔ بیچ ذخیرہ شدہ طریقہ کار میں بڑے ڈیلیٹس کو لپیٹیں۔ چند سیکنڈ میں مکمل ہونے والے آپریشنز تالے کو مختصر طور پر روکیں گے اور تاخیر کم ہو جائے گی۔

آپریشنوں کو بے اختیار بناتا ہے۔ سرور دوبارہ شروع ہو سکتا ہے اور آپریشن وقت سے پہلے ناکام ہو سکتا ہے۔ استعمال کریں ON CONFLICTوقت کی حد کی پیشین گوئیاں اور دوسرے نمونے جو دوبارہ کرنے کو بے ضرر بناتے ہیں۔

مارو cron.job_run_details: مانیٹرنگ سیکشن میں صفائی کے کاموں کو شیڈول کریں اس سے پہلے کہ آپ کی میزیں نمایاں طور پر بڑی ہو جائیں۔

خاموشی کی نگرانی کریں، نہ صرف ناکامی۔ ناکام پھانسیاں آگے ظاہر ہوتی ہیں: job_run_detailsتاہم، مکمل طور پر غیر طے شدہ کاموں کا کوئی نشان باقی نہیں رہتا۔ باقاعدگی سے جانچنا کہ آیا ہر اہم کام حال ہی میں کامیابی سے چلا ہے دونوں صورتوں کو پکڑ لے گا۔

SELECT j.jobname, max(d.end_time) AS last_success
FROM cron.job j
LEFT JOIN cron.job_run_details d
  ON d.jobid = j.jobid AND d.status="succeeded"
GROUP BY j.jobname
HAVING max(d.end_time) < now() - interval '1 day'
   OR max(d.end_time) IS NULL;

اس استفسار کی واپسی کے تمام آپریشنز ایک دن سے زیادہ عرصے سے ناکام رہے ہیں، لہذا اس پر ایک نظر ڈالنے کے قابل ہے۔

نتیجہ

pg_cron PostgreSQL کو اپنے شیڈولر میں بدل دیتا ہے۔ آپ ایس کیو ایل میں آپریشن کی وضاحت کرتے ہیں، ڈیٹا بیس اس آپریشن کو انجام دیتا ہے، اور پورا سسٹم (تعریف، تاریخ، غلطیاں) باقاعدہ سوالات کے ذریعے ظاہر ہوتا ہے۔

اس ٹیوٹوریل میں، آپ نے سیکھا کہ ایکسٹینشن اندرونی طور پر کیسے کام کرتی ہے، ایکسٹینشن کو اپنے سرورز اور انتظامی خدمات پر کیسے انسٹال کرنا ہے، نظام الاوقات کیسے بنانا ہے (بشمول pg_cron میں مہینے کے شروع اور آخر کی ایکسٹینشن)، اور ایکسٹینشن کو بحالی کے کاموں میں کیسے لاگو کیا جائے (کاٹنا، رول اپ، ریفریش، اور ویکیوموباسلیٹنگ کے تمام کاموں پر)۔ ہم نے یہ بھی دیکھا کہ کاموں کی نگرانی کیسے کی جائے، اجازتوں کا انتظام کیا جائے، اور یہ پہچانا جائے کہ فزیکل ٹاسک کیو یا آرکیسٹریٹر کہاں بہتر ٹول ہوگا۔

اگر آپ کے بنیادی ڈھانچے میں فی الحال تنہا سرور ہیں جن کا واحد مقصد چلانا ہے۔ psql اب آپ جانتے ہیں کہ اسے کرونٹاب میں کیسے ٹھکانے لگایا جائے۔

پڑھنے کے لیے شکریہ! میں PostgreSQL اور بیک اینڈ انجینئرنگ کے بارے میں لکھتا ہوں۔ آپ مجھ سے LinkedIn پر رابطہ کر سکتے ہیں اور