نهارك سعيد يا عزيزي خابروفيتس! اسمح لي أن أقدم نفسي ، ألكساندر. مدير النظام لاستوديو 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. انتقل إلى موقع الويب الخاص بهم واتصل بالدعم. على الفور تقريبًا نحصل على الإجابة "مشكلة صعبة. أعطتها لكبار المهندسين - انتظر ... "
اضطررت إلى الانتظار لفترة طويلة (تم إجراء الحوار بالكامل من 25.06.2019/9.07.2019/10.4.6 إلى XNUMX/XNUMX/XNUMX) وكانت النتيجة هي الرسالة "هذه المشكلة لا تتعلق بتشغيل Bitrix CMS ، ولكنها مرتبطة لتشغيل قاعدة البيانات نفسها في mariadb XNUMX ، وللأسف ، مع وجود جانب من الموقع ، فإن هذه المشكلة لحل هذه المشكلة مفقودة ، سيكون من الضروري الانتقال إلى الإصدار القديم من 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!
مرحبا ، الدعم؟ يا رفاق ، ساعدوا!
- عذرًا ، لا ندعم البلطجية الذين يغيرون الإصدارات الأصلية لنظام إدارة قواعد البيانات. إذا كنت تريد ، فهناك خيار مع خادم بديل في عامل الإرساء.
- ولكن كيف سيصل المستخدمون وقواعد البيانات إلى هناك؟ إلى عامل ميناء؟
- حسنًا ، تسحبهم إلى هناك بيديك ...
- نعم! ولا تنس أن منفذ 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). ولكن عند إنشاء أو محاولة تحميل ملف تفريغ إلى قاعدة بيانات تحتوي على واصلة في الاسم ، تظهر رسالة تفيد بأن بنية الاستعلام غير صحيحة.
اقرأ حتى نهاية كل النعم. أعتذر عن الفواصل غير المتباعدة على الأرجح - فهم في مأزق. إذا كانت هناك رغبات في عرض ما تم وصفه بشكل أساسي - اكتب بشكل شخصي لأنني أخشى أن يفوتني شيئًا في التعليقات. ولا أقسم كثيرًا - هذه هي مقالتي الأولى 🙂
التحديث 1:
لقد نسيت تقريبًا أن أذكر: بينما كنت أحاول إيجاد حل للمشكلة دون الرجوع إلى تصنيف MariaDB ، كان علي تحديث المعلومات بطريقة ما. تم تحديثه على هذا النحو: يتم تحويل قاعدة البيانات بأكملها من InnoDB إلى MyISAM ، ويتم تحديث infa ثم تحويلها مرة أخرى إلى InooDB.
التحديث 2:
تلقيت للتو رسالة من 1C-Bitrix بالمحتوى التالي:
اكتمل طلب المراجعة
"بعد تحديث mariadb إلى الإصدار 10.4.6 ، حدث خطأ أثناء حفظ عنصر infoblock"
الوحدة: iblock ، الإصدار: غير معروف
الحل: مرفوض
حتى الآن ، يبدو أنه من المستحيل التحديث إلى 10.4
المصدر: www.habr.com