Grundlæggende om implementering af et MongoDB-replikasæt og -skår ved hjælp af dukke

Databasesystemer fungerer bedst, når de er integreret med nogle veldefinerede tilgange, der letter både læse- og skrivegennemløbsoperationer. MongoDB gik den ekstra mil ved at omfavne replikering og sharding med det formål at muliggøre horisontal og vertikal skalering i modsætning til relationelle DBM'er, hvis samme koncept kun forbedrer vertikal skalering.

Sharding sikrer fordeling af belastningen blandt medlemmerne af databaseklyngen, så læsehandlingerne udføres med lille latenstid. Uden sharding kan kapaciteten af en enkelt databaseserver med et stort sæt data og høje gennemløbsoperationer blive teknisk udfordret og kan resultere i fejl på den pågældende server, hvis de nødvendige foranstaltninger ikke tages i betragtning. For eksempel, hvis frekvensen af forespørgsler er meget høj, vil serverens CPU-kapacitet blive overvældet.

replikering på den anden side er et koncept, hvor forskellige databaseservere rummer de samme data. Det sikrer høj tilgængelighed af data udover at forbedre dataintegriteten. Tag et eksempel på en højtydende social medieapplikation, hvis det primære serverdatabasesystem fejler som i tilfælde af strømafbrydelse, bør vi have et andet system til at betjene de samme data. Et godt replikasæt bør have mere end 3 medlemmer, en dommer og optimal valgTimeoutMillis. I replikering vil vi have en master/primær node, hvor alle skriveoperationer udføres og derefter anvendes på en Oplog. Fra Oplog bliver alle de foretagne ændringer derefter anvendt på de andre medlemmer, som i dette tilfælde omtales som sekundære noder eller slaver. I tilfælde af at de primære noder ikke kommunikerer efter et stykke tid:choiceTimeoutMillis, signaleres de andre noder til at gå til et valg. ChoiceTimeoutMillis bør ikke indstilles for højt eller for lavt, fordi systemerne vil være nede i lang tid og dermed tabe en masse data eller hyppige valg, der kan resultere selv med midlertidig netværksforsinkelse og datainkonsistens. En dommer bruges til at tilføje en stemme til et vindende medlem for at blive en mester i tilfælde af, at der er uafgjort, men ikke bærer nogen data som de andre medlemmer.

Hvorfor bruge Puppet til at implementere et MongoDB-replikasæt

Ofte bruges sharding hånd i hånd med replikering. Processen med at konfigurere og vedligeholde et replikasæt er ikke let på grund af:

Store chancer for menneskelige fejl
Uevne til at udføre gentagne opgaver automatisk
Tidskrævende, især når et stort antal medlemmer er involveret
Mulighed for arbejdsutilfredshed
Overvældende kompleksitet, der kan dukke op.

For at overvinde de skitserede tilbageslag nøjes vi med et automatiseret system som Puppet, der har masser af ressourcer til at hjælpe os med at arbejde med lethed.

I vores tidligere blog lærte vi processen med at installere og konfigurere MongoDB med Puppet. Det er dog vigtigt at forstå Puppets grundlæggende ressourcer, da vi vil bruge dem til at konfigurere vores replikasæt og shards. Hvis du gik glip af det, er dette manifestfilen til processen med at installere og køre din MongoDB på den maskine, du har oprettet

  package {'mongodb':

    ensure => 'installed',

  }

  service {'mongodb':

    ensure => 'running',

    enable => true

  }

Så vi kan lægge indholdet ovenfor i en fil kaldet runMongoDB.pp og køre den med kommandoen

$ sudo apply runMongoDB.pp

Syng 'mongodb'-modulet og funktionerne, vi kan konfigurere vores replikasæt med de tilsvarende parametre for hver mongodb-ressource.

MongoDB-forbindelse

Vi skal etablere en mongodb-forbindelse mellem en node og mongodb-serveren. Hovedformålet med dette er at forhindre konfigurationsændringer i at blive anvendt, hvis mongodb-serveren ikke kan nås, men potentielt kan bruges til andre formål såsom databaseovervågning. Vi bruger mongodb_conn_validator

mongodb_conn_validator{‘mongodb_validator’:

ensure => present,

     server: ‘127.0.0.1:27017’,

     timeout: 40,

     tcp_port:27017

    }

navn: i dette tilfælde definerer navnet mongodb_validator ressourcens identitet. Det kunne også betragtes som en forbindelsesstreng

server:dette kan være en streng eller en række strenge, der indeholder DNS-navne/IP-adresser på serveren, hvor mongodb skal køre.

timeout:dette er det maksimale antal sekunder, som validatoren skal vente, før den beslutter, at puppetdb ikke kører.

tcp_port: dette er en udbyder til ressourcen, der validerer mongodb-forbindelsen ved at forsøge https-forbindelsen til mongodb-serveren. Dukke-SSL-certifikatopsætningen fra det lokale dukkemiljø bruges i godkendelsen.

Oprettelse af databasen

mongodb_database{‘databaseName’:

ensure => present,

     tries => 10

}

Denne funktion tager 3 parametre, dvs.:

navn: i dette tilfælde definerer navnet databaseName navnet på den database, vi opretter, som også ville være blevet erklæret som navn => 'databaseName'.

forsøg:dette definerer det maksimale antal af to sekunders forsøg for at vente MongoDB-start

Oprettelse af MongoDB-bruger

Modulet mongodb_user gør det muligt at oprette og administrere brugere for en given database i dukkemodulet.

mongodb_user {userprod:

  username => ‘prodUser’,

  ensure => present,

  password_hash => mongodb_password(‘prodUser’, ‘passProdser’),

  database => prodUser,

  roles => [‘readWrite’, ‘dbAdmin’],

  tries  => 10

}

Egenskaber

brugernavn:definerer navnet på brugeren.

password_hash:dette er brugerens password-hash. Funktionen mongodb_password() tilgængelig på MongoDB 3.0 og nyere bruges til at oprette hashen.

roller:dette definerer de roller, som brugeren har tilladelse til at udføre på måldatabasen.

adgangskode:dette er den almindelige brugeradgangskodetekst.

database:definerer brugerens måldatabase.

Oprettelse af et replikasæt

Vi bruger modulet mongodb_replset til at oprette et replikasæt.

Mongodb_replset{'replicaset1':

   arbiter: 'host0:27017',

   ensure  => present,

   members => ['host0:27017','host1:27017', 'host2:27017', 'host3:27017'] 

   initialize_host: host1:27017

}

navn:definerer navnet på replikasættet.

medlemmer:en række medlemmer, som replikasættet vil indeholde.

initialize_host:vært, der skal bruges til initialisering af replikasættet

arbiter:definerer replikasætmedlemmet, der skal bruges som arbiter.

Oprettelse af en MongoDB Shard

mongodb_shard{'shard1':

   ensure  => present,

   members => ['shard1/host1:27017', 'shard1/host2:27017', 'shard1/host3:27017'] 

   keys: 'price'

}

navn:definerer navnet på shard'et.

medlemmer:dette er den række af medlemmer, som sharden skal holde.

nøgler:definer den nøgle, der skal bruges i shardingen eller en række nøgler, der kan bruges til at oprette en sammensat shard-nøgle.