MySQL 8.0 jest dostępny od jakiegoś czasu, a Percona XtraDB Cluster 8.0 jest również dostępny od jakiegoś czasu. Ponadto MySQL 5.6 zbliża się do końca życia, a ludzie korzystający z PXC 5.6 również będą chcieli wkrótce przejść na nowszą wersję. Rzućmy okiem na ten proces i podzielmy się kilkoma wskazówkami na jego temat.
Pamiętaj, że to MySQL pod spodem...
Na początek musisz pamiętać, że Galera to tylko wtyczka współpracująca z MySQL, więc musisz upewnić się, że przestrzegasz reguł i procesów migracji dla konkretnej wersji MySQL, która jest używana w Twoim PXC. Jeśli używamy PXC 5.7 i chcesz uaktualnić do PXC 8.0, musisz najpierw zaznaczyć wszystkie pola na liście kontrolnej aktualizacji MySQL. Omówiliśmy niektóre z nich na naszym blogu, opisując proces aktualizacji między MySQL 5.7 a MySQL 8.0. Oznacza to również, że możliwe są tylko ścieżki aktualizacji obsługiwane przez MySQL - na przykład nie można zaktualizować PXC 5.6 bezpośrednio do PXC 8.0, ponieważ bezpośrednia aktualizacja MySQL z wersji 5.6 do 8.0 nie jest obsługiwana.
Przeczytaj dokumentację aktualizacji
Jak zwykle za każdym razem, gdy planujesz aktualizację, powinieneś zapoznać się z dokumentacją przygotowaną przez dostawcę. Percona ma stronę internetową poświęconą wyjaśnieniu procesu aktualizacji i ostrzeżeń z nim związanych. Omówimy niektóre z tych punktów w tym poście na blogu.
Zmiany konfiguracji
Istnieje kilka zmian w domyślnych ustawieniach konfiguracji, które mogą powodować problemy w procesie aktualizacji — pxc_strict_mode jest domyślnie ustawione na WYMUSZENIE. Ten tryb blokuje wszelkiego rodzaju konfiguracje, które są eksperymentalne i mogą wpływać na stabilność klastra. Kontrole obejmują między innymi używane silniki pamięci masowej, format dziennika binarnego, istnienie kluczy podstawowych i kilka innych rzeczy. Podczas uaktualniania możesz chcieć ustawić go na PERMISSIVE, aby śledzić niezgodności w dzienniku błędów, ale poza tym pozwolić PXC działać, nawet jeśli niektóre rzeczy nie są w najlepszym stanie.
Inne ustawienie, pxc_encrypt_cluster_traffic, jest również domyślnie włączone, wymuszając szyfrowanie komunikacji Galera między węzłami. Nie jest możliwe łączenie węzłów z węzłami zaszyfrowanymi i niezaszyfrowanymi w tym samym klastrze, dlatego musisz albo skonfigurować go na wszystkich węzłach, albo wyłączyć pxc_encrypt_cluster_traffic w nowych węzłach PXC 8.0.
Zmiana domyślnej wtyczki uwierzytelniania
Wspominaliśmy o tym w naszym poście na blogu dotyczącym migracji do MySQL 8.0, ale zmiana jest tak ważna, że chcemy ją powtórzyć również tutaj – w MySQL 8.0 domyślna wtyczka uwierzytelniająca zmienia się na caching_sha2_password – może uczynić niektóre starsze aplikacje niezgodnymi z MySQL 8.0. Oczywiście możesz zmienić to ustawienie, ale jeśli nie weźmiesz go pod uwagę, może ono zadziałać odwrotnie po zakończeniu aktualizacji.
Procesy aktualizacji
Na początek pamiętaj, że choć nie jest to zalecane, w przypadku niektórych możliwe jest posiadanie zarówno węzłów PXC 5.7, jak i PXC 8.0 działających w tym samym klastrze. Daje to możliwość przeprowadzenia aktualizacji na miejscu. Proces byłby dość prosty - zatrzymaj węzeł PXC 5.7, zaktualizuj go do PXC 8.0, instalując nową wersję i uruchamiając. W katalogu danych procesowych zostanie zaktualizowany do nowej wersji, a nowy węzeł PXC 8.0 powinien być w stanie poprawnie się uruchomić i dołączyć do klastra. Następnie przechodzisz do węzłów jeden po drugim, migrując je z PXC 5.7 do PXC 8.0. Należy pamiętać, że należy unikać SST, ponieważ katalog danych z węzła PXC 8.0 nie może być używany w wersji 5.7. W drugą stronę powinno działać dobrze. Aby zapobiec występowaniu SST, upewnij się, że rozmiar pamięci podręcznej gcache jest wystarczająco duży, aby pomieścić zapisy i umożliwić IST. Sam IST będzie działał dobrze.
Jeśli masz więcej wolnych węzłów, zawsze możesz przeprowadzić aktualizację za pomocą dwóch klastrów na różnych głównych wersjach działających równolegle i połączonych za pomocą replikacji asynchronicznej. Co ważne, takie podejście pozwoli Ci dokładniej przetestować PXC 8.0, ponieważ będziesz miał go na chwilę (w zasadzie tak długo, jak tego potrzebujesz) i będziesz mógł przetestować swoją aplikację na tym klastrze - w dowolnym momencie czas można przenieść część obciążenia tylko do odczytu do PXC 8.0, sprawdzając, jak obsługiwane są zapytania, czy występują błędy lub problemy z wydajnością.
Jeśli używasz ClusterControl, można to osiągnąć za pomocą zadania „Utwórz klaster podrzędny”.
Zostaniesz poproszony o podjęcie decyzji, skąd powinny pochodzić dane początkowe, mistrzu węzeł PXC lub z kopii zapasowej.
Konieczne będzie również przekazanie szczegółów połączenia, takich jak użytkownik SSH i ścieżka klucza .
Następnie zostaniesz poproszony o wybranie dostawcy i wersji - prawdopodobnie chcesz aby na razie używać PXC 5.7, zaktualizujesz węzły później, testując sam proces aktualizacji.
Na koniec musisz przekazać nazwy hostów węzłów lub adresy IP dla ClusterControl do połącz się i zacznij konfigurować węzły.
W rezultacie będziesz mieć drugi klaster Percona XtraDB działający w wersji 5.7 , replikując z oryginalnego klastra. Ten klaster może zostać zaktualizowany do nowej wersji i ostatecznie możesz przekierować do niego ruch. Szczegółowo wyjaśniliśmy ten proces w naszym poprzednim poście na blogu.
Mamy nadzieję, że ten krótki wpis na blogu pomoże Ci lepiej przygotować się do uaktualnienia Twojego klastra Percona XtraDB do wersji 8.0.
