Hyvää päivää, rakkaat habrovilaiset! Sallikaa minun esitellä itseni, Alexander. Yhden pienen mutta ylpeän WEB-studion järjestelmävastaava. Haluamme todella, että kaikki toimii nopeasti, turvallisesti ja uusilla ohjelmistoilla. Tätä varten nostimme jopa nagios + PhantomJS -nipun toimiston sisäiseen tietokoneeseen ja tarkistamme 30 minuutin välein sivun latausnopeuden. Palveluehtojen mukaisesti seuraamme myös 1C-Bitrixin päivityksiä ja asennamme ne säännöllisesti. Ja sitten eräänä päivänä, seuraavan päivityksen jälkeen, näemme hallintapaneelissa viestin, jossa todetaan, että kesästä 2019 lähtien 1C-Bitrix lakkaa toimimasta MySQL 5.5:n kanssa ja se on päivitettävä. ISPSystemin kaverit ovat komeita ja laajentavat säännöllisesti paneelin toimivuutta, mistä heille erityinen kiitos. Mutta tällä kertaa ei ollut mahdollista napsauttaa kaikkea hiirellä. Mutta mitä tapahtui ja kuinka monta harmaata karvaa parrassani on nyt, löytyy leikkauksen alta.
Oli vain vaihtoehto asentaa "vaihtoehtoinen DBMS-palvelin", joka on asennettu Docker-säilöön. Tietenkin ymmärrän, että Docker on erittäin säästäväinen resurssien kanssa, mutta riippumatta siitä, kuinka hyvin se toimii, yleiskustannukset ovat silti > 0. Ja tässä olemme ikään kuin taistelemassa sekunneissa ja optimoimassa kaikki sivustot sisäänkäynnin kohdalla ennen julkaisua ja sopimuksen allekirjoittamista. Ei siis minun valintani.
Ok, mitä asiakirjoissa on? Varmuuskopioi kaikki, lisää tiedosto, jossa on linkki MariaDB-tietovarastoon osoitteeseen yum.repos.d, ja sitten
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum vannoo myöhemmin, että joku poisti paketit hänen tietämättään. Mutta ensin - anna hänen vannoa, se on okei. Ja toiseksi, jos teet poiston yumin kautta, se yrittää purkaa MariaDB:n kanssa kaiken, mikä siihen liittyy riippuvuuksilla, ja tämä on PHP ja ISPManager ja PHPmyadmin. Joten käsittelemme vikoja myöhemmin.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonYleensä kaikki oli asetettu ja aloitettu. Hienoa on, että alustat poimittiin ja niitä ei tarvinnut palauttaa kaatopaikoilta. Tarkistin sivustot - ne toimivat ja nopeasti. Kävin parissa admin paneelissa varmistaakseni, että mikään ei putoa, ja peruutin ohjaajan tilauksen, että kaikki oli kunnossa. Alle 30 minuutissa kävi ilmi, että se ei ollut edes kunnossa...
Kun yritin mennä hallintapaneeliin ja lisätä mitä tahansa sisältöön muokkausta, sieltä putosi viesti
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']Koska sivuston sisällön ovat lisänneet työntekijämme, asiakkaat eivät vielä tienneet mitään eivätkä olleet vielä alkaneet repiä meitä erilleen. Mutta se oli ajan kysymys, koska sivustojen tiedot on päivitettävä, ja monet asiakkaat seuraavat tätä erittäin tarkasti.
Virheen tekstistä voimme päätellä, että Bitrix yrittää lisätä tietokantaan uutta tietuetta, mutta samalla määrittää saman ensisijaisen avaimen, joka oli muokattavalla artikkelilla. Joten on syytä epäillä, että ongelma ilmenee Bitrixin puolella. Mene heidän verkkosivustolleen ja ota yhteyttä tukeen. Melkein heti saamme vastauksen "vaikea ongelma. Annoit sen vanhemmille insinööreille - odota ... "
Jouduin odottamaan melko kauan (koko dialogi tapahtui 25.06.2019-9.07.2019) ja tuloksena oli viesti "tämä ongelma ei liity Bitrix CMS:n toimintaan, vaan liittyy Itse tietokannan toiminnalle mariadb 10.4.6:ssa ja valitettavasti sivuston puolelta tämän ongelman ratkaiseminen puuttuu, on tarpeen siirtyä MariaDB:n vanhaan versioon."
Purjehtii... Ajattelin laskea alentaa tarinan alussa, mutta että alentaa ei voi olla. Yhdistä vedokset ja asenna ne uudelleen juuri asennetulle palvelimelle. Nuo. hyvä, etten päivittänyt kaikkia palvelimia kerralla. Nuo. "vain" sata sivustoa (hermostunut nauru :-)). He sanoivat myös tueksi: "Jos haluat ratkaista ongelman MariaDB 10.4.6 -tietokantaa käytettäessä, sinun on otettava yhteyttä MariaDB:n tekniseen tukeen, että tapahtuma ei poista tietuetta tietokannasta, jos pyyntö tehdään:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
Toivo välähti pari tuntia siitä hetkestä, kun aloimme kommunikoida MariaDB-tuen kanssa, mutta sitten sain kirjeen, jossa minulle ilmoitettiin erittäin oikein, että en ole kaupallinen käyttäjä ja siksi kukaan ei tarkoituksella ratkaise ongelmaani, mutta foorumi heidän verkkosivuillaan ja voit yrittää etsiä sieltä vaihtoehtoja… En kyllästy teitä yksityiskohdilla. Siellä ei ole vaihtoehtoja.
NOIN! Olemme ostaneet lisenssin ISP:lle!
Hei tuki? Kaverit, auttakaa!
- Valitettavasti emme tue roistoja, jotka vaihtavat DBMS:n alkuperäisiä versioita. Jos haluat, Dockerissa on vaihtoehto vaihtoehtoisella palvelimella.
- Mutta miten käyttäjät ja tietokannat pääsevät sinne? Telakkariin?
- No, vedät ne sinne käsilläsi...
- Joo! Ja älä unohda, että mysql:n portti muuttuu ja sinun täytyy käydä läpi ja kirjoittaa uudelleen kaikki asetukset.
Okei kiitos, mietin asiaa...
Ajattelin ja päätin purkaa kahvallisen 10.4:n ja asentaa 10.2:n, jonka kanssa ei ollut ongelmia muilla palvelimilla.
Prosessi ei eronnut paljon päivitysprosessista. Ainoastaan täytyi muuttaa 10.4 arvoksi 10.2 arkiston linkissä, nollata ja luoda yumin välimuisti uudelleen. No, vielä yksi "pikkuasia": 10.4:n poistamisen jälkeen siirrymme hakemistoon /var/lib/mysql ja poistamme sieltä kaiken. Ilman tätä vaihetta 10.2:n asentamisen jälkeen palvelu kaatuu jatkuvasti ja näet
Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"tai
Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104Ennen tietokantojen tuontia asetin ensin mysql-root-salasanan, joka määritettiin Internet-palveluntarjoajan asetuksissa, ja toin mysql-tietokannan vedostiedoston. No, koska käyttäjiä ja oikeuksia on jo olemassa, tuomme yksinkertaisesti kaikki käyttäjätietokannat peräkkäin root-tilillä.
Tietokannan vedosteksti:
#!/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'Ennen kuin tuot tietokannat, sinun on purettava ne. Joten suorita komento
gunzip /BACK/*.gzJa viimeinen asia: jostain syystä yhdysmerkit ovat sallittuja tietokantojen nimissä (jos luot ne ISPmanagerilla). Mutta kun luot vedostiedoston tai yrität ladata sitä tietokantaan, jonka nimessä on yhdysmerkki, saat viestin, että kyselyn syntaksi on virheellinen.
Lue kaikki siunaukset loppuun. Pyydän anteeksi todennäköisimmin väliälyitä pilkkuja - ne ovat pulassa. Jos on toiveita olennaisesti kuvattuun ehdotukseen - kirjoita henkilökohtaisesti, koska kommenteissa pelkään, että missaan jotain. Ja älä vanno liikaa - tämä on ensimmäinen artikkelini 🙂
UPD1:
Melkein unohdin mainita: kun yritin löytää ratkaisua ongelmaan alentamatta MariaDB:tä, minun piti jotenkin päivittää tiedot. Se päivitettiin näin: koko tietokanta muunnetaan InnoDB:stä MyISAMiksi, infa päivitetään ja muunnetaan sitten takaisin InooDB:ksi.
UPD2:
Sain juuri 1C-Bitrixiltä seuraavan sisällön sisältävän kirjeen:
Tarkistuspyyntö suoritettu
"Kun mariadb on päivitetty versioon 10.4.6, tapahtui virhe tallennettaessa infoblock-elementtiä"
Moduuli: iblock, versio: tuntematon
Ratkaisu: hylätty
Joten toistaiseksi ilmeisesti on mahdotonta päivittää versioon 10.4 🙁
Lähde: will.com