فهارس PostgreSQL المتزامنة: الانتظار واستعادة البناء الفاشل

لنتصور محاولةً افتراضية لإعادة تنفيذ ترحيل تُبلغ عن وجود علاقة بالاسم نفسه. يتابع الترحيل عمله، لكن أحدًا لم يتحقق من قابلية استخدام الفهرس. قد يترك PostgreSQL فهرسًا غير صالح بعد فشل إنشائه بالتزامن؛ ولا تتحقق IF NOT EXISTS من التعريف الموجود. تشرح وثائق الأمر كلا السلوكين.

ابدأ بالعملية الخلفية. هل ما زالت تبني الفهرس، أم تنتظر؟ تأكد من انتهاء البناء قبل النظر في الاستعادة. ثم قارن الفهرس الفعلي بالترحيل المقصود. فإشعار وجود الاسم لا يكفي للتحقق من الاكتمال.

يغطي هذا الدليل جداول التطبيقات العادية غير المقسّمة. روجعت قوالب SQL بالرجوع إلى المصادر، لكنها لم تُنفّذ. عدّل الأسماء الافتراضية مثل public.orders وتحقق من قاعدة البيانات والصلاحيات المطلوبة. ارجع إلى وثائق الإصدار الرئيسي المنشور لديك، وجرّب التغييرات في بيئة معزولة.

ما الذي يغيّره CREATE INDEX CONCURRENTLY وما الذي يبقى كما هو

السماح بالكتابة لا يعني غياب الأقفال أو الانتظار

يمنع CREATE INDEX العادي الكتابة إلى الجدول مع السماح بالقراءات العادية. ويسمح CREATE INDEX CONCURRENTLY بالكتابات العادية أثناء البناء، لكنه يظل بحاجة إلى التنسيق والانتظار. لا يمكن تشغيل أكثر من عملية بناء متزامن واحدة على جدول معين في الوقت نفسه. ويجب تشغيله خارج كتلة معاملة. يوثّق PostgreSQL هذه القيود.

عمليتا مسح وانتظار المعاملات والانتقال إلى الصلاحية

يسجّل الإنشاء المتزامن مُدخلًا غير صالح في كتالوج النظام قبل إجراء عمليتي مسح للجدول في معاملتين منفصلتين. وينتظر معاملات التعديل ذات الصلة قبل المسح، واللقطات الأقدم بعد المسح الثاني. قد ينتمي هذا المُدخل غير الصالح إلى عملية بناء سليمة. اتركه دون تغيير حتى تتأكد من خلاف ذلك. كما تعني عمليات المسح الإضافية والانتظار أن الإنشاء المتزامن قد يستغرق وقتًا أطول. راجع تسلسل البناء.

تشخيص انتظار بناء فهارس PostgreSQL بحسب المرحلة والعملية الخلفية

اقرأ pg_stat_progress_create_index قبل تقدير التقدم

اتصل بقاعدة البيانات المستهدفة. يرشّح هذا القالب المخصّص للقراءة فقط النتائج بحسب الجدول، مع الاحتفاظ بالمعرّفات الخام وتحويل المعرّفات الصفرية غير المتاحة إلى null:

SELECT p.pid, p.command, p.phase, p.relid,
       NULLIF(p.index_relid, 0) AS index_relid,
       p.lockers_total, p.lockers_done,
       NULLIF(p.current_locker_pid, 0) AS current_locker_pid,
       p.blocks_total, p.blocks_done
FROM pg_stat_progress_create_index AS p
WHERE p.datname = current_database()
  AND p.relid = to_regclass('public.orders');

إذا كان الهدف غير موجود، تُرجع الدالة null ولا تنتج أي مطابقة. تحقق من المعرّف قبل تفسير نتيجة فارغة. راجع وثائق to_regclass.

فسّر العدّادات ضمن المرحلة المُبلّغ عنها. تميّز تعريفات التقدم في PostgreSQL بين الأعمال التالية.

في صف التحقق أعلاه، تسبق كلًا من "sorting tuples" و"scanning table" أيضًا بادئة المرحلة الكاملة "index validation:". وقد تُبلغ إعادة الفهرسة المتزامنة عن "waiting for readers before marking dead" و"waiting for readers before dropping"؛ ويصف مرجع التقدم نفسه حالات الانتظار هذه.

تصف إجماليات الكتل المرحلة الحالية. ولا تثبت مقدار التقدم من البداية إلى النهاية، ولا يمكن الاستناد إلى إجماليات صفرية أو غير متاحة لتقدير نسبة مئوية.

اربط العملية الخلفية المنتظرة بأدلة المعاملات والأقفال

افحص العمليات الخلفية للبناء إلى جانب حاملي الأقفال الحاليين المُبلّغ عنهم باستخدام هذا القالب المنفصل المخصّص للقراءة فقط.

WITH progress AS (
  SELECT pid, current_locker_pid
  FROM pg_stat_progress_create_index
  WHERE datname = current_database()
    AND relid = to_regclass('public.orders')
), participants AS (
  SELECT pid FROM progress
  UNION
  SELECT current_locker_pid FROM progress
  WHERE current_locker_pid > 0
)
SELECT a.pid, a.state, a.xact_start, a.backend_xmin,
       a.wait_event_type, a.wait_event,
       pg_blocking_pids(a.pid) AS lock_blocking_pids
FROM pg_stat_activity AS a
JOIN participants AS t ON t.pid = a.pid;

تُبلغ pg_blocking_pids عن العمليات الحاجبة بسبب الأقفال، لكنها لا تفسّر كل تأخير مرتبط باللقطات. ولا تستبعد مصفوفة فارغة وجود انتظار. وبالمثل، فإن قِدم xact_start أو backend_xmin يستدعي الفحص؛ ولا يحدد جلسةً ينبغي إنهاؤها. نسّق مع مالك المعاملة. يشمل هذا الاستعلام العملية الخلفية للبناء وحامل القفل الحالي المُبلّغ عنه، ولا يشمل شجرةً تكرارية للعمليات الحاجبة. تتبّع معرّفات العمليات الحاجبة المُرجعة كلًا على حدة. قد تُرجع الدالة صفرًا عندما تكون الجهة الحاجبة معاملةً مُحضّرة؛ ولا يشير الصفر إلى عملية خلفية ينبغي إنهاؤها. راجع مرجع الدالة نفسه.

للمقارنة خارج PostgreSQL، يتناول دليل Optijara لرصد عمليات البناء في TensorRT كيفية التمييز بين العمل طويل المدة والفشل.

فسّر الصفوف الغائبة والرؤية الجزئية بحذر

غياب صف التقدم لا يحسم شيئًا. تحقق من معرّف العملية الخلفية المحفوظ ونتيجة العميل، ثم اربط أخطاء الخادم بحالة الكتالوج. تأكد من اختيار قاعدة البيانات وصلاحيات دور المراقبة. فقد تكون تفاصيل الجلسات الأخرى محجوبة. وقد تجعل معاملات المراقبة الطويلة الملاحظات قديمةً أيضًا؛ فأعدها خارج تلك المعاملة. تشرح وثائق مراقبة النشاط كلا القيدين.

افحص الفهارس غير الصالحة قبل إعادة المحاولة باستخدام IF NOT EXISTS

تحقق من indisvalid وindisready وindislive والتعريف الفعلي

افحص الفهرس المحدد بالاسم والجدول الذي ينتمي إليه فعليًا. لا يستطيع سجل الترحيلات إثبات أي منهما. تتبع عمليات الربط أدناه ما هو موثّق في كتالوج العلاقات وكتالوج مساحات الأسماء.

SELECT ns.nspname AS index_schema, ix.relname AS index_name,
       tn.nspname AS table_schema, t.relname AS table_name,
       i.indisunique, i.indisvalid, i.indisready, i.indislive,
       pg_get_indexdef(i.indexrelid) AS definition
FROM pg_index AS i
JOIN pg_class AS ix ON ix.oid = i.indexrelid
JOIN pg_namespace AS ns ON ns.oid = ix.relnamespace
JOIN pg_class AS t ON t.oid = i.indrelid
JOIN pg_namespace AS tn ON tn.oid = t.relnamespace
WHERE ns.nspname = 'public'
  AND ix.relname = 'orders_customer_id_idx';

قارن التعريف بالترحيل المعتمد، بما يشمل التفرّد وطريقة الوصول. تحقق من ترتيب المفاتيح والتعبيرات والأعمدة المضمّنة وشرط الفهرس. تعيد pg_get_indexdef بناء هذا التعريف.

في pg_index، يصف indisvalid صلاحية الفهرس للاستعلامات. ويتتبّع indisready جاهزيته للتحديث أثناء عمليات الإدراج والتحديث؛ ويسجّل indislive بقاءه قيد الاستخدام. وإذا كانت قيمة علامة البقاء هذه «خطأ»، فهذا يعني أن الفهرس قيد الحذف ويجب تجاهله لجميع الأغراض. وقد يظل الفهرس غير الصالح يضيف عبئًا على الكتابة. ولا تكفي علامة عدم الصلاحية وحدها لتحديد عملية بناء متزامن فاشلة.

يتطلب بناء فهارس التفرّد عنايةً خاصة. يبدأ فرض التفرّد على المعاملات الأخرى مع بدء المسح الثاني للجدول، قبل أن يصبح الفهرس صالحًا. وقد يترك الفشل أثناء ذلك المسح فهرسًا غير صالح يظل يرفض الكتابات المكررة. كذلك لا تثبت علامة عدم الصلاحية أن البيانات الموجودة تستوفي شرط التفرّد. تشرح تنبيهات البناء المتزامن هذا التوقيت.

لماذا لا يعني التكرار الآمن المستند إلى الاسم نجاح الترحيل

تمنع IF NOT EXISTS ظهور خطأ عند وجود علاقة بالاسم نفسه. وهي لا تعيد بناء فهرس غير صالح، ولا تضمن تكافؤ التعريف. تعرض المشكلة رقم 52583 في Rails مأزق انتهاء المهلة وإعادة المحاولة الناتج عن ذلك. ولا يثبت هذا البلاغ العام وجود إصلاح حالي في Rails. ويحدد مرجع الأوامر في PostgreSQL السلوك الأساسي.

دليل الاستعادة PACE: تحديد المرحلة، والتقييم، والاختيار، وإثبات الجاهزية

تحديد المرحلة والتقييم: احفظ الأدلة قبل تغيير الحالة

PACE إطار تحريري يُقدَّم هنا. قبل تغيير الحالة، احفظ الخطأ الأصلي والمرحلة الحالية. واحتفظ بهوية الفهرس وتعريفه، إلى جانب سياق مالك المعاملة.

قبل الحذف، تحقق مما إذا كان أحد القيود يستخدم الفهرس المحدد بالاسم.

SELECT conname, contype, conrelid::regclass AS owning_table
FROM pg_constraint
WHERE conindid = to_regclass('public.orders_customer_id_idx');

يحدد pg_constraint.conindid الفهارس الداعمة للقيود. وتترك النتيجة الفارغة تبعياتٍ أخرى وملكيةً ينبغي فحصها. لا تغني إضافة CASCADE عن تلك المراجعة.

الاختيار: الانتظار أو الحذف وإعادة الإنشاء أو إعادة الفهرسة

اختر المسار استنادًا إلى الحالة المثبتة. تتجاوز حلقة إعادة المحاولة غير المشروطة هذا القرار.

لا تستخدم قالب الحذف وإعادة الإنشاء التالي، الذي لم يُنفّذ، إلا بعد انتهاء البناء الفاشل وسماح فحوص التبعيات بالحذف. ويفترض أن التعريف المعتمد هو بالضبط فهرس B-tree غير فريد على public.orders(customer_id).

DROP INDEX CONCURRENTLY public.orders_customer_id_idx;
CREATE INDEX CONCURRENTLY orders_customer_id_idx
  ON public.orders USING btree (customer_id);

أرسل أوامر مستقلة على المستوى الأعلى خارج كتل المعاملات. إذا فشل الحذف، فتوقف وأعد الفحص. لا يقبل CREATE INDEX اسم فهرس مؤهلًا باسم المخطط؛ فتأهيل public.orders يضع الفهرس في ذلك المخطط. تحقق من القيود المختلفة لكل من الإنشاء والحذف المتزامن.

بالنسبة إلى فهرس غير صالح مؤهل ينبغي الحفاظ على تعريفه، يرد المسار البديل أدناه.

REINDEX INDEX CONCURRENTLY public.orders_customer_id_idx;

عالج السبب أولًا. لا تستطيع إعادة الفهرسة إصلاح البيانات المكررة أو تغيير تعريف غير صحيح، ولا تزيل عبء العمل المسبّب للحجب. حدّد الفهرس صراحةً: فالصيغة على مستوى الفهرس وحدها تستطيع إعادة بناء فهرس غير صالح بالتزامن. لا تستبدل بها إعادة فهرسة متزامنة للجدول بأكمله. تحقق من العملية والاستثناءات.

قد تترك إعادة الفهرسة المتزامنة الفاشلة بديلًا غير صالح يحمل اللاحقة _ccnew، ويحذفه المسار الموثّق قبل إعادة المحاولة. أما _ccold غير الصالح، فقد يكون النسخة القديمة المتبقية بعد نجاح إعادة البناء. وقد تظهر لواحق رقمية. تحقق من الفهرس الصالح المتبقي والتبعيات قبل الموافقة على الحذف. لا تحذف فهارس بالجملة بناءً على اللاحقة أبدًا. يوثّق PostgreSQL مسارات التنظيف المختلفة.

إثبات الجاهزية: تحقق من الشروط النهائية المقصودة

بعد الاستعادة، اشترط نجاح الأمر وأعد استعلام الكتالوج. طابق المخطط والجدول مع التعريف المقصود؛ وأكّد علامات الصلاحية والجاهزية والبقاء قيد الاستخدام. لا تُلزم الصلاحية مخطّط الاستعلامات باختيار الفهرس، وقد تؤخّر المعاملات الأقدم إمكانية استخدامه. ويستكشف دليل Optijara لاتخاذ قرارات مجسّات Kubernetes الفرق الأوسع بين سلامة العملية وجاهزيتها.

احتفظ بسجل للملاحظات بدلًا من وضع حد زمني عام من دون أساس.

هذه قياسات مقترحة، وليست نتائج اختبارات أداء معيارية. يلخّص JSON أدناه الإطار وقاعدة الاكتمال.

{
  "framework": "pace",
  "layers": ["phase", "assess", "choose", "establish_readiness"],
  "completionRequires": ["successful_command", "intended_definition", "valid_ready_live"],
  "automaticDestructiveRetry": false
}

الأخطاء التي تقع فيها الفرق عند إعادة محاولة الترحيلات

اعتبار إشعار نجاح إعادة المحاولة دليلًا على صلاحية الفهرس

يجيب إشعار إعادة المحاولة عن سؤال أضيق مما يحتاج الترحيل إلى حسمه. تحقق من الكتالوج والتعريف كلًا على حدة. أدرج فحص القبول هذا في سير عمل التكامل والتسليم المستمرين بمساعدة الذكاء الاصطناعي، بما في ذلك الترحيلات التي تقترحها الأتمتة.

إعادة المحاولة قبل إصلاح سبب فشل البناء

لا تحل محاولة أخرى مشكلة البيانات المكررة أو المعاملة المفتوحة. احتفظ بالخطأ الأول حتى تعالج الاستعادة الفشل الذي رصدته فعلًا. استخدم قائمة التحقق التالية قبل المتابعة.

اعتبار التنظيف الهدّام آليةً عامة للتكرار الآمن

أبقِ التنظيف الهدّام خارج منطق إعادة المحاولة العام. اشترط موافقةً بشرية وفحصًا حديثًا للحالة قبل اتخاذ إجراء على الجلسات أو الفهارس غير الصالحة. تشرح مراجع البناء المتزامن وإعادة الفهرسة لماذا لا تكفي الأسماء والعلامات الوسيطة لتبرير الحذف.

تنبيهات: الأقسام والقيود وصلاحيات المراقبة والتكلفة التشغيلية

حدود تطبيق الدليل على الجداول العادية

لا تدعم الوثائق المشار إليها الإنشاء المتزامن على جدول أب مقسّم. ابنِ فهارس الأقسام الطرفية بالتزامن، ثم خطط لتجميع فهرس الجدول الأب على نحو منفصل. لا تفترض أن تلك العملية على الجدول الأب تخلو من الأقفال. يصف PostgreSQL هذا المسار.

يقبل DROP INDEX CONCURRENTLY فهرسًا واحدًا ويحظر CASCADE. ويجب تشغيله خارج كتلة معاملة. كما يستثني فهارس الجداول المقسّمة والحذف المباشر للفهارس التي تدعم قيود UNIQUE أو PRIMARY KEY. تحقق من أهلية الحذف. وتستثني إعادة الفهرسة المتزامنة كتالوجات النظام وفهارس قيود الاستبعاد. وفحوص أهليتها منفصلة.

لماذا ينطوي التزامن على موازنة ولا يضمن الأداء

تستهلك عمليات المسح الإضافية موارد وحدة المعالجة المركزية والإدخال والإخراج. خصّص وقتًا هندسيًا للتجربة والمراقبة، ثم حدّد فترة رصد وخطة استجابة لعبء العمل. تحذّر وثائق البناء المتزامن من العبء التشغيلي.

احمِ نصوص الاستعلامات وتفاصيل النشاط الحساسة عند مشاركة أدلة الحوادث. وراعِ قيود صلاحيات المراقبة. لم تُنفّذ هذه القوالب على بيئة اختبار PostgreSQL في هذه المراجعة. ولم تُرصد حالة انتظار أو استعادة، ولا يُدّعى تحقيق أي نتيجة إنتاجية أو نتيجة اختبار أداء معياري. جرّب المسار المختار قبل الاستخدام التشغيلي.