Chmura zapewnia bardzo elastyczne środowiska pracy. Możesz go łatwo skalować w górę i w dół, dodając lub usuwając węzły. Jeśli zajdzie taka potrzeba, możesz łatwo stworzyć klon swojego środowiska. Można to wykorzystać do procesów takich jak aktualizacje, testy obciążeniowe, odzyskiwanie po awarii. Głównym problemem, z którym musisz sobie poradzić, jest to, że aplikacje muszą w jakiś sposób łączyć się z bazami danych, a elastyczne konfiguracje mogą być trudne dla baz danych - zwłaszcza w przypadku konfiguracji master-slave. Na szczęście istnieje kilka opcji, które ułatwiają ten proces.
Jednym ze sposobów jest wykorzystanie serwera proxy bazy danych. Istnieje kilka serwerów proxy do wyboru, ale w tym wpisie na blogu użyjemy ProxySQL, dobrze znanego serwera proxy dostępnego dla MySQL i MariaDB. Pokażemy, jak można go wykorzystać do efektywnego przenoszenia ruchu między węzłami MySQL bez widocznego wpływu na aplikację. Wyjaśnimy również pewne ograniczenia i wady tego podejścia.
Wstępna konfiguracja chmury
Najpierw omówmy konfigurację. Wykorzystamy instancje AWS EC2 dla naszego środowiska. Ponieważ tylko testujemy, tak naprawdę nie zależy nam na wysokiej dostępności poza tym, co chcemy udowodnić — bezproblemowymi zmianami głównymi. Dlatego użyjemy pojedynczego węzła aplikacji i pojedynczego węzła ProxySQL. Zgodnie z dobrymi praktykami umieścimy ProxySQL w węźle aplikacji, a aplikacja zostanie skonfigurowana do łączenia się z ProxySQL przez gniazdo Unix. Zmniejszy to obciążenie związane z połączeniami TCP i zwiększy bezpieczeństwo - ruch z aplikacji do proxy nie opuści lokalnej instancji, pozostawiając do zaszyfrowania tylko połączenie ProxySQL -> MySQL. Ponownie, ponieważ jest to prosty test, nie będziemy konfigurować SSL. W środowiskach produkcyjnych chcesz to zrobić, nawet jeśli używasz VPC.
Środowisko będzie wyglądało jak na poniższym diagramie:
Jako aplikacji użyjemy Sysbench - syntetycznego programu benchmarkowego dla MySQL . Posiada opcję wyłączania i włączania korzystania z transakcji, której użyjemy, aby zademonstrować, jak obsługuje je ProxySQL.
Instalowanie klastra replikacji MySQL za pomocą ClusterControl
Aby wdrożenie było szybkie i wydajne, użyjemy ClusterControl do wdrożenia dla nas konfiguracji replikacji MySQL. Instalacja ClusterControl wymaga tylko kilku kroków. Nie będziemy tutaj wchodzić w szczegóły, ale powinieneś otworzyć naszą stronę internetową, rejestracja i instalacja ClusterControl powinna być dość prosta. Pamiętaj, że musisz skonfigurować bezhasłowe SSH między instancją ClusterControl a wszystkimi węzłami, którymi będziemy za jej pomocą zarządzać.
Po zainstalowaniu ClusterControl możesz się zalogować. Zostanie wyświetlony kreator wdrażania:
Ponieważ mamy już instancje działające w chmurze, po prostu pójdziemy z Opcja „Wdróż”. Zostanie nam przedstawiony następujący ekran:
Wybierzemy replikację MySQL jako typ klastra i musimy zapewnić łączność Detale. Może to być połączenie przy użyciu użytkownika root lub może to być również użytkownik sudo z hasłem lub bez.
W kolejnym kroku musimy podjąć pewne decyzje. Będziemy używać Percona Server for MySQL w jego najnowszej wersji. Musimy również zdefiniować hasło dla użytkownika root w węzłach, które wdrożymy.
W ostatnim kroku musimy zdefiniować topologię - pójdziemy co zaproponowaliśmy na początku - mistrza i trzech niewolników.
ClusterControl uruchomi wdrożenie - możemy to śledzić w zakładce Aktywność, jak pokazano na powyższym zrzucie ekranu.
Po zakończeniu wdrażania możemy zobaczyć klaster na liście klastrów:
Instalowanie ProxySQL 2.0 za pomocą ClusterControl
Następnym krokiem będzie wdrożenie ProxySQL. ClusterControl może to za nas zrobić.
Możemy to zrobić w Zarządzaj -> Load Balancer.
Ponieważ tylko testujemy różne rzeczy, zamierzamy ponownie użyć instancji ClusterControl dla ProxySQL i Sysbench. W prawdziwym życiu prawdopodobnie chciałbyś użyć swojego „prawdziwego” serwera aplikacji. Jeśli nie możesz go znaleźć w menu rozwijanym, zawsze możesz ręcznie wpisać adres serwera (IP lub nazwę hosta).
Chcemy również zdefiniować poświadczenia dla użytkownika monitorującego i administracyjnego. Sprawdziliśmy również dwukrotnie, czy ProxySQL 2.0 zostanie wdrożony (w razie potrzeby zawsze możesz zmienić go na 1.4.x).
W dolnej części kreatora określimy użytkownika, który będzie utworzony zarówno w MySQL, jak i ProxySQL. Jeśli masz istniejącą aplikację, prawdopodobnie chcesz użyć istniejącego użytkownika. Jeśli używasz wielu użytkowników dla swojej aplikacji, zawsze możesz zaimportować resztę później, po wdrożeniu ProxySQL.
Chcemy mieć pewność, że wszystkie instancje MySQL zostaną skonfigurowane w ProxySQL. Użyjemy transakcji jawnych, więc odpowiednio ustawimy przełącznik. To wszystko, co musieliśmy zrobić - reszta to kliknąć przycisk „Wdróż ProxySQL” i pozwolić ClusterControl zrobić swoje.
Po zakończeniu instalacji ProxySQL pojawi się na liście węzłów w klastrze. Jak widać na powyższym zrzucie ekranu, wykrył już topologię i rozproszone węzły w grupach hostów odczytujących i zapisujących.
Instalowanie aplikacji Sysbench
Ostatnim krokiem będzie utworzenie naszej „aplikacji” poprzez zainstalowanie Sysbench. Proces jest dość prosty. Najpierw musimy zainstalować wymagania wstępne, biblioteki i narzędzia wymagane do kompilacji Sysbench:
[email protected]:~# apt install git automake libtool make libssl-dev pkg-config libmysqlclient-devW takim razie chcemy sklonować repozytorium sysbench:
[email protected]:~# git clone https://github.com/akopytov/sysbench.gitNareszcie chcemy skompilować i zainstalować Sysbench:
[email protected]:~# cd sysbench/
[email protected]:~/sysbench# ./autogen.sh && ./configure && make && make installTo jest to, Sysbench został zainstalowany. Teraz musimy wygenerować trochę danych. W tym celu najpierw musimy stworzyć schemat. Połączymy się z lokalnym ProxySQL i za jego pośrednictwem stworzymy schemat „sbtest” na masterze. Pamiętaj, że do połączenia z ProxySQL użyliśmy gniazda Unix.
[email protected]:~/sysbench# mysql -S /tmp/proxysql.sock -u sbtest -psbtest
mysql> CREATE DATABASE sbtest;
Query OK, 1 row affected (0.01 sec)Teraz możemy użyć sysbench do zapełnienia bazy danych danymi. Ponownie używamy gniazda Unix do połączenia z proxy:
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --events=0 --time=3600 --mysql-socket=/tmp/proxysql.sock --mysql-user=sbtest --mysql-password=sbtest --tables=32 --report-interval=1 --skip-trx=on --table-size=100000 --db-ps-mode=disable prepareGdy dane są gotowe, możemy przystąpić do naszych testów.
Wnioski
W drugiej części tego bloga omówimy obsługę połączeń przez ProxySQL, przełączanie awaryjne i jego ustawienia, które mogą pomóc nam zarządzać przełącznikiem głównym w sposób, który będzie jak najmniej inwazyjny dla aplikacji.
