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 და ISPMmanager და 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-ისთვის!
გამარჯობა, მხარდაჭერა? ბიჭებო, დაეხმარეთ!
- უკაცრავად, ჩვენ არ ვუჭერთ მხარს ავაზაკებს, რომლებიც ცვლიან 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 root პაროლი, რომელიც მითითებული იყო ISP-ის კონფიგურაციებში და შემოვიტანე mysql მონაცემთა ბაზის ნაგავსაყრელი. კარგი, მაშინ, რადგან უკვე არსებობს მომხმარებლები და უფლებები, ჩვენ უბრალოდ იმპორტირებს მომხმარებლის ყველა მონაცემთა ბაზას ზედიზედ root ანგარიშით.

სკრიპტის ტექსტი მონაცემთა ბაზის ნაგავსაყრელისთვის:

#!/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-ში, განახლდება infa და შემდეგ ისევ გარდაიქმნება InooDB-ში.
UPD2:

ახლახან მივიღე წერილი 1C-Bitrix-ისგან შემდეგი შინაარსით:

შესწორების მოთხოვნა დასრულებულია
"მარიადბის 10.4.6-ზე განახლების შემდეგ, მოხდა შეცდომა ინფობლოკის ელემენტის შენახვისას"
მოდული: iblock, ვერსია: უცნობი
გამოსავალი: უარყოფილია

ასე რომ, ჯერჯერობით, როგორც ჩანს, შეუძლებელია 10.4-ზე განახლება 🙁

წყარო: www.habr.com