Oftere end ikke implementeres replikaer til høj tilgængelighed og/eller læseskalering. Hvis den primære fejler, forfremmes en af replikaerne til primær. Hvis der er mange læsninger, og det er næsten altid tilfældet, tilføjes replikaer for at skalere ud. Ideelt set dirigeres skrivninger til det primære, og læsninger er belastningsbalanceret på tværs af replikaerne. Det er den mest effektive måde at udnytte de tilgængelige ressourcer på.
RDS, Azure Database og Cloud SQL giver dig alle individuelle slutpunkter til databaseforekomster, et til det primære og et for hver replika. Hvis du vil indlæse balancelæsninger, skal du oprette flere forbindelser (en for hver replika) og gøre det selv. Hvis du vil udføre skrivninger på den primære og læser på replikaerne (dvs. læse/skrive opdeling), skal du oprette en ekstra forbindelse til den primære og gøre det selv.
Ikke sjovt. Ikke fedt.
Med MaxScale, en avanceret databaseproxy til MariaDB Enterprise Server, behøver du ikke bekymre dig om det. MaxScale udfører læsebelastningsbalancering og læse/skriveopdeling for dig - det er det, vi kalder transparent forespørgselsrouting. Udviklere skal ikke være bekymrede over den fysiske infrastruktur (dvs. databasetopologi). Hvorfor skulle de det? Måske er der én replika, måske er der fem. Måske tilføjede DBA'erne en replika i går aftes, måske fjernede de to. Det burde ikke være ligegyldigt, og applikationer skal ikke tage højde for det.
Det er det fantastiske ved MaxScale. Det abstraherer den underliggende databaseinfrastruktur og implementeringstopologi. Måske er det en selvstændig database. Måske er det en replikeret database. Måske er det en klynget database. Og hvad så? Især i skyen.
Så hvorfor kan du drage fordel af gennemsigtig forespørgselsrouting på stedet, men ikke i skyen? Fordi RDS, Azure Database og Google Cloud SQL ikke har MaxScale. Hvis bare der var en DBaaS med MaxScale og transparent forespørgselsrouting. Hvis bare vi kunne svæve højere med den ultimative MariaDB-sky. Hold fast, hej SkySQL!
Ja, vi har bragt kraften fra MaxScale til SkySQL.
Når du har oprettet en replikeret database, får du et værtsnavn og to porte, en læse og en læse/skrive. Du behøver kun læse/skrive-porten, da den også læser belastningsbalancering. Men hvis du har skrivebeskyttede applikationer (f.eks. BI/rapportering), kan læseporten være praktisk. Let peasy.
Du spørger måske dig selv, delte Shane lige værtsnavnet og porten til sin database?
Hvorfor ja, det gjorde jeg. Som standard er SkySQL-databaser ikke tilgængelige. Du skal hvidliste IP-adresserne (eller områderne) for alle klienter og applikationsservere, der kræver adgang. Og den eneste IP-adresse, jeg har hvidlistet, er den til min bærbare computer derhjemme. Held og lykke. 😉
Tilbage til emnet ved hånden, vil du se de to porte:5001 til læse-/skriveopdeling (skriver til primær, læser belastningsbalanceret på tværs af replikaer) og 5002 til skrivebeskyttet belastningsbalancering. Min database har to replikaer, men de programmer, der forbinder til den, behøver ikke at bekymre sig om det. Jeg kunne tilføje to replikaer mere i morgen, og der kræves ingen applikationsændringer for at drage fordel af dem. MaxScale ville simpelthen og automatisk begynde at dirigere læsninger til dem.
Og hvis den primære fejler, er der ingen big deal. MaxScale vil automatisk fremme en replika og begynde at dirigere skrivninger til den (og belastningsbalancering læser på tværs af de resterende replikaer). Hvis du nogensinde har lidt under RDS' uforudsigelige failover-tid, ved du hvorfor. RDS-failover er baseret på DNS-udbredelse, så du ikke behøver at ændre slutpunktets værtsnavn. Det er næsten gennemsigtigt, men det tager tid. Med MaxScale er det på den anden side øjeblikkeligt – ingen DNS-udbredelse påkrævet.
Men jeg ønsker ikke at gå for langt væk fra emnet. Jeg har noget andet i tankerne til HA. Følg med.