تعديل قاعدة البيانات داخل نسخة احتياطية لإزالة وسم مفتاح مكرر لتجنب الفشل عند الاستعادة

andy@ubuntu-s-1vcpu-1gb-ams3-01:/var/discourse/shared/standalone/backups/default$ file public-happiness-2023-07-25-033857-v20220628031850.tar.gz
public-happiness-2023-07-25-033857-v20220628031850.tar.gz: gzip compressed data, was "public-happiness-2023-07-25-033857-v20220628031850.tar", last modified: Tue Aug  8 14:53:40 2023, max speed, from FAT filesystem (MS-DOS, OS/2, NT)

محتويات الملف بالكامل تبدو جيدة، على الرغم من صعوبة التأكيد نظرًا لوجود الكثير من المعلومات: Hastebin

أعتقد أن الأمر يتعلق بمسارات الملفات. ألق نظرة على

هممم. قد لا يكون هذا هو السبب. أنا لا أثق في 7zip لإنشاء ملف tar متوافق، ولكن هذا قد يكون غير منطقي.

  -h, --dereference
              Follow symlinks; archive and dump the files they point to.

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

إعجاب واحد (1)

شكراً - المحتويات الصحيحة، ولكن تحت الأسماء الخاطئة، أعتقد. ومن هنا المشكلة.
لديك

-rwxrwxrwx 0/0        26927534 2023-08-08 14:37 public-happiness-2023-07-25-033857-v20220628031850/dump.sql.gz

ولكن الأصل وأي نسخة احتياطية غير معدلة سيكون لديها

-rwxrwxrwx 0/0        26927534 2023-08-08 14:37 dump.sql.gz

تعديل: لذا تحتاج إلى تشغيل 7zip بشكل مختلف قليلاً في بناء ملف tar.gz هذا.

إعجاب واحد (1)

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

الآن عند الاستعادة، أرى رسالة الخطأ هذه، والتي تبدو أكثر شيوعًا:

[2023-08-25 15:25:21] CREATE INDEX
[2023-08-25 15:25:21] ERROR:  could not create unique index "index_tags_on_lower_name"
[2023-08-25 15:25:21] DETAIL:  Key (lower(name::text))=(socialmedia) is duplicated.
[2023-08-25 15:25:21] EXCEPTION: psql failed: DETAIL:  Key (lower(name::text))=(socialmedia) is duplicated.

أفترض أن هذا يعني أنني قمت بتغيير العلامة بنجاح، ولكن لا تزال هناك بعض الحالات من العلامة في المنشورات في قاعدة البيانات الخاصة بي. رقم tag_id يشير إلى أنه يجب أن تكون هناك علامة تسمى socialmedia ولكن بدلاً من ذلك يجد علامة تسمى socialmedia2 مما يسبب تعارضًا.

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

لحسن الحظ، في قاعدة البيانات الخاصة بي، لدي فقط 38 حالة من 'socialmedia' (على عكس أكثر من 50,000 حالة socialmedia). بافتراض أنني كنت على حق في تغيير السطر 395421 كما قمت بتصويره أعلاه، فلا يمكنني معرفة كيفية تحديد أي من الحالات المتبقية مرتبطة بعلامة ‘socialmedia’، وأيها مرتبطة بالعلامة التي قمت بتغييرها إلى ‘socialmedia2’.

إليك مثال لمنشور قصير نسبيًا يستخدم علامة socialmedia

9488	'/groups/communitybuilders':86 '/groups/socialmedia':84 '/groups/webdev':89 '1st':117 '2022':131 '6':125 'activ':61 'banner':113 'btw':143 'close':169 'comment':21 'communiti':47 'communitybuild':87 'concept':4A 'especi':28 'event':119 'excit':164 'feedback':8B 'final':166 'get':38,133 'github':94 'grow':6A,142 'hack':127 'hard':156 'help':96 'homepag':151 'host':124 'improv':11B 'join':71,106 'launch':41,118,126 'like':128 'link':110 'live':140,175 'lot':27 'love':1A,67 'marvelxi':152 'mean':25 'media':51 'member':62 'mention':93 'move':45 'much':15 'new':150 'one':72,107 'onto':53 'plan':121 'platform':7B,43,139 'pleas':5A 'project':137 'promot':97 're':33,36,56,161 'readi':39,172 'rhorho358':23 'right':63 'see':100,167 'site':176 'slight':76,177,179 'small':58 'smile':77,178,180 'social':50 'socialmedia':85 'stage':31 'suggest':10B 'sure':79 'take':17 'team':59,75,103 'thank':12 'think':147 'time':19 'use':108 'webdev':90 'websit':3A 'whether':80 'work':155 'would':66,82	Thank you so much for taking the time to comment here @R , it means a lot, especially in the st... has been working hard on it and we’re all very excited to finally see it close to being ready on the live site :slight_smile: :slight_smile:	en_GB	4	f

قد أكون على المسار الخاطئ هنا على الرغم من أن ذلك يبدو وكأنه علامات أكثر في البداية مما من المحتمل أن يستخدمه المستخدم في منشور. من الممكن أيضًا أن ‘socialmedia’ ليست علامة مستخدمة في المنشور أعلاه، على الرغم من أنه كان ينبغي أن تكون كذلك.

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

  1. لا أعتقد أن هذا هو الاستنتاج الفوري الذي يمكنك/يجب عليك استخلاصه. يجب أن تكون المشكلة واضحة:

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

    لذلك أعتقد أنك لا تزال بحاجة إلى العثور على الإدخالات ذات الصلة في هذا الجدول الواحد التي تتعارض عند المرور بهذا التحويل.

  1. أيضًا، لا يتم وضع علامات على المشاركات، بل يتم وضع علامات على المواضيع.

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

3 إعجابات

تمت استعادة موقعنا! شكراً لكل من ساعد.

يبدو أنني قمت بحلها قبل أيام، لكنني كنت مهملاً في قراءة رسالة الخطأ. كان هناك علامتين مكررتين، ‘socialmedia’ و ‘social-media’. بعد إصلاح العلامة الأولى، لم ألاحظ أن رسالة الخطأ قد تغيرت، نظرًا لمدى تشابه العلامتين المكررتين.

هذه هي العمليات لإصلاح هذين الخطأين:

1. العثور على جدول العلامات والعلامة المكررة

  • قم بتنزيل النسخة الاحتياطية إلى نظام التشغيل الخاص بك. هذا الدليل مخصص لنظام ويندوز، ولكن العملية ستكون متشابهة تقريبًا على نظام لينكس.

  • قم بفك ضغط جميع المجلدات المضغوطة فيه، والتي يجب أن تترك لك ملف dump.sql ومجلد uploads.

  • افتح ملف dump.sql باستخدام محرر نصوص، لقد استخدمت Visual Studio Code.

  • ابحث عن “COPY public.tags” لتحديد موقع جدول العلامات. يجب أن يكون بالقرب من الأسفل ويبدو كالتالي:

  • إما أن تتصفحه يدويًا، أو قم بنسخ ولصق جدول العلامات الخاص بك في مستند منفصل حيث يمكنك استخدام وظيفة البحث فيه للعثور على العلامة المكررة.

  • احفظ ملف dump.sql الثابت باسم dump.sql.

2. يجب أن يكون ترتيب وأسماء الملفات والمجلدات مثاليًا في إعادة الضغط.

  • بعد فك الضغط، يجب أن يكون لديك ملف dump.sql ومجلد uploads.

  • انقر بزر الماوس الأيمن على dump.sql. حدد 7zip و “add to archive”.

  • حدد gzip كصيغة الأرشيف، مع الاحتفاظ بنفس اسم الملف.

  • حدد ملف dump.sql.gz الجديد وملف uploads، ثم انقر بزر الماوس الأيمن > 7zip > add to archive > archive format: tar. تأكد من أن اسم الملف مطابق تمامًا للنسخة الاحتياطية الأصلية، يجب أن يبدو شيئًا كهذا: ‘public-happiness-2023-07-25-033857-v20220628031850’.

  • حدد ملف .tar الجديد الخاص بك > 7zip > add to archive > archive format: gzip. تأكد من أن اسم الملف مطابق تمامًا للنسخة الاحتياطية الأصلية، يجب أن يبدو شيئًا كهذا: ‘public-happiness-2023-07-25-033857-v20220628031850’.

  • يجب أن تكون النتيجة النهائية ملف .tar.gz بنفس اسم النسخة الاحتياطية الأصلية.

  • قم بالتحميل إلى منطقة المسؤول واستعادة نسختك الاحتياطية.

3 إعجابات

هناك مكان واحد آخر يتكرر فيه الوسم أو قد يتكرر فيه، وهو جدول بيانات البحث:

COPY public.tag_search_data (tag_id, search_data, raw_data, locale, version) FROM stdin;

لست متأكدًا مما إذا كان هذا يحتاج أيضًا إلى تصحيح أم لا.

يسعدني أنك قمت بإصلاحه أخيرًا!

إعجابَين (2)