Bitrix وتحديث MariaDB إلى أحدث إصدار مستقر

يوم جيد يا عزيزي خابروفيان! اسمحوا لي أن أقدم نفسي ، ألكساندر. مسؤول نظام واحد صغير ولكن فخور WEB- الاستوديو. نريد حقًا أن يعمل كل شيء بسرعة وأمان وبأحدث البرامج. للقيام بذلك ، رفعوا حتى حفنة من nagios + PhantomJS على الكمبيوتر المكتبي والتحقق من سرعة تحميل الصفحة كل 30 دقيقة. وفقًا لشروط الخدمة ، نتابع أيضًا تحديثات 1C-Bitrix ونقوم بتثبيتها بانتظام. ومرة واحدة ، بعد التحديث التالي ، نرى رسالة في لوحة الإدارة تفيد أنه في صيف عام 2019 ، توقف 1C-Bitrix عن العمل مع MySQL 5.5 ويحتاج إلى تحديث. الرجال من ISPSystem هم وسيمون ويوسعون بانتظام وظائف اللوحة ، والتي شكر خاص لهم. ولكن هذه المرة لم يكن من الممكن النقر فوق كل الماوس. ولكن ما حدث ومقدار الشعر الرمادي الموجود الآن في لحيتي يمكن العثور عليه تحت القص.

لم يكن هناك سوى خيار لوضع "خادم DBMS بديل" والذي يتم وضعه في حاوية Docker. بالطبع ، أنا أفهم أن Docker يتميز بالكفاءة في استخدام الموارد ، لكن بغض النظر عن مدى روعته ، فسيظل مقدار الحمل أكبر من 0. ونحن هنا نقاتل ، كما كان ، في أعشار الثانية ، وعند المدخل نقوم بتحسين جميع المواقع قبل نشر العقد وتوقيعه. لذلك هذا ليس خياري.
حسنا ، ما هو مكتوب في الوثائق؟ مجموع النسخ الاحتياطي ، إضافة ملف مع وصلة إلى مستودع MariaDB في yum.repos.d ، ثم

rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-common 

سوف يلعن Yum لاحقًا أن يقوم شخص ما بإزالة / تثبيت الحزم دون علمه. لكن أولاً - دعها أقسم ، هذا جيد. وثانيا ، إذا قمت بالحذف عبر yum ، فسيحاول هدم ، مع MariaDB ، كل ما يتعلق به ، وهذا هو PHP و ISPManager و PHPmyadmin. لذلك ، سوف نتعامل مع الشخبطة.

 yum clean all yum update yum install MariaDB-server MariaDB-client MariaDB-common 

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

عند محاولة الانتقال إلى لوحة المشرف وإضافة / تحرير أي شيء ، سقطت رسالة في المحتوى

 MySQL Query Error: INSERT INTO b_iblock_element_property (ID, IBLOCK_ELEMENT_ID, IBLOCK_PROPERTY_ID, VAL UE, VALUE_NUM) SELECT 10555 ,2201 ,P.ID ,'3607' ,3607.0000 FR OM b_iblock_property P WHERE ID = 184 [[1062] Duplicate entry '10555' for key 'PRIMARY'] 

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

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

كان علينا الانتظار لفترة طويلة (تم إجراء الحوار بالكامل من 06/25/2019 إلى 07/09/2019) وكانت النتيجة هي الرسالة "هذه المشكلة لا تتعلق بعمل Bitrix CMS ، ولكن بقاعدة البيانات نفسها في mariadb 10.4.6 وللأسف مع الجانب من الموقع هذه المشكلة لحل احتمال مفقود سيكون من الضروري الترقية إلى الإصدار القديم من MariaDB.

لقد وصلوا ... فكرت في خفض التصنيف في بداية القصة ، ولكن هنا يقال بالأبيض والأسود أنه لا يمكن تقليله. دمج مقالب ونشر مرة أخرى على خادم مثبت بشكل نظيف. أي من الجيد أنني لم أقوم بتحديث جميع الخوادم دفعة واحدة. أي "فقط" مئات المواقع (ضحك عصبي :-)). قالوا أيضًا في الدعم: "لحل المشكلة عند استخدام قاعدة بيانات MariaDB 10.4.6 ، ستحتاج إلى الاتصال بالدعم الفني MariaDB أن المعاملة لن تحذف السجل من قاعدة البيانات إذا تم تقديم الطلب:

 $DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]); $results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);” 

كانت ناديجدا تعمل على الاحترار لبضع ساعات منذ بدء الاتصال بدعم MariaDB ، ولكن بعد ذلك جاءت رسالة أخبرني فيها بشكل صحيح أنني لست مستخدمًا تجاريًا وبالتالي لا أحد سيحل مشكلتي ، لكن كان هناك منتدى على موقعه على الويب ويمكنك محاولة البحث عن خيارات هناك ... لن أتحمل التفاصيل. لا توجد خيارات هناك.
أوه! لدينا ترخيص تم شراؤه لـ ISP!
- مرحبا ، الدعم؟ الرجال ، مساعدة!
- عذرًا ، لا ندعم scumbags التي تغير الإصدار الأصلي من DBMS. هل تريد - هناك خيار مع خادم بديل في عامل الميناء.
- لكن كيف يصل المستخدمون وقواعد البيانات إلى هناك؟ إلى عامل ميناء؟
- حسنًا ، يمكنك سحبهم هناك بيديك ...
- نعم! ولا تنس أن منفذ mysql سوف يتغير وسوف تحتاج إلى المرور عبر جميع التكوينات وإعادة كتابته.
- حسنا ، شكرا ، سوف أفكر ...
فكرت وقررت هدم 10.4 مع الأقلام ووضع 10.2 مع أنه لا توجد مشاكل على خوادم أخرى.

لم تكن العملية مختلفة تمامًا عن عملية التحديث. فقط كان من الضروري في رابط المستودع تغيير 10.4 إلى 10.2 ، وإعادة تعيين وإعادة إنشاء ذاكرة التخزين المؤقت لـ yum. حسنًا ، واحد آخر "تافه": بعد إزالة 10.4 ، انتقل إلى / var / lib / mysql وحذف كل شيء من هناك. بدون هذه الخطوة ، بعد تثبيت الإصدار 10.2 ، ستنخفض الخدمة باستمرار وستظهر لك

       '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer" 

أو

 Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104 

قبل استيراد قواعد البيانات ، قمت أولاً بتعيين كلمة مرور الجذر لـ mysql التي تم تسجيلها في تكوينات ISP واستوردت تفريغ قاعدة بيانات mysql. حسنًا ، إذن ، نظرًا لوجود مستخدمين وحقوق بالفعل ، فإننا ببساطة نستورد جميع قواعد المستخدمين في صف واحد باستخدام حساب الجذر.

نص البرنامج النصي لتفريغ قاعدة البيانات:

 #!/bin/bash echo 'show databases' | mysql -u root --password="_" --skip-column-names | grep -v information_schema | xargs -I {} -t bash -c 'mysqldump -u root --password="_" {} | gzip > /BACK/back-$(hostname)-{}-$(date +%Y-%m-%d-%H.%M.%S).sql.gz' 

قبل استيراد قواعد البيانات ، تحتاج إلى فك ضغطها. حتى مجرد تنفيذ الأمر

 gunzip /BACK/*.gz 

والأخير: لسبب ما ، يتم السماح للواصلات في اسم قواعد البيانات (إذا قمت بإنشاء من خلال ISPmanager). ولكن عند إنشاء أو محاولة ملء التفريغ في قاعدة البيانات باستخدام واصلة في الاسم ، تظهر لك رسالة تفيد بأن بناء جملة الاستعلام غير صحيح.

قراءة حتى نهاية كل النعم. أعتذر عن الفواصل التي لم يتم وضعها على الأرجح - مشكلة معهم. إذا كانت هناك رغبات / اقتراحات بشأن جوهر ما هو موصوف - فاكتب في رسالة شخصية لأنني أخشى أن تفوت أي شيء في التعليقات. ولا أقسم كثيرًا - هذا هو مقالي الأول :-)

UPD1:

لقد نسيت تقريبا أن أذكر: بينما كنت أحاول إيجاد حل للمشكلة دون الرجوع إلى MariaDB ، كان عليّ تحديث المعلومات بطريقة أو بأخرى. تم تحديثه على النحو التالي: يتم تحويل قاعدة البيانات بأكملها من InnoDB إلى MyISAM ، ويتم تحديث المعلومات ، ثم يتم تحويلها مرة أخرى إلى InooDB.
UPD2:

وصلت لتوها رسالة من 1C-Bitrix مع المحتوى التالي:

تطبيق للمراجعة تنفيذها
"بعد تحديث mariadb إلى 10.4.6 ، حدث خطأ أثناء حفظ عنصر كتلة المعلومات"
الوحدة: iblock ، الإصدار: غير معروف
الحل: مرفوض

لذلك في حين أنه من المستحيل على ما يبدو التحديث إلى 10.4 :-(