Bitrix kaj MariaDB ĝisdatigas al la plej nova stabila versio

Bonan tagon, karaj Ĥabrovskanoj! Lasu min prezenti min, Aleksandro. Sistemadministranto de unu malgranda sed fiera WEB-studio. Ni vere volas, ke ĉio funkciu rapide, sekure kaj kun la plej nova programaro. Por fari tion, ni eĉ instalis la pakaĵon nagios+PhantomJS sur la intra-oficeja komputilo kaj kontrolas la paĝan ŝarĝrapidecon ĉiujn 30 minutojn. Laŭ la servokondiĉoj, ni ankaŭ kontrolas ĝisdatigojn de 1C-Bitrix kaj instalas ilin regule. Kaj tiam unu tagon, post la sekva ĝisdatigo, ni vidas mesaĝon en la administra panelo, ke ekde la somero de 2019, 1C-Bitrix ĉesas funkcii kun MySQL 5.5 kaj ni devas ĝisdatigi. La infanoj de ISPSystem estas belaj kaj regule vastigas la funkciojn de la panelo, pro kio speciala danko al ili. Sed ĉi-foje ne eblis klaki ĉion per la muso. Sed vi povas ekscii kio okazis kaj kiom da grizaj haroj nun estas en mia barbo sub la tranĉo.

Estis nur eblo instali "alternativan DBMS-servilon", kiu estas instalita en Docker-ujo. Kompreneble, mi komprenas, ke Docker estas tre ŝparema kun rimedoj, sed kiom ajn bonege ĝi funkcias, la superkosto ankoraŭ estos >0. Kaj ĉi tie ni ŝajnas batali en dekonoj de sekundoj kaj optimumigi ĉiujn retejojn ĉe la enirejo antaŭ ol publikigi ilin kaj subskribi interkonsenton. Do ne mia elekto.
Bone, kion diras la dokumentaro? Rezervu ĉion, aldonu dosieron al yum.repos.d kun ligilo al la deponejo MariaDB, tiam

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

Yum poste ĵuros, ke iu forigis la pakaĵojn sen sia scio. Sed antaŭ ĉio, li ĵuru, ĝi estas en ordo. Kaj due, se vi faras la forigon per yum, tiam ĝi provas forigi, kune kun MariaDB, ĉion, kio estas ligita al ĝi per dependeco, kaj ĉi tio inkluzivas PHP kaj ISPManager kaj PHPmyadmin. Sekve, ni traktos la ĵuron poste.

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

Ĝenerale ĉio estis instalita kaj komencita. La agrabla afero estas, ke la datumbazoj estis prenitaj kaj ne necesis restarigi ilin el rubejoj. Mi kontrolis la retejojn - ili funkcias kaj estas rapidaj. Mi iris en kelkajn administrajn areojn por certigi, ke nenio defalis kaj skribis al la direktoro, ke ĉio estas en ordo. Malpli ol 30 minutojn poste montriĝis, ke ĝi tute ne estas en ordo...

Kiam mi provis iri en la administran areon kaj aldoni kaj redakti ion ajn en la enhavo, aperis mesaĝo

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']

Ĉar la enhavo en la retejo estas aldonita de niaj propraj dungitoj, la klientoj ankoraŭ nenion sciis kaj ankoraŭ ne komencis disŝiri nin. Sed estis demando de tempo, ĉar la informoj pri la retejoj devas esti ĝisdatigitaj, kaj multaj klientoj atente kontrolas tion mem.

El la teksto de la eraro, ni povas konkludi, ke Bitrix provas aldoni novan eniron al la datumbazo dum ĝi specifas la saman ĉefan ŝlosilon, kiu estis en la redaktata artikolo. Ĉi tio signifas, ke ekzistas kialo por suspekti, ke la problemo ŝprucas ĉe la flanko de Bitrix. Ni iras al ilia retejo kaj kontaktas subtenon. Preskaŭ tuj ni ricevas la respondon "komplika problemo. Donis ĝin al altrangaj inĝenieroj - atendu..."

Ni devis atendi sufiĉe longe (la tuta dialogo okazis de la 25.06.2019-a de junio 9.07.2019 ĝis la 10.4.6-a de julio XNUMX) kaj la rezulto estis la mesaĝo "ĉi tiu problemo ne rilatas al la funkciado de la Bitrix CMS, sed rilatas al la funkciado de la datumbazo mem en mariadb XNUMX kaj, bedaŭrinde, ĉe la retejo, ne ekzistas maniero solvi ĉi tiun problemon; vi devos ŝanĝi al la malnova versio de MariaDB."

Ili alvenis... Mi pensis pri malaltigo komence de la rakonto, sed ĝi diras ĝin en nigra kaj blankake ne povas esti malaltigo. Forĵetu rubejojn kaj re-deplojiĝi sur tute instalita servilo. Tiuj. Estas bone, ke mi ne ĝisdatigis ĉiujn servilojn samtempe. Tiuj. “nur” cent ejoj (nerva rido :-)). La subteno ankaŭ diris: "Por solvi la problemon kiam vi uzas la MariaDB 10.4.6-datumbazon, vi devos kontakti MariaDB-teknikan subtenon, ke la transakcio ne forigos rekordon el la datumbazo se la peto estas farita:

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

Espero ekbrilis dum kelkaj horoj de la momento, kiam mi komencis komuniki kun MariaDB-subteno, sed tiam mi ricevis leteron, en kiu ili tre ĝuste diris al mi, ke mi ne estas komerca uzanto kaj tial neniu intence solvos mian problemon, sed ekzistas forumon en ilia retejo kaj tie vi povas provi serĉi eblojn ... mi ne enuigos vin per detaloj. Ne estas ebloj tie.
PRI! Ni aĉetis ISP-licencon!
- Saluton, subteno? Knaboj, helpu!
— Pardonu, ni ne subtenas friponojn, kiuj ŝanĝas denaskajn versiojn de la DBMS. Se vi volas, ekzistas opcio kun alternativa servilo en Docker.
— Sed kiel uzantoj kaj datumbazoj alvenos tien? Al docker?
- Nu, vi trenu ilin tien per viaj manoj...
- Jes! Kaj ne forgesu, ke la haveno por mysql ŝanĝiĝos kaj vi devos trarigardi ĉiujn agordojn kaj reverki ilin.
- Bone, dankon, mi pripensos ĝin...
Mi pensis pri tio kaj decidis mane malkonstrui 10.4 kaj instali 10.2 kun kiu ne estis problemoj en aliaj serviloj.

La procezo ne multe diferencis de la ĝisdatiga procezo. Mi nur devis ŝanĝi 10.4 al 10.2 en la ligilo al la deponejo, restarigi kaj rekrei la kaŝmemoron por yum. Nu, ankoraŭ unu "etaĵo": post forigo de 10.4, iru al /var/lib/mysql kaj forigu ĉion de tie. Sen ĉi tiu paŝo post instalo de 10.2, la servo senĉese kraŝos kaj vi vidos

Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"

Aŭ

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

Antaŭ ol importi la datumbazojn, mi unue starigis la radikan pasvorton por mysql, kiu estis specifita en la ISP-agordoj, kaj importis la mysql-datumbazon. Nu, do, ĉar ni jam havas uzantojn kaj rajtojn, ni simple importas ĉiujn uzantdatumbazon en vico uzante la radikan konton.

Skriptteksto por datumbaza rubejo:

#!/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'

Antaŭ ol importi datumbazojn, vi devas malzipi ilin. Do ni nur rulu la komandon

gunzip /BACK/*.gz

Kaj laste: ial streketoj estas permesitaj en la nomo de la datumbazo (se vi kreas ĝin per ISPmanager). Sed kiam vi kreas aŭ provas alŝuti rubejon al datumbazo kiu havas streketon en sia nomo, vi ricevas mesaĝon ke la peta sintakso estas malĝusta.

Ĉion bonan al tiuj, kiuj legas ĝis la fino. Mi pardonpetas pro la plej verŝajne mislokigitaj komoj - ili estas problemo. Se vi havas sugestojn pri la esenco de kio estas priskribita, skribu en persona mesaĝo ĉar mi timas, ke mi maltrafos ion en la komentoj. Kaj ne ĵuru tro - jen mia unua artikolo :)

UPD1:

Mi preskaŭ forgesis mencii: dum mi klopodis trovi solvon al la problemo sen malaltigi MariaDB, mi devis iel ĝisdatigi la informojn. Ĝi estis ĝisdatigita tiel: la tuta datumbazo estas konvertita de InnoDB al MyISAM, la informoj estas ĝisdatigitaj kaj poste konvertitaj reen al InooDB.
UPD2:

Mi ĵus ricevis leteron de 1C-Bitrix kun jena enhavo:

Peto por revizio finiĝis
"Post altgradigo de mariadb al 10.4.6, eraro okazis dum konservado de infobloka elemento"
Modulo: iblock, versio: nekonata
Solvo: malakceptita

Do ŝajne estas neeble ĝisdatigi al 10.4 nuntempe 🙁

fonto: www.habr.com