MySQL heeft een lange traditie in geografische replicatie. Het distribueren van clusters naar externe datacenters vermindert de effecten van geografische latentie door gegevens dichter bij de gebruiker te brengen. Het biedt ook een mogelijkheid voor noodherstel. Vanwege de hoge kosten van het dupliceren van hardware op een aparte site, konden niet veel bedrijven dit in het verleden betalen. Een andere kostenpost is bekwaam personeel dat in staat is om een geavanceerde omgeving met meerdere datacenters te ontwerpen, implementeren en onderhouden.
Met de cloud- en DevOps-automatiseringsrevolutie is het hebben van een gedistribueerd datacenter nog nooit zo toegankelijk geweest voor de massa. Cloudproviders breiden hun dienstenaanbod uit voor een betere prijs. Men kan cross-cloud, hybride omgevingen bouwen met data verspreid over de hele wereld. Men kan flexibele en schaalbare DR-plannen maken om een breed scala aan verstoringsscenario's te benaderen. In sommige gevallen kan dat gewoon een back-up zijn die offsite is opgeslagen. In andere gevallen kan het een 1 op 1 kopie zijn van een productieomgeving die ergens anders draait.
In deze blog zullen we enkele van deze gevallen bekijken en veelvoorkomende scenario's behandelen.
Back-ups opslaan in de cloud
Een DR-plan is een algemene term die een proces beschrijft om verstoorde IT-systemen en andere kritieke activa die een organisatie gebruikt, te herstellen. Back-up is de primaire methode om dit te bereiken. Wanneer een back-up zich in hetzelfde datacenter bevindt als uw productieservers, loopt u het risico dat alle gegevens worden gewist als u dat datacenter verliest. Om dat te voorkomen, moet u het beleid hebben om een kopie op een andere fysieke locatie te maken. Het is nog steeds een goede gewoonte om een back-up op schijf te bewaren om de hersteltijd te verkorten. In de meeste gevallen bewaart u uw primaire back-up in hetzelfde datacenter (om de hersteltijd tot een minimum te beperken), maar u moet ook een back-up hebben die kan worden gebruikt om zakelijke procedures te herstellen wanneer het primaire datacenter niet beschikbaar is.
ClusterControl:back-up uploaden naar de cloud ClusterControl zorgt voor een naadloze integratie tussen uw database-omgeving en de cloud. Het biedt opties voor het migreren van gegevens naar de cloud. We bieden een volledige combinatie van databaseback-ups voor Amazon Web Services (AWS), Google Cloud Services of Microsoft Azure. Back-ups kunnen nu rechtstreeks vanaf uw cloudprovider naar keuze worden uitgevoerd, gepland, gedownload en hersteld. Deze mogelijkheid biedt meer redundantie, betere opties voor noodherstel en voordelen in zowel prestaties als kostenbesparingen.
ClusterControl:Cloud-referenties beheren De eerste stap om "datacenterfout - proof back-up" in te stellen, is het verstrekken van inloggegevens voor uw cloudoperator. U kunt hier kiezen uit meerdere leveranciers. Laten we eens kijken naar het proces dat is ingesteld voor de meest populaire cloudoperator - AWS.
ClusterControl:cloudreferenties toevoegen Het enige dat u nodig hebt, is de AWS-sleutel-ID en het geheim voor de regio waar u uw back-up wilt opslaan. Je kunt dat krijgen van de AWS-console. Je kunt een paar stappen volgen om het te krijgen.
- Gebruik het e-mailadres en wachtwoord van uw AWS-account om u aan te melden bij de AWS Management Console als de rootgebruiker van het AWS-account.
- Kies op de IAM-dashboardpagina uw accountnaam in de navigatiebalk en selecteer vervolgens Mijn beveiligingsreferenties .
- Als u een waarschuwing ziet over toegang tot de beveiligingsreferenties voor uw AWS-account, kiest u voor Doorgaan naar beveiligingsreferenties .
- Vouw het gedeelte Toegangssleutels (toegangssleutel-ID en geheime toegangssleutel) uit.
- Kies om Nieuwe toegangssleutel te maken . Kies vervolgens Sleutelbestand downloaden om de toegangssleutel-ID en geheime toegangssleutel op te slaan in een bestand op uw computer. Nadat u het dialoogvenster hebt gesloten, kunt u deze geheime toegangssleutel niet meer ophalen.
ClusterControl:hybride cloudback-up Als alles is ingesteld, kunt u uw back-upschema aanpassen en de optie voor back-up naar cloud inschakelen. Om het netwerkverkeer te verminderen, moet u gegevenscompressie inschakelen. Het maakt back-ups kleiner en minimaliseert de tijd die nodig is voor het uploaden. Een andere goede gewoonte is om de back-up te versleutelen. ClusterControl maakt automatisch een sleutel aan en gebruikt deze als u besluit deze te herstellen. Geavanceerd back-upbeleid moet verschillende bewaartijden hebben voor back-ups die zijn opgeslagen op servers in hetzelfde datacenter en de back-ups die op een andere fysieke locatie zijn opgeslagen. U moet een langere bewaarperiode instellen voor back-ups in de cloud en een kortere periode voor back-ups die in de buurt van de productieomgeving zijn opgeslagen, aangezien de kans op herstel afneemt met de levensduur van de back-up.
ClusterControl:beleid voor het bewaren van back-ups Uw cluster uitbreiden met asynchrone replicatie
Galera met asynchrone replicatie kan een uitstekende oplossing zijn om een actieve DR-node in een extern datacenter te bouwen. Er zijn een paar goede redenen om een asynchrone slave aan een Galera Cluster te koppelen. Langlopende OLAP-query's op een Galera-knooppunt kunnen een heel cluster vertragen. Met de optie voor vertraagde toepassing kan vertraagde replicatie u behoeden voor menselijke fouten, zodat al die gouden ingangen niet onmiddellijk worden toegepast op uw back-upknooppunt.
ClusterControl:vertraagde replicatie In ClusterControl wordt het uitbreiden van een Galera-knooppuntgroep met asynchrone replicatie gedaan in een wizard van één pagina. U moet de nodige informatie verstrekken over uw toekomstige of bestaande slave-server. De slave wordt ingesteld vanaf een bestaande back-up of een vers gestreamde XtraBackup van de master naar de slave.
Loadbalancers in multi-datacenter
Load balancers zijn een cruciaal onderdeel in de hoge beschikbaarheid van MySQL en MariaDB-databases. Het is niet voldoende om een cluster te hebben dat zich over meerdere datacenters uitstrekt. U hebt nog steeds uw services nodig om er toegang toe te krijgen. Een storing van een load balancer die in één datacenter beschikbaar is, maakt uw hele omgeving onbereikbaar.
Webproxy's in clusteromgeving Een van de populaire methoden om de complexiteit van de databaselaag voor een toepassing te verbergen, is het gebruik van een proxy. Proxy's fungeren als toegangspunt tot de databases, ze volgen de status van de databaseknooppunten en zouden verkeer altijd naar alleen de beschikbare knooppunten moeten leiden. ClusterControl maakt het gemakkelijk om verschillende load balancing-technologieën voor MySQL en MariaDB te implementeren en configureren, waaronder ProxySQL, HAProxy, met een grafische aanwijzen-en-klik-interface.
ClusterControl:load balancer HA Het maakt het ook mogelijk om dit onderdeel overbodig te maken door er keepalive aan toe te voegen. Om te voorkomen dat uw load balancers een single point of failure worden, zou men twee identieke (een actieve en een in verschillende DC als stand-by) HAProxy-, ProxySQL- of MariaDB Maxscale-instanties instellen en Keepalive gebruiken om Virtual Router Redundancy Protocol (VRRP) tussen hen. VRRP levert een virtueel IP-adres aan de actieve load balancer en draagt het virtuele IP over aan de stand-by HAProxy in geval van storing. Het is naadloos omdat de twee proxy-instanties geen gedeelde status nodig hebben.
Natuurlijk zijn er veel dingen waarmee u rekening moet houden om uw databases immuun te maken voor datacenterstoringen.
Een goede planning en automatisering zullen ervoor zorgen dat het werkt! Gelukkig clusteren!