Dober dan, dragi prebivalci Khabrovska! Naj se predstavim, Alexander. Sistemski skrbnik enega majhnega, a ponosnega WEB studia. Resnično želimo, da vse deluje hitro, varno in z najnovejšo programsko opremo. Da bi to naredili, smo celo namestili paket nagios+PhantomJS na računalnik v pisarni in preverjamo hitrost nalaganja strani vsakih 30 minut. V skladu s pogoji storitve spremljamo tudi posodobitve 1C-Bitrix in jih redno nameščamo. In potem nekega dne, po naslednji posodobitvi, na skrbniški plošči vidimo sporočilo, da od poletja 2019 1C-Bitrix preneha delovati z MySQL 5.5 in moramo posodobiti. Fantje iz ISPSystema so čedni in redno širijo funkcionalnosti panela, za kar jim gre posebna hvala. A tokrat ni bilo mogoče vsega klikniti z miško. Lahko pa ugotovite, kaj se je zgodilo in koliko sivih las je zdaj v moji bradi pod rezom.
Obstajala je samo možnost namestitve "alternativnega strežnika DBMS", ki je nameščen v vsebniku Docker. Seveda razumem, da je Docker zelo varčen z viri, toda ne glede na to, kako dobro deluje, bodo režijski stroški še vedno >0. In tukaj se zdi, da se borimo v desetinkah sekunde in optimiziramo vsa spletna mesta na vhodu, preden jih objavimo in podpišemo pogodbo. Torej ni moja možnost.
Ok, kaj piše v dokumentaciji? Varnostno kopirajte vse, dodajte datoteko v yum.repos.d s povezavo do repozitorija MariaDB, nato
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum bo naknadno prisegel, da je nekdo izbrisal pakete brez njegove vednosti. Ampak najprej naj priseže, v redu je. In drugič, če brisanje izvedete prek yum, potem poskuša skupaj z MariaDB odstraniti vse, kar je z njim povezano po odvisnosti, in to vključuje PHP in ISPManager ter PHPmyadmin. Zato se bomo s kletvicami ukvarjali kasneje.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonNa splošno je bilo vse nameščeno in zagnano. Dobra stvar je, da so bile zbirke podatkov pobrane in jih ni bilo treba obnoviti iz odlagališč. Preveril sem strani - delujejo in so hitre. Šel sem v nekaj skrbniških območij, da bi se prepričal, da ni kaj odpadlo, in direktorju pisal, da je vse v redu. Manj kot 30 minut kasneje se je izkazalo, da sploh ni OK ...
Ko sem poskušal iti v skrbniško območje in dodati in urediti karkoli v vsebini, se je pojavilo sporočilo
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']Ker vsebine na strani dodajajo naši zaposleni, naročniki še niso vedeli ničesar in nas še niso začeli razdirati. Vendar je bilo vprašanje časa, saj je treba podatke na spletnih mestih posodobiti in številne stranke to pozorno spremljajo same.
Iz besedila napake lahko sklepamo, da Bitrix poskuša dodati nov vnos v bazo podatkov, medtem ko navaja isti primarni ključ, ki je bil v članku, ki se ureja. To pomeni, da obstaja razlog za sum, da se težava pojavlja na strani Bitrixa. Gremo na njihovo spletno stran in kontaktiramo podporo. Skoraj takoj dobimo odgovor »zapleten problem. Dali so ga višjim inženirjem - počakajte ..."
Morali smo čakati precej dolgo (celoten dialog je potekal od 25.06.2019. junija 9.07.2019 do 10.4.6. julija XNUMX) in rezultat je bil sporočilo »ta težava ni povezana z delovanjem Bitrix CMS, ampak je povezana z delovanja same baze podatkov v mariadb XNUMX in, na žalost, z Na strani spletnega mesta te težave ni mogoče rešiti; morali boste preklopiti na staro različico MariaDB.«
Prišli so ... Na začetku zgodbe sem razmišljal o znižanju, a da ni mogoče znižati. Odložite odlagališča in ponovno namestite na popolnoma nameščen strežnik. Tisti. Še dobro, da nisem posodobil vseh strežnikov naenkrat. Tisti. “le” sto strani (živčen smeh :-)). Podpora je tudi povedala: »Za rešitev težave pri uporabi baze podatkov MariaDB 10.4.6 se boste morali obrniti na tehnično podporo MariaDB, da transakcija ne bo izbrisala zapisa iz baze podatkov, če je podana zahteva:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
Upanje je tlelo nekaj ur od trenutka, ko sem začel komunicirati s podporo MariaDB, potem pa sem prejel pismo, v katerem so mi zelo pravilno povedali, da nisem komercialni uporabnik in zato nihče ne bo načrtno reševal moje težave, vendar obstaja forum na njihovi spletni strani in tam lahko poskusite iskati možnosti ... ne bom vas dolgočasil s podrobnostmi. Tam ni možnosti.
O! Kupili smo licenco ISP!
- Halo, podpora? Fantje, pomagajte!
— Oprostite, ne podpiramo bedakov, ki spreminjajo izvorne različice DBMS. Če želite, obstaja možnost z alternativnim strežnikom v Dockerju.
— Toda kako bodo uporabniki in baze podatkov prišli tja? Na dokerja?
- No, tja jih vlečeš z rokami ...
- Da! In ne pozabite, da se bodo vrata za mysql spremenila in da boste morali iti skozi vse konfiguracije in jih znova napisati.
- Ok, hvala, bom razmislil ...
Pomislil sem in se odločil, da ročno rušim 10.4 in namestim 10.2, s katerim na drugih strežnikih ni bilo težav.
Postopek se ni veliko razlikoval od postopka posodobitve. Pravkar sem moral spremeniti 10.4 v 10.2 v povezavi do repozitorija, ponastaviti in znova ustvariti predpomnilnik za yum. No, še ena "malenkost": po odstranitvi 10.4 pojdite na /var/lib/mysql in izbrišite vse od tam. Brez tega koraka po namestitvi 10.2 se bo storitev nenehno zrušila in videli boste
Не удалось подключиться к базе данных '' 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: 104Pred uvozom podatkovnih baz sem najprej nastavil korensko geslo za mysql, ki je bilo določeno v konfiguracijah ponudnika internetnih storitev, in uvozil izpis baze podatkov mysql. No, potem pa, ker že imamo uporabnike in pravice, preprosto uvozimo vse baze podatkov uporabnikov po vrsti z uporabo korenskega računa.
Besedilo skripta za izpis baze podatkov:
#!/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'Preden uvozite baze podatkov, jih morate razpakirati. Torej samo zaženemo ukaz
gunzip /BACK/*.gzIn nazadnje: iz nekega razloga so dovoljeni vezaji v imenu baze (če jo ustvarite prek ISPmanagerja). Toda ko ustvarite ali poskušate naložiti izpis v bazo podatkov, ki ima v imenu vezaj, prejmete sporočilo, da je sintaksa zahteve napačna.
Vse najboljše tistim, ki ste prebrali do konca. Opravičujem se za najverjetneje napačno postavljene vejice - so problem. Če imate kakršne koli predloge glede bistva opisanega, pišite v osebnem sporočilu, ker se bojim, da bom kaj spregledal v komentarjih. In ne preklinjaj preveč - to je moj prvi članek :)
UPD1:
Skoraj sem pozabil omeniti: ko sem poskušal najti rešitev problema brez znižanja MariaDB, sem moral nekako posodobiti informacije. Posodobljen je bil takole: celotna baza podatkov je pretvorjena iz InnoDB v MyISAM, informacije so posodobljene in nato pretvorjene nazaj v InooDB.
UPD2:
Pravkar sem prejel pismo od 1C-Bitrix z naslednjo vsebino:
Zahteva za revizijo zaključena
"Po nadgradnji mariadb na 10.4.6 je prišlo do napake pri shranjevanju elementa infobloka"
Modul: iblock, različica: neznana
Rešitev: zavrnjeno
Tako da je za zdaj očitno nemogoče posodobiti na 10.4 🙁
Vir: www.habr.com