God dag, kjære Khabroviter! Tillat meg å introdusere meg selv, Alexander. Systemadministrator for ett lite, men stolt WEB-studio. Vi ønsker virkelig at alt skal fungere raskt, trygt og med fersk programvare. For å gjøre dette, hevet vi til og med nagios + PhantomJS-pakken på den interne datamaskinen og sjekker sideinnlastingshastigheten hvert 30. minutt. I henhold til tjenestevilkårene overvåker vi også 1C-Bitrix-oppdateringer og installerer dem regelmessig. Og så en dag, etter neste oppdatering, ser vi en melding i adminpanelet som sier at siden sommeren 2019 slutter 1C-Bitrix å fungere med MySQL 5.5 og må oppdateres. Gutta fra ISPSystem er kjekke og utvider regelmessig funksjonaliteten til panelet, som en spesiell takk til dem. Men denne gangen var det ikke mulig å klikke alt med musa. Men hva som skjedde og hvor mange grå hår som nå er i skjegget mitt, kan du finne under kuttet.
Det var bare et alternativ for å installere en "alternativ DBMS-server" som er installert i Docker-beholderen. Selvfølgelig forstår jeg at Docker er veldig sparsommelig med ressurser, men uansett hvor bra det fungerer, vil overhead fortsatt være > 0. Og her kjemper vi liksom på tideler av sekunder og optimaliserer alle sider ved inngangen før vi publiserer og signerer en avtale. Så ikke mitt valg.
Ok, hva står i dokumentasjonen? Sikkerhetskopier alt, legg til en fil med en lenke til MariaDB-depotet til yum.repos.d, og deretter
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum vil senere banne på det faktum at noen fjernet pakkene uten hans viten. Men først - la ham banne, det er greit. Og for det andre, hvis du sletter gjennom yum, så prøver den å rive, sammen med MariaDB, alt som er relatert til den av avhengigheter, og dette er PHP og ISPManager og PHPmyadmin. Så vi skal håndtere feilene senere.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonGenerelt ble alt satt opp og startet. Det fine er at basene ble plukket opp og det var ikke nødvendig å restaurere dem fra dumping. Jeg sjekket sidene - de fungerer og raskt. Jeg gikk til et par admin-paneler for å forsikre meg om at ingenting falt av og sa opp direktøren om at alt var i orden. På mindre enn 30 minutter viste det seg at det ikke engang var OK i det hele tatt ...
Da jeg prøvde å gå til administrasjonspanelet og legge til å redigere noe i innholdet, falt det ut en melding
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']Siden innholdet på siden er lagt til av våre ansatte, visste ikke kundene noe og hadde ennå ikke begynt å rive oss fra hverandre. Men det var et spørsmål om tid, for informasjonen på sidene må oppdateres, og mange kunder følger dette veldig nøye.
Fra teksten til feilen kan vi konkludere med at Bitrix prøver å legge til en ny post i databasen, mens den spesifiserer den samme primærnøkkelen som artikkelen som redigeres hadde. Så det er grunn til å mistenke at problemet oppstår på siden av Bitrix. Gå til nettsiden deres og kontakt support. Nesten umiddelbart får vi svaret «vanskelig problem. Ga det til senioringeniører - vent ... "
Jeg måtte vente ganske lenge (hele dialogen fant sted fra 25.06.2019 til 9.07.2019) og resultatet var meldingen "dette problemet er ikke relatert til driften av Bitrix CMS, men er relatert til driften av selve databasen i mariadb 10.4.6, og dessverre, med siden av nettstedet for å løse dette problemet mangler, vil det være nødvendig å migrere til en eldre versjon av MariaDB.
Seilte ... Jeg tenkte på nedgradering i begynnelsen av historien, men at det ikke kan være noen nedgradering. Slå sammen dumper og omdistribuer på en nyinstallert server. De. det er bra at jeg ikke oppdaterte alle serverne samtidig. De. "bare" hundre nettsteder (nervøs latter :-)). De sa også til støtte: "For å løse problemet når du bruker MariaDB 10.4.6-databasen, må du kontakte MariaDB teknisk støtte om at transaksjonen ikke vil slette en post fra databasen hvis en forespørsel blir gjort:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
Håpet lyste i et par timer fra det øyeblikket vi begynte å kommunisere med MariaDB-support, men så mottok jeg et brev der jeg ble ekstremt korrekt informert om at jeg ikke var en kommersiell bruker og derfor ingen målrettet ville løse problemet mitt, men det er et forum på nettsiden deres, og du kan prøve å se etter alternativer der ... Jeg skal ikke kjede deg med detaljer. Det er ingen alternativer der.
OM! Vi har kjøpt en lisens for ISP!
Hei, støtte? Gutter, hjelp!
- Beklager, vi støtter ikke kjeltringer som endrer opprinnelige versjoner av DBMS. Hvis du vil, er det et alternativ med en alternativ server i docker.
– Men hvordan skal brukere og databaser komme dit? Til havnearbeider?
- Vel, du drar dem dit med hendene ...
– Ja! Og ikke glem at porten for mysql vil endres, og du må gå gjennom og omskrive alle konfigurasjonene.
Ok takk, jeg skal tenke på det...
Jeg tenkte og bestemte meg for å rive 10.4 med håndtak og installere 10.2 som det ikke var noen problemer med på andre servere.
Prosessen var ikke mye forskjellig fra oppgraderingsprosessen. Bare det var nødvendig å endre 10.4 til 10.2 i lenken til depotet, tilbakestille og gjenopprette cachen for yum. Vel, en "bagatell" til: etter å ha fjernet 10.4, går vi til /var/lib/mysql og sletter alt derfra. Uten dette trinnet, etter installasjon av 10.2, vil tjenesten konstant krasje, 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: 104Før jeg importerte databasene, satte jeg først mysql root-passordet som ble spesifisert i ISP-konfigurasjonene og importerte mysql-databasedumpen. Vel, da, siden det allerede er brukere og rettigheter, importerer vi ganske enkelt alle brukerdatabasene på rad med root-kontoen.
Skripttekst for 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, må du pakke dem ut. Så bare kjør kommandoen
gunzip /BACK/*.gzOg den siste tingen: av en eller annen grunn er bindestreker tillatt i databasenavn (hvis du oppretter dem ved hjelp av ISPmanager). Men når du oppretter eller prøver å laste opp en dump til en database som har en bindestrek i navnet, får du en melding om at søkesyntaksen er feil.
Les til slutten av alle velsignelsene. Jeg beklager mest sannsynlig ikke mellomrom - de er i trøbbel. Hvis det er ønsker om et forslag i hovedsak beskrevet - skriv i en personlig fordi jeg er redd for å gå glipp av noe i kommentarfeltet. Og ikke banne for mye - dette er min første artikkel 🙂
UPD1:
Jeg glemte nesten å nevne: mens jeg prøvde å finne en løsning på problemet uten å nedgradere MariaDB, måtte jeg på en eller annen måte oppdatere informasjonen. Den ble oppdatert slik: hele databasen konverteres fra InnoDB til MyISAM, infa oppdateres og konverteres deretter tilbake til InooDB.
UPD2:
Fikk nettopp et brev fra 1C-Bitrix med følgende innhold:
Revisjonsforespørsel fullført
"Etter å ha oppdatert mariadb til 10.4.6, oppstod det en feil ved lagring av infoblokkelementet"
Modul: iblock, versjon: ukjent
Løsning: avvist
Så foreløpig er det tilsynelatende umulig å oppdatere til 10.4 🙁
Kilde: www.habr.com