Bitrix a diweddaru MariaDB i'r fersiwn sefydlog ddiweddaraf

Diwrnod da, annwyl Khabrovites! Gadewch i mi gyflwyno fy hun, Alexander. Gweinyddwr system un WEB-stiwdio fach ond balch. Rydyn ni wir eisiau i bopeth weithio'n gyflym, yn ddiogel a gyda meddalwedd ffres. I wneud hyn, fe wnaethom hyd yn oed godi bwndel nagios + PhantomJS ar y cyfrifiadur o fewn y swyddfa a bob 30 munud rydym yn gwirio cyflymder llwytho'r dudalen. Yn ôl y telerau gwasanaeth, rydym hefyd yn monitro diweddariadau 1C-Bitrix ac yn eu gosod yn rheolaidd. Ac yna un diwrnod, ar ôl y diweddariad nesaf, gwelwn neges yn y panel gweinyddol yn nodi, ers haf 2019, bod 1C-Bitrix yn rhoi'r gorau i weithio gyda MySQL 5.5 a bod angen ei ddiweddaru. Mae'r dynion o system ISPS yn olygus ac yn ehangu ymarferoldeb y panel yn rheolaidd, a diolch yn arbennig iddyn nhw. Ond y tro hwn nid oedd yn bosibl clicio popeth gyda'r llygoden. Ond mae'r hyn a ddigwyddodd a faint o flew llwyd sydd bellach yn fy barf i'w gael o dan y toriad.

Dim ond opsiwn oedd i osod “gweinydd DBMS amgen” sydd wedi'i osod yn y cynhwysydd Docker. Wrth gwrs, deallaf fod Docker yn gynnil iawn o ran adnoddau, ond ni waeth pa mor wych y mae'n gweithio, bydd y gorbenion yn dal i fod> 0. A dyma ni, fel petai, yn ymladd mewn degfedau o eiliadau ac yn optimeiddio pob safle wrth y fynedfa cyn cyhoeddi a llofnodi cytundeb. Felly nid fy newis i.
Iawn, beth sydd yn y ddogfennaeth? Gwneud copi wrth gefn o bopeth, ychwanegu ffeil gyda dolen i ystorfa MariaDB i yum.repos.d, yna

rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-common

Bydd Yum wedyn yn tyngu bod rhywun wedi tynnu'r pecynnau heb yn wybod iddo. Ond yn gyntaf - gadewch iddo dyngu, mae'n iawn. Ac yn ail, os gwnewch y dileu trwy yum, yna mae'n ceisio dymchwel, ynghyd â MariaDB, bopeth sy'n gysylltiedig ag ef gan ddibyniaethau, a dyma PHP ac ISPManager a PHPmyadmin. Felly byddwn yn delio â'r bygiau yn ddiweddarach.

yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-common

Yn gyffredinol, roedd popeth wedi'i sefydlu a'i ddechrau. Y peth braf yw bod y gwaelodion wedi'u codi ac nid oedd angen eu hadfer o'r tomenni. Fe wnes i wirio'r safleoedd - maen nhw'n gweithio ac yn gyflym. Es i un neu ddau o baneli gweinyddol i wneud yn siŵr nad oedd dim byd yn disgyn i ffwrdd a dad-danysgrifio i'r cyfarwyddwr bod popeth yn iawn. Mewn llai na 30 munud, daeth i'r amlwg nad oedd hyd yn oed yn iawn o gwbl ...

Pan geisiais fynd i'r panel gweinyddol ac ychwanegu golygu unrhyw beth yn y cynnwys, syrthiodd neges allan

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']

Gan fod y cynnwys ar y wefan yn cael ei ychwanegu gan ein gweithwyr, nid oedd y cleientiaid yn gwybod dim o hyd ac nid oeddent wedi dechrau ein rhwygo'n ddarnau eto. Ond roedd yn fater o amser, oherwydd mae angen diweddaru'r wybodaeth ar y safleoedd, ac mae llawer o gleientiaid yn dilyn hyn yn agos iawn.

O destun y gwall, gallwn ddod i'r casgliad bod Bitrix yn ceisio ychwanegu cofnod newydd i'r gronfa ddata, tra'n nodi'r un allwedd gynradd a oedd gan yr erthygl sy'n cael ei golygu. Felly mae lle i amau ​​​​bod y broblem yn digwydd ar ochr Bitrix. Ewch i'w gwefan a chysylltwch â'r tîm cymorth. Bron ar unwaith cawn yr ateb “problem anodd. Wedi'i roi i uwch beirianwyr - arhoswch ... "

Bu'n rhaid i mi aros am amser eithaf hir (digwyddodd y ddeialog gyfan rhwng 25.06.2019/9.07.2019/10.4.6 a XNUMX/XNUMX/XNUMX) a'r canlyniad oedd y neges “nid yw'r broblem hon yn gysylltiedig â gweithrediad Bitrix CMS, ond mae'n gysylltiedig i weithrediad y gronfa ddata ei hun ym mariadb XNUMX ac, yn anffodus, gydag ochr y wefan mae'r broblem hon i ddatrys y posibilrwydd ar goll, bydd angen mudo i'r hen fersiwn o MariaDB.”

Hwyliodd ... meddyliais am israddio ar ddechrau'r stori, ond yma mewn du a gwynna all fod unrhyw israddio. Cyfuno tomenni ac adleoli ar weinydd sydd newydd ei osod. Y rhai. mae'n dda na wnes i ddiweddaru'r holl weinyddion ar unwaith. Y rhai. “dim ond” cant o safleoedd (chwcl nerfus :-)). Dywedasant hefyd i gefnogi: “I ddatrys y broblem wrth ddefnyddio cronfa ddata MariaDB 10.4.6, bydd angen i chi gysylltu â chymorth technegol MariaDB na fydd y trafodiad yn dileu cofnod o'r gronfa ddata os gwneir cais:

$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”

Daeth y gobaith i’r amlwg am ychydig oriau o’r eiliad y dechreuon ni gyfathrebu â chymorth MariaDB, ond yna derbyniais lythyr yn dweud yn hynod gywir nad oeddwn yn ddefnyddiwr masnachol ac felly na fyddai neb yn datrys fy mhroblem yn bwrpasol, ond mae yna fforwm ar eu gwefan a gallwch geisio chwilio am opsiynau yno ... ni fyddaf yn diflasu gyda manylion. Nid oes unrhyw opsiynau yno.
AM! Rydym wedi prynu trwydded ar gyfer ISP!
Helo, cefnogaeth? Bois, helpwch!
- Mae'n ddrwg gennym, nid ydym yn cefnogi thugs sy'n newid fersiynau brodorol o'r DBMS. Os ydych chi eisiau, mae yna opsiwn gyda gweinydd arall yn y docwr.
- Ond sut bydd defnyddwyr a chronfeydd data yn cyrraedd yno? I dociwr?
- Wel, rydych chi'n eu llusgo yno â'ch dwylo ...
- Oes! A pheidiwch ag anghofio y bydd y porthladd ar gyfer mysql yn newid a bydd angen i chi fynd drwodd ac ailysgrifennu'r holl gyfluniadau.
Iawn diolch, byddaf yn meddwl amdano ...
Meddyliais a phenderfynais ddymchwel 10.4 gyda dolenni a gosod 10.2 nad oedd unrhyw broblemau ar weinyddion eraill ag ef.

Nid oedd y broses yn llawer gwahanol i'r broses uwchraddio. Dim ond roedd angen newid 10.4 i 10.2 yn y ddolen i'r ystorfa, ailosod ac ail-greu'r storfa ar gyfer yum. Wel, un “treiffl” arall: ar ôl tynnu 10.4, rydyn ni'n mynd i /var/lib/mysql ac yn dileu popeth oddi yno. Heb y cam hwn, ar ôl gosod 10.2, bydd y gwasanaeth yn chwalu'n gyson a byddwch yn gweld

Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"

Neu

Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104

Cyn mewnforio'r cronfeydd data, yn gyntaf gosodais y cyfrinair gwraidd mysql a nodwyd yn y cyfluniadau ISP a mewnforiwyd y dymp cronfa ddata mysql. Wel, felly, gan fod defnyddwyr a hawliau eisoes, rydym yn syml yn mewnforio'r holl gronfeydd data defnyddwyr yn olynol gyda'r cyfrif gwraidd.

Testun sgript ar gyfer dympio cronfa ddata:

#!/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'

Cyn mewnforio cronfeydd data, mae angen i chi eu dadsipio. Felly dim ond rhedeg y gorchymyn

gunzip /BACK/*.gz

A'r peth olaf: am ryw reswm, caniateir cysylltnodau mewn enwau cronfa ddata (os ydych chi'n eu creu gan ddefnyddio ISPmanager). Ond wrth greu neu geisio uwchlwytho dymp i gronfa ddata sydd â chysylltnod yn yr enw, rydych chi'n cael neges bod y gystrawen ymholiad yn anghywir.

Darllenwch hyd y diwedd yr holl fendithion. Ymddiheuraf am yr atalnodau mwyaf tebygol nad ydynt wedi'u gwasgaru - maen nhw mewn trafferth. Os oes dymuniadau ar gyfer cynnig a ddisgrifir yn y bôn - ysgrifennwch yn bersonol oherwydd yn y sylwadau mae arnaf ofn colli rhywbeth. A pheidiwch â rhegi gormod - dyma fy erthygl gyntaf 🙂

UPD1:

Bu bron i mi anghofio sôn: tra roeddwn i'n ceisio dod o hyd i ateb i'r broblem heb israddio MariaDB, roedd yn rhaid i mi ddiweddaru'r wybodaeth rywsut. Fe'i diweddarwyd fel hyn: mae'r gronfa ddata gyfan yn cael ei throsi o InnoDB i MyISAM, mae infa yn cael ei diweddaru ac yna'n cael ei throsi yn ôl i InooDB.
UPD2:

Newydd dderbyn llythyr gan 1C-Bitrix gyda'r cynnwys canlynol:

Cais adolygu wedi'i gwblhau
msgstr "Ar ôl diweddaru mariadb i 10.4.6, bu gwall wrth gadw'r elfen infoblock"
Modiwl: iblock, fersiwn: anhysbys
Ateb: gwrthod

Felly am y tro, mae'n debyg ei bod hi'n amhosibl diweddaru i 10.4 🙁

Ffynhonnell: hab.com