God eftermiddag, kære Habrovchane! Tillad mig at præsentere mig selv, Alexander. Systemadministrator for et lille, men stolt WEB-studie. Vi ønsker virkelig, at alt fungerer hurtigt, sikkert og med den nyeste software. Derfor har vi endda sat en kombination af nagios+PhantomJS op på vores interne kontorcomputer, og vi tjekker sideindlæsningshastigheden hver 30. minut. I henhold til servicebetingelserne holder vi også øje med opdateringer til 1C-Bitrix og installerer dem regelmæssigt. Og en dag, efter endnu en opdatering, ser vi en meddelelse i adminpanelet om, at fra sommeren 2019 stopper 1C-Bitrix med at fungere med MySQL 5.5, og vi skal opdatere. Drenge fra ISPSystem gør et fantastisk arbejde og udvider hele tiden funktionaliteten af deres panel, for hvilket de fortjener en særlig tak. Men denne gang kunne jeg ikke bare klikke mig gennem det. Hvad jeg fik ud af det, og hvor mange grå hår jeg nu har i mit skæg, kan du finde ud af under cut.
Der var kun muligheden for at installere "den alternative DB-server", som sættes op i en Docker-container. Jeg forstår selvfølgelig, at Docker er meget ressourcevenlig, men uanset hvor godt det arbejder, vil overhovedet stadig være >0. Vi kæmper for at opnå tiendedel af sekunder, og vi optimerer alle websteder, inden vi offentliggør dem hos os og underskriver kontrakten. Så det var ikke min løsning.
Okay, hvad står der i dokumentationen? Backup af alt, tilføj i yum.repos.d filen med link til MariaDB-repositoriet, derefter
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum vil senere klage over, at nogen har fjernet eller installeret pakker uden dets viden. Men for det første — lad dem klage, der er ikke noget at frygte. Og for det andet, hvis man fjerner via yum, så forsøger det at afinstallere alt, der er afhængigt af MariaDB, hvilket også inkluderer PHP og ISPManager samt PHPmyadmin. Så vi tager os af klagerne senere.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonAlt blev i det hele taget installeret og fungerede. Det er dejligt, at databaserne blev genkendt, og vi ikke behøvede at gendanne dem fra dumps. Jeg tjekkede webstederne — de fungerer hurtigt. Jeg gik ind i et par adminpaneler for at sikre mig, at intet var faldet ud, og skrev til direktøren, at alt var i orden. Der gik ikke 30 minutter, før det viste sig, at alt var langt fra i orden…
Ved forsøg på at få adgang til adminpanelet og tilføje/redigere noget som helst i indholdet dukkede der en besked op
MySQL Query Fejl: 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] Duplikat indtastning '10555' for nøgle 'PRIMARY']Da indholdet til hjemmesiden tilføjes af vores egne medarbejdere, vidste kunderne endnu ikke noget og var endnu ikke begyndt at rive os fra hinanden. Men det var et spørgsmål om tid, da information på hjemmesider skal opdateres, og mange kunder holder øje med det selv og nøje.
Fra fejlmeddelelsen kan man konkludere, at Bitrix forsøger at tilføje en ny post til databasen, mens den angiver den samme primære nøgle som den redigerede artikel. Derfor er der grund til at mistænke, at problemet opstår på Bitrix's side. Lad os gå til deres hjemmeside og kontakte supporten. Næsten straks får vi svaret "kompleks problem. Givet til senior ingeniører - vent..."
Vi måtte vente ret længe (hele dialogen fandt sted fra 25.06.2019 til 09.07.2019), og resultatet blev meddelelsen "dette problem er ikke relateret til arbejdet i CMS Bitrix, men relaterer sig til selve databasen i mariadb 10.4.6, og desværre kan dette problem ikke løses fra hjemmesiden, det er nødvendigt at skifte til en ældre version af MariaDB."
Nu er vi her... Jeg tænkte på downgrade allerede i begyndelsen af historien, men , at der ikke kan være nogen downgrade. Tag backups og geninstaller fra bunden serveren. Altså, det er godt, at jeg ikke opdaterede alle servere på én gang. “Bare” hundrede hjemmesider (nervøs latter:-)). Supporten sagde også: “For at løse problemet ved brug af databasen MariaDB 10.4.6 skal du kontakte teknisk support for MariaDB, da der i transaktionen ikke kan udføres sletning af post fra databasen, hvis der gøres forespørgsel:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);” Håbet holdt sig i et par timer efter samtalens begyndelse med supporten fra MariaDB, men så kom der et brev, hvor jeg meget korrekt blev informeret om, at jeg ikke var kommerciel bruger, og derfor ville ingen målrettet løse mit problem, men der er et forum på deres hjemmeside, hvor man kan forsøge at finde løsninger… Jeg vil ikke trætte med detaljer. Der er ingen løsninger der.
Åh! Vi har jo en købt licens på ISP!
— Hej, support? Drengene, hjælp mig!
— Beklager, vi understøtter ikke afrimere, der ændrer de native versioner af DBMS. Hvis du vil, er der en mulighed med en alternativ server i Docker.
— Men hvordan kommer brugerne og databaserne så ind? I Docker?
— Nå, du må selv få dem derind…
— Ja! Og glem ikke, at porten til MySQL vil ændre sig, og du skal gennemgå alle konfigurationsfiler og omskrive dem.
— Ok, tak, jeg vil tænke over det…
Jeg tænkte over det og besluttede at slette 10.4 og installere 10.2, som ikke har givet problemer på de andre servere.
Processen var ikke særlig forskellig fra opgraderingsprocessen. Man skulle blot ændre linket til repositoryet fra 10.4 til 10.2, nulstille og oprette cachen for yum igen. Og en anden 'detalje': efter at have slettet 10.4, skal vi gå til /var/lib/mysql og slette alt derfra. Uden dette trin vil tjenesten konstant falde, og du vil se
Kunne ikke oprette forbindelse til databasen '' Mistet forbindelse til MySQL-serveren ved 'læse det indledende kommunikationspakke', systemfejl: 104 "Forbindelse nulstillet af peer"Eller
Mistede forbindelsen til MySQL-serveren ved 'handshake: læse det indledende kommunikationspakke', systemfejl: 104Før jeg importerede databaserne, satte jeg først den rodadgangskode til MySQL, som var angivet i ISP-konfigurationerne, og importerede dumpen af MySQL-databasen. Derefter, da brugerne og rettighederne allerede eksisterede, importerede vi simpelthen alle brugerens databaser sekventielt med rodkontoen.
Scripttekst til dump af databaser:
#!/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 man importerer databaserne skal de dekomprimeres. Så vi kører blot kommandoen
gunzip /BACK/*.gzOg til sidst: af en eller anden grund tillades bindestreger i navnet på databaserne (hvis de oprettes via ISPmanager). Men når man prøver at oprette en dump i en database, der har et bindestreg i navnet, får man en besked om, at forespørgslens syntaks er forkert.
For dem, der er nået til slutningen, ønsker jeg alt godt. Beklager nok for manglende kommaer — det er et problem. Hvis der er forslag eller ønsker til det beskrevne — skriv til mig privat, for i kommentarerne frygter jeg, at jeg vil miste noget. Og vær ikke for hård ved mig — det er min første artikel 🙂
OPD1:
Lidt glemte jeg at nævne: mens jeg forsøgte at finde en løsning på problemet uden at nedgradere MariaDB, blev informationen opdateret på følgende måde: hele databasen konverteres fra InnoDB til MyISAM, informationen opdateres, og derefter konverteres den tilbage til InnoDB.
OPD2:
Jeg har netop modtaget en e-mail fra 1C-Bitrix med følgende indhold:
Anmodningen om tilpasning er gennemført
«Efter opgraderingen af MariaDB til 10.4.6 opstod der en fejl ved gemning af elementet i infoblocken»
Modul: iblock, version: ukendt
Løsning: afvist
Så det ser ud til, at vi ikke kan opdatere til 10.4 endnu 🙁
Kilde: habr.com
