Laba diena, mieli chabroviečiai! Leiskite man prisistatyti, Aleksandrai. Vienos nedidelės, bet išdidžios WEB studijos sistemos administratorius. Labai norime, kad viskas veiktų greitai, saugiai ir naudojant naują programinę įrangą. Norėdami tai padaryti, mes netgi pakėlėme nagios + PhantomJS paketą biuro kompiuteryje ir tikriname puslapio įkėlimo greitį kas 30 minučių. Pagal paslaugų teikimo sąlygas taip pat stebime 1C-Bitrix naujinimus ir reguliariai juos diegiame. Ir tada vieną dieną, po kito atnaujinimo, administratoriaus skydelyje matome pranešimą, kad nuo 2019 m. vasaros 1C-Bitrix nustoja veikti su MySQL 5.5 ir jį reikia atnaujinti. Vaikinai iš ISPSystem yra gražūs ir nuolat plečia skydelio funkcionalumą, už ką jiems ypatinga ačiū. Tačiau šį kartą nepavyko visko spustelėti pele. Bet kas atsitiko ir kiek žilų plaukų dabar yra mano barzdoje, galima rasti po pjūviu.
Buvo tik galimybė įdiegti „alternatyvų DBVS serverį“, kuris yra įdiegtas „Docker“ konteineryje. Žinoma, aš suprantu, kad Docker labai taupo išteklius, bet kad ir kaip puikiai jis veiktų, pridėtinės išlaidos vis tiek bus > 0. Ir štai mes tarsi kovojame per dešimtąsias sekundžių ir optimizuojame visas svetaines prie įėjimo prieš paskelbiant ir pasirašant sutartį. Taigi ne mano pasirinkimas.
Gerai, kas parašyta dokumentacijoje? Viską sukurkite atsarginę kopiją, pridėkite failą su nuoroda į MariaDB saugyklą į yum.repos.d, tada
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum vėliau prisiekia, kad kažkas išėmė pakuotes be jo žinios. Bet pirmiausia – tegul prisiekia, viskas gerai. Ir antra, jei ištrinate per yum, tada jis kartu su MariaDB bando sugriauti viską, kas su juo susiję priklausomybėmis, tai yra PHP ir ISPManager bei PHPmyadmin. Taigi su klaidomis spręsime vėliau.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonApskritai viskas buvo nustatyta ir pradėta. Gražu tai, kad bazės buvo paimtos ir nereikėjo jų atkurti iš sąvartynų. Patikrinau svetaines - veikia ir greitai. Nuėjau į porą admin panelių, kad įsitikinčiau, ar niekas nenukrenta, ir atsisakiau direktoriaus prenumeratos, kad viskas gerai. Per mažiau nei 30 minučių paaiškėjo, kad tai net negerai ...
Kai bandžiau eiti į administratoriaus skydelį ir pridėti bet ką redaguoti turinyje, iškrito pranešimas
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']Kadangi turinį svetainėje prideda mūsų darbuotojai, klientai dar nieko nežinojo ir dar nepradėjo mūsų skaldyti. Tačiau tai buvo laiko klausimas, nes informaciją svetainėse reikia atnaujinti, o daugelis klientų tai labai atidžiai seka.
Iš klaidos teksto galime daryti išvadą, kad Bitrix bando į duomenų bazę įtraukti naują įrašą, nurodydama tą patį pirminį raktą, kurį turėjo redaguojamas straipsnis. Taigi yra pagrindo įtarti, kad problema kyla „Bitrix“ pusėje. Eikite į jų svetainę ir susisiekite su palaikymo tarnyba. Beveik iš karto gauname atsakymą „sudėtinga problema. Skirta vyresniems inžinieriams - palaukite ... "
Teko laukti gana ilgai (visas dialogas vyko nuo 25.06.2019-9.07.2019-10.4.6 iki XNUMX-XNUMX-XNUMX) ir rezultatas buvo pranešimas „ši problema nesusijusi su Bitrix CMS veikimu, bet susijusi pačios duomenų bazės veikimui mariadb XNUMX ir, deja, trūksta svetainės pusės šiai problemai išspręsti, reikės pereiti prie senesnės MariaDB versijos.
Išplaukė... Istorijos pradžioje galvojau apie pažeminimą, bet kad negali būti pažeminimo. Sujunkite sąvartynus ir perskirstykite naujai įdiegtame serveryje. Tie. gerai, kad neatnaujinau visų serverių iš karto. Tie. "tik" šimtas svetainių (nervinis kikenimas :-)). Jie taip pat palaikydavo: „Norėdami išspręsti problemą, kai naudojatės MariaDB 10.4.6 duomenų baze, turėsite susisiekti su MariaDB technine pagalba, kad atlikus operaciją nebūtų ištrintas įrašas iš duomenų bazės, jei bus pateikta užklausa:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
Nuo tada, kai pradėjome bendrauti su MariaDB palaikymu, viltis blykčiojo porą valandų, tačiau tada gavau laišką, kuriame buvau itin teisingai informuotas, kad nesu komercinis vartotojas, todėl niekas tikslingai neišspręs mano problemos, tačiau yra forumas jų svetainėje ir jūs galite pabandyti ten ieškoti variantų... Nevarginsiu jūsų smulkmenomis. Ten nėra variantų.
APIE! Įsigijome IPT licenciją!
Sveiki, palaikote? Vaikinai, padėk!
- Atsiprašome, mes nepalaikome banditų, kurie keičia vietines DBVS versijas. Jei norite, yra galimybė naudoti alternatyvų serverį „Docker“.
– Bet kaip ten pateks vartotojai ir duomenų bazės? Į dokerį?
- Na, tu tempk juos ten rankomis ...
- Taip! Ir nepamirškite, kad mysql prievadas pasikeis ir jums reikės pereiti ir perrašyti visas konfigūracijas.
Gerai, ačiū, pagalvosiu...
Pagalvojau ir nusprendžiau nugriauti 10.4 su rankenomis ir įdiegti 10.2 su kuriuo kituose serveriuose nebuvo jokių problemų.
Procesas nedaug skyrėsi nuo atnaujinimo proceso. Tik reikėjo pakeisti 10.4 į 10.2 nuorodoje į saugyklą, iš naujo nustatyti ir iš naujo sukurti yum talpyklą. Na, dar viena „smulkmena“: pašalinę 10.4 einame į /var/lib/mysql ir iš ten ištriname viską. Be šio žingsnio, įdiegus 10.2, paslauga nuolat strigs ir pamatysite
Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"Or
Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104Prieš importuodamas duomenų bazes, pirmiausia nustatiau mysql root slaptažodį, kuris buvo nurodytas IPT konfigūracijose, ir importavau mysql duomenų bazės iškeltą. Na, o tada, kadangi jau yra vartotojų ir teisių, mes tiesiog importuojame visas vartotojų duomenų bazes iš eilės su root paskyra.
Duomenų bazės iškelties scenarijaus tekstas:
#!/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'Prieš importuodami duomenų bazes, turite jas išpakuoti. Taigi tiesiog paleiskite komandą
gunzip /BACK/*.gzIr paskutinis dalykas: dėl tam tikrų priežasčių duomenų bazių pavadinimuose yra leidžiami brūkšneliai (jei juos kuriate naudodami ISPmanager). Tačiau kai kuriate arba bandote įkelti išklotinę į duomenų bazę, kurios pavadinime yra brūkšnelis, gaunate pranešimą, kad užklausos sintaksė yra neteisinga.
Perskaitykite iki visų palaiminimų pabaigos. Atsiprašau už greičiausiai neišdėtus kablelius – jiems bėda. Jei yra pageidavimų dėl pasiūlymo iš esmės aprašyta - rašykite asmenine, nes komentaruose bijau ką nors praleisti. Ir per daug neprisiekti – tai pirmasis mano straipsnis 🙂
UPD1:
Beveik pamiršau paminėti: kol bandžiau rasti problemos sprendimą nesumažindamas MariaDB, turėjau kažkaip atnaujinti informaciją. Jis buvo atnaujintas taip: visa duomenų bazė konvertuojama iš InnoDB į MyISAM, atnaujinama infa ir vėl konvertuojama į InooDB.
UPD2:
Ką tik gavau laišką iš 1C-Bitrix su tokiu turiniu:
Patikslinimo užklausa baigta
"Atnaujinus mariadb į 10.4.6, išsaugant informacijos bloko elementą įvyko klaida"
Modulis: iblock, versija: nežinoma
Sprendimas: atmesta
Taigi kol kas, matyt, neįmanoma atnaujinti į 10.4 🙁
Šaltinis: www.habr.com