Najczęściej repliki są wdrażane w celu zapewnienia wysokiej dostępności i/lub skalowania odczytu. Jeśli podstawowy nie powiedzie się, jedna z replik jest promowana do podstawowego. Jeśli jest dużo odczytów, a tak jest prawie zawsze, repliki są dodawane w celu skalowania. W idealnym przypadku zapisy są kierowane do podstawowego, a odczyty są równoważone obciążeniem w replikach. To najskuteczniejszy sposób wykorzystania dostępnych zasobów.
RDS, Azure Database i Cloud SQL zapewniają indywidualne punkty końcowe dla instancji bazy danych, jeden dla podstawowej i jeden dla każdej repliki. Jeśli chcesz równoważyć odczyty, musisz utworzyć wiele połączeń (po jednym dla każdej repliki) i zrobić to samodzielnie. Jeśli chcesz wykonywać zapisy na serwerze podstawowym i odczyty na replikach (tj. dzielenie odczytu/zapisu), musisz utworzyć dodatkowe połączenie z serwerem podstawowym i zrobić to samodzielnie.
Nie śmieszne. Nie fajne.
Dzięki MaxScale, zaawansowanemu serwerowi proxy bazy danych dla MariaDB Enterprise Server, nie musisz się tym martwić. MaxScale wykonuje dla Ciebie równoważenie obciążenia odczytu i dzielenie odczytu/zapisu — to jest to, co nazywamy przezroczystym routingiem zapytań. Deweloperzy nie powinni martwić się o infrastrukturę fizyczną (tj. topologię bazy danych). Dlaczego mieliby? Może jest jedna replika, może jest pięć. Może administratorzy baz danych dodali replikę zeszłej nocy, a może usunęli dwie. To nie powinno mieć znaczenia, a aplikacje nie powinny się z tego rozliczać.
To świetna rzecz w MaxScale. Oddziela podstawową infrastrukturę bazy danych i topologię wdrażania. Może to samodzielna baza danych. Może to zreplikowana baza danych. Może to klastrowana baza danych. Kogo to obchodzi? Zwłaszcza w chmurze.
Dlaczego więc możesz korzystać z przejrzystego routingu zapytań lokalnie, ale nie w chmurze? Ponieważ RDS, Azure Database i Google Cloud SQL nie mają MaxScale. Gdyby tylko istniał DBaaS z MaxScale i przejrzystym routingiem zapytań. Gdybyśmy tylko mogli wznieść się wyżej dzięki najlepszej chmurze MariaDB. Czekaj, witaj SkySQL!
Tak, wprowadziliśmy moc MaxScale do SkySQL.
Po utworzeniu zreplikowanej bazy danych otrzymasz nazwę hosta i dwa porty, jeden do odczytu i jeden do odczytu/zapisu. Potrzebujesz tylko portu odczytu/zapisu, ponieważ wykonuje on również równoważenie obciążenia odczytu. Ale jeśli masz aplikacje tylko do odczytu (np. BI/raportowanie), port do odczytu może się przydać. Łatwe straszne.
Możesz zadać sobie pytanie, czy Shane właśnie udostępnił nazwę hosta i port swojej bazy danych?
Dlaczego tak, tak zrobiłem. Domyślnie bazy danych SkySQL są niedostępne. Musisz dodać do białej listy adresy IP (lub zakresy) wszystkich klientów i serwerów aplikacji wymagających dostępu. A jedyny adres IP, który dodałem do białej listy, to adres mojego laptopa w domu. Powodzenia.
Wracając do tematu, zobaczysz dwa porty:5001 do dzielenia odczytu/zapisu (zapis do podstawowego, równoważenie obciążenia odczytu w replikach) i 5002 do równoważenia obciążenia tylko do odczytu. Moja baza danych ma dwie repliki, ale łączące się z nią aplikacje nie muszą się tym martwić. Mógłbym jutro dodać jeszcze dwie repliki i nie byłyby wymagane żadne zmiany aplikacji, aby z nich skorzystać. MaxScale po prostu i automatycznie rozpocznie kierowanie do nich odczytów.
A jeśli pierwotna zawiedzie, nic wielkiego. MaxScale automatycznie promuje replikę i rozpoczyna routing do niej zapisy (oraz odczyty równoważące obciążenie w pozostałych replikach). Jeśli kiedykolwiek cierpiałeś z powodu nieprzewidywalnego czasu przełączania awaryjnego RDS, wiesz dlaczego. Przełączanie awaryjne RDS opiera się na propagacji DNS, więc nie musisz zmieniać nazwy hosta punktu końcowego. Jest prawie przezroczysty, ale wymaga czasu. Z drugiej strony dzięki MaxScale jest to natychmiastowe – nie jest wymagana propagacja DNS.
Ale nie chcę zbytnio odbiegać od tematu. Planuję coś innego dla HA. Bądź na bieżąco.
