Vaker wel dan niet worden replica's ingezet voor hoge beschikbaarheid en/of leesschaling. Als de primaire mislukt, wordt een van de replica's gepromoveerd tot primair. Als er veel reads zijn, en dat is bijna altijd het geval, worden replica's toegevoegd om uit te schalen. In het ideale geval worden schrijfbewerkingen doorgestuurd naar de primaire en leesbewerkingen worden verdeeld over de replica's. Het is de meest efficiënte manier om de beschikbare middelen te gebruiken.
RDS, Azure Database en Cloud SQL bieden u allemaal individuele eindpunten voor database-instanties, één voor de primaire en één voor elke replica. Als u uitlezingen wilt laden, moet u meerdere verbindingen maken (één voor elke replica) en dit zelf doen. Als u schrijfbewerkingen op de primaire en leesbewerkingen op de replica's wilt uitvoeren (d.w.z. lezen/schrijven splitsen), moet u een extra verbinding met de primaire maken en dit zelf doen.
Niet leuk. Niet cool.
Met MaxScale, een geavanceerde databaseproxy voor MariaDB Enterprise Server, hoeft u zich daar geen zorgen over te maken. MaxScale voert leestaakverdeling en lees-/schrijfsplitsing voor u uit - dit noemen we transparante queryrouting. Ontwikkelaars hoeven zich geen zorgen te maken over de fysieke infrastructuur (d.w.z. databasetopologie). Waarom zouden ze? Misschien is er één replica, misschien zijn het er vijf. Misschien hebben de DBA's gisteravond een replica toegevoegd, misschien hebben ze er twee verwijderd. Het zou niet uit moeten maken, en applicaties zouden er geen rekening mee moeten houden.
Dat is het mooie van MaxScale. Het abstraheert de onderliggende database-infrastructuur en implementatietopologie. Misschien is het een op zichzelf staande database. Misschien is het een gerepliceerde database. Misschien is het een geclusterde database. Wie kan het schelen? Vooral in de cloud.
Dus waarom kunt u profiteren van transparante queryrouting op locatie, maar niet in de cloud? Omdat RDS, Azure Database en Google Cloud SQL geen MaxScale hebben. Was er maar een DBaaS met MaxScale en transparante queryrouting. Konden we maar hoger stijgen met de ultieme MariaDB-cloud. Wacht even, hallo daar SkySQL!
Ja, we hebben de kracht van MaxScale naar SkySQL gebracht.
Nadat u een gerepliceerde database hebt gemaakt, krijgt u een hostnaam en twee poorten, één lezen en één lezen/schrijven. U hebt alleen de lees-/schrijfpoort nodig, aangezien deze ook de taakverdeling leest. Maar als u alleen-lezen toepassingen heeft (bijv. BI/rapportage), kan de leespoort van pas komen. Makkelijk.
Je vraagt je misschien af, heeft Shane zojuist de hostnaam en poort van zijn database gedeeld?
Waarom ja, ja dat deed ik. Standaard zijn SkySQL-databases niet toegankelijk. U moet de IP-adressen (of bereiken) op de witte lijst zetten van alle clients en applicatieservers die toegang nodig hebben. En het enige IP-adres dat ik op de witte lijst heb gezet, is dat van mijn laptop thuis. Veel geluk.
Terug naar het onderwerp bij de hand, zie je de twee poorten:5001 voor lezen/schrijven splitsen (schrijft naar primair, leest load balanced over replica's) en 5002 voor read-only load balancing. Mijn database heeft twee replica's, maar de toepassingen die ermee verbinding maken, hoeven zich er geen zorgen over te maken. Ik zou morgen nog twee replica's kunnen toevoegen en er zijn geen applicatiewijzigingen nodig om hiervan te profiteren. MaxScale zou eenvoudig en automatisch beginnen met het routeren van leesacties naar hen.
En als de primaire faalt, geen probleem. MaxScale promoot automatisch een replica en begint de schrijfbewerkingen ernaar te routeren (en load balancing-lezingen over de resterende replica's). Als je ooit last hebt gehad van de onvoorspelbare failover-tijd van RDS, weet je waarom. RDS-failover is gebaseerd op DNS-propagatie, dus u hoeft de hostnaam van het eindpunt niet te wijzigen. Het is bijna transparant, maar het kost tijd. Met MaxScale daarentegen is het onmiddellijk - geen DNS-propagatie vereist.
Maar ik wil niet te ver van het onderwerp afdwalen. Ik heb iets anders in gedachten gepland voor HA. Blijf op de hoogte.