Bitrix en MariaDB werk op na die nuutste stabiele weergawe

Goeie dag, liewe Khabrovsk inwoners! Kom ek stel myself voor, Alexander. Stelseladministrateur van een klein maar trotse WEB-ateljee. Ons wil regtig hê alles moet vinnig, veilig en met die nuutste sagteware werk. Om dit te doen, het ons selfs die nagios+PhantomJS-bundel op die binnekantoorrekenaar geïnstalleer en die bladsylaaispoed elke 30 minute nagegaan. Volgens die diensbepalings monitor ons ook 1C-Bitrix-opdaterings en installeer dit gereeld. En dan eendag, na die volgende opdatering, sien ons 'n boodskap in die administrasiepaneel dat 2019C-Bitrix sedert die somer van 1 ophou werk met MySQL 5.5 en ons moet opdateer. Die ouens van ISPSystem is aantreklik en brei gereeld die funksionaliteit van die paneel uit, waarvoor spesiale dank aan hulle. Maar hierdie keer was dit nie moontlik om alles met die muis te klik nie. Maar jy kan uitvind wat gebeur het en hoeveel grys hare is nou in my baard onder die sny.

Daar was slegs 'n opsie om 'n "alternatiewe DBMS-bediener" te installeer wat in 'n Docker-houer geïnstalleer is. Natuurlik verstaan ​​ek dat Docker baie spaarsaam is met hulpbronne, maar maak nie saak hoe goed dit werk nie, die bokoste sal steeds >0 wees. En hier lyk dit of ons in tiendes van sekondes baklei en alle terreine by die ingang optimaliseer voordat ons dit publiseer en 'n ooreenkoms onderteken. So nie my opsie nie.
Ok, wat sê die dokumentasie? Rugsteun alles, voeg 'n lêer by yum.repos.d met 'n skakel na die MariaDB-bewaarplek, dan

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

Yum sal daarna sweer dat iemand die pakkette sonder sy medewete uitgevee het. Maar eers, laat hom sweer, dit is oukei. En tweedens, as jy die verwydering via yum doen, dan probeer dit om, saam met MariaDB, alles te verwyder wat deur afhanklikheid daaraan gekoppel is, en dit sluit PHP en ISPManager en PHPmyadmin in. Daarom sal ons later die vloekery hanteer.

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

Oor die algemeen is alles geïnstalleer en begin. Die lekker ding is dat die databasisse opgetel is en dit was nie nodig om dit van stortings af te herstel nie. Ek het die webwerwe nagegaan - hulle werk en is vinnig. Ek het in 'n paar admin-areas ingegaan om seker te maak dat niks afgeval het nie en het aan die direkteur teruggeskryf dat alles in orde is. Minder as 30 minute later het dit geblyk dat dit glad nie reg was nie...

Toe ek probeer om in die administrasie-area in te gaan en enigiets in die inhoud by te voeg en te wysig, het 'n boodskap verskyn

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

Aangesien die inhoud op die webwerf deur ons eie werknemers bygevoeg word, het die kliënte nog niks geweet nie en het hulle nog nie begin om ons uitmekaar te skeur nie. Maar dit was 'n kwessie van tyd, want die inligting op die webwerwe moet bygewerk word, en baie kliënte monitor dit self noukeurig.

Uit die teks van die fout kan ons aflei dat Bitrix probeer om 'n nuwe inskrywing by die databasis te voeg, terwyl dieselfde primêre sleutel spesifiseer wat in die artikel wat geredigeer word, was. Dit beteken daar is rede om te vermoed dat die probleem aan die Bitrix-kant ontstaan. Ons gaan na hul webwerf en kontak ondersteuning. Byna dadelik kry ons die antwoord “complicated problem. Het dit vir senior ingenieurs gegee - wag ..."

Ons moes nogal lank wag (die hele dialoog het van 25.06.2019 Junie 9.07.2019 tot 10.4.6 Julie XNUMX plaasgevind) en die resultaat was die boodskap “hierdie probleem hou nie verband met die werking van die Bitrix CMS nie, maar hou verband met die werking van die databasis self in mariadb XNUMX en, ongelukkig, met Aan die werfkant, is daar geen manier om hierdie probleem op te los nie; jy sal moet oorskakel na die ou weergawe van MariaDB.”

Hulle het aangekom... Ek het aan die begin van die storie gedink aan afgradering, maar dit sê dit in swart en witdat daar geen afgradering kan wees nie. Stort stortings en herontplooi op 'n volledig geïnstalleerde bediener. Dié. Dit is goed dat ek nie al die bedieners gelyktydig opgedateer het nie. Dié. “net” honderd webwerwe (senuweelag :-)). Die ondersteuning het ook gesê: "Om die probleem op te los wanneer die MariaDB 10.4.6-databasis gebruik word, sal jy MariaDB tegniese ondersteuning moet kontak dat die transaksie nie 'n rekord van die databasis sal verwyder as die versoek gerig word nie:

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

Hoop het vir 'n paar uur geskitter vandat ek met MariaDB-ondersteuning begin kommunikeer het, maar toe kry ek 'n brief waarin hulle baie korrek vir my sê dat ek nie 'n kommersiële gebruiker is nie en daarom sal niemand my probleem doelbewus oplos nie, maar daar is 'n forum op hul webwerf en daar kan jy probeer om opsies te soek ... ek sal jou nie verveel met besonderhede nie. Daar is geen opsies daar nie.
OOR! Ons het 'n ISP-lisensie gekoop!
- Hallo, ondersteuning? Ouens, help!
— Jammer, ons ondersteun nie skelms wat inheemse weergawes van die DBBS verander nie. As u wil, is daar 'n opsie met 'n alternatiewe bediener in Docker.
— Maar hoe sal gebruikers en databasisse daar kom? Docker?
- Wel, jy sleep hulle daar met jou hande ...
- Ja! En moenie vergeet dat die poort vir mysql sal verander nie en jy sal deur al die konfigurasies moet gaan en dit herskryf.
- Ok, dankie, ek sal daaroor dink ...
Ek het daaroor nagedink en besluit om 10.4 handmatig af te breek en 10.2 te installeer waarmee daar geen probleme op ander bedieners was nie.

Die proses was nie veel anders as die opdateringsproses nie. Ek moes net 10.4 na 10.2 in die skakel na die bewaarplek verander, die kas vir yum terugstel en herskep. Wel, nog een "klein dingetjie": nadat jy 10.4 verwyder het, gaan na /var/lib/mysql en verwyder alles van daar af. Sonder hierdie stap na die installering van 10.2, sal die diens voortdurend ineenstort en jy sal sien

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

Of

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

Voordat ek die databasisse invoer, het ek eers die root-wagwoord vir mysql ingestel wat in die ISP-konfigurasies gespesifiseer is en die mysql-databasisstorting ingevoer. Wel, dan, aangesien ons reeds gebruikers en regte het, voer ons eenvoudig al die gebruikerdatabasisse in 'n ry in deur die wortelrekening te gebruik.

Skripteks vir databasisstorting:

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

Voordat u databasisse invoer, moet u dit uitpak. So ons voer net die opdrag uit

gunzip /BACK/*.gz

En laastens: om een ​​of ander rede word koppeltekens in die naam van die databasis toegelaat (as jy dit via ISPmanager skep). Maar wanneer jy 'n dump skep of probeer oplaai na 'n databasis wat 'n koppelteken in sy naam het, ontvang jy 'n boodskap dat die versoeksintaksis verkeerd is.

Alle sterkte aan die wat tot die einde lees. Ek vra om verskoning vir die mees waarskynlike misplaaste kommas - dit is 'n probleem. As jy enige voorstelle het oor die essensie van wat beskryf word, skryf in 'n persoonlike boodskap want ek is bang ek mis iets in die kommentaar. En moenie te veel vloek nie - dit is my eerste artikel :)

UPD1:

Ek het amper vergeet om te noem: terwyl ek probeer het om 'n oplossing vir die probleem te vind sonder om MariaDB af te gradeer, moes ek op een of ander manier die inligting opdateer. Dit is so opgedateer: die hele databasis word van InnoDB na MyISAM omgeskakel, die inligting word opgedateer en dan terug na InooDB omgeskakel.
UPD2:

Ek het sopas 'n brief van 1C-Bitrix ontvang met die volgende inhoud:

Versoek om hersiening voltooi
"Na die opgradering van mariadb na 10.4.6, het 'n fout voorgekom met die stoor van 'n infoblok-element"
Module: iblock, weergawe: onbekend
Oplossing: verwerp

Dit is dus blykbaar onmoontlik om vir eers na 10.4 op te dateer 🙁

Bron: will.com