روز بخیر، ساکنان خابروفسک عزیز! بگذار خودم را معرفی کنم، اسکندر. مدیر سیستم یک استودیوی وب کوچک اما مفتخر. ما واقعاً می خواهیم همه چیز به سرعت، ایمن و با جدیدترین نرم افزار کار کند. برای انجام این کار، ما حتی باندل nagios+PhantomJS را روی کامپیوتر درون اداری نصب کردیم و هر 30 دقیقه سرعت بارگذاری صفحه را بررسی کردیم. با توجه به شرایط خدمات، ما همچنین به روز رسانی 1C-Bitrix را نظارت کرده و آنها را به طور منظم نصب می کنیم. و سپس یک روز، پس از آپدیت بعدی، پیامی را در پنل مدیریت مشاهده می کنیم که از تابستان 2019، 1C-Bitrix با MySQL 5.5 کار نمی کند و باید به روز رسانی کنیم. بچه های ISPSystem خوش تیپ هستند و به طور منظم عملکرد پانل را گسترش می دهند که برای این کار تشکر ویژه ای از آنها داریم. اما این بار امکان کلیک روی همه چیز با ماوس وجود نداشت. اما می توانید بفهمید که چه اتفاقی افتاده است و اکنون چند تا موی خاکستری در ریش من زیر بریده شده است.
تنها گزینه ای برای نصب "سرور DBMS جایگزین" وجود داشت که در یک ظرف Docker نصب شده است. البته، می‌دانم که Docker با منابع بسیار مقتصد است، اما مهم نیست که چقدر عالی کار می‌کند، باز هم سربار > 0 خواهد بود. و در اینجا به نظر می رسد که ما در یک دهم ثانیه با هم مبارزه می کنیم و قبل از انتشار و امضای توافق، همه سایت ها را در ورودی بهینه می کنیم. پس گزینه من نیست
خوب، مستندات چه می گوید؟ از همه چیز بک آپ بگیرید، یک فایل به yum.repos.d با پیوندی به مخزن MariaDB اضافه کنید، سپس
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonیام متعاقباً قسم می خورد که شخصی بدون اطلاع او بسته ها را حذف کرده است. اما اول از همه، بگذارید قسم بخورد، اشکالی ندارد. و ثانیاً، اگر حذف را از طریق yum انجام دهید، آنگاه سعی می‌کند، همراه با MariaDB، هر چیزی را که با وابستگی به آن متصل است حذف کند، و این شامل PHP و ISPManager و PHPmyadmin می‌شود. بنابراین بعداً به فحش می پردازیم.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonدر کل همه چیز نصب و راه اندازی شد. نکته خوب این است که پایگاه داده ها برداشت شده و نیازی به بازیابی آنها از dump ها وجود ندارد. من سایت ها را بررسی کردم - آنها کار می کنند و سریع هستند. من به چند بخش مدیریت رفتم تا مطمئن شوم که چیزی از بین نرفته است و به کارگردان نوشتم که همه چیز خوب است. کمتر از 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 انجام شد) و نتیجه این پیام بود "این مشکل به عملکرد 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 خریدیم!
- سلام، پشتیبانی؟ بچه ها، کمک کنید!
- متأسفیم، ما از آدم‌های بدجنسی که نسخه‌های بومی 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قبل از وارد کردن پایگاه‌های داده، ابتدا رمز عبور root را برای 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 ایجاد کنید). اما وقتی یک Dump ایجاد می‌کنید یا سعی می‌کنید در پایگاه داده‌ای که یک خط فاصله در نام خود دارد آپلود کنید، پیامی دریافت می‌کنید مبنی بر اینکه نحو درخواست نادرست است.
بهترین ها برای کسانی که تا آخر می خوانند. من برای کاماهای نابجا عذرخواهی می کنم - آنها یک مشکل هستند. اگر پیشنهادی در مورد ماهیت آنچه توضیح داده شده دارید، در یک پیام شخصی بنویسید زیرا می ترسم چیزی را در نظرات از دست بدهم. و زیاد قسم نخورید - این اولین مقاله من است :)
UPD1:
تقریباً فراموش کردم ذکر کنم: در حالی که سعی می کردم بدون دانگرید MariaDB راه حلی برای مشکل پیدا کنم، مجبور شدم به نحوی اطلاعات را به روز کنم. به این صورت به روز شد: کل پایگاه داده از InnoDB به MyISAM تبدیل می شود، اطلاعات به روز می شود و سپس دوباره به InooDB تبدیل می شود.
UPD2:
من به تازگی نامه ای از 1C-Bitrix با محتوای زیر دریافت کردم:
درخواست بازبینی تکمیل شد
"پس از ارتقاء mariadb به 10.4.6، هنگام ذخیره یک عنصر infoblock خطایی رخ داد"
ماژول: iblock، نسخه: ناشناخته
راه حل: رد شد
بنابراین ظاهراً در حال حاضر به روز رسانی به 10.4 غیرممکن است 🙁
منبع: www.habr.com