Битрик и ажурирање МариаДБ на најновију стабилну верзију

Добар дан, драги Хабровци! Дозволите ми да се представим, Александре. Систем администратор једног малог, али поносног ВЕБ-студија. Заиста желимо да све ради брзо, безбедно и са свежим софтвером. Да бисмо то урадили, чак смо подигли пакет нагиос + ПхантомЈС на рачунару унутар канцеларије и проверавали брзину учитавања странице сваких 30 минута. Према условима услуге, такође пратимо ажурирања 1Ц-Битрикса и редовно их инсталирамо. А онда једног дана, након следећег ажурирања, видимо поруку у админ панелу у којој се наводи да од лета 2019. 1Ц-Битрикс престаје да ради са МиСКЛ 5.5 и да треба да се ажурира. Момци из ИСПСистем-а су згодни и редовно проширују функционалност панела, на чему им посебно хвала. Али овога пута није било могуће кликнути на све мишем. Али шта се десило и колико ми је сада седих длака у бради, види се испод реза.

Постојала је само опција да се инсталира „алтернативни ДБМС сервер“ који је инсталиран у Доцкер контејнеру. Наравно, разумем да је Доцкер веома штедљив са ресурсима, али без обзира на то колико добро функционише, додатни трошкови ће и даље бити > 0. И ево нас као да се боримо за десетинке секунде и оптимизујемо све сајтове на улазу пре објављивања и потписивања уговора. Дакле, није мој избор.
Ок, шта је у документацији? Направите резервну копију свега, додајте датотеку са везом до МариаДБ спремишта у иум.репос.д, а затим

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

Иум ће се накнадно заклети у чињеницу да је неко уклонио пакете без његовог знања. Али прво – нека се закуне, у реду је. И друго, ако урадите брисање преко иум-а, онда покушава да сруши, заједно са МариаДБ-ом, све што је повезано са њим по зависностима, а ово су ПХП и ИСПМанагер и ПХПмиадмин. Тако да ћемо се касније позабавити грешкама.


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

Генерално, све је постављено и почело. Лепо је то што су базе покупљене и није их било потребно обнављати са депонија. Проверио сам сајтове - раде и брзо. Отишао сам на пар админ панела да се уверим да ништа није отпало и одјавио се директору да је све ОК. За мање од 30 минута испоставило се да то уопште није у реду...

Када сам покушао да одем на админ панел и да додам било шта измени у садржај, испала је порука

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

Пошто садржај на сајт додају наши запослени, клијенти још ништа нису знали и још нису почели да нас раздвајају. Али то је било питање времена, јер је потребно ажурирати информације на сајтовима, а многи клијенти то веома пажљиво прате.

Из текста грешке можемо закључити да Битрикс покушава да дода нови запис у базу података, при чему наводи исти примарни кључ који је имао чланак који се уређује. Дакле, постоји разлог за сумњу да се проблем јавља на страни Битрикса. Идите на њихову веб локацију и контактирајте подршку. Скоро одмах добијамо одговор „тежак проблем. Дато старијим инжењерима - чекајте ... "

Морао сам да чекам прилично дуго (цео дијалог се одвијао од 25.06.2019. до 9.07.2019.) и резултат је била порука „овај проблем није повезан са радом Битрик ЦМС-а, али је повезан на рад саме базе података у мариадб 10.4.6 и, нажалост, пошто недостаје страна сајта за решавање овог проблема, биће потребно прећи на старију верзију МариаДБ-а.”

Отпловио... Размишљао сам о деградацији на почетку приче, али овде црно-белода не може бити деградације. Спојите думпове и поново распоредите на свеже инсталираном серверу. Оне. добро је што нисам ажурирао све сервере одједном. Оне. „само“ стотину сајтова (нервозно смејање :-)). Такође су рекли у подршци: „Да бисте решили проблем када користите МариаДБ 10.4.6 базу података, мораћете да контактирате МариаДБ техничку подршку да трансакција неће избрисати запис из базе података ако се упути захтев:

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

Нада је светлуцала неколико сати од тренутка када смо почели да комуницирамо са МариаДБ подршком, али онда сам добио писмо у коме сам изузетно коректно обавештен да нисам комерцијални корисник и да нико неће намерно да решава мој проблем, али постоји форум на њиховој веб страници и тамо можете покушати да потражите опције… Нећу вас замарати детаљима. Ту нема опција.
О ТОМЕ! Купили смо лиценцу за ИСП!
Здраво, подршка? Момци, помозите!
- Жао нам је, не подржавамо насилнике који мењају изворне верзије ДБМС-а. Ако желите, постоји опција са алтернативним сервером у доцкер-у.
- Али како ће корисници и базе података стићи тамо? За доцкер?
- Па ти их тамо рукама довучеш...
- Да! И не заборавите да ће се порт за мискл променити и да ћете морати да прођете и поново напишете све конфигурације.
Ок хвала, размислићу о томе...
Мислио сам и одлучио да срушим 10.4 са ручкама и инсталирам 10.2 са којим није било проблема на другим серверима.

Процес се није много разликовао од процеса надоградње. Само је било потребно променити 10.4 у 10.2 у линку ка спремишту, ресетовати и поново креирати кеш за иум. Па, још једна „ситница“: након уклањања 10.4, идемо у /вар/либ/мискл и бришемо све одатле. Без овог корака, након инсталирања 10.2, услуга ће се стално рушити и видећете

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

Ор

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

Пре увоза база података, прво сам поставио мискл роот лозинку која је наведена у конфигурацијама ИСП-а и увезао дамп мискл базе података. Па, онда, пошто већ постоје корисници и права, једноставно увозимо све корисничке базе података по реду са роот налогом.

Текст скрипте за думп базе података:

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

Пре увоза база података, потребно је да их распакујете. Зато само покрените команду

gunzip /BACK/*.gz

И последња ствар: из неког разлога, цртице су дозвољене у именима база података (ако их креирате помоћу ИСПманагер-а). Али када креирате или покушавате да отпремите думп у базу података која има цртицу у имену, добијате поруку да је синтакса упита нетачна.

Прочитајте до краја све благослове. Извињавам се због највероватније нераздвојених зареза - у невољи су. Ако постоје жеље за предлогом суштински описаним - пишите у лично јер се у коментарима плашим да нешто пропустим. И не псујте превише - ово је мој први чланак 🙂

УПД1:

Скоро да заборавим да напоменем: док сам покушавао да пронађем решење проблема без деградације МариаДБ-а, морао сам некако да ажурирам информације. Ажурирано је овако: цела база података се конвертује из ИнноДБ у МиИСАМ, инфа се ажурира и затим поново конвертује у ИнооДБ.
УПД2:

Управо сам примио писмо од 1Ц-Битрикса следећег садржаја:

Захтев за ревизију је завршен
„Након ажурирања мариадб-а на 10.4.6, дошло је до грешке приликом чувања елемента инфоблока“
Модул: иблоцк, верзија: непозната
Решење: одбијено

Дакле, за сада, очигледно је немогуће ажурирати на 10.4 🙁

Извор: ввв.хабр.цом

Додај коментар