Onze nieuwste release van ClusterControl verandert enkele van de meest lastige MongoDB-taken in slechts 15 seconden werk. Er zijn nieuwe functies toegevoegd om u meer controle over uw cluster te geven en topologiewijzigingen uit te voeren:
- Converteer een MongoDB-replicaSet naar een shard MongoDB-cluster
- Scherven toevoegen en verwijderen
- Shard-routers toevoegen aan een shard MongoDB-cluster
- Een knooppunt verlagen of bevriezen
- Nieuwe MongoDB-adviseurs
We zullen deze toegevoegde functies hieronder uitgebreid beschrijven.
Converteer een MongoDB ReplicaSet naar een Sharded MongoDB-cluster
Aangezien de meeste MongoDB-gebruikers beginnen met een replicaSet om hun database op te slaan, is dit het meest gebruikte type cluster. Als u schaalproblemen tegenkomt, kunt u deze replicaSet schalen door meer secondaries toe te voegen of uit te schalen door sharding. U kunt een bestaande replicaSet converteren naar een shard-cluster, maar dit is een lang proces waarbij u gemakkelijk fouten kunt maken. In ClusterControl hebben we dit proces geautomatiseerd, waarbij we automatisch de Configservers, shard-routers toevoegen en sharding inschakelen.
Om een replicaSet om te zetten in een shard-cluster, kunt u deze eenvoudig activeren via de vervolgkeuzelijst voor acties:
Dit opent een dialoog in twee stappen over hoe dit in een scherf kan worden omgezet. De eerste stap is om te definiëren waar de Configserver en shard-routers moeten worden geïmplementeerd:
De tweede stap is waar de gegevens moeten worden opgeslagen en welke configuratiebestanden moeten worden gebruikt voor de Configserver en shardrouter.
Nadat de shardmigratietaak is voltooid, geeft het clusteroverzicht nu shards weer in plaats van replicaSet-instanties:
Na conversie naar een shard-cluster kunnen nieuwe shards worden toegevoegd.
Scherven toevoegen aan of verwijderen uit een Sharded MongoDB-cluster
Scherven toevoegen
Aangezien een MongoDB-shard technisch gezien een replicaSet is, omvat het toevoegen van een nieuwe shard ook de implementatie van een nieuwe replicaSet. Binnen ClusterControl implementeren we eerst een nieuwe replicaSet en voegen deze vervolgens toe aan het sharded cluster.
Vanuit de gebruikersinterface van ClusterControl kunt u eenvoudig nieuwe shards toevoegen met een tweestapswizard, geopend vanuit de vervolgkeuzelijst met acties:
Hier kunt u de topologie van de nieuwe shard definiëren.
Zodra de nieuwe shard aan het cluster is toegevoegd, begint de MongoDB shard-router er nieuwe chunks aan toe te wijzen en zal de balancer automatisch alle chunks over alle shards verdelen.
Scherven verwijderen
Het verwijderen van shards is iets moeilijker dan het toevoegen van een shard, omdat dit inhoudt dat de gegevens naar de andere shards worden verplaatst voordat de shard zelf wordt verwijderd. Voor alle gegevens die over alle shards zijn verdeeld, wordt dit een taak die wordt uitgevoerd door de MongoDB-balancer.
Elke niet-shard database/verzameling waaraan deze shard als primaire shard is toegewezen, moet echter naar een andere shard worden verplaatst en de nieuwe primaire shard ervan maken. Voor dit proces moet MongoDB weten waar deze databases/verzamelingen zonder shard naartoe moeten worden verplaatst.
In ClusterControl kunt u ze eenvoudig verwijderen via de vervolgkeuzelijst acties:
Hiermee kunt u de shard selecteren die u wilt verwijderen en de shard waarnaar u eventuele primaire databases wilt migreren:
De taak die de shard verwijdert, voert vervolgens soortgelijke acties uit als eerder beschreven:het verplaatst alle primaire databases naar de aangewezen shard, schakelt de balancer in en wacht tot alle gegevens van de shard zijn verplaatst.
Zodra alle gegevens zijn verwijderd, wordt de scherf uit de gebruikersinterface verwijderd.
Extra MongoDB Shard-routers toevoegen
Zodra u uw toepassing begint uit te schalen met behulp van een MongoDB-shardcluster, heeft u mogelijk extra shard-routers nodig.
Het toevoegen van extra MongoDB-shardrouters is een heel eenvoudig proces met ClusterControl, open gewoon het dialoogvenster Knooppunt toevoegen in de vervolgkeuzelijst met acties:
Hiermee wordt een nieuwe Shard-router aan het cluster toegevoegd. Vergeet niet de juiste standaardpoort (27017) op de router in te stellen.
Supdown-server
Als u onderhoud wilt plegen aan de primaire node in een replicaSet, is het beter om deze eerst op een elegante manier te laten "afstappen" voordat u deze offline haalt. Het aftreden van een primary betekent in feite dat de host niet langer een primary is en een secundaire wordt en gedurende een bepaald aantal seconden niet in aanmerking komt om een primary te worden. De nodes in de MongoDB replicaSet met stemrecht, zullen een nieuwe primaire kiezen, waarbij de afgetreden primaire gedurende het ingestelde aantal seconden wordt uitgesloten.
In ClusterControl hebben we de step down functionaliteit toegevoegd als actie op de Nodes pagina. Om af te treden, selecteert u dit gewoon als een actie in de vervolgkeuzelijst:
Na het instellen van het aantal seconden voor aftreden en bevestigen, zal de voorverkiezingen aftreden en een nieuwe voorverkiezingen worden gekozen.
Een knooppunt bevriezen
Deze functionaliteit is vergelijkbaar met het step down-commando:hierdoor komt een bepaald knooppunt gedurende een bepaald aantal seconden niet in aanmerking om primair te worden. Dit betekent dat u kunt voorkomen dat een of meer secundaire knooppunten een primaire knooppunt worden wanneer u de primaire knooppunten verlaat, en op deze manier een bepaald knooppunt dwingen om de nieuwe primaire knooppunt te worden.
In ClusterControl hebben we de freeze node functionaliteit toegevoegd als actie op de Nodes pagina. Om een knooppunt te bevriezen, selecteert u dit gewoon als een actie in de vervolgkeuzelijst:
Na het instellen van het aantal seconden en bevestigen, komt de node niet in aanmerking als primair voor het ingestelde aantal seconden.
Nieuwe MongoDB-adviseurs
Adviseurs zijn miniprogramma's die advies geven over specifieke databasevraagstukken. We hebben drie nieuwe adviseurs voor MongoDB toegevoegd. De eerste berekent het replicatievenster, de tweede waakt over het replicatievenster en de derde controleert op niet-gecodeerde databases/verzamelingen.
MongoDB Replicatie Lag Advisor
Replicatievertraging is erg belangrijk om in de gaten te houden als je reads uitschaalt door meer secondaries toe te voegen. MongoDB zal deze secondaries alleen gebruiken als ze niet te ver achterblijven. Als de secundaire replicatievertraging heeft, loopt u het risico verouderde gegevens op te leveren die al zijn overschreven op de primaire.
Om de replicatievertraging te controleren, volstaat het om verbinding te maken met de primaire en deze gegevens op te halen met de opdracht replSetGetStatus. In tegenstelling tot MySQL houdt de primaire de replicatiestatus van de secundaire bij.
We hebben deze controle geïmplementeerd in een adviseur in ClusterControl, om ervoor te zorgen dat uw replicatievertraging altijd wordt bewaakt.
MongoDB Replicatie Venster Adviseur
Net als de replicatievertraging, is het replicatievenster een even belangrijke statistiek om naar te kijken. De lag-adviseur informeert ons al over het aantal seconden dat een secundaire node zich achter de primaire/master bevindt. Omdat de oplog beperkt is in omvang, brengt het hebben van slaafvertraging de volgende risico's met zich mee:
- Als een node te ver achterblijft, kan deze de achterstand mogelijk niet meer inhalen omdat de transacties die nodig zijn om de achterstand in te halen niet langer in de oplog van de primaire staan.
- Een achterblijvend secundair knooppunt heeft minder de voorkeur bij een MongoDB-verkiezing voor een nieuwe primaire. Als alle secundairen achterblijven bij de replicatie, heb je een probleem en wordt een met de minste vertraging primair gemaakt.
- Secondaries die achterblijven hebben minder de voorkeur van de MongoDB-driver bij het uitschalen van reads met MongoDB, het voegt ook een hogere werklast toe aan de resterende secondaries.
Als we een secundair knooppunt hebben dat een paar minuten (of uren) achterblijft, zou het handig zijn om een adviseur te hebben die ons informeert hoeveel tijd we nog hebben voordat onze volgende transactie uit de oplog wordt verwijderd. Het tijdsverschil tussen de eerste en de laatste invoer in de oplog wordt het Replicatievenster genoemd. Deze statistiek kan worden gemaakt door de eerste en laatste items uit de oplog op te halen en het verschil van hun tijdstempels te berekenen.
In de MongoDB-shell is al een functie beschikbaar die het replicatievenster voor u berekent. Deze functie is echter ingebouwd in de shell van de opdrachtregel, dus elke externe verbinding die de shell van de opdrachtregel niet gebruikt, heeft deze ingebouwde functie niet. Daarom hebben we een adviseur gemaakt die over het replicatievenster waakt en u waarschuwt als u een vooraf ingestelde drempel overschrijdt.
MongoDB-adviseur voor databases en verzamelingen zonder shard
Niet-shard data bases en verzamelingen worden toegewezen aan een standaard primaire shard door de MongoDB shard-router. Dit betekent dat de database of verzameling beperkt is tot de grootte van deze primaire shard, en als er in grote volumes naar wordt geschreven, alle resterende schijfruimte van een shard kan worden gebruikt. Zodra dit gebeurt, zal de scherf uiteraard niet meer werken. Daarom is het belangrijk om alle bestaande databases en collecties in de gaten te houden en de configuratiedatabase te scannen om te valideren dat ze zijn ingeschakeld voor sharding.
Om dit te voorkomen hebben we een un-sharded database en incassoadviseur gemaakt. Deze adviseur scant elke database en verzameling en waarschuwt u als deze niet is geshard.
ClusterControl heeft de onderhoudbaarheid van MongoDB verbeterd
We hebben een grote stap gezet door alle verbeteringen aan ClusterControl voor MongoDB replicaSets en sharded clusters toe te voegen. Dit verbetert de bruikbaarheid voor MongoDB enorm en stelt DBA's, sysops en devops in staat hun clusters nog beter te onderhouden!