حل مشكلة pg_restore: role XXX does not exist في PostgreSQL

عند مواجهتك لخطأ “pg_restore: role XXX does not exist” أثناء محاولة نسخ قاعدة بيانات من نظام إلى آخر، يعكس هذا تباينًا في الأذونات والمالكية بين النظامين. في حالتك، حاولت نسخ قاعدة البيانات من النظام المصدر (الإصدار 9.5.0) إلى النظام الهدف (الإصدار 9.5.2) باستخدام أدوات مثل pg_dump و pg_restore.

على الرغم من استخدام الخيار “–no-owner” في أمر pg_dump، إلا أنه يبدو أن هناك مشكلة في عملية إعادة الاسترجاع (pg_restore). الخطأ الذي تلقيته يشير إلى محاولة إعادة تعيين الصلاحيات للدور “pgdba” الذي لا يوجد في النظام الهدف.

لحل هذه المشكلة، يمكنك اتباع الخطوات التالية:

1. إضافة المستخدم المفقود:
   يمكنك إضافة المستخدم “pgdba” إلى النظام الهدف باستخدام أمر CREATE ROLE. يمكن أن يكون هذا حلاً سريعًا، ولكن قد لا يكون هو الحلا الأمثل إذا كنت تفضل عدم إضافة المستخدمين يدوياً.

   sqlCopy code
   CREATE ROLE pgdba;
   

2. التحقق من صحة استخدام –no-owner:
   تأكد من أنك تستخدم الخيار “–no-owner” بشكل صحيح أثناء إنشاء نسخة الاحتياط باستخدام pg_dump. يمكنك أيضاً محاولة استخدام الخيار “–no-acl” لتجاهل الصلاحيات.

   bashCopy code
   pg_dump -f schema_backup.dump --no-owner --no-acl -Fc -U pgdba -h $PROD_DB_HOSTNAME -p $PROD_DB_PORT -d foodb -s --clean;
   

3. تعديل الدورات والصلاحيات في النسخة المستهدفة:
   إذا كان الهدف هو عدم إضافة المستخدم “pgdba”، فيجب عليك تعديل الدورات والصلاحيات في ملف النسخة المستند إليه. يمكنك استخدام أمر sed أو أي أداة تحرير نصوص أخرى لإزالة الإشارات إلى المستخدم “pgdba” من ملف النسخة.

   bashCopy code
   sed -i '/pgdba/d' schema_backup.dump
   

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

باختصار، يمكن أن تكون هناك مشكلة في تكامل الأذونات والمستخدمين بين النظامين، وتحتاج إلى تحقيق للتأكد من تطابق الإصدارات واستخدام الخيارات الصحيحة في أوامر pg_dump و pg_restore.

في السياق الحالي، يظهر أن المشكلة تكمن في عملية استعادة النسخة الاحتياطية باستخدام أمر pg_restore. الخيار --no-owner يهدف إلى تجاهل معلومات المالك وعدم إعادة إعدادها عند استعادة النسخة الاحتياطية. ومع ذلك، يظهر أن هناك مشكلة في عملية التراجع عن الصلاحيات (REVOKE) وتخصيصها (GRANT) للدور “pgdba” الذي لا يوجد في النظام الهدف.

قد يكون لديك الخيار في تجنب إعادة تعيين الصلاحيات لهذا الدور عن طريق تغيير الطريقة التي تقوم بها بإنشاء النسخة الاحتياطية باستخدام pg_dump. يمكنك تجربة الخيار --no-acl إضافة إلى --no-owner لتجاهل المعلومات المتعلقة بالصلاحيات. قد يساعد ذلك في تجنب إضافة أو إزالة الصلاحيات التي تتعلق بالدور “pgdba”.

bashCopy code
pg_dump -f schema_backup.dump --no-owner --no-acl -Fc -U pgdba -h $PROD_DB_HOSTNAME -p $PROD_DB_PORT -d foodb -s --clean;

يُفضل أيضًا التحقق من إصدارات PostgreSQL على النظامين والتأكد من أنهما متوافقين. إذا كان لديك إمكانية الترقية إلى إصدار أحدث من PostgreSQL على النظام الهدف، قد يكون ذلك مفيدًا لضمان التوافق.

في حال استمرار المشكلة، قد تكون هناك حاجة إلى تحليل محتوى ملف النسخة الاحتياطية (schema_backup.dump) بشكل أكثر دقة لفهم كيفية تنسيق المستخدمين والصلاحيات في النسخة الاحتياطية. يمكن استخدام أدوات مثل pg_restore بخيارات إضافية لاستكشاف المزيد من التفاصيل حول المشكلة.

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