Bon ghjornu, cari abitanti di Khabrovsk! Lasciami presentà, Alexander. Amministratore di sistema di un studiu WEB picculu ma fieru. Vulemu veramente chì tuttu funziona rapidamente, in modu sicuru è cù l'ultimu software. Per fà questu, avemu ancu installatu u bundle nagios + PhantomJS in l'urdinatore intra-uffiziu è verificate a velocità di carica di a pagina ogni 30 minuti. Sicondu i termini di serviziu, monitoremu ancu l'aghjurnamenti di 1C-Bitrix è stallà regularmente. E dopu un ghjornu, dopu a prossima aghjurnazione, vedemu un missaghju in u pannellu di amministrazione chì da l'estiu di 2019, 1C-Bitrix cessà di travaglià cù MySQL 5.5 è avemu bisognu di aghjurnà. I picciotti di ISPSystem sò belli è espansione regularmente a funziunalità di u pannellu, per quale ringraziu speciale à elli. Ma sta volta ùn era micca pussibule di cliccà tuttu cù u mouse. Ma pudete scopre ciò chì hè accadutu è quanti capelli grisgi sò avà in a mo barba sottu u cut.
Ci era solu una opzione per installà un "servitore DBMS alternativu" chì hè stallatu in un containeru Docker. Di sicuru, aghju capitu chì Docker hè assai frugale cù risorse, ma ùn importa micca quantu travaglia, u sopratuttu serà sempre> 0. È quì ci paremu di cummattiri in decimi di sicondi è ottimisà tutti i siti à l'entrata prima di pubblicà è firmà un accordu. Allora micca a mo opzione.
Ok, chì dice a documentazione? Salvà tuttu, aghjunghje un schedariu à yum.repos.d cù un ligame à u repository MariaDB, dopu
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum dopu ghjurà chì qualchissia hà sguassatu i pacchetti senza u so sapè. Ma prima di tuttu, ch'ellu ghjurà, hè bè. E in segundu, se fate l'eliminazione via yum, allora prova di sguassà, inseme cù MariaDB, tuttu ciò chì hè cunnessu cù questu per dipendenza, è questu include PHP è ISPManager è PHPmyadmin. Dunque, avemu da trattà cù u ghjuramentu dopu.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonIn generale, tuttu hè stallatu è cuminciatu. A cosa bella hè chì e basa di dati sò stati cullati è ùn ci era micca bisognu di restaurà da i dumps. Aghju verificatu i siti - travaglianu è sò veloci. Sò andatu in un paru di spazii amministrativi per assicurà chì nunda ùn era cascatu è hà scrittu à u direttore chì tuttu era OK. Meno di 30 minuti dopu s'hè risultatu chì ùn era micca bè in tuttu ...
Quandu aghju pruvatu à andà in l'area di amministratore è aghjunghje è edità qualcosa in u cuntenutu, un missaghju apparsu
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']Siccomu u cuntenutu nantu à u situ hè aghjuntu da i nostri propri impiegati, i clienti ùn sapianu nunda è ùn anu micca ancu cuminciatu à strappà. Ma era una questione di tempu, perchè l'infurmazione nantu à i siti deve esse aghjurnata, è parechji clienti monitoranu da quì.
Da u testu di l'errore, pudemu cuncludi chì Bitrix prova di aghjunghje una nova entrata à a basa di dati mentre specifica a stessa chjave primaria chì era in l'articulu editatu. Questu significa chì ci hè una ragione per sospettà chì u prublema nasce da u latu Bitrix. Andemu à u so situ web è cuntattate u supportu. Quasi subitu avemu a risposta "prublemu cumplicatu. L'hà datu à ingegneri anziani - aspetta ... "
Avemu avutu aspittà assai tempu (tuttu u dialogu hè accadutu da u 25.06.2019 di ghjugnu 9.07.2019 à u 10.4.6 di lugliu di u XNUMX) è u risultatu era u missaghju "stu prublema ùn hè micca ligatu à l'operazione di u CMS Bitrix, ma hè ligatu à u U funziunamentu di a basa di dati stessa in mariadb XNUMX è, sfurtunatamenti, cù Da u situ, ùn ci hè manera di risolve stu prublema; avete bisognu di cambià à a versione vechja di MariaDB.
Sò ghjunti... Pensu à downgrade à u principiu di a storia, ma chì ùn pò esse micca downgrade. Dump dumps and re-deploy in a server completamente installatu. Quelli. Hè bonu chì ùn aghju micca aghjurnatu tutti i servitori in una volta. Quelli. "solu" centu siti (risata nervosa :-)). U supportu hà dettu ancu: "Per risolve u prublema quandu si usa a basa di dati MariaDB 10.4.6, avete bisognu di cuntattà l'assistenza tecnica MariaDB chì a transazzione ùn sguasserà micca un registru da a basa di dati se a dumanda hè fatta:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
Hope brillava per un paru d'ore da u mumentu ch'e aghju cuminciatu à cumunicà cù u supportu MariaDB, ma dopu aghju ricevutu una lettera in quale m'hà dettu assai currettamente chì ùn sò micca un utilizatore cummerciale è per quessa nimu ùn risolve u mo prublema apposta, ma ci hè. un foru nant'à u so situ web è quì pudete pruvà à circà l'opzioni ... ùn vi stancu micca cù dettagli. Ùn ci sò micca opzioni.
À propositu! Avemu compru una licenza ISP!
- Salute, sustegnu ? Ragazzi, aiutu!
- Scusate, ùn sustenemu micca scumbags chì cambianu e versioni native di u DBMS. Se vulete, ci hè una opzione cù un servitore alternativu in Docker.
- Ma cumu si ghjunghjeranu l'utilizatori è e basa di dati ? À docker?
- Ebbè, li trascinate culà cù e mani...
- Iè! È ùn vi scurdate chì u portu per mysql cambierà è avete bisognu di passà per tutte e cunfigurazioni è riscrive.
- Ok, grazie, ci penseraghju...
Aghju pensatu è decisu di demolisce manualmente 10.4 è installate 10.2 cù quale ùn ci era micca prublemi in altri servitori.
U prucessu ùn era micca assai sfarente da u prucessu di aghjurnamentu. Aghju avutu solu cambià da 10.4 à 10.2 in u ligame à u repository, resettate è ricreate a cache per yum. Ebbè, un'altra "piccola cosa": dopu avè eliminatu 10.4, andate à /var/lib/mysql è sguassate tuttu da quì. Senza stu passu dopu a stallazione di 10.2, u serviziu hà da sempre crash è vi vede
Не удалось подключиться к базе данных '' 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: 104Prima di impurtà e basa di dati, aghju prima stabilitu a password root per mysql chì hè stata specificata in a cunfigurazione di l'ISP è impurtatu u dump di basa di dati mysql. Ebbè, allora, postu chì avemu digià utilizatori è diritti, simpricimenti impurtate tutte e basa di dati d'utilizatori in una fila utilizendu u contu root.
Testu di script per a basa di dati:
#!/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'Prima di impurtà e basa di dati, avete bisognu di unzip. Allora avemu solu eseguisce u cumandamentu
gunzip /BACK/*.gzÈ infine: per una certa ragione, i trattini sò permessi in u nome di a basa di dati (se creanu via ISPmanager). Ma quandu create o pruvate à carica un dump à una basa di dati chì hà un trattino in u so nome, riceve un missaghju chì a sintassi di dumanda hè incorrecta.
Tuttu u megliu à quelli chì leghjenu finu à a fine. Mi scusate per i più probabili virgule sbagliate - sò un prublema. Sì avete qualchì suggerimentu in quantu à l'essenza di ciò chì hè descrittu, scrivite in un missaghju persunale perchè aghju paura chì mi manca qualcosa in i cumenti. È ùn ghjurà micca troppu - questu hè u mo primu articulu :)
UPD1:
I quasi scurdatu di mintuvà: mentre ch'e aghju pruvatu à truvà una suluzione à u prublema senza downgrade MariaDB, aghju avutu à aghjurnà in qualchì modu l'infurmazioni. Hè stata aghjurnata cusì: tutta a basa di dati hè cunvertita da InnoDB à MyISAM, l'infurmazione hè aghjurnata è poi cunvertita in InooDB.
UPD2:
Aghju ricevutu appena una lettera da 1C-Bitrix cù u cuntenutu seguente:
A dumanda di rivisione hè finita
"Dopu à l'aghjurnamentu di mariadb à 10.4.6, un errore hè accadutu quandu si salva un elementu infoblock"
Modulu: iblock, versione: scunnisciutu
Soluzione : rifiutatu
Dunque hè apparentemente impussibile di aghjurnà à 10.4 per avà 🙁
Source: www.habr.com