Častěji jsou repliky nasazovány pro vysokou dostupnost a/nebo škálování čtení. Pokud primární selže, jedna z replik je povýšena na primární. Pokud existuje mnoho čtení, a to je téměř vždy případ, přidávají se repliky, aby se zmenšily. V ideálním případě jsou zápisy směrovány na primární a čtení je vyváženo zatížením napříč replikami. Je to nejefektivnější způsob, jak využít dostupné zdroje.
RDS, Azure Database a Cloud SQL vám poskytují jednotlivé koncové body pro instance databáze, jeden pro primární a jeden pro každou repliku. Pokud chcete načíst údaje o zůstatku, musíte vytvořit více připojení (jedno pro každou repliku) a udělat to sami. Pokud chcete provádět zápisy na primární a čtení na replikách (tj. rozdělení čtení/zápisu), musíte vytvořit další připojení k primárnímu a provést to sami.
Není to legrace. Není cool.
S MaxScale, pokročilým databázovým proxy serverem MariaDB Enterprise Server, se o to nemusíte starat. MaxScale za vás provádí vyvažování zátěže při čtení a rozdělování čtení/zápisu – tomu říkáme transparentní směrování dotazů. Vývojáři by se neměli starat o fyzickou infrastrukturu (tj. topologii databáze). Proč by měli? Možná existuje jedna replika, možná jich je pět. Možná, že DBA včera večer přidali repliku, možná odstranili dvě. Na tom by nemělo záležet a aplikace by s tím neměly počítat.
To je skvělá věc na MaxScale. Abstrahuje základní databázovou infrastrukturu a topologii nasazení. Možná je to samostatná databáze. Možná je to replikovaná databáze. Možná je to klastrovaná databáze. Koho to zajímá? Zejména v cloudu.
Proč tedy můžete využít transparentní směrování dotazů v prostorách, ale ne v cloudu? Protože RDS, Azure Database a Google Cloud SQL nemají MaxScale. Kdyby tak existoval DBaaS s MaxScale a transparentním směrováním dotazů. Kdybychom tak mohli stoupat výš s ultimátním cloudem MariaDB. Počkejte, ahoj SkySQL!
Ano, přinesli jsme sílu MaxScale do SkySQL.
Po vytvoření replikované databáze vám bude poskytnut název hostitele a dva porty, jeden pro čtení a jeden pro čtení/zápis. Potřebujete pouze port pro čtení/zápis, protože také vyrovnává zatížení při čtení. Ale pokud máte aplikace pouze pro čtení (např. BI/reporting), port pro čtení se může hodit. Snadno.
Možná se sami sebe ptáte, sdílel Shane právě název hostitele a port své databáze?
Proč ano, ano, udělal. Ve výchozím nastavení nejsou databáze SkySQL přístupné. Musíte přidat na seznam povolených IP adres (nebo rozsahů) všech klientů a aplikačních serverů vyžadujících přístup. A jediná IP adresa, kterou jsem přidal na bílou listinu, je adresa mého notebooku doma. Hodně štěstí. 😉
Zpět k danému tématu uvidíte dva porty:5001 pro rozdělení čtení/zápisu (zápis na primární, čtení s vyvážením zátěže napříč replikami) a 5002 pro vyrovnávání zátěže pouze pro čtení. Moje databáze má dvě repliky, ale aplikace, které se k ní připojují, se o to nemusí starat. Zítra bych mohl přidat další dvě repliky a k jejich využití by nebyly potřeba žádné změny aplikace. MaxScale by k nim jednoduše a automaticky začal směrovat čtení.
A pokud primární selže, nevadí. MaxScale automaticky povýší repliku a zahájí směrování zápisů do ní (a čtení vyvažování zátěže napříč zbývajícími replikami). Pokud jste někdy trpěli nepředvídatelnou dobou selhání RDS, víte proč. Služba RDS failover je založena na šíření DNS, takže nemusíte měnit název hostitele koncového bodu. Je to skoro průhledné, ale chce to čas. Na druhou stranu s MaxScale je to okamžité – není potřeba žádné šíření DNS.
Nechci však příliš odbočovat od tématu. Na HA mám v plánu ještě něco jiného. Zůstaňte naladěni.