„Zaktualizuj swoją bazę danych do najnowszej wersji — to dla Twojego bezpieczeństwa” to coś, co możesz często słyszeć jako dobrą radę i najlepszą praktykę, jeśli chodzi o zarządzanie bazą danych. Z drugiej strony aktualizacja bazy danych może być czasochłonnym zadaniem. Nawet niewielkie uaktualnienie wersji wymaga dokładnego przetestowania uaktualnienia w środowisku przejściowym przed uaktualnieniem konfiguracji produkcyjnej. Więc o co chodzi? Jeśli pozostajesz w tyle za jedną mniejszą wersją, nie powinno to mieć znaczenia, prawda? Cóż, może nie... dopóki tak się nie stanie. Czy naprawdę jesteś gotów podjąć takie ryzyko?
Na początku tego roku w Galera Cluster (CVE-2021-27928) zidentyfikowano nową potencjalnie niebezpieczną lukę w zabezpieczeniach. Na pierwszy rzut oka widzimy, że dotkliwość została oznaczona jako wysoka, a kiedy zaczniemy dalej zagłębiać się w tę kwestię, rzeczywiście wygląda ona na poważną. Wygląda na to, że użytkownik SUPER może wykonać dowolny kod, zmieniając zmienne wsrep_provider i wsrep_notify_cmd w czasie wykonywania. Pozwala użytkownikowi załadować bibliotekę .so i wskazać skrypt, który wykona serwer. Jak możesz sobie wyobrazić, to nie jest dobra sytuacja. Oczywiście, musisz mieć dostęp do użytkownika SUPER i musiałbyś mieć coś do wykonania w węźle bazy danych, ale fakt, że Galera może być skonfigurowany do wykonywania dowolnego kodu jako użytkownik „mysql” jest wystarczająco zły na jego własne.
Jak zwykle w takich przypadkach utworzono poprawki i wypchnięto nowe wersje oprogramowania, na które nie ma wpływu luka. Ten konkretny problem został rozwiązany w MariaDB 10.5.9, 10.4.18, 10.3.28 i 10.2.37, a także w klastrach Percona XtraDB 5.6.51-28.46, Percona XtraDB Cluster 5.7.33-31.49 i Percona XtraDB Cluster 8.0.22-13.1. Wydaje się, że wszystko wróciło do normy. Prawda?
Źle. W środowisku produkcyjnym działa niezliczona ilość systemów, które nie zostały jeszcze zaktualizowane do nowej, niezmienionej wersji. Zespół wsparcia Manynines jest w kontakcie z wieloma środowiskami baz danych na wolności, a my stale pracujemy z potencjalnymi klientami, aby pomóc im w migracji do środowiska zarządzanego przez ClusterControl. Widzimy wszystkie rodzaje MySQL (i nie tylko MySQL) działające w przestarzałych wersjach, czasami nawet w wersjach, które osiągnęły swój koniec życia i nie otrzymują już aktualizacji zabezpieczeń. Nie powinno tak być, zwłaszcza jeśli jesteś użytkownikiem ClusterControl.
ClusterControl zawiera zestaw funkcji, które pomogą Ci być na bieżąco ze wszystkimi poprawkami bezpieczeństwa. Rzućmy okiem:
Przede wszystkim ClusterControl zawiera raporty operacyjne, jednym z nich jest raport aktualizacji pakietu:
Podobnie jak wszystkie raporty operacyjne ClusterControl, raport aktualizacji pakietu można zaplanować na być regularnie wykonywane, a następnie dostarczane za pośrednictwem poczty elektronicznej. Będzie zawierał informacje o wersjach pakietów zainstalowanych na węzłach i czy są jakieś aktualizacje, które należy wykonać:
Raport dotyczący aktualizacji pakietów zawiera listę pakietów, które należy zaktualizować dla wszystkich bazy danych, loadbalancery, poprawki bezpieczeństwa i wszelkie inne pakiety zainstalowane w węźle. W przypadku wszystkich pakietów systemowych rozwiązaniem jest uaktualnienie ich standardowymi metodami (apt, yum). Jeśli chodzi o bazy danych i systemy równoważenia obciążenia, ClusterControl jest wyposażony w funkcję, która umożliwia wykonanie uaktualnienia mniejszej wersji bezpośrednio z interfejsu użytkownika.
Zanim tam pójdziemy, załóżmy, że baza danych musi zostać zaktualizowana. Nie chcesz po prostu kontynuować i uruchomić aktualizacji na ślepo — może to potencjalnie spowodować problemy dla Twojej aplikacji. Nie powinno - mniejsze wersje nie łamią wstecznej kompatybilności (z wyjątkiem sytuacji, gdy używasz MySQL 8.0 - wtedy tak, możesz spodziewać się wszystkiego, przechodząc z 8.0.x do 8.0.x+1); jednak zawsze istnieje pewne ryzyko. To, co powinieneś najpierw zrobić, to przetestować aktualizację w oddzielnym środowisku.
Mamy prosty klaster MariaDB Galera z ProxySQL i Keepalived:
Chcielibyśmy zbudować klaster testowy, aby przetestować aktualizację proces. Dzięki ClusterControl jest to tak proste, jak użycie zadania tworzenia klastra repliki:
Możemy uzyskać świeże dane z istniejącego klastra lub możemy wykorzystać dane z kopii zapasowej.
Musimy również wybrać węzeł źródłowy w klastrze produkcyjnym:
Następnie musimy przejść przez zwykły kreator wdrażania, wybierając wersję i dostawca bazy danych, definiujący hasło roota i tak dalej. Na koniec przekazujemy węzły, na których zostanie zainstalowany klaster.
W rezultacie na liście pojawi się nowy klaster z wyraźny znak, że replikuje się poza klastrem produkcyjnym. Warto wspomnieć, że w domyślnej konfiguracji ClusterControl użyje najnowszych wersji pakietów do utworzenia klastra replik. Jeśli chcesz dokładnie sprawdzić tylko zapytania, to wystarczy. Jeśli chcesz przejść przez cały proces aktualizacji, musisz przypiąć starsze wersje pakietów MySQL, aby zainstalować starą wersję (a następnie odpiąć je i przetestować aktualizację).
Tak czy inaczej, po pomyślnych testach w końcu będziesz chciał przeprowadzić aktualizację. ClusterControl może Ci w tym pomóc:
W Zarządzaj -> Aktualizacje znajdziesz interfejs do przeprowadzenia aktualizacji .
Możesz użyć opcji „Sprawdź nowe pakiety”, aby odświeżyć bazę dostępnych pakiety. Możemy również wybrać, które węzły chcemy uaktualnić i które usługi:
Po prostu potwierdź i to wszystko — ClusterControl wykona aktualizację i wyświetli najnowsza wersja pakietów.
Jak widać, ClusterControl sprawia, że aktualizowanie baz danych jest łatwe i proste. Jedynym krokiem, który musisz wykonać ręcznie, jest prawidłowe testowanie. W przeciwnym razie wszystko inne może wykonać za Ciebie ClusterControl. Chcesz dowiedzieć się więcej o tym, jak ClusterControl może pomóc w efektywnym zarządzaniu bazą danych? Wypróbuj bezpłatnie przez 30 dni.
