God dag kära Khabroviter! Tillåt mig att presentera mig själv, Alexander. Systemadministratör för en liten men stolt WEB-studio. Vi vill verkligen att allt ska fungera snabbt, säkert och med fräsch mjukvara. För att göra detta höjde vi till och med nagios + PhantomJS-paketet på interndatorn och kontrollerade sidladdningshastigheten var 30:e minut. Enligt användarvillkoren övervakar vi även 1C-Bitrix-uppdateringar och installerar dem regelbundet. Och så en dag, efter nästa uppdatering, ser vi ett meddelande i adminpanelen som säger att sedan sommaren 2019 slutar 1C-Bitrix att fungera med MySQL 5.5 och behöver uppdateras. Killarna från ISPSystem är snygga och utökar regelbundet panelens funktionalitet, för vilket särskilt tack till dem. Men den här gången gick det inte att klicka på allt med musen. Men vad som hände och hur många gråa hårstrån som nu finns i mitt skägg kan hittas under klippet.
Det fanns bara ett alternativ att installera en "alternativ DBMS-server" som är installerad i Docker-behållaren. Självklart förstår jag att Docker är väldigt sparsam med resurser, men hur bra det än fungerar så kommer omkostnaden fortfarande vara > 0. Och här kämpar vi liksom på tiondels sekunder och optimerar alla sajter vid entrén innan vi publicerar och skriver på ett avtal. Så inte mitt val.
Ok, vad står i dokumentationen? Säkerhetskopiera allt, lägg till en fil med en länk till MariaDB-förvaret till yum.repos.d, sedan
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum kommer senare att svära på det faktum att någon tog bort paketen utan hans vetskap. Men först - låt honom svära, det är okej. Och för det andra, om du gör raderingen genom yum, så försöker den, tillsammans med MariaDB, riva allt som är relaterat till det av beroenden, och det här är PHP och ISPManager och PHPmyadmin. Så vi ska ta itu med buggarna senare.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonI allmänhet sattes allt upp och startade. Det fina är att baserna plockades upp och det var inte nödvändigt att återställa dem från soptippar. Jag kollade på sajterna - de fungerar och snabbt. Jag gick till ett par adminpaneler för att se till att inget ramlade av och avregistrerade regissören att allt var OK. På mindre än 30 minuter visade det sig att det inte ens var OK alls ...
När jag försökte gå till adminpanelen och lägga till redigera vad som helst i innehållet föll ett meddelande ut
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']Eftersom innehållet på sajten läggs till av våra anställda, visste kunderna fortfarande ingenting och hade ännu inte börjat slita isär oss. Men det var en tidsfråga, eftersom informationen på sajterna behöver uppdateras, och många kunder följer detta mycket noga.
Från texten till felet kan vi dra slutsatsen att Bitrix försöker lägga till en ny post i databasen, samtidigt som den anger samma primärnyckel som artikeln som redigeras hade. Så det finns anledning att misstänka att problemet uppstår på sidan av Bitrix. Gå till deras hemsida och kontakta supporten. Nästan direkt får vi svaret ”svårt problem. Ges till senior ingenjörer - vänta ... "
Jag fick vänta ganska länge (hela dialogen ägde rum från 25.06.2019/9.07.2019/10.4.6 till XNUMX/XNUMX/XNUMX) och resultatet blev meddelandet "det här problemet är inte relaterat till driften av Bitrix CMS, men är relaterat till driften av själva databasen i mariadb XNUMX och, tyvärr, med sidan av webbplatsen för att lösa detta problem saknas, kommer det att vara nödvändigt att migrera till en äldre version av MariaDB.”
Seglade ... Jag tänkte på nedgradering i början av historien, men att det inte kan bli någon nedgradering. Slå samman dumpar och distribuera om på en nyinstallerad server. De där. det är bra att jag inte uppdaterade alla servrar på en gång. De där. "bara" hundra sajter (nervöst skratt :-)). De sa också till stöd: "För att lösa problemet när du använder MariaDB 10.4.6-databasen måste du kontakta MariaDB tekniska support att transaktionen inte kommer att radera en post från databasen om en begäran görs:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
Hoppet glimmade i ett par timmar från det att vi började kommunicera med MariaDB support, men sedan fick jag ett brev där jag ytterst korrekt informerades om att jag inte var en kommersiell användare och därför skulle ingen målmedvetet lösa mitt problem, men det finns ett forum på deras hemsida och du kan försöka leta efter alternativ där ... Jag kommer inte att tråka ut dig med detaljer. Det finns inga alternativ där.
HANDLA OM! Vi har köpt en licens för ISP!
Hej, support? Killar, hjälp!
- Tyvärr, vi stöder inte ligister som ändrar inhemska versioner av DBMS. Om du vill finns det ett alternativ med en alternativ server i docker.
– Men hur ska användare och databaser komma dit? Till hamnarbetare?
- Tja, du drar dit dem med händerna ...
- Ja! Och glöm inte att porten för mysql kommer att ändras och du måste gå igenom och skriva om alla konfigurationer.
Ok tack, jag ska fundera på det...
Jag tänkte och bestämde mig för att riva 10.4 med handtag och installera 10.2 som det inte var några problem med på andra servrar.
Processen skilde sig inte mycket från uppgraderingsprocessen. Bara det var nödvändigt att ändra 10.4 till 10.2 i länken till förvaret, återställa och återskapa cachen för yum. Nåväl, en "bagatell" till: efter att ha tagit bort 10.4 går vi till /var/lib/mysql och tar bort allt därifrån. Utan detta steg, efter installation av 10.2, kommer tjänsten ständigt att krascha och du kommer att 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: 104Innan jag importerade databaserna ställde jag först in mysql root-lösenordet som specificerades i ISP-konfigurationerna och importerade mysql-databasdumpen. Tja, då, eftersom det redan finns användare och rättigheter, importerar vi helt enkelt alla användardatabaser i rad med root-kontot.
Skripttext för databasdump:
#!/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'Innan du importerar databaser måste du packa upp dem. Så kör bara kommandot
gunzip /BACK/*.gzOch det sista: av någon anledning är bindestreck tillåtna i databasnamn (om du skapar dem med ISPmanager). Men när du skapar eller försöker ladda upp en dump till en databas som har ett bindestreck i namnet får du ett meddelande om att frågesyntaxen är felaktig.
Läs till slutet av alla välsignelser. Jag ber om ursäkt för de mest troliga kommatecken som inte är mellanrum - de har problem. Om det finns önskemål om ett förslag i huvudsak beskrivet - skriv i en personlig för i kommentarerna är jag rädd att missa något. Och svär inte för mycket - det här är min första artikel 🙂
UPD1:
Jag glömde nästan att nämna: medan jag försökte hitta en lösning på problemet utan att nedgradera MariaDB, var jag tvungen att uppdatera informationen på något sätt. Den uppdaterades så här: hela databasen konverteras från InnoDB till MyISAM, infa uppdateras och konverteras sedan tillbaka till InooDB.
UPD2:
Fick precis ett brev från 1C-Bitrix med följande innehåll:
Revisionsbegäran slutförd
"Efter att ha uppdaterat mariadb till 10.4.6, uppstod ett fel när infoblockelementet skulle sparas"
Modul: iblock, version: okänd
Lösning: avvisad
Så för tillfället är det tydligen omöjligt att uppdatera till 10.4 🙁
Källa: will.com