Бітрыкс і абнаўленне MariaDB да апошняй стабільнай версіі

Добрага часу сутак, шаноўныя Хабраўчане! Дазвольце прадставіцца, Аляксандр. Сістэмны адміністратар адной маленькай але ганарлівай WEB-студыі. Мы вельмі жадаем, каб усё працавала хутка, бяспечна і са свежым софтам. Для гэтага нават паднялі на унутрыофіснага кампе звязку nagios + PhantomJS і кожныя 30 хвілін правяраем хуткасць загрузкі старонак. Па ўмовах абслугоўвання, мы таксама сочым за абнаўленнямі 1С-Бітрыкс і рэгулярна ўсталёўваны іх. І вось аднойчы пасля чарговага абнаўлення бачым паведамленне ў адмінцы аб тым, што з лета 2019 1С-Бітрыкс перастае працаваць з MySQL 5.5 і трэба абнаўляцца. Рабяты з ISPSystem прыгажуны і рэгулярна пашыраюць функцыянал панэлі завошта ім асобнае дзякуй. Але на гэты раз не атрымалася наклікаць усё мышшу. А вось аб тым, што атрымалася і колькі сівых валасоў зараз у маёй барадзе можна даведацца пад катом.

Быў толькі варыянт ставіць "альтэрнатыўны сервер СКБД" які ставіцца ў Docker-кантэйнер. Я вядома разумею, што Docker вельмі беражлівы з рэсурсамі, але як бы выдатна ён ні працаваў, оверхед усё роўна будуць >0. А мы тут як-бы за дзясятыя дзелі секунд б'емся і на ўваходзе ўсе сайты аптымізуем перш чым апублікаваць у сябе і падпісаць дамову. Так што ня мой варыянт.
Ок, што тамака ў дакументацыі напісана? Backup за ўсё, дадаць у yum.repos.d файл са спасылкай на рэпазітар MariaDB, далей

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

Yum пасля будзе лаяцца на тое, што хтосьці пакеты выдаляўставіў без яго ведама. Але ў першых - хай лаецца, нічога страшнага. А па-другое калі рабіць выдаленне праз yum, то ён спрабуе разам з MariaDB знесці і ўсё, што па залежнасцях з ім звязана, а гэта і PHP і ISPManager і PHPmyadmin. Таму з лаянкамі потым разбярэмся.

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

Паколькі кантэнт на сайт дадаюць нашы ж супрацоўніцы, кліенты яшчэ нічога не ведалі і пакуль не пачалі ірваць нас на часткі. Але гэта было пытанне часу, бо інфу на сайтах трэба абнаўляць і вось за гэтым многія кліенты сочаць самі і пільна.

З тэксту памылкі можна зрабіць выснову аб тым, што Битрикс спрабуе дадаць новы запіс у базу пры гэтым паказаўшы той жа primary key, што быў у рэдагуемага артыкула. Значыць ёсць падставы падазраваць, што праблема ўзнікае на баку Бітрыкс. Ідзем на іх сайт і звяртаемся ў падтрымку. Амаль адразу атрымліваем адказ “складаная праблема. Аддалі старэйшым інжынерам — чакайце…”

Чакаць прыйшлося даволі доўга (увесь дыялог адбываўся ў перыяд з 25.06.2019 па 9.07.2019гг.) і вынікам стала паведамленне “гэтая праблема не звязана з працай CMS Битрикс, а звязана з працай самой базы дадзеных у mariadb 10.4.6 і на жаль са боку сайта дадзеную праблему вырашыць магчымасць адсутнічае неабходна будзе перайсці на старую версію MariaDB.”

Прыплылі… Пра downgrade я думаў яшчэ на пачатку гісторыі, але тут чорным па белым сказана, Што ніякага downgrade быць не можа. Злівайце дампы і разгортвайце зноўку на начыста ўсталяваным серверы. Г.зн. гэта добра, што я не ўсе сервера зараз абнавіў. Г.зн. "усяго-то" сотня сайтаў (нервовы смяшок:-)). Яшчэ ў падтрымцы сказалі: “Для вырашэння праблемы пры выкарыстанні базы MariaDB 10.4.6 вам неабходна будзе звярнуцца ў тэхнічную падтрымку MariaDB, што ў транзакцыі не выканаецца выдаленне запісу з БД, калі робіцца запыт:

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

Надзея цяплілася пару гадзін з моманту пачатку зносін з падтрымкай MariaDB, але потым нетутэйша ліст у якім лімітава карэктна мне паведамілі, што я не камерцыйны карыстач і таму маю праблему мэтанакіравана вырашаць ніхто не будзе, але ёсць форум на іх сайце і тамака можна паспрабаваць пашукаць варыянты … Не буду стамляць падрабязнасцямі. Няма тамака варыянтаў.
О! У нас жа набытая ліцэнзія на ISP!
- Алё, падтрымка? Хлопцы, дапамажыце!
- Выбачыце, мы не падтрымліваем адмарозкаў якія натыўныя версіі СКБД змяняюць. Хочаце - ёсць варыянт з альтэрнатыўным серверам у докеры.
- Але як жа туды патрапяць карыстачы і базы? У докер?
— Ну вы іх туды рукамі зацягнеце…
- Так! І не забудзьцеся, што порт для mysql памяняецца і трэба будзе па ўсіх канфігах прайсціся і перапісаць.
- Ок, дзякуй, буду думаць...
Падумаў я і вырашыў такі ручкамі знесці 10.4/10.2 і паставіць XNUMX/XNUMX з якім на іншых серверах праблем не было.

Працэс не асоба адрозніваўся ад працэсу абнаўлення. Толькі трэба было ў спасылцы на рэпазітар памяняць 10.4/10.2 на 10.4/10.2, скінуць і зноўку стварыць кэш для yum. Ну і яшчэ адна "дробязь": пасля выдалення XNUMX, ідзем у /var/lib/mysql і ўсё адтуль выдаляны. Без гэтага кроку пасля ўстаноўкі XNUMX/XNUMX, сэрвіс будзе пастаянна падаць і будзеце бачыць

Не удалось подключиться к базе данных '' 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

Перад тым, як імпартаваць базы я спачатку ўсталяваў той пароль root для mysql які быў прапісаны ў канфігах ISP і імпартаваў дамп базы mysql. Ну а далей бо карыстачы і правы ўжо ёсць, проста з улікам root імпартуем запар усе базы карыстачоў.

Тэкст скрыпту для дампа баз:

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

І апошняе: па нейкім чынніку ў назове баз (калі ствараеце праз ISPmanager) дапушчаюцца злучкі. А вось пры стварэнні ці спробе заліць дамп у базу ў якой у назове злучок, вы атрымліваеце паведамленне аб тым, што сінтаксіс запыту няправільны.

Тым, хто дачытаў да канца ўсіх выгод. Прашу прабачэння за хутчэй за ўсё не расстаўленыя коскі - з імі бяда. Калі будуць пажаданні прапановы па сутнасці апісанага - пішыце ў твары бо ў каментарах баюся нешта прапусціць. І моцна не лайцеся - гэта мой першы артыкул 🙂

UPD1:

Ледзь не забыўся згадаць: пакуль я спрабаваў знайсці рашэнне праблемы без downgrade MariaDB, трэба было неяк інфу абнаўляць. Абнаўлялася так: уся база канвертуецца з InnoDB у MyISAM, абнаўляецца інфармацыя і пота канвертуецца зваротна ў InooDB.
UPD2:

Толькі што прыйшоў ліст ад 1С-Бітрыкс наступнага зместу:

Заяўка на дапрацоўку рэалізавана
"Пасля абнаўлення mariadb да 10.4.6 памылка пры захаванні элемента інфаблока"
Модуль: iblock, версія: не вядома
Рашэнне: адхілена

Так што пакуль да 10.4/XNUMX абнаўляцца мабыць нельга 🙁

Крыніца: habr.com