Dobar dan, dragi Khabrovci! Dozvolite mi da se predstavim, Aleksandre. Sistem administrator jednog malog, ali ponosnog WEB-studija. Zaista želimo da sve radi brzo, sigurno i sa svježim softverom. Da bismo to uradili, čak smo podigli paket nagios + PhantomJS na računaru unutar kancelarije i proveravali brzinu učitavanja stranice svakih 30 minuta. Prema uslovima usluge, pratimo i ažuriranja 1C-Bitrixa i redovno ih instaliramo. A onda jednog dana, nakon sljedećeg ažuriranja, vidimo poruku u admin panelu u kojoj se navodi da od ljeta 2019. 1C-Bitrix prestaje raditi s MySQL 5.5 i treba ga ažurirati. Momci iz ISPSystema su zgodni i redovno proširuju funkcionalnost panela, na čemu im posebno hvala. Ali ovaj put nije bilo moguće kliknuti na sve mišem. Ali šta se desilo i koliko mi je sada sijedih dlačica u bradi, može se naći ispod reza.
Postojala je samo opcija da se instalira “alternativni DBMS server” koji je instaliran u Docker kontejneru. Naravno, razumijem da je Docker vrlo štedljiv sa resursima, ali bez obzira na to koliko dobro funkcionira, dodatni troškovi će i dalje biti > 0. I evo nas, takoreći, borimo se u desetinkama sekunde i optimiziramo sve stranice na ulazu prije objavljivanja i potpisivanja ugovora. Dakle, nije moj izbor.
Ok, šta je u dokumentaciji? Napravite sigurnosnu kopiju svega, dodajte datoteku s vezom na MariaDB spremište na yum.repos.d, a zatim
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum će se naknadno zakleti u činjenicu da je neko uklonio pakete bez njegovog znanja. Ali prvo – neka se zakune, u redu je. I drugo, ako brisanje obavite preko yum-a, onda pokušava da sruši, zajedno sa MariaDB-om, sve što je vezano za njega po zavisnostima, a to su PHP i ISPManager i PHPmyadmin. Tako da ćemo se kasnije pozabaviti greškama.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonGeneralno, sve je postavljeno i počelo. Lijepa stvar je što su baze pokupljene i nije ih bilo potrebno obnavljati sa deponija. Provjerio sam stranice - rade i brzo. Otišao sam na par admin panela da se uvjerim da ništa nije otpalo i odjavio se direktoru da je sve OK. Za manje od 30 minuta ispostavilo se da to uopšte nije u redu...
Kada sam pokušao da odem na admin panel i dodam edit bilo šta u sadržaj, ispala je poruka
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']Budući da sadržaj na stranicu dodaju naši zaposlenici, klijenti još ništa nisu znali i još nisu počeli da nas razdvajaju. Ali bilo je to pitanje vremena, jer je potrebno ažurirati informacije na stranicama, a mnogi klijenti to pomno prate.
Iz teksta greške možemo zaključiti da Bitrix pokušava dodati novi zapis u bazu podataka, pritom navodeći isti primarni ključ koji je imao članak koji se uređuje. Dakle, postoji razlog za sumnju da se problem javlja na strani Bitrixa. Idite na njihovu web stranicu i kontaktirajte podršku. Gotovo odmah dobijamo odgovor „težak problem. Dato starijim inženjerima - čekajte..."
Morao sam dosta dugo čekati (cijeli dijalog se odvijao od 25.06.2019. do 9.07.2019.) i rezultat je bila poruka „ovaj problem nije povezan s radom Bitrix CMS-a, ali je povezan na rad same baze podataka u mariadb 10.4.6 i, nažalost, s obzirom da nedostaje strana stranice za rješavanje ovog problema, bit će potrebno migrirati na stariju verziju MariaDB-a.”
Otplovio... Razmišljao sam o degradaciji na početku priče, ali da ne može biti nižeg ranga. Spojite dumpove i ponovo rasporedite na svježe instaliranom serveru. One. dobro je što nisam ažurirao sve servere odjednom. One. “samo” stotinjak sajtova (nervozno cerekanje :-)). U podršci su također rekli: „Da biste riješili problem kada koristite MariaDB 10.4.6 bazu podataka, morat ćete kontaktirati MariaDB tehničku podršku da transakcija neće izbrisati zapis iz baze podataka ako se uputi zahtjev:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
Nada je svjetlucala nekoliko sati od trenutka kada smo počeli komunicirati sa MariaDB podrškom, ali onda sam dobio pismo u kojem sam krajnje korektno obaviješten da nisam komercijalni korisnik i da stoga niko neće namjerno rješavati moj problem, ali postoji forum na njihovoj web stranici i tamo možete pokušati potražiti opcije… Neću vas zamarati detaljima. Tu nema opcija.
O! Kupili smo licencu za ISP!
Zdravo, podrška? Momci, pomozite!
- Žao nam je, ne podržavamo nasilnike koji mijenjaju izvorne verzije DBMS-a. Ako želite, postoji opcija sa alternativnim serverom u docker-u.
- Ali kako će korisnici i baze podataka stići tamo? Za docker?
- Pa ti ih dovuci tamo rukama...
- Da! I ne zaboravite da će se port za mysql promijeniti i morat ćete proći kroz i ponovo napisati sve konfiguracije.
Ok hvala, razmislicu o tome...
Razmislio sam i odlučio da srušim 10.4 sa ručkama i instaliram 10.2 sa kojim nije bilo problema na drugim serverima.
Proces se nije mnogo razlikovao od procesa nadogradnje. Samo je bilo potrebno promijeniti 10.4 u 10.2 u linku do spremišta, resetovati i ponovo kreirati keš memoriju za yum. Pa, još jedna “sitnica”: nakon uklanjanja 10.4, idemo na /var/lib/mysql i brišemo sve odatle. Bez ovog koraka, nakon instaliranja 10.2, usluga će se stalno rušiti i vidjet ćete
Не удалось подключиться к базе данных '' 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: 104Prije uvoza baza podataka, prvo sam postavio mysql root lozinku koja je navedena u ISP konfiguracijama i uvezao sam mysql dump baze podataka. Pa, pošto već postoje korisnici i prava, jednostavno uvozimo sve korisničke baze podataka zaredom sa root nalogom.
Tekst skripte za dump baze podataka:
#!/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'Prije uvoza baza podataka, morate ih raspakirati. Zato samo pokrenite komandu
gunzip /BACK/*.gzI poslednja stvar: iz nekog razloga, crtice su dozvoljene u imenima baza podataka (ako ih kreirate pomoću ISPmanager-a). Ali kada kreirate ili pokušavate da otpremite dump u bazu podataka koja ima crticu u imenu, dobijate poruku da je sintaksa upita netačna.
Pročitajte do kraja sve blagoslove. Izvinjavam se zbog najvjerovatnije nerazdvojenih zareza - u nevolji su. Ako postoje želje za prijedlogom suštinski opisanim - pišite u lično jer se u komentarima bojim da neću propustiti nešto. I ne psujte previše - ovo je moj prvi članak 🙂
UPD1:
Skoro da zaboravim da napomenem: dok sam pokušavao da pronađem rešenje problema bez degradacije MariaDB, morao sam nekako da ažuriram informacije. Ažurirano je na sljedeći način: cijela baza podataka se konvertuje iz InnoDB u MyISAM, infa se ažurira i zatim ponovo konvertuje u InooDB.
UPD2:
Upravo sam primio pismo od 1C-Bitrixa sa sljedećim sadržajem:
Zahtjev za reviziju je završen
"Nakon ažuriranja mariadb-a na 10.4.6, došlo je do greške prilikom spremanja elementa infobloka"
Modul: iblock, verzija: nepoznata
Rješenje: odbijeno
Dakle, za sada je očigledno nemoguće ažurirati na 10.4 🙁
izvor: www.habr.com