Goddag, kære Khabrovsk-beboere! Lad mig præsentere mig selv, Alexander. Systemadministrator af et lille, men stolt WEB-studie. Vi ønsker virkelig, at alt fungerer hurtigt, sikkert og med den nyeste software. For at gøre dette installerede vi endda nagios+PhantomJS-pakken på den interne computer og tjekkede sideindlæsningshastigheden hvert 30. minut. I henhold til servicevilkårene overvåger vi også 1C-Bitrix-opdateringer og installerer dem regelmæssigt. Og så en dag, efter den næste opdatering, ser vi en besked i admin-panelet om, at siden sommeren 2019 holder 1C-Bitrix op med at arbejde med MySQL 5.5, og vi skal opdatere. Fyrene fra ISPSystem er smukke og udvider jævnligt panelets funktionalitet, som en særlig tak til dem. Men denne gang var det ikke muligt at klikke på alt med musen. Men du kan finde ud af, hvad der skete, og hvor mange grå hår der nu er i mit skæg under klippet.
Der var kun en mulighed for at installere en "alternativ DBMS-server", der er installeret i en Docker-container. Selvfølgelig forstår jeg, at Docker er meget sparsommelig med ressourcer, men uanset hvor godt det virker, vil overhead stadig være >0. Og her ser vi ud til, at vi kæmper på tiendedele af sekunder og optimerer alle sider ved indgangen, før vi offentliggør dem og underskriver en aftale. Så ikke min mulighed.
Ok, hvad siger dokumentationen? Sikkerhedskopier alt, tilføj en fil til yum.repos.d med et link til MariaDB-lageret, og derefter
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum vil efterfølgende sværge på, at nogen har slettet pakkerne uden hans vidende. Men først og fremmest, lad ham sværge, det er okay. Og for det andet, hvis du laver sletningen via yum, så forsøger den sammen med MariaDB at fjerne alt, der er forbundet med den af afhængighed, og dette inkluderer PHP og ISPManager og PHPmyadmin. Derfor behandler vi banden senere.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonGenerelt blev alt installeret og startet. Det gode er, at databaserne blev samlet op, og der var ingen grund til at gendanne dem fra lossepladser. Jeg tjekkede siderne - de virker og er hurtige. Jeg gik ind i et par admin-områder for at sikre mig, at intet var faldet af, og skrev tilbage til instruktøren, at alt var OK. Mindre end 30 minutter senere viste det sig, at det slet ikke var i orden...
Da jeg forsøgte at gå ind i administrationsområdet og tilføje og redigere noget i indholdet, dukkede en besked op
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']Da indholdet på siden er tilføjet af vores egne medarbejdere, vidste kunderne ikke noget endnu og er endnu ikke begyndt at rive os fra hinanden. Men det var et spørgsmål om tid, for informationerne på siderne skal opdateres, og mange kunder følger dette nøje selv.
Fra teksten til fejlen kan vi konkludere, at Bitrix forsøger at tilføje en ny post til databasen, mens den angiver den samme primære nøgle, som var i artiklen, der redigeres. Det betyder, at der er grund til at formode, at problemet opstår på Bitrix-siden. Vi går ind på deres hjemmeside og kontakter support. Næsten med det samme får vi svaret "kompliceret problem. Gav det til senioringeniører - vent..."
Vi måtte vente ret længe (hele dialogen fandt sted fra den 25.06.2019. juni 9.07.2019 til den 10.4.6. juli XNUMX), og resultatet var beskeden "dette problem er ikke relateret til driften af Bitrix CMS, men er relateret til drift af selve databasen i mariadb XNUMX, og desværre med På webstedssiden er der ingen måde at løse dette problem på; du bliver nødt til at skifte til den gamle version af MariaDB."
De ankom... Jeg tænkte på nedgradering i begyndelsen af historien, men at der ikke kan ske en nedgradering. Dump dumps og geninstaller på en fuldstændig installeret server. De der. Det er godt, at jeg ikke opdaterede alle serverne på én gang. De der. "kun" hundrede steder (nervøs grin :-)). Supporten sagde også: "For at løse problemet, når du bruger MariaDB 10.4.6-databasen, skal du kontakte MariaDBs tekniske support om, at transaktionen ikke vil slette en post fra databasen, hvis anmodningen fremsættes:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
Håbet glimtede i et par timer fra det øjeblik, jeg begyndte at kommunikere med MariaDB-support, men så modtog jeg et brev, hvori de meget korrekt fortalte mig, at jeg ikke er en kommerciel bruger, og derfor er der ingen, der specifikt vil løse mit problem, men der er et forum på deres hjemmeside, og der kan du prøve at kigge efter muligheder ... Jeg vil ikke kede dig med detaljer. Der er ingen muligheder der.
OM! Vi har købt en ISP-licens!
- Hej, support? Gutter, hjælp!
— Beklager, vi understøtter ikke skurke, der ændrer oprindelige versioner af DBMS. Hvis du vil, er der en mulighed med en alternativ server i Docker.
— Men hvordan kommer brugere og databaser dertil? Til havnearbejder?
- Nå, du trækker dem derhen med dine hænder...
- Ja! Og glem ikke, at porten for mysql vil ændre sig, og du bliver nødt til at gennemgå alle konfigurationerne og omskrive dem.
- Ok, tak, jeg vil tænke over det...
Jeg tænkte over det og besluttede mig for manuelt at rive 10.4 ned og installere 10.2, som der ikke var problemer med på andre servere.
Processen var ikke meget anderledes end opdateringsprocessen. Jeg skulle bare ændre 10.4 til 10.2 i linket til depotet, nulstille og genskabe cachen til yum. Nå, en "lille ting" mere: efter at have fjernet 10.4, gå til /var/lib/mysql og slet alt derfra. Uden dette trin efter installation af 10.2 vil tjenesten konstant gå ned, og du vil se
Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"eller
Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104Inden jeg importerede databaserne, satte jeg først root-adgangskoden til mysql, der var angivet i ISP-konfigurationerne, og importerede mysql-databasedumpen. Nå, da vi allerede har brugere og rettigheder, importerer vi simpelthen alle brugerdatabaserne i en række ved hjælp af root-kontoen.
Scripttekst til databasedump:
#!/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'Før du importerer databaser, skal du udpakke dem. Så vi kører bare kommandoen
gunzip /BACK/*.gzOg til sidst: af en eller anden grund er bindestreger tilladt i databasens navn (hvis du opretter den via ISPmanager). Men når du opretter eller forsøger at uploade et dump til en database, der har en bindestreg i navnet, modtager du en besked om, at anmodningssyntaksen er forkert.
Alt det bedste til dem, der læser til slutningen. Jeg undskylder for de mest sandsynlige malplacerede kommaer - de er et problem. Hvis du har forslag til essensen af det beskrevne, så skriv i en personlig besked, fordi jeg er bange for, at jeg går glip af noget i kommentarerne. Og band ikke for meget - dette er min første artikel :)
UPD1:
Jeg glemte næsten at nævne: mens jeg forsøgte at finde en løsning på problemet uden at nedgradere MariaDB, var jeg nødt til på en eller anden måde at opdatere oplysningerne. Det blev opdateret sådan her: hele databasen konverteres fra InnoDB til MyISAM, informationen opdateres og konverteres derefter tilbage til InooDB.
UPD2:
Jeg har lige modtaget et brev fra 1C-Bitrix med følgende indhold:
Anmodning om revision afsluttet
"Efter opgradering af mariadb til 10.4.6 opstod der en fejl ved lagring af et infoblokelement"
Modul: iblock, version: ukendt
Løsning: afvist
Så det er tilsyneladende umuligt at opdatere til 10.4 lige nu 🙁
Kilde: www.habr.com