MariaDB
 sql >> Database >  >> RDS >> MariaDB

DBaaS, cloud e query routing trasparente

Nella maggior parte dei casi, le repliche vengono distribuite per la disponibilità elevata e/o il ridimensionamento della lettura. In caso di errore del primario, una delle repliche viene promossa a primaria. Se ci sono molte letture, e questo è quasi sempre il caso, le repliche vengono aggiunte per aumentare la scalabilità. Idealmente, le scritture vengono instradate al primario e le letture vengono bilanciate nel carico tra le repliche. È il modo più efficiente per utilizzare le risorse disponibili.

RDS, Database di Azure e Cloud SQL forniscono tutti endpoint individuali per le istanze di database, uno per la primaria e uno per ogni replica. Se vuoi bilanciare il carico delle letture, devi creare più connessioni (una per ogni replica) e farlo da solo. Se vuoi eseguire le scritture sul primario e le letture sulle repliche (ad esempio, la suddivisione in lettura/scrittura), devi creare una connessione aggiuntiva al primario e farlo da solo.

Non è divertente. Non bello.

Con MaxScale, un proxy database avanzato per MariaDB Enterprise Server, non devi preoccuparti. MaxScale esegue il bilanciamento del carico in lettura e la suddivisione in lettura/scrittura per te:è ciò che chiamiamo routing delle query trasparente. Gli sviluppatori non dovrebbero preoccuparsi dell'infrastruttura fisica (ad esempio, la topologia del database). Perché dovrebbero? Forse c'è una replica, forse ce ne sono cinque. Forse i DBA hanno aggiunto una replica ieri sera, forse ne hanno rimossi due. Non dovrebbe importare e le applicazioni non dovrebbero tenerne conto.

Questa è la cosa grandiosa di MaxScale. Astrae l'infrastruttura del database sottostante e la topologia di distribuzione. Forse è un database autonomo. Forse è un database replicato. Forse è un database in cluster. Che importa? Soprattutto nel cloud.

Quindi, perché è possibile sfruttare l'instradamento trasparente delle query in locale, ma non nel cloud? Perché RDS, Database di Azure e Google Cloud SQL non hanno MaxScale. Se solo ci fosse un DBaaS con MaxScale e un routing delle query trasparente. Se solo potessimo salire più in alto con il cloud MariaDB definitivo. Aspetta, ciao SkySQL!

Sì, abbiamo portato la potenza di MaxScale in SkySQL.

Dopo aver creato un database replicato, ti vengono forniti un nome host e due porte, una di lettura e una di lettura/scrittura. Hai solo bisogno della porta di lettura/scrittura in quanto legge anche il bilanciamento del carico. Tuttavia, se si dispone di applicazioni di sola lettura (ad es. BI/reporting), la porta di lettura potrebbe tornare utile. Facile facile.

Potresti chiederti, Shane ha appena condiviso il nome host e la porta del suo database?

Perché sì, sì l'ho fatto. Per impostazione predefinita, i database SkySQL non sono accessibili. È necessario inserire nella whitelist gli indirizzi IP (o intervalli) di tutti i client e server delle applicazioni che richiedono l'accesso. E l'unico indirizzo IP che ho inserito nella whitelist è quello del mio laptop a casa. In bocca al lupo. 😉

Tornando all'argomento in questione, vedrai le due porte:5001 per la suddivisione in lettura/scrittura (scrive su primario, legge il carico bilanciato tra le repliche) e 5002 per il bilanciamento del carico di sola lettura. Il mio database ha due repliche, ma le applicazioni che si connettono ad esso non devono preoccuparsene. Potrei aggiungere altre due repliche domani e non sarebbero necessarie modifiche all'applicazione per trarne vantaggio. MaxScale inizierebbe semplicemente e automaticamente a indirizzare le letture a loro.

E se le primarie falliscono, niente di grave. MaxScale promuoverà automaticamente una replica e inizierà a instradare le scritture su di essa (e il bilanciamento del carico delle letture sulle repliche rimanenti). Se hai mai sofferto del tempo di failover imprevedibile di RDS, sai perché. Il failover RDS si basa sulla propagazione DNS, quindi non è necessario modificare il nome host dell'endpoint. È quasi trasparente, ma ci vuole tempo. Con MaxScale, invece, è immediato:non è richiesta la propagazione DNS.

Ma non voglio allontanarmi troppo dall'argomento. Ho qualcos'altro in mente in programma per HA. Resta sintonizzato.