Добар ден, драги жители на Хабровск! Да се претставам Александар. Системски администратор на едно мало, но гордо WEB студио. Навистина сакаме сè да работи брзо, безбедно и со најновиот софтвер. За да го направите ова, дури и го инсталиравме пакетот nagios+PhantomJS на компјутерот внатре во канцеларијата и ја проверуваме брзината на вчитување на страницата на секои 30 минути. Според условите за користење, ние исто така ги следиме ажурирањата на 1C-Bitrix и ги инсталираме редовно. А потоа еден ден, по следното ажурирање, гледаме порака во административниот панел дека од летото 2019 година, 1C-Bitrix престанува да работи со MySQL 5.5 и треба да се ажурираме. Момците од ISPSystem се згодни и редовно ја прошируваат функционалноста на панелот, за што посебно им благодариме. Но, овој пат не беше можно да се кликне сè со глувчето. Но, можете да дознаете што се случило и колку сиви влакна сега има во мојата брада под резот.
Имаше само опција да се инсталира „алтернативен DBMS сервер“ што е инсталиран во контејнер Docker. Се разбира, разбирам дека Docker е многу штедлив со ресурсите, но колку и да работи одлично, трошоците сепак ќе бидат >0. И овде се чини дека се бориме за десетинки од секунди и ги оптимизираме сите страници на влезот пред да ги објавиме и да потпишеме договор. Значи не е моја опција.
Добро, што пишува документацијата? Направете резервна копија на сè, додајте датотека на yum.repos.d со врска до складиштето на MariaDB, а потоа
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum последователно ќе се заколне дека некој ги избришал пакетите без негово знаење. Но, пред се, нека се заколне, во ред е. И второ, ако го направите бришењето преку 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']Бидејќи содржината на страницата ја додаваат нашите вработени, клиентите сè уште не знаеле ништо и сè уште не почнале да не растргнуваат. Но, тоа беше прашање на време, бидејќи информациите на сајтовите треба да се ажурираат, а многу клиенти самите внимателно го следат тоа.
Од текстот на грешката, можеме да заклучиме дека Bitrix се обидува да додаде нов запис во базата на податоци додека го наведува истиот примарен клуч што беше во написот што се уредува. Ова значи дека има причина да се сомневаме дека проблемот се јавува на страната на Битрикс. Одиме на нивната веб-страница и контактираме со поддршката. Речиси веднаш го добиваме одговорот „комплициран проблем. Даде на високи инженери - чекај...“
Моравме да чекаме доста долго (целиот дијалог се одржа од 25.06.2019 јуни 9.07.2019 до 10.4.6 јули XNUMX година) и резултатот беше пораката „овој проблем не е поврзан со работата на Bitrix CMS, туку е поврзан со функционирање на самата база на податоци во mariadb XNUMX и, за жал, со страната на страницата, нема начин да се реши овој проблем; ќе треба да се префрлите на старата верзија на MariaDB.
Пристигнаа... Размислував за деградирање на почетокот на приказната, но дека не може да има деградирање. Отфрлете ги депонии и повторно распоредете ги на целосно инсталиран сервер. Оние. Добро е што не ги ажурирав сите сервери одеднаш. Оние. „само“ сто локации (нервозна смеа :-)). Поддршката, исто така, рече: „За да го решите проблемот при користење на базата на податоци на 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, но потоа добив писмо во кое многу точно ми кажаа дека не сум комерцијален корисник и затоа никој нема конкретно да ми го реши проблемот, но има форум на нивната веб-страница и таму може да се обидете да барате опции ... нема да ви досадувам со детали. Нема опции таму.
ЗА! Купивме лиценца за интернет провајдер!
- Здраво, поддршка? Момци, помогнете!
— Извинете, ние не поддржуваме ѓубриња кои ги менуваат оригиналните верзии на DBMS. Ако сакате, постои опција со алтернативен сервер во Docker.
- Но, како корисниците и базите на податоци ќе стигнат таму? Докер?
- Па, таму ги влечеш со раце...
- Да! И не заборавајте дека портата за mysql ќе се промени и ќе треба да ги поминете сите конфигурации и да ги преработите.
- Добро, благодарам, ќе размислам...
Размислував и решив рачно да го демолирам 10.4 и да инсталирам 10.2 со кој немаше проблеми на другите сервери.
Процесот не се разликуваше многу од процесот на ажурирање. Само требаше да сменам 10.4 на 10.2 во врската до складиштето, да го ресетирам и повторно да го создадам кешот за yum. Па, уште една „ситница“: откако ќе ја отстраните 10.4, одете на /var/lib/mysql и избришете сè од таму. Без овој чекор по инсталирањето на 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Пред да ги увезам базите на податоци, прво ја поставив root лозинката за mysql што беше наведена во конфигурациите на интернет провајдерот и ја увезав депонијата на базата на податоци 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:
За малку ќе заборавив да напоменам: додека се обидував да најдам решение за проблемот без да го намалам рејтингот на MariaDB, морав некако да ги ажурирам информациите. Се ажурираше вака: целата база на податоци се конвертира од InnoDB во MyISAM, информациите се ажурираат и потоа се претвораат назад во InooDB.
UPD2:
Само што добив писмо од 1C-Bitrix со следнава содржина:
Барањето за ревизија е завршено
„По надградбата на mariadb на 10.4.6, се појави грешка при зачувување на елементот инфоблок“
Модул: iblock, верзија: непозната
Решение: одбиено
Значи, очигледно е невозможно да се ажурира на 10.4 засега 🙁
Извор: www.habr.com