sql >> Database >  >> NoSQL >> MongoDB

Transparante database-failover voor uw toepassingen

ClusterControl is een geweldig hulpmiddel voor het implementeren en beheren van databaseclusters - als u van MySQL houdt, kunt u eenvoudig clusters implementeren op basis van zowel traditionele MySQL-master-slave-replicatie, Galera-cluster of MySQL NDB-cluster. Om een ​​hoge beschikbaarheid te bereiken, is het inzetten van een cluster echter niet voldoende. Nodes kunnen (en zullen hoogstwaarschijnlijk) uitvallen, en uw systeem moet zich aan die veranderingen kunnen aanpassen.

Deze aanpassing kan op verschillende niveaus plaatsvinden. U kunt een soort logica in de toepassing implementeren - het zou de status van clusterknooppunten controleren en verkeer leiden naar degenen die op dat moment bereikbaar zijn. U kunt ook een proxylaag bouwen die hoge beschikbaarheid in uw systeem implementeert. In deze blogpost willen we enkele tips delen over hoe u dat kunt bereiken met ClusterControl.

HAProxy implementeren met behulp van de ClusterControl

HAProxy is de standaard - een van de meest populaire proxy's die wordt gebruikt in combinatie met MySQL (maar niet alleen natuurlijk). ClusterControl ondersteunt de implementatie en bewaking van HAProxy-knooppunten. Het helpt ook om hoge beschikbaarheid van de proxy zelf te implementeren met behulp van keepalive.

Implementatie is vrij eenvoudig - je moet het IP-adres van een host kiezen of invullen waar HAProxy wordt geïnstalleerd, een poort kiezen, een taakverdelingsbeleid, beslissen of ClusterControl een bestaande repository of de meest recente broncode moet gebruiken om HAProxy te implementeren. Je kunt ook kiezen welke backend-knooppunten je wilt opnemen in de proxyconfiguratie en of ze actief moeten zijn of een back-up moeten maken.

Standaard werkt de door ClusterControl geïmplementeerde HAProxy-instantie op MySQL-cluster (NDB), Galera-cluster, PostgreSQL-streamingreplicatie en MySQL-replicatie. Voor master-slave-replicatie kan ClusterControl twee listeners configureren, een voor alleen-lezen en een andere voor lezen-schrijven. Toepassingen moeten dan lees- en schrijfbewerkingen naar de respectieve poorten sturen. Voor replicatie met meerdere masters stelt ClusterControl de standaard TCP-taakverdeling in op basis van het algoritme voor de minste verbinding (bijv. voor Galera Cluster waarbij alle knooppunten beschrijfbaar zijn).

Keepalive wordt gebruikt om hoge beschikbaarheid toe te voegen aan de proxylaag. Als je ten minste twee HAProxy-knooppunten in je systeem hebt, kun je Keepalived installeren vanuit de ClusterControl-gebruikersinterface.

U moet twee HAProxy-knooppunten kiezen en deze worden geconfigureerd als een actief - stand-by-paar. Er wordt een virtueel IP-adres toegewezen aan de actieve server en als het niet werkt, wordt het opnieuw toegewezen aan de stand-byproxy. Op deze manier kunt u gewoon verbinding maken met de VIP en worden al uw vragen doorgestuurd naar de momenteel actieve en werkende HAProxy-node.

U kunt meer details vinden over hoe de interne onderdelen zijn geconfigureerd door onze HAProxy-zelfstudie te lezen.

ProxySQL implementeren met ClusterControl

Hoewel HAProxy een ijzersterke proxy is en een zeer populaire keuze, mist het databasebewustzijn, bijvoorbeeld lezen-schrijven splitsen. De enige manier om dit in HAProxy te doen, is door twee backends te maken en op twee poorten te luisteren - één voor lezen en één voor schrijven. Dit is meestal prima, maar het vereist dat u wijzigingen in uw toepassing doorbrengt - de toepassing moet begrijpen wat lezen en schrijven is, en vervolgens die vragen naar de juiste poort leiden. Het zou veel gemakkelijker zijn om gewoon verbinding te maken met een enkele poort en de proxy te laten beslissen wat hij vervolgens moet doen - dit is iets wat HAProxy niet kan doen, omdat het alleen pakketten routert - er wordt geen pakketinspectie uitgevoerd en vooral, het heeft geen begrip van het MySQL-protocol.

ProxySQL lost dit probleem op - het spreekt over het MySQL-protocol en het kan (onder andere) een lees-schrijfsplitsing uitvoeren via zijn krachtige queryregels en het inkomende MySQL-verkeer routeren volgens verschillende criteria. De installatie van ProxySQL vanuit ClusterControl is eenvoudig - u wilt naar het gedeelte Beheren -> Load Balancer gaan en het tabblad "ProxySQL implementeren" vullen met de vereiste gegevens.

Kortom, we moeten kiezen waar ProxySQL wordt geïnstalleerd, welke beheerdersgebruiker en wachtwoord het moet hebben, welke monitoringgebruiker het moet gebruiken om verbinding te maken met de MySQL-backends en hun status en controlestatus te verifiëren. Vanuit ClusterControl kunt u ofwel een nieuwe gebruiker maken die door de toepassing moet worden gebruikt - u kunt beslissen over de naam, het wachtwoord, de toegang tot welke databases worden verleend en welke MySQL-rechten die gebruiker heeft. Een dergelijke gebruiker wordt zowel aan de MySQL- als aan de ProxySQL-kant gemaakt. Tweede optie, meer geschikt voor bestaande infrastructuren, is om de bestaande databasegebruikers te gebruiken. U moet een gebruikersnaam en wachtwoord doorgeven, en een dergelijke gebruiker wordt alleen op ProxySQL aangemaakt.

Tot slot moet u een vraag beantwoorden:gebruikt u impliciete transacties? Daarmee begrijpen we transacties die zijn gestart door SET autocommit=0 uit te voeren; Als u het toch gebruikt, zal ClusterControl ProxySQL configureren om al het verkeer naar de master te sturen. Dit is vereist om ervoor te zorgen dat ProxySQL transacties correct afhandelt in ProxySQL 1.3.x en eerder. Als u SET autocommit=0 niet gebruikt om een ​​nieuwe transactie aan te maken, zal ClusterControl de lees-/schrijfsplitsing configureren.

ProxySQL kan, zoals elke proxy, een single point of failure worden en moet redundant worden gemaakt om hoge beschikbaarheid te bereiken. Er zijn een aantal methoden om dat te doen. Een daarvan is om ProxySQL op de webknooppunten te plaatsen. Het idee hier is dat het ProxySQL-proces meestal prima zal werken en de reden voor zijn onbeschikbaarheid is dat het hele knooppunt uitvalt. In zo'n geval, als ProxySQL is gecolloceerd met het webknooppunt, is er niet veel schade aangericht omdat dat specifieke webknooppunt ook niet beschikbaar zal zijn.

Een andere methode is om Keepalive op dezelfde manier te gebruiken als in het geval van HAProxy.

U kunt meer details vinden over hoe de interne onderdelen zijn geconfigureerd door onze ProxySQL-zelfstudie te lezen.


  1. Aankondiging van ClusterControl 1.4.2 - de DevOps-editie

  2. Inleiding tot MongoDB-gegevenstypen

  3. Waarom wordt geadviseerd KEYS niet te gebruiken in Redis?

  4. Hoe de korte maandnaam in SQL te krijgen