🥇Bitrix i aktualizacja MariaDB do najnowszej stabilnej wersji

Dzień dobry, szanowni Czytelnicy! Pozwólcie, że się przedstawię, nazywam się Aleksander. Jestem administratorem systemów małej, ale dumnej agencji internetowej. Chcemy, aby wszystko działało szybko, bezpiecznie i z nowym oprogramowaniem. W tym celu uruchomiliśmy także połączenie nagios+PhantomJS na komputerze biurowym i co 30 minut sprawdzamy prędkość ładowania stron. W ramach obsługi monitorujemy również aktualizacje 1C-Bitrix i regularnie je instalujemy. Pewnego dnia, po kolejnej aktualizacji, zobaczyliśmy w panelu administracyjnym komunikat, że od lata 2019 roku 1C-Bitrix przestaje działać z MySQL 5.5 i trzeba się zaktualizować. Chłopaki z ISPSystem są świetni i regularnie rozwijają funkcjonalność panelu, za co im serdecznie dziękuję. Ale tym razem nie udało się wszystkiego kliknąć myszą. A o tym, co się udało i ile siwych włosów teraz mam w brodzie, można się dowiedzieć pod katem.

Pozostała tylko opcja zainstalowania „alternatywnego serwera DB”, który instaluje się w kontenerze Docker. Oczywiście rozumiem, że Docker jest bardzo oszczędny w użyciu zasobów, ale niezależnie od tego, jak dobrze działa, overhead i tak będą >0. A my walczymy o dziesiąte części sekundy i optymalizujemy wszystkie strony przed opublikowaniem ich u siebie oraz podpisaniem umowy. Więc to nie jest moja opcja.
Dobrze, co jest napisane w dokumentacji? Backup wszystkiego, dodać do pliku yum.repos.d link do repozytorium MariaDB, następnie

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

Yum później będzie narzekać, że ktoś usunął zainstalowane pakiety bez jego wiedzy. Ale po pierwsze - niech narzeka, nic strasznego. A po drugie, jeśli usuwa się przez yum, to próbuje usunąć razem z MariaDB także wszystko, co z nim zależne, czyli PHP, ISPManager i PHPmyadmin. Zatem później zajmiemy się narzekaniem.


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

W końcu wszystko zostało zainstalowane i działa. Miło, że bazy zostały podchwycone i nie trzeba było ich przywracać z kopii zapasowych. Sprawdziłem strony - działają i szybko. Zajrzałem do kilku paneli administracyjnych, aby upewnić się, że nic nie padło, i powiadomiłem dyrektora, że wszystko jest OK. Minęło zaledwie 30 minut, a okazało się, że wcale nie jest OK...

Podczas próby zalogowania się do panelu administracyjnego i dodania/edytowania czegokolwiek w treści pojawił się komunikat

Błąd zapytania MySQL: Wstaw do b_iblock_element_property (ID, IBLOCK_ELEMENT_ID, IBLOCK_PROPERTY_ID, VAL UE, VALUE_NUM) wybierz 10555 ,2201 ,P.ID ,'3607' ,3607.0000 Z b_iblock_property P GDZIE ID = 184 [[1062] Duplikat wpisu '10555' dla klucza 'PRIMARY']

Ponieważ treść na stronę dodają nasze pracownice, klienci jeszcze nic nie wiedzieli i na razie nie zaczęli nas rozrywać na kawałki. Ale to była kwestia czasu, ponieważ informacje na stronach trzeba aktualizować, a wielu klientów śledzi to samodzielnie i uważnie.

Z treści błędu można wnioskować, że Bitrix próbuje dodać nowy wpis do bazy, wskazując ten sam klucz główny, który miał edytowany artykuł. Oznacza to, że można podejrzewać, że problem występuje po stronie Bitrix. Wchodzimy na ich stronę i kontaktujemy się z pomocą techniczną. Prawie natychmiast otrzymujemy odpowiedź „skomplikowany problem. Przekazaliśmy starszym inżynierom — czekajcie…”.

Czekanie trwało dość długo (cała rozmowa odbywała się w okresie od 25.06.2019 do 9.07.2019) i ostatecznym wynikiem była wiadomość „problem nie jest związany z działaniem CMS Bitrix, ale z działaniem samej bazy danych w mariadb 10.4.6 i niestety po stronie strony nie ma możliwości rozwiązania tego problemu, będziemy musieli przejść na starszą wersję MariaDB.”

Płyniemy… O downgrade myślałem jeszcze na początku historii, ale tutaj czarnym na białym jest napisane, że żaden downgrade nie może mieć miejsca. Zróbcie zrzuty i wdrażajcie na nowo na czysto zainstalowanym serwerze. Tzn. to dobrze, że nie zaktualizowałem wszystkich serwerów naraz. Tzn. „tylko” stówka stron (nervowe śmiechy:-)). Jeszcze w pomocy technicznej powiedzieli: „Aby rozwiązać problem przy używaniu bazy MariaDB 10.4.6, będziecie musieli skontaktować się z pomocą techniczną MariaDB, która w transakcji nie wykona usunięcia rekordu z bazy, jeśli wykonuje się zapytanie:

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

Nadzieja tliła się przez kilka godzin od momentu rozpoczęcia kontaktu z pomocą techniczną MariaDB, ale potem przyszło pismo, w którym bardzo poprawnie mi powiedziano, że nie jestem użytkownikiem komercyjnym i dlatego nikt nie będzie celowo rozwiązywał mojego problemu, ale jest forum na ich stronie i tam można spróbować poszukać opcji… Nie będę męczyć szczegółami. Nie ma tam opcji.
O! Mamy kupioną licencję na ISP!
— Halo, wsparcie? Chłopaki, pomóżcie!
— Przykro mi, nie wspieramy modyfikacji, które zmieniają natywne wersje DBMS. Jeśli chcesz — jest opcja z alternatywnym serwerem w Dockerze.
— Ale jak użytkownicy i bazy tam trafią? W Dockerze?
— Cóż, wrzucisz je tam ręcznie...
— Tak! I nie zapomnij, że port dla mysql się zmieni i trzeba będzie przejrzeć wszystkie konfiguracje i je przepisać.
— Ok, dziękuję, pomyślę o tym...
Pomyślałem i zdecydowałem się ręcznie usunąć 10.4 i zainstalować 10.2, z którym na innych serwerach nie było problemów.

Proces niewiele różnił się od procesu aktualizacji. Tylko trzeba było w linku do repozytorium zmienić 10.4 na 10.2, zresetować i stworzyć ponownie cache dla yum. No i jeszcze jedna „drobnostka”: po usunięciu 10.4 idziemy do /var/lib/mysql i wszystko stamtąd usuwamy. Bez tego kroku po instalacji 10.2, usługa będzie się ciągle zawieszać i będziesz widział

Nie udało się połączyć z bazą danych '' Utracono połączenie z serwerem MySQL przy 'czytaniu wstępnego pakietu komunikacyjnego', błąd systemowy: 104 "Połączenie zresetowane przez partnera"

Lub

Utracono połączenie z serwerem MySQL przy 'handshake: czytanie wstępnego pakietu komunikacyjnego', błąd systemowy: 104

Zanim zaimportowałem bazy, najpierw ustawiłem ten hasło root dla mysql, które było zapisane w konfiguracjach ISP i zaimportowałem zrzut bazy mysql. A potem, ponieważ użytkownicy i uprawnienia już istnieją, po prostu z kontem root importujemy kolejno wszystkie bazy użytkowników.

Skrypt do zrzutu baz:

#!/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 importem baz muszą być one rozpakowane. Dlatego po prostu wykonujemy polecenie

gunzip /BACK/*.gz

I ostatnie: z jakiegoś powodu w nazwach baz (jeśli tworzysz przez ISPmanager) dozwolone są myślniki. A gdy przy tworzeniu lub próbie załadowania zrzutu do bazy, której nazwa zawiera myślnik, otrzymujesz komunikat o tym, że składnia zapytania jest nieprawidłowa.

Dla tych, którzy przeczytali aż do końca, wszystkiego dobrego. Przepraszam za możliwe błędy interpunkcyjne — z nimi mam problem. Jeśli będą sugestie co do opisu — piszcie na priv, bo w komentarzach boję się coś przeoczyć. I nie obrażajcie się za bardzo — to mój pierwszy artykuł 🙂

UPD1:

Trochę nie zapomniałem wspomnieć: podczas gdy próbowałem znaleźć rozwiązanie problemu bez downgrade'u MariaDB, jakoś trzeba było aktualizować dane. Proces przebiegał tak: cała baza konwertowana jest z InnoDB do MyISAM, aktualizowane są informacje, a następnie konwertowana z powrotem do InnoDB.
UPD2:

Właśnie przyszła wiadomość od 1C-Bitrix o następującej treści:

Zgłoszenie na poprawkę zrealizowane
„Po aktualizacji mariadb do 10.4.6 błąd podczas zapisywania elementu bloku informacyjnego”
Moduł: iblock, wersja: nieznana
Rozwiązanie: odrzucone

Więc na razie nie można zaktualizować do 10.4 🙁

Źródło: habr.com