Oftare än inte distribueras repliker för hög tillgänglighet och/eller lässkalning. Om den primära misslyckas, flyttas en av replikerna upp till primär. Om det finns många läsningar, och det är nästan alltid fallet, läggs repliker till för att skala ut. I idealfallet dirigeras skrivningar till den primära och läsningar är lastbalanserade över replikerna. Det är det mest effektiva sättet att använda de tillgängliga resurserna.
RDS, Azure Database och Cloud SQL ger dig alla individuella slutpunkter för databasinstanser, en för den primära och en för varje replik. Om du vill ladda balansläsningar måste du skapa flera anslutningar (en för varje replik) och göra det själv. Om du vill utföra skrivningar på den primära och läser på replikerna (d.v.s. läs/skrivdelning), måste du skapa en ytterligare anslutning till den primära och göra det själv.
Inte kul. Inte coolt.
Med MaxScale, en avancerad databasproxy för MariaDB Enterprise Server, behöver du inte oroa dig för det. MaxScale utför läsbelastningsbalansering och läs/skrivdelning åt dig – det är vad vi kallar transparent frågedirigering. Utvecklare ska inte behöva oroa sig för den fysiska infrastrukturen (d.v.s. databastopologi). Varför skulle de det? Kanske finns det en replik, kanske finns det fem. Kanske lade DBA:erna till en replik i går kväll, kanske tog de bort två. Det borde inte spela någon roll, och applikationer ska inte behöva ta hänsyn till det.
Det är det fantastiska med MaxScale. Den abstraherar bort den underliggande databasinfrastrukturen och distributionstopologin. Kanske är det en fristående databas. Kanske är det en replikerad databas. Kanske är det en klustrad databas. Vem bryr sig? Särskilt i molnet.
Så varför kan du dra fördel av transparent frågedirigering i lokaler, men inte i molnet? Eftersom RDS, Azure Database och Google Cloud SQL inte har MaxScale. Om det bara fanns en DBaaS med MaxScale och transparent frågedirigering. Om vi bara kunde sväva högre med det ultimata MariaDB-molnet. Vänta, hej där SkySQL!
Ja, vi har fört kraften i MaxScale till SkySQL.
När du har skapat en replikerad databas får du ett värdnamn och två portar, en läs och en läs/skriv. Du behöver bara läs/skrivporten eftersom den läser lastbalansering också. Men om du har skrivskyddade applikationer (t.ex. BI/rapportering), kan läsporten vara praktisk. Easy peasy.
Du kanske frågar dig själv, delade Shane bara värdnamnet och porten för sin databas?
Varför ja, ja det gjorde jag. Som standard är SkySQL-databaser inte tillgängliga. Du måste vitlista IP-adresserna (eller intervallen) för alla klienter och applikationsservrar som kräver åtkomst. Och den enda IP-adressen jag har vitlistat är den för min bärbara dator hemma. Lycka till. 😉
Tillbaka till det aktuella ämnet kommer du att se de två portarna:5001 för läs/skrivdelning (skriver till primär, läser lastbalanserad över repliker) och 5002 för skrivskyddad lastbalansering. Min databas har två repliker, men applikationerna som ansluter till den behöver inte bry sig om det. Jag skulle kunna lägga till ytterligare två repliker i morgon, och inga applikationsändringar skulle behövas för att dra nytta av dem. MaxScale skulle helt enkelt och automatiskt börja dirigera läsningar till dem.
Och om den primära misslyckas, ingen stor sak. MaxScale kommer automatiskt att marknadsföra en replik och börja dirigera skrivningar till den (och lastbalansering läser över de återstående replikerna). Om du någonsin har lidit av den oförutsägbara failover-tiden för RDS, vet du varför. RDS-failover baseras på DNS-spridning så du behöver inte ändra värdnamnet för slutpunkten. Det är nästan genomskinligt, men det tar tid. Med MaxScale, å andra sidan, är det omedelbart – ingen DNS-spridning krävs.
Men jag vill inte gå för långt från ämnet. Jag har något annat i åtanke för HA. Håll utkik.