Tere päevast, kallid Khabrovites! Lubage mul end tutvustada, Aleksander. Ühe väikese, kuid uhke WEB-stuudio süsteemiadministraator. Me tõesti tahame, et kõik töötaks kiiresti, turvaliselt ja värske tarkvaraga. Selleks tõstsime isegi kontorisisesesse arvutisse nagios + PhantomJS kimbu ja iga 30 minuti järel kontrollime lehe laadimise kiirust. Vastavalt teenusetingimustele jälgime ka 1C-Bitrixi värskendusi ja installime neid regulaarselt. Ja siis ühel päeval, pärast järgmist värskendust, näeme administraatoripaneelil teadet, mis ütleb, et alates 2019. aasta suvest lõpetab 1C-Bitrix töö MySQL 5.5-ga ja vajab värskendamist. ISPSystemi poisid on nägusad ja laiendavad regulaarselt paneeli funktsionaalsust, mille eest on neile eriline tänu. Aga seekord ei saanud kõike hiirega klõpsida. Aga mis juhtus ja kui palju halli juukseid nüüd habemes on, leiab lõike alt.
Seal oli ainult võimalus installida "alternatiivne DBMS-server", mis on installitud Dockeri konteinerisse. Muidugi saan aru, et Docker on ressurssidega väga kokkuhoidlik, aga ükskõik kui hästi see ka ei töötaks, on üldkulud ikkagi > 0. Ja siin me justkui võitleme kümnendiku sekunditega ja optimeerime kõik saidid sissepääsu juures enne avaldamist ja lepingu allkirjastamist. Nii et mitte minu valik.
Ok, mis on dokumentatsioonis? Varundage kõik, lisage failile yum.repos.d fail koos lingiga MariaDB hoidlale ja seejärel
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum vannub hiljem, et keegi tema teadmata pakid eemaldas. Aga esiteks – las ta vannub, pole midagi. Ja teiseks, kui teete kustutamise yumi kaudu, siis proovib see koos MariaDB-ga lammutada kõike, mis on sellega seotud sõltuvuste kaudu, ja see on PHP ja ISPManager ja PHPmyadmin. Nii et me tegeleme vigadega hiljem.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonÜldiselt sai kõik paika pandud ja käima lükatud. Tore on see, et alused said üles korjatud ja neid polnud vaja prügimäelt taastada. Kontrollisin saite - need töötavad ja kiiresti. Käisin paaris admin paneelis veendumaks, et midagi ära ei kukuks ja loobusin direktorile tellimusest, et kõik on korras. Vähem kui 30 minutiga selgus, et see pole isegi üldse korras ...
Kui proovisin minna administraatori paneelile ja lisada sisusse midagi muud, kukkus välja teade
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']Kuna saidi sisu lisavad meie töötajad, ei teadnud kliendid ikka veel midagi ega hakanud meid veel lõhki kiskuma. Kuid see oli aja küsimus, sest saitidel olevat teavet tuleb uuendada ja paljud kliendid jälgivad seda väga tähelepanelikult.
Vea tekstist võime järeldada, et Bitrix üritab andmebaasi lisada uut kirjet, määrates samal ajal sama primaarvõtme, mis redigeeritaval artiklil oli. Seega on põhjust kahtlustada, et probleem ilmneb Bitrixi poolel. Minge nende veebisaidile ja võtke ühendust toega. Peaaegu kohe saame vastuse „raske probleem. Andsin selle vaneminseneridele - oodake ... "
Pidin päris kaua ootama (kogu dialoog toimus 25.06.2019-9.07.2019) ja tulemuseks oli teade “see probleem ei ole seotud Bitrix CMS-i tööga, vaid on seotud andmebaasi enda toimimisele mariadb versioonis 10.4.6 ja kahjuks saidi poolel puudub see võimalus selle probleemi lahendamiseks, tuleb migreeruda MariaDB vanale versioonile.
Purjetatud ... Ma mõtlesin loo alguses alandamisele, kuid et alandada ei saa. Ühendage prügimäed ja paigutage need ümber värskelt installitud serverisse. Need. hea, et ma kõiki servereid korraga ei uuendanud. Need. “ainult” sada saiti (närviline naeratus :-)). Nad ütlesid ka toetuseks: "MariaDB 10.4.6 andmebaasi kasutamisel probleemi lahendamiseks peate võtma ühendust MariaDB tehnilise toega, et tehing ei kustutaks kirjet andmebaasist, kui esitatakse päring:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
Lootus säras paariks tunniks hetkest, kui MariaDB toega suhtlema hakkasime, kuid siis sain kirja, kus mulle anti üliõigesti teada, et ma ei ole kommertskasutaja ja seetõttu ei hakka keegi mu probleemi sihikindlalt lahendama, kuid foorum nende veebisaidil ja võite proovida sealt võimalusi otsida... Ma ei tüüta teid üksikasjadega. Seal pole valikuid.
KOHTA! Ostsime ISP litsentsi!
Tere, tugi? Poisid, aidake!
- Kahjuks me ei toeta pätte, kes muudavad DBMS-i algversioone. Kui soovite, on dockeris võimalus kasutada alternatiivset serverit.
- Aga kuidas kasutajad ja andmebaasid sinna jõuavad? Dockerisse?
- Noh, sa lohistad nad oma kätega sinna ...
- Jah! Ja ärge unustage, et mysql-i port muutub ja peate kõik konfiguratsioonid läbi tegema ja ümber kirjutama.
Ok aitäh, ma mõtlen selle üle...
Mõtlesin ja otsustasin käepidemetega 10.4 lammutada ja paigaldada 10.2 millega teistes serverites probleeme polnud.
Protsess ei erinenud palju uuendusprotsessist. Ainult hoidla lingis oli vaja muuta 10.4 10.2-ks, lähtestada ja yumi vahemälu uuesti luua. Noh, veel üks pisiasi: pärast 10.4 eemaldamist läheme /var/lib/mysql-i ja kustutame sealt kõik. Ilma selle sammuta jookseb teenus pärast versiooni 10.2 installimist pidevalt kokku ja näete
Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"Või
Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104Enne andmebaaside importimist määrasin esmalt mysql root parooli, mis oli määratud ISP seadistustes ja importisin mysql andmebaasi dump. Noh, kuna kasutajad ja õigused on juba olemas, siis impordime kõik kasutajate andmebaasid järjest juurkontoga.
Andmebaasi väljavõtte skripti tekst:
#!/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'Enne andmebaaside importimist peate need lahti pakkima. Nii et lihtsalt käivitage käsk
gunzip /BACK/*.gzJa viimane asi: mingil põhjusel on sidekriipsud andmebaasinimedes lubatud (kui loote need ISPmanageriga). Kuid kui loote või proovite üles laadida andmebaasi, mille nimes on sidekriips, kuvatakse teade, et päringu süntaks on vale.
Lugege kõik õnnistused lõpuni. Vabandan suure tõenäosusega mittevaheliste komade pärast – need on hädas. Kui on soove sisuliselt kirjeldatud ettepanekule - kirjutage isiklikult, sest kommentaarides kardan millestki ilma jääda. Ja ärge vannuge liiga palju - see on minu esimene artikkel 🙂
UPD1:
Peaaegu unustasin mainida: kui ma püüdsin probleemile lahendust leida ilma MariaDB versiooni alandamiseta, pidin teavet kuidagi värskendama. Uuendati nii: kogu andmebaas teisendatakse InnoDB-st MyISAMiks, uuendatakse infa-d ja teisendatakse seejärel tagasi InooDB-ks.
UPD2:
Sain just 1C-Bitrixilt järgmise sisuga kirja:
Revisjonitaotlus on täidetud
"Pärast mariadb värskendamist versioonile 10.4.6 ilmnes infobloki elemendi salvestamisel viga"
Moodul: iblock, versioon: teadmata
Lahendus: tagasi lükatud
Nii et praegu on ilmselt võimatu värskendada versioonile 10.4 🙁
Allikas: www.habr.com