Dzień dobry, drodzy Khabrovity! Pozwól, że się przedstawię, Aleksandrze. Administrator systemu jednego małego, ale dumnego studia WEB. Bardzo nam zależy, żeby wszystko działało szybko, bezpiecznie i ze świeżym oprogramowaniem. Aby to zrobić, podnieśliśmy nawet pakiet nagios + PhantomJS na komputerze biurowym i sprawdzaliśmy prędkość ładowania strony co 30 minut. Zgodnie z warunkami świadczenia usług monitorujemy również aktualizacje 1C-Bitrix i regularnie je instalujemy. I pewnego dnia, po kolejnej aktualizacji, w panelu administracyjnym pojawia się komunikat, że od lata 2019 roku 1C-Bitrix przestaje współpracować z MySQL 5.5 i wymaga aktualizacji. Chłopaki z ISPSystem są przystojni i regularnie poszerzają funkcjonalność panelu, za co im szczególne podziękowania. Ale tym razem nie udało się kliknąć wszystkiego myszką. Ale to, co się stało i ile siwych włosów jest teraz na mojej brodzie, można znaleźć pod cięciem.
Istniała jedynie możliwość zainstalowania „alternatywnego serwera DBMS”, który jest instalowany w kontenerze Docker. Oczywiście rozumiem, że Docker bardzo oszczędnie wykorzystuje zasoby, ale niezależnie od tego, jak świetnie działa, obciążenie będzie nadal > 0. I tu jesteśmy niejako w ułamku sekundy walcząc i optymalizując wszystkie strony na wejściu przed publikacją i podpisaniem umowy. Więc nie mój wybór.
OK, co jest w dokumentacji? Zrób kopię zapasową wszystkiego, dodaj plik z linkiem do repozytorium MariaDB do yum.repos.d, następnie
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum będzie następnie przysięgał, że ktoś usunął paczki bez jego wiedzy. Ale po pierwsze – niech przysięga, że jest w porządku. Po drugie, jeśli usuniesz przez yum, spróbuje on zniszczyć wraz z MariaDB wszystko, co jest z nim powiązane przez zależności, a to jest PHP i ISPManager i PHPmyadmin. Zatem błędami zajmiemy się później.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonOgólnie rzecz biorąc, wszystko zostało skonfigurowane i uruchomione. Fajną rzeczą jest to, że bazy zostały odebrane i nie było konieczności przywracania ich ze śmietników. Sprawdziłem strony - działają i szybko. Poszedłem do kilku paneli administracyjnych, aby upewnić się, że nic nie odpadło i wypisałem się do dyrektora, że wszystko jest w porządku. W niecałe 30 minut okazało się, że wcale nie było OK...
Kiedy próbowałem przejść do panelu administracyjnego i dodać coś do edycji treści, wypadł komunikat
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']Ponieważ treści na stronie dodawane są przez naszych pracowników, klienci nadal nic nie wiedzieli i jeszcze nie zaczęli nas rozdzierać. Było to jednak kwestią czasu, gdyż informacje na stronach wymagają aktualizacji, a wielu klientów bardzo tego przestrzega.
Z tekstu błędu możemy wywnioskować, że Bitrix próbuje dodać nowy rekord do bazy danych, podając przy tym ten sam klucz podstawowy, jaki posiadał edytowany artykuł. Istnieją więc podstawy, aby podejrzewać, że problem występuje po stronie Bitrixa. Wejdź na ich stronę internetową i skontaktuj się z pomocą techniczną. Niemal natychmiast otrzymujemy odpowiedź „trudny problem. Dałem to starszym inżynierom - czekaj…”
Musiałem dość długo czekać (cały dialog trwał od 25.06.2019 do 9.07.2019) i w rezultacie pojawił się komunikat „ten problem nie jest związany z działaniem Bitrix CMS, ale jest związany do działania samej bazy danych w mariadb 10.4.6 i niestety, ze względu na brak strony na stronie, aby rozwiązać ten problem, konieczna będzie migracja do starszej wersji MariaDB.”
Popłynął... Myślałem o obniżeniu wersji na początku historii, ale że nie może być mowy o obniżeniu. Scal zrzuty i ponownie wdróż na świeżo zainstalowanym serwerze. Te. dobrze, że nie zaktualizowałem wszystkich serwerów na raz. Te. „tylko” sto stron (nerwowy chichot :-)). Powiedzieli także w wsparciu: „Aby rozwiązać problem podczas korzystania z bazy danych MariaDB 10.4.6, należy skontaktować się z pomocą techniczną MariaDB, aby transakcja nie usunęła rekordu z bazy danych, jeśli zostanie złożone żądanie:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
Nadzieja błysnęła na kilka godzin od chwili, gdy zaczęliśmy komunikować się z obsługą MariaDB, ale potem otrzymałem list, w którym zostałem wyjątkowo poprawnie poinformowany, że nie jestem użytkownikiem komercyjnym i dlatego nikt celowo nie rozwiąże mojego problemu, ale jest forum na ich stronie i możesz tam spróbować poszukać opcji… Nie będę Cię zanudzać szczegółami. Nie ma tam żadnych opcji.
O! Kupiliśmy licencję dla ISP!
Witam, wsparcie? Chłopaki, pomóżcie!
- Przepraszamy, nie wspieramy bandytów, którzy zmieniają natywne wersje DBMS. Jeśli chcesz, istnieje opcja z alternatywnym serwerem w oknie dokowanym.
- Ale w jaki sposób użytkownicy i bazy danych się tam dostaną? Do dokowania?
- Cóż, przeciągasz je tam rękami ...
- Tak! I nie zapominaj, że port mysql ulegnie zmianie i będziesz musiał przejrzeć i przepisać wszystkie konfiguracje.
OK, dzięki, pomyślę o tym...
Pomyślałem i zdecydowałem się wyburzyć 10.4 z uchwytami i zainstalować 10.2, z którym nie było problemów na innych serwerach.
Proces ten nie różnił się zbytnio od procesu aktualizacji. Tylko trzeba było zmienić 10.4 na 10.2 w linku do repozytorium, zresetować i ponownie utworzyć pamięć podręczną dla yum. No cóż, jeszcze jeden „drobiazg”: po usunięciu wersji 10.4 wchodzimy do /var/lib/mysql i stamtąd wszystko usuwamy. Bez tego kroku po zainstalowaniu wersji 10.2 usługa będzie się ciągle zawieszać i zobaczysz
Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"Lub
Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104Przed zaimportowaniem baz danych najpierw ustawiłem hasło roota mysql, które zostało określone w konfiguracjach ISP i zaimportowałem zrzut bazy danych mysql. Cóż, skoro istnieją już użytkownicy i uprawnienia, po prostu importujemy wszystkie bazy danych użytkowników z rzędu z kontem root.
Tekst skryptu dla zrzutu bazy danych:
#!/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'Przed zaimportowaniem baz danych należy je rozpakować. Więc po prostu uruchom polecenie
gunzip /BACK/*.gzI ostatnia rzecz: z jakiegoś powodu łączniki są dozwolone w nazwach baz danych (jeśli tworzysz je za pomocą ISPmanager). Jednak podczas tworzenia lub próby przesłania zrzutu do bazy danych zawierającej łącznik w nazwie pojawia się komunikat, że składnia zapytania jest nieprawidłowa.
Przeczytaj do końca wszystkie błogosławieństwa. Przepraszam za najprawdopodobniej bez odstępów przecinki - mają kłopoty. Jeżeli są życzenia dotyczące propozycji merytorycznie opisane - piszcie prywatnie, bo w komentarzach boję się coś przeoczyć. I nie przeklinaj za bardzo - to mój pierwszy artykuł 🙂
UPD1:
Prawie zapomniałem wspomnieć: kiedy próbowałem znaleźć rozwiązanie problemu bez obniżania wersji MariaDB, musiałem w jakiś sposób zaktualizować informacje. Zostało zaktualizowane w ten sposób: cała baza danych jest konwertowana z InnoDB na MyISAM, infa jest aktualizowana, a następnie konwertowana z powrotem do InooDB.
UPD2:
Właśnie otrzymałem list od 1C-Bitrix o następującej treści:
Żądanie zmiany zostało zakończone
„Po aktualizacji mariadb do wersji 10.4.6 wystąpił błąd podczas zapisywania elementu infoblock”
Moduł: iblock, wersja: nieznana
Rozwiązanie: odrzucone
Więc na razie najwyraźniej nie da się zaktualizować do wersji 10.4 🙁
Źródło: www.habr.com