Napraw błędy migracji bazy danych Kopano po aktualizacji wersji MySQL

Błąd migracji bazy danych Kopano bezpośrednio po aktualizacji wersji MySQL lub MariaDB zazwyczaj oznacza, że ​​aplikacja i baza danych nie są już zgodne w kwestiach, które wcześniej były niejawne: stan schematu, ustawienia domyślne serwera, zachowanie SQL, uwierzytelnianie czy sama ścieżka aktualizacji. Cel nie polega tylko na kopano-serverjednorazowym uruchomieniu. Celem jest osiągnięcie stanu, w którym schemat jest spójny, Kopano uruchamia się bez błędów aktualizacji bazy danych, użytkownicy mogą otwierać magazyny, a przepływ poczty przetrwa restart.

Ten przewodnik koncentruje się na dowodach. Każdy etap zawiera sygnał sukcesu i punkt, w którym należy przerwać stosowanie tego samego rozwiązania i zmienić kierunek. Publiczna dokumentacja administratora Kopano jest starsza niż obecne wydania MySQL i MariaDB, więc nie należy zakładać, że każda nowoczesna wersja bazy danych jest obsługiwana przez każdą historyczną kompilację Kopano. Jako decydujący dowód należy użyć dokładnej wersji pakietu Kopano, dostawcy bazy danych i błędu serwera.

Zacznij od wyniku, którego potrzebujesz

Przed zmianą konfiguracji zdefiniuj, co oznacza „stały”. Prawidłowe odzyskiwanie zazwyczaj charakteryzuje się wszystkimi poniższymi cechami:

• kopano-serveruruchamia się i działa po ponownym uruchomieniu usługi.
• Dziennik Kopano nie raportuje już aktualizacji schematu bazy danych ani błędu wykonania polecenia SQL.
• Baza danych jest czytelna i możliwa do zapisu za pomocą skonfigurowanego konta Kopano.
• Widoczne są istniejące sklepy i użytkownicy, a nie nowo utworzony pusty schemat.
• Wysyłanie i dostarczanie poczty będzie kontynuowane normalnie.
• Drugie ponowne uruchomienie daje ten sam dobry wynik.

Jeśli osiągniesz tylko pierwszy cel, kontynuuj testowanie. Tymczasowe rozpoczęcie po zmianie sql_mode, na przykład, nie dowodzi, że schemat bazowy jest poprawny.

1. Zatrzymaj autorów Kopano i wykonaj kopię zapasową bazy danych, którą można przywrócić

Dokumentacja aktualizacji Kopano zaleca utworzenie kopii zapasowej bazy danych i plików konfiguracyjnych oraz zatrzymanie usług korzystających z bazy danych przed rozpoczęciem aktualizacji. Dokumentacja wyraźnie wskazuje na zatrzymanie kopano-spooleri kopano-server, a także na uruchomione komponenty opcjonalne. Zobacz dokumentację aktualizacji Kopano Core .

sudo systemctl stop kopano-spooler
sudo systemctl stop kopano-server

mysqldump -u root -p --single-transaction kopano > /root/kopano-before-fix.sql
ls -lh /root/kopano-before-fix.sql

W przypadku dużej instalacji należy również zachować /etc/kopano/, zanotować lokalizację przechowywania załączników i postępować zgodnie z obowiązującą polityką tworzenia kopii zapasowych bazy danych. Jeśli załączniki są przechowywane poza MySQL, sam zrzut SQL nie stanowi kompletnej kopii zapasowej Kopano.

Przed zmianą schematu lub ustawień serwera zatrzymaj usługi Kopano, które zapisują dane w bazie danych i sprawdź, czy istnieje nowy zrzut.

Sygnał powodzenia: masz kopię zapasową, którą można przywrócić do osobnej instancji bazy danych i wiesz, gdzie przechowywane są zewnętrzne załączniki. Zmień podejście, jeśli: samo wykonanie zrzutu się nie powiedzie. Napraw uszkodzenie bazy danych, uprawnienia, miejsce na dysku lub łączność przed podjęciem próby migracji schematu Kopano.

2. Zapisz dokładną wersję bazy danych i zmienione ustawienia domyślne

Duża aktualizacja MySQL może zmienić domyślne ustawienia serwera bez modyfikowania istniejących tabel. Na przykład MySQL 8.0 zmienił domyślny zestaw znaków serwera na utf8mb4, a domyślne sortowanie na utf8mb4_0900_ai_ci. Zmienił również inne domyślne ustawienia i usunął lub uznał starsze zachowanie za przestarzałe. Oracle dokumentuje te różnice w artykule „Zmiany w MySQL 8.0” .

Przechwyć rzeczywisty stan serwera, zamiast zakładać, co zrobiła aktualizacja pakietu:

mysql -u root -p

SELECT VERSION();
SHOW VARIABLES LIKE 'sql_mode';
SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';

Zapisz wersję bazy danych i ustawienia domyślne, jakie teraz widzi Kopano. Wartości te pomagają wyjaśnić błędy, które pojawiły się dopiero po uaktualnieniu bazy danych.

Nie wyłączaj od razu trybów ścisłego SQL. Błąd trybu ścisłego może ujawnić nieprawidłowe dane lub kod SQL, które należy poprawić. Wyłączenie trybu ścisłego może ukryć symptom, pozostawiając dane, które później przestaną działać. Najpierw zarejestruj dokładne błędne polecenie lub błąd bazy danych z logu Kopano.

3. Przeczytaj pierwszy błąd SQL, a nie tylko ostateczną awarię usługi

Systemd często pokazuje tylko to, co kopano-serverzostało zakończone. Przydatny wiersz znajduje się zazwyczaj wcześniej w dzienniku lub logu Kopano. Zacznij od:

journalctl -u kopano-server -n 100 --no-pager

Następnie sklasyfikuj awarię. Poniższa tabela to praktyczna mapa triażowa, a nie stwierdzenie, że jedna przyczyna dotyczy każdej instalacji.

Dziennik zmian Kopano potwierdza, że ​​niektóre wydania wprowadziły zmiany schematu, które wymagały wykonania określonych kopano-dbadmoperacji. Rejestruje również historyczne błędy aktualizacji baz danych, w tym błędy związane ze starymi definicjami tabel MySQL i aktualizacjami UTF-8MB4. Skorzystaj z dziennika zmian Kopano Core , aby dopasować działania konserwacyjne do konkretnej wersji Kopano.

4. Porównaj istniejący schemat Kopano z domyślnymi ustawieniami nowego serwera

Sprawdź schemat w obecnej postaci; same domyślne ustawienia serwera nie mówią nic na temat tego, jak stare są zdefiniowane tabele Kopano.

SHOW CREATE DATABASE kopano;
SHOW TABLE STATUS FROM kopano;

Przeprowadź inspekcję istniejącej definicji bazy danych Kopano i silników pamięci masowej, zachowując przy tym oryginalny błąd migracji w celu porównania.

Jeśli baza danych została pierwotnie utworzona w starszej wersji MySQL, jej tabele mogą zachować starsze zestawy znaków, mimo że nowo tworzone obiekty domyślnie używają teraz utf8mb4. MySQL wyraźnie stwierdza, że ​​aktualizacja z wersji 5.7 do 8.0 nie powoduje automatycznej konwersji istniejących obiektów bazy danych na nowy domyślny zestaw znaków. To rozróżnienie ma znaczenie: migracja może się nie powieść, gdy nowa kolumna lub indeks zostaną utworzone z innymi domyślnymi zestawami znaków niż sąsiednie obiekty.

Kopano dodało obsługę utf8mb4 w późniejszych wersjach Core i udokumentowało konkretny krok konserwacji bazy danych, kopano-dbadm usmp, w celu uaktualnienia istniejących baz danych do obsługi 4-bajtowego Unicode. Nie uruchamiaj tego polecenia tylko dlatego, że MySQL teraz domyślnie używa utf8mb4; uruchamiaj je tylko wtedy, gdy wymaga tego dokumentacja zainstalowanej wersji Kopano lub dane wyjściowe serwera.

5. Jeśli MariaDB została zaktualizowana, najpierw wykonaj aktualizację po stronie MariaDB

Jeśli Twoim back-endem jest MariaDB, a nie Oracle MySQL, zakończ procedurę aktualizacji serwera bazy danych, zanim zrzucisz winę na Kopano. Dokumenty MariaDB mariadb-upgradewskazują na narzędzie, które aktualizuje tabele systemowe i sprawdza je po zmianach wersji głównej. W dokumentacji zaleca się wcześniejsze utworzenie kopii zapasowej wszystkich baz danych. Zobacz oficjalną dokumentację mariadb-upgrade .

To jest gałąź, a nie polecenie uniwersalne. Nie uruchamiaj jej mariadb-upgradew środowisku Oracle MySQL. I odwrotnie, nie stosuj założeń MySQL 8.0 do serwera MariaDB tylko dlatego, że oba akceptują mysqlprotokół klienta.

6. Sprawdź, czy konto bazy danych Kopano nadal ma wymagane uprawnienia

W podręczniku administratora Kopano podano, że serwer potrzebuje uprawnień, w tym ALTER, CREATE, CREATE ROUTINE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, i UPDATEdo bazy danych Kopano. Parametry połączenia z bazą danych są konfigurowane za pomocą ustawień związanych z MySQL w /etc/kopano/server.cfg. Zobacz Konfigurowanie komponentów KC .

Po migracji wersji MySQL administrator może ponownie utworzyć użytkowników, zmienić wtyczki uwierzytelniające, przenieść hosta bazy danych lub przywrócić niekompletne uprawnienia. Przetestuj tę samą nazwę hosta i konto, których używa Kopano. Jeśli uwierzytelnianie nie powiedzie się przed wykonaniem migracji SQL, najpierw rozwiąż problem z kontem lub uprawnieniami.

7. Naprawiaj tylko stan, który został udowodniony błędem

W tym momencie powinieneś mieć jedną konkretną klasę awarii. Zastosuj najmniejszą zmianę, która ją wyjaśnia:

• Częściowa aktualizacja schematu Kopano: postępuj zgodnie z uaktualnieniem Kopano właściwym dla danej wersji lub kopano-dbadminstrukcją wskazaną przez zainstalowaną wersję. Nigdy nie usuwaj znacznika wersji ani nie dodawaj ręcznie kolumn tylko po to, aby uruchomić kolejne polecenie.
• Niezgodność zestawu znaków lub sortowania: najpierw zidentyfikuj problematyczną tabelę i kolumnę. Zaplanuj konwersje na podstawie odtworzonej kopii przed wprowadzeniem do produkcji, ponieważ zmiany w zestawie znaków mogą zmienić rozmiary indeksów i sposób porównywania.
• Niezgodność tabel systemowych MariaDB: wykonaj udokumentowaną procedurę aktualizacji MariaDB, a następnie spróbuj ponownie użyć Kopano.
• Uprawnienia lub uwierzytelnianie: popraw konto Kopano DB i zweryfikuj logowanie z hosta Kopano.
• Nieobsługiwana kombinacja wersji: przerwij eksperymenty konfiguracyjne. Przywróć środowisko bazy danych sprzed aktualizacji lub przejdź na kombinację Kopano/baza danych, którą obsługuje dostawca lub źródło pakietu.

Ostatni przypadek jest istotny. Publicznie dostępny podręcznik administratora Kopano Core pochodzi ze starszej generacji produktu, podczas gdy obecne wersje MySQL i MariaDB ulegają ciągłym zmianom. Jeśli nie możesz znaleźć informacji o wsparciu technicznym dla swojego konkretnego połączenia, brak dokumentacji nie powinien być interpretowany jako brak zgodności.

8. Uruchom Kopano i sprawdź stan procesu

sudo systemctl start kopano-server
sudo systemctl start kopano-spooler

systemctl --no-pager --full status kopano-server
journalctl -u kopano-server -n 50 --no-pager

Zdrowy stan usługi jest konieczny, ale niewystarczający; przejrzyj dziennik uruchamiania, a następnie zweryfikuj magazyny użytkowników i przepływ poczty.

Po uruchomieniu usługi przetestuj działanie z użyciem rzeczywistej aplikacji. Otwórz co najmniej jedną istniejącą skrzynkę pocztową, sprawdź, czy znajdują się tam stare foldery i wiadomości, wyślij wiadomość między dwoma kontami lokalnymi, wyślij jedną wiadomość wychodzącą i sprawdź, czy działa dostarczanie wiadomości przychodzących. Jeśli korzystasz z protokołu IMAP, ActiveSync, archiwizacji, komponentów wieloserwerowych lub zewnętrznej pamięci masowej załączników, przetestuj również te ścieżki.

Kiedy należy zmienić podejście?

Przestań powtarzać zmiany schematu, jeśli wystąpi którykolwiek z poniższych warunków:

• Błąd SQL zmienia się po każdej ręcznej modyfikacji, co sugeruje częściową migrację schematu.
• Przywrócona baza danych sprzed aktualizacji działa w starej wersji bazy danych, ale stale zawodzi w nowej.
• Nie możesz ustalić, czy kompilacja Kopano obsługuje zainstalowaną główną wersję bazy danych MySQL lub MariaDB.
• Sprawdzanie tabel zgłasza uszkodzenia, a nie zwykłą niezgodność schematu.
• Konwersja zestawu znaków wymagałaby zmiany wielu dużych tabel bez przetestowanego wycofania.

W takich przypadkach bezpieczniejszym rozwiązaniem jest często odtworzenie poprzedniego środowiska bazy danych, przywrócenie znanej, dobrej kopii zapasowej i zaplanowanie etapowej aktualizacji w postaci klonu. Oracle zaznacza, że ​​obniżenie wersji MySQL 8.0 do 5.7 nie jest obsługiwane; obsługiwanym rozwiązaniem alternatywnym jest przywrócenie kopii zapasowej wykonanej przed aktualizacją. Zobacz informacje o wydaniu MySQL 8.0 .

Ostateczna lista kontrolna weryfikacji

• Kopia zapasowa bazy danych i kopia zapasowa konfiguracji Kopano zostają zachowane.
• Rejestrowana jest dokładna wersja MySQL lub MariaDB.
• Pierwszy poważny błąd SQL został zidentyfikowany i wyjaśniony.
• Nie zastosowano żadnego szerokiego obejścia trybu SQL lub zestawu znaków bez dowodów.
• Wymagana konserwacja schematu Kopano jest zgodna z zainstalowaną wersją Kopano.
• kopano-serverprzetrwa drugi restart.
• Istniejące skrzynki pocztowe, foldery i wiadomości pozostają nienaruszone.
• Testy dostarczania danych przychodzących, wychodzących i lokalnych zakończyły się sukcesem.
• Przetestowano opcjonalne komponenty używane w Twoim środowisku.

Problem migracji bazy danych zostaje rozwiązany, gdy schemat, serwer bazy danych i wersja Kopano ponownie się zgadzają, a nie gdy komunikat o błędzie po prostu znika. Zachowaj dowody, które doprowadziły do ​​naprawy, ponieważ są to również informacje potrzebne do kolejnej aktualizacji bazy danych lub Kopano.