Kuinka asentaa MongoDB Ubuntuun

Johdanto

MongoDB on yksi suosituimmista avoimen lähdekoodin NoSQL-tietokannoista, jota käytetään laajalti sovelluksissa, jotka vaativat joustavia tietorakenteita, hyvää skaalautuvuutta ja nopeaa suorituskykyä. Se tallentaa tietoja dokumenttiperusteisessa muodossa käyttäen JSON-tyyppisiä objekteja, mikä tekee siitä ihanteellisen nykyaikaisille verkkosovelluksille, mobiilisovelluksille ja analytiikkatyökuormille. Kehittäjät suosivat MongoDB:tä sen dynaamisen skeeman, automaattisen shardingin ja sisäänrakennettujen replikaatio-ominaisuuksien ansiosta, jotka tukevat sekä horisontaalista skaalautuvuutta että korkeaa saatavuutta. Yhdistettynä Ubuntun vakauteen ja turvallisuuteen, MongoDB tarjoaa vahvan perustan luotettavien ja tehokkaiden tietokantaohjattujen sovellusten ajamiseen.

Tässä artikkelissa selitämme, kuinka MongoDB 8.2 asennetaan, konfiguroidaan ja ylläpidetään Ubuntu 24.04 LTS:ssä. Käymme läpi kaikki olennaiset vaiheet, palvelimen valmistelusta ja tietoturvaominaisuuksien käyttöönotosta suorituskyvyn optimointiin, replikaation ja varmuuskopioiden määrittämiseen sekä yleisten ongelmien ratkaisemiseen. Artikkelin lopussa sinulla on tuotantovalmiiksi toteutettu MongoDB-järjestelmä, joka on asianmukaisesti suojattu, valvottu ja optimoitu pitkäaikaiseen käyttöön. Olipa kyse MongoDB:n käyttöönotosta kehitystä, testausta tai täysimittaista tuotantoympäristöä varten, tämä opas tarjoaa yksityiskohtaiset ohjeet ja parhaat käytännöt sen tehokkaaseen ajamiseen.

Edellytykset

Seurataksesi tätä opasta tarvitset:

• Palvelin, jossa on Ubuntu 24.04 LTS. Tällä palvelimella tulisi olla ei-root-käyttäjä, jolla on hallinnolliset oikeudet, ja UFW (Uncomplicated Firewall) asennettuna ja konfiguroituna. Katso meidän Alkuperäinen palvelinasennusopas Ubuntulle tämän tekemiseen.

MongoDB:n asentaminen virallisesta arkistosta

Ubuntu 24.04 sisältää MongoDB:n version oletuspakettivarastoissaan, mutta se on yleensä vanhentunut. Tuotantojärjestelmissä sinun kannattaa aina asentaa MongoDB suoraan MongoDB:n virallisesta arkistosta. Tämä varmistaa, että saat uusimman vakaan version (kirjoitushetkellä 8.2) sekä ajantasaiset turvallisuus- ja ylläpitopäivitykset.

Lisätään MongoDB-repositorio järjestelmäsi APT-lähteisiin, tuodaan GPG-avain pakettien varmentamista varten ja asennetaan sitten tietokanta.

1. Tuo MongoDB:n GPG-avain

APT käyttää GPG-avaimia varmistaakseen pakettien aitouden. Ilman tätä järjestelmäsi ei luottaisi MongoDB:n arkistoon.

Suorita seuraava komento tuodaksesi MongoDB 8.0:n julkisen avaimen:

curl -fsSL https://www.mongodb.org/static/pgp/server-8.0.asc | sudo gpg -o /usr/share/keyrings/mongodb-server-8.0.gpg --dearmor

Tämä on sen vaikutus:

• curl -fsSL hakee hiljaisesti GPG-avaimen MongoDB:n virallisilta palvelimilta.
• --dearmor muuntaa avaimen ASCII-armoroidusta muodosta binääriseksi avainrenkaaksi, joka on yhteensopiva APT:n kanssa.
• Tuloste tallennetaan sijaintiin /usr/share/keyrings/mongodb-server-8.0.gpg, joka on vakiopaikka luotettaville avaimille.

Jos komento suoritetaan ilman virheitä, avain on lisätty onnistuneesti.

2. Lisää MongoDB-repositorio

Seuraavaksi luo uusi repositorioluettelotiedosto, joka osoittaa MongoDB:n viralliseen pakettivarastoon Ubuntulle 24.04 ("Noble").

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ] https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/8.2 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-8.2.list

Jokaisella tämän komennon osalla on selkeä tarkoitus:

• deb kertoo APT:lle, että tämä on binääripakettivarasto (toisin kuin deb-src, joka on lähdekoodia varten).
• arch=amd64,arm64 rajoittaa sen MongoDB:n tukemiin 64-bittisiin Intel/AMD- ja ARM-arkkitehtuureihin.
• signed-by=... varmistaa, että APT käyttää tiettyä MongoDB-avainta (lisätty yllä) latausten tarkistamiseen.
• https://repo.mongodb.org/apt/ubuntu on MongoDB:n virallisen APT-repositorion perus-URL.
• noble/mongodb-org/8.2 määrittää sekä Ubuntun julkaisukoodinimen (noble=Ubuntu 24.04) että MongoDB-version (8.2).
• multiverse on Ubuntun komponenttiosio kolmannen osapuolen ohjelmistoille.

3. Päivitä pakettihakemisto

Uuden arkiston lisäämisen jälkeen sinun on päivitettävä järjestelmäsi paikallinen saatavilla olevien pakettien luettelo, jotta APT tunnistaa uuden lähteen:

sudo apt update

APT lataa uusimmat pakettilistat ja tarkistaa ne GPG-avaimella. Jos näet MongoDB:n listattuna arkistoissa, asetuksesi ovat oikein.

4. Asenna MongoDB

Asenna nyt MongoDB ja siihen liittyvät työkalut:

sudo apt install -y mongodb-org

-y-lippu vahvistaa asennuskehotteet automaattisesti.

Tämä asentaa joukon toisiinsa liittyviä paketteja, mukaan lukien:

• mongodb-org-server: MongoDB-palvelinprosessi (mongod), joka vastaa tietokannan tallennuksesta ja toiminnoista.
• mongodb-org-mongos: Hajautettujen käyttöönottojen sharding-reititin.
• mongodb-org-shell: MongoDB:hen yhdistämiseen käytettävä interaktiivinen komentoriviasiakas (mongosh).
• mongodb-org-tools: Varmistus- ja palautustyökalut (mongodump, mongorestore, bsondump jne.).

Asennuksen jälkeen binäärit sijoitetaan hakemistoon /usr/bin/ ja konfiguraatiotiedostot löytyvät hakemistosta /etc/mongod.conf.

5. Varmista asennus

Voit varmistaa, että MongoDB 8.2 asennettiin onnistuneesti tarkistamalla sen version:

mongod --version

Sinun pitäisi nähdä vastaava tulos:

db version v8.2.3
Build Info: {
    "version": "8.2.3",
    "gitVersion": "36f41c9c30a2f13f834d033ba03c3463c891fb01",
    "openSSLVersion": "OpenSSL 3.0.13 30 Jan 2024",
    "modules": [],
    "allocator": "tcmalloc-google",
    "environment": {
        "distmod": "ubuntu2404",
        "distarch": "x86_64",
        "target_arch": "x86_64"
    }
}

Jos näet tämän, MongoDB on asennettu oikein ja valmis käynnistettäväksi palveluna.

MongoDB-palvelun käynnistäminen ja hallinta

Kun asennat MongoDB:n Ubuntulle, paketti sisältää automaattisesti systemd-palveluyksikön nimeltä mongod.service. Tämä integraatio mahdollistaa MongoDB:n käynnistämisen, pysäyttämisen ja uudelleenkäynnistämisen siististi Ubuntun vakiopalvelun hallintakomennoilla, aivan kuten Nginx, PostgreSQL tai mikä tahansa muu merkittävä demonipalvelu.

Käynnistä MongoDB-palvelu

Oletusarvoisesti MongoDB ei käynnisty automaattisesti asennuksen jälkeen. Käynnistääksesi sen manuaalisesti, käytä seuraavaa komentoa:

sudo systemctl start mongod

Jos komento suoritetaan ilman virheitä, palvelun pitäisi nyt olla aktiivinen. Voit vahvistaa sen seuraavasti:

sudo systemctl status mongod

Esimerkkituloste:

● mongod.service - MongoDB Database Server
     Loaded: loaded (/usr/lib/systemd/system/mongod.service; disabled; preset: enabled)
     Active: active (running) since Tue 2026-01-06 07:08:28 UTC; 5s ago
       Docs: https://docs.mongodb.org/manual
   Main PID: 12462 (mongod)
     Memory: 195.4M (peak: 277.1M)
        CPU: 739ms
     CGroup: /system.slice/mongod.service
             └─12462 /usr/bin/mongod --config /etc/mongod.conf

Rivi „Active: active (running)” vahvistaa, että tietokanta on päällä ja toimii.

Jos sen sijaan näet “epäonnistui” tai “ei aktiivinen”, siirry suoraan kohtaan MongoDB-lokien tarkistaminen vianmääritystä varten.

Ota MongoDB käyttöön käynnistymään automaattisesti

Useimmissa tuotantojärjestelmissä tietokannan on käynnistyttävä automaattisesti uudelleenkäynnistyksen jälkeen. Ota MongoDB:n käynnistyminen käyttöön käynnistyksen yhteydessä suorittamalla:

sudo systemctl enable mongod

Tämä luo symbolisen linkin /etc/systemd/system/multi-user.target.wants/, joka kertoo systemd:lle käynnistää palvelun automaattisesti aina, kun järjestelmä siirtyy monen käyttäjän tilaan (palvelimille vakiokäyttötila).

Voit vahvistaa muutoksen seuraavalla tavalla:

systemctl is-enabled mongod

Odotettu tulos:

enabled

Jos haluat joskus poistaa automaattisen käynnistyksen käytöstä (huoltoa tai testausta varten), käytä:

sudo systemctl disable mongod

Vahvista MongoDB-toiminto

Kun MongoDB on käynnissä, on hyvä idea varmistaa, että se reagoi oikein.

Suorita seuraava komento yhdistääksesi tietokantaan ja tarkistaaksesi sen yhteyden tila:

mongosh --eval "db.runCommand({ connectionStatus: 1 })"

Tämä komento:

• Avaa väliaikaisen komentokuoren istunnon (mongosh on uusi MongoDB-kuori, joka korvaa vanhemman mongo-asiakasohjelman).
• Suorittaa connectionStatus-komennon suoraan paikallisessa instanssissa.
• Näyttää yhteysraportin ilman, että sinun tarvitsee pysyä komentorivillä.

Esimerkkituloste:

{
  authInfo: { authenticatedUsers: [], authenticatedUserRoles: [] },
  uuid: UUID('be686f2a-9cb3-41c1-aad2-8849367de4e5'),
  ok: 1
}

Arvo "ok": 1 vahvistaa, että palvelin toimii oikein ja hyväksyy yhteydet portissa 27017.

Hallinnoi MongoDB-palvelun elinkaarta

Kun olet varmistanut, että MongoDB on käynnissä, on hyödyllistä tietää, miten sitä hallitaan turvallisesti päivittäisessä käytössä.

Tässä ovat tärkeimmät komennot:

sudo systemctl stop mongod

sudo systemctl start mongod

sudo systemctl restart mongod

sudo systemctl reload mongod

sudo systemctl disable mongod

sudo systemctl status mongod

Palvelun uudelleenkäynnistäminen (restart) on erityisen tärkeää /etc/mongod.conf-tiedoston muokkaamisen jälkeen. Tämä varmistaa, että asetuksiisi tekemäsi muutokset otetaan käyttöön.

MongoDB-lokien tarkistaminen

Jos MongoDB ei käynnisty tai käyttäytyy odottamattomasti, ensimmäinen vianmääritysvaiheesi tulisi olla lokien tarkistaminen.

MongoDB-lokit sijaitsevat kohdassa:

/var/log/mongodb/mongod.log

Voit tarkastella viimeisiä 20 riviä komennolla:

sudo tail -n 20 /var/log/mongodb/mongod.log

Yleisiä lokiviestejä ovat:

• "Odotetaan yhteyksiä portissa 27017": MongoDB käynnistyi onnistuneesti ja on valmis.
• "Tietohakemisto /var/lib/mongodb ei löydy": Tarkista, että tietopolku on olemassa ja että sillä on oikeat käyttöoikeudet.
• "Osoite on jo käytössä": Toinen prosessi käyttää jo porttia 27017.
• "Lupa evätty": Varmista, että MongoDB-käyttäjä (mongodb) omistaa sen tiedosto- ja lokihakemistot.

Voit myös käyttää journalctl-komentoa katsellaksesi systemd:n hallitsemia palvelukohtaisia lokitietoja:

sudo journalctl -u mongod --since "5 minutes ago"

MongoDB:n testaaminen järjestelmän käynnistyessä

On hyvä käytäntö varmistaa, että MongoDB käynnistyy automaattisesti uudelleenkäynnistyksen jälkeen, erityisesti ennen sovellusten käyttöönottoa.

Käynnistääksesi uudelleen, suorita:

sudo reboot

Kun palvelimesi käynnistyy uudelleen, kirjaudu takaisin ja tarkista palvelu:

sudo systemctl status mongod

Jos näyttöön tulee “aktiivinen (käynnissä)”, kokoonpanosi on oikea ja pysyvä.

MongoDB:n kokoonpanoasetusten ymmärtäminen

Kun asennat MongoDB:n, sen toimintaa ohjataan yhdellä asetustiedostolla, joka sijaitsee osoitteessa /etc/mongod.conf.

Tämä tiedosto määrittelee, miten MongoDB toimii: kaiken siitä, missä se tallentaa tietonsa, miten se kirjaa toimintaa, mitä IP-osoitteita se kuuntelee ja mitkä turvallisuusmekanismit ovat käytössä. Tämän tiedoston ymmärtäminen on kriittistä, erityisesti jos aiot käyttää MongoDB:tä tuotantoympäristössä. Tiedoston asetukset vastaavat vastaavia komentorivioptioita, mutta kokoonpanotiedoston käyttö tekee palvelimen hallinnasta yksinkertaisempaa, erityisesti suuremmissa tai automatisoiduissa käyttöönotossa.

Yleiskatsaus kokoonpanotiedostoon

MongoDB:n kokoonpanotiedosto käyttää YAML-syntaksia, joka on sisennysherkkä. Tämä tarkoittaa, että sitä muokatessa on käytettävä välilyöntejä (ei sarkaimia), sillä jo yksi väärin sijoitettu välilyönti voi rikkoa kokoonpanon.

Voit tarkastella tiedoston nykyisiä sisältöjä seuraavasti:

sudo cat /etc/mongod.conf

Oletustiedosto näyttää jotakuinkin tältä:

# mongod.conf

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

net:
  port: 27017
  bindIp: 127.0.0.1

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

Käydään tämä läpi osio kerrallaan.

Storage-osio

Tässä osassa määritellään, mihin MongoDB tallentaa tietonsa ja miten se hallitsee lokitusta (joka varmistaa tietojen säilyvyyden).

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true

• dbPath: Tämä on hakemisto, johon MongoDB tallentaa tietokantansa, kokoelmansa ja indeksinsä. Oletusarvoisesti se osoittaa kohtaan /var/lib/mongodb. Jos muutat tätä polkua, varmista, että hakemisto on olemassa ja että sen omistaa mongodb-käyttäjä:

  sudo mkdir -p /data/mongodb
  
  sudo chown -R mongodb:mongodb /data/mongodb

• journal.enabled: Kun asetetaan true, MongoDB ylläpitää lokitiedostoa, joka auttaa palautumaan kaatumisista tai odottamattomista sammutuksista. Lokitus kirjoittaa muutokset erilliseen lokiin ennen niiden sitomista tietotiedostoihin, mikä estää tietojen vaurioitumisen. Pidä tämä aina käytössä tuotantojärjestelmissä.

systemLog-osio

Tämä määrittää, miten ja mihin MongoDB kirjoittaa lokinsa.

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

• destination: Määrittää, mihin lokit kirjoitetaan. Oletusarvo file kirjoittaa lokit tiedostoon; voit vaihtaa sen syslog, jos haluat MongoDB-lokit integroitavan järjestelmän lokien kanssa.
• logAppend: Kun true, MongoDB lisää uusia lokimerkintöjä olemassa olevaan tiedostoon sen sijaan, että ylikirjoittaisi sen uudelleenkäynnistyksen yhteydessä.
• polku: Lokitiedoston absoluuttinen polku.

Voit tarkastella lokitiedostoja suoraan seuraavasti:

sudo tail -f /var/log/mongodb/mongod.log

Jos lokisi kasvavat liian suuriksi, harkitse lokien kierron käyttöönottoa työkalulla, kuten logrotate, tai järjestelmän lokien automaattisen kierron määrittämistä.

net-osio

Tässä osassa määritellään, miten MongoDB kuuntelee saapuvia verkkoyhteyksiä.

net:
  port: 27017
  bindIp: 127.0.0.1

• portti: Oletus MongoDB-portti on 27017. Voit muuttaa tätä, jos ajat useita tietokantapalveluja samalla isäntäkoneella.
• bindIp: Tämä määrittää, millä verkkoliitännöillä MongoDB kuuntelee.

Oletuksena se on rajoitettu osoitteeseen 127.0.0.1 (paikallinen loopback-osoite), mikä tarkoittaa, että vain paikalliset yhteydet hyväksytään. Tämä on kriittinen turvallisuusasetuksen oletus, joka estää etäyhteydet, kunnes sallitaan ne erikseen.

Jos aiot muodostaa yhteyden toiselta koneelta (esimerkiksi verkkopalvelimelta tai etäsovelluksesta), voit muokata sitä seuraavasti:

bindIp: 127.0.0.1,192.168.1.100

Tai kuunnella kaikilla rajapinnoilla (käytä varoen tuotannossa):

bindIp: 0.0.0.0

turvallisuus-osio

MongoDB asennetaan oletuksena ilman todennusta. Kuka tahansa, joka pystyy yhdistämään tietokantaan, voi lukea tai muokata tietoja. Tämä on ok testauksessa, mutta turvallisuusriski oikeassa järjestelmässä. Käyttäjäperusteisen todennuksen ottamiseksi käyttöön, lisää seuraava osio:

security:
  authorization: enabled

Kun tämä otetaan käyttöön, MongoDB vaatii käyttäjiä kirjautumaan sisään käyttäjätunnuksella ja salasanalla ennen toimintojen suorittamista.

Tämän osion muita valinnaisia asetuksia ovat:

• keyFile: Käytetään replikaattisarjoissa todennukseen klusterin solmujen välillä.
• javascriptEnabled: Ottaa palvelinpuolen JavaScriptin suorituksen käyttöön tai poistaa sen käytöstä (suositellaan pitää poissa käytöstä, ellei ole tarpeen).

processManagement-osio

Tämä osa ohjaa, miten MongoDB käsittelee prosessinhallintaa ja suoritustietoja.

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

Tämä on pääasiassa tiedonantavaa; se varmistaa, että MongoDB:llä on pääsy aikavyöhyketietoihin aikaleimojen muunnoksia varten. Kehittyneemmissä käyttöönotossa voit myös ottaa käyttöön forking tässä (taustatoimintoa varten), jos MongoDB käynnistetään manuaalisesti ilman systemd.

replication ja sharding -osiot (valinnainen)

Et näe näitä osioita uudessa asennuksessa, mutta niitä käytetään monisolmu- tai hajautetuissa ympäristöissä.

Esimerkki replikaattisarjan ottamisesta käyttöön:

replication:
  replSetName: "rs0"

Tämä ohjaa MongoDB:n käynnistymään osana replikaatiosarjaa nimeltä rs0. Tämän jälkeen voit alustaa ja lisätä jäseniä MongoDB-kuoren kautta.

Shardingia varten:

sharding:
  clusterRole: "shardsvr"

Tämä määrittää solmun roolin jaetussa klusterissa.

setParameter-osio

Tämä valinnainen osio antaa sinun ohittaa ajonaikaiset parametrit, jotka hienosäätävät MongoDB:n toimintaa.

Esimerkki :

setParameter:
  enableLocalhostAuthBypass: false

Tämän asettaminen arvoon false varmistaa, että jopa localhost-yhteydet vaativat todennuksen. Muut parametrit voivat hallita kyselyaikakatkaisuja, kursorin käyttäytymistä tai diagnostista lokitusta.

Muutosten tekeminen ja soveltaminen

Aina kun muokkaat /etc/mongod.conf-tiedostoa, sinun täytyy käynnistää MongoDB uudelleen, jotta muutokset tulevat voimaan:

sudo systemctl restart mongod

Varmista sitten, että palvelu on käynnissä:

sudo systemctl status mongod

Jos MongoDB ei käynnisty uudelleen, tarkista syntaksivirheet (YAML:n sisennysvirheet ovat yleisiä) tai tarkista lokit:

sudo tail -n 20 /var/log/mongodb/mongod.log

Esimerkki: Turvallinen ja tuotantovalmiin kokoonpano

Tässä on esimerkki siististä, tuotantoon suunnatusta mongod.conf-tiedostosta Ubuntulle 24.04:

# mongod.conf — Example production configuration

storage:
  dbPath: /data/mongodb
  journal:
    enabled: true
  engine: wiredTiger

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

net:
  port: 27017
  bindIp: 127.0.0.1,192.168.10.10

security:
  authorization: enabled
  javascriptEnabled: false

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

replication:
  replSetName: "rs0"

setParameter:
  enableLocalhostAuthBypass: false

Tämä kokoonpano:

• Mahdollistaa todennuksen
• Käyttää WiredTigeriä (oletustallennusmoottori)
• Sitoutuu vain tiettyihin luotettuihin rajapintoihin
• Valmistelee instanssin replikasarjan alustamista varten
• Kirjaa kaikki toiminnot erilliseen lokitiedostoon

MongoDB:n suojaaminen

MongoDB:n joustavuus tekee siitä tehokkaan, mutta se tarkoittaa myös, että turvaton käyttöönotto voi helposti johtaa tietovuotoihin. MongoDB:n varhaisina päivinä monet palvelimet jätettiin avoimiksi internetiin ilman todennusta, jolloin hyökkääjät pystyivät listaamaan, muokkaamaan tai jopa poistamaan tietokantoja pelkästään yhdistämällä porttiin 27017.

Tänään MongoDB toimitetaan turvallisemmilla oletusasetuksilla, mutta on silti sinun vastuullasi varmistaa todennus, verkkorajoitukset ja salaus.

Todennuksen ottaminen käyttöön

Oletuksena MongoDB käynnistyy ilman todennusta käytössä. Tämä tarkoittaa, että kuka tahansa, joka voi muodostaa yhteyden tietokantaan, voi suorittaa hallinnollisia komentoja, poistaa kokoelmia tai muokata tietoja ilman rajoituksia. Tämän estämiseksi MongoDB käyttää roolipohjaista käyttöoikeuksien hallintajärjestelmää (RBAC), joka täytyy ottaa erikseen käyttöön.

1. Avaa MongoDB:n määritystiedosto:

   sudo nano /etc/mongod.conf

2. Etsi security-osio tai luo sellainen, jos sitä ei ole:

   security:
     authorization: enabled

3. Tallenna ja poistu (Ctrl+O, sitten Ctrl+X).

4. Käynnistä MongoDB uudelleen, jotta muutos tulee voimaan:

   sudo systemctl restart mongod

MongoDB tarjoaa väliaikaisen localhost-autentikoinnin ohituksen uudessa asennuksessa, jotta ensimmäinen hallintakäyttäjä voidaan luoda. Tämä ohitus poistetaan automaattisesti käytöstä, kun hallintakäyttäjä on olemassa tai jos tietyt tietoturva-asetukset (kuten keyFile tai clusterAuthMode) on otettu käyttöön.

Se tarkoittaa, että voit turvallisesti luoda ensimmäisen ylläpitäjäkäyttäjäsi ennen täyden käyttöönoton alkamista.

Ensimmäisen järjestelmänvalvojakäyttäjän luominen

Ylläpitäjäkäyttäjä on MongoDB:n todennuksen järjestelmän perusta. Sillä on oikeus luoda muita käyttäjiä, määrittää rooleja ja myöntää pääsyä tiettyihin tietokantoihin.

Luoaksesi tämän tilin:

1. Aloita paikallinen MongoDB-komentokehote:

   mongosh

2. Vaihda admin-tietokantaan, joka tallentaa käyttäjätunnukset ja roolien määritelmät:

   use admin

3. Luo käyttäjä seuraavalla komennolla:

   db.createUser({
     user: "admin",
     pwd: "StrongPasswordHere",
     roles: [
       { role: "userAdminAnyDatabase", db: "admin" },
       "readWriteAnyDatabase"
     ]
   })

   Puretaan tämä osiin:

   • userAdminAnyDatabase antaa tälle käyttäjälle oikeuden luoda, muokata ja poistaa käyttäjiä kaikissa tietokannoissa.
   • readWriteAnyDatabase antaa luku- ja kirjoitusoikeudet maailmanlaajuisesti. (Voit jättää tämän pois, jos haluat tiukemman vain ylläpitäjille tarkoitetun käyttäjän.)

   Tämä komento kirjoittaa uuden dokumentin MongoDB:n system.users-kokoelmaan admin-tietokannassa. Voit varmistaa tämän listaamalla käyttäjät sen jälkeen:

   show users

4. Poistu kuoresta:

   exit

5. Yhdistä uudelleen ylläpitäjäkäyttäjänä vahvistaaksesi, että todennus on nyt pakotettu:

   mongosh -u admin -p --authenticationDatabase admin

Kun olet todennut henkilöllisyytesi, voit suorittaa hallinnollisia komentoja, kuten:

show dbs

Jos MongoDB pyytää salasanaa ja myöntää pääsyn vasta todennuksen jälkeen, RBAC toimii oikein.

Roolipohjaisten käyttäjien luominen sovelluksille

Tuotannossa sovelluksesi ei koskaan saisi käyttää ylläpitäjätiliä. Sen sijaan luo jokaiselle sovellukselle omat käyttäjät, joilla on vain ne oikeudet, joita ne tarvitsevat.

Esimerkiksi luodaksesi käyttäjän verkkosovellukselle, joka hallinnoi tietoja tietyssä tietokannassa:

use myappdb
db.createUser({
  user: "appuser",
  pwd: "AppPassword123",
  roles: [ { role: "readWrite", db: "myappdb" } ]
})

• readWrite antaa sovellukselle oikeuden suorittaa kaikki tavalliset CRUD-toiminnot (lisää, kysely, päivitä, poista) vain tässä tietokannassa.
• Se ei voi luoda muita käyttäjiä, muokata järjestelmätietokantoja tai käyttää muita tietokantoja.

Voit listata kaikki tietokannan käyttäjät seuraavasti:

show users

Verkon pääsyn rajoittaminen

Vaikka todennus olisi käytössä, on vaarallista altistaa MongoDB avoimelle internetille. Automaattiset tarkistajat etsivät säännöllisesti avoimia portteja (erityisesti 27017, MongoDB:n oletusportti) ja yrittävät murtaa salasanoja tai hyödyntää väärin konfiguroituja instansseja.

Oletuksena MongoDB kuuntelee vain osoitteessa 127.0.0.1, paikallisessa rajapinnassa. Jos sovelluksesi ja MongoDB-palvelin ovat samalla isäntäkoneella, sinun ei tarvitse muuttaa mitään. Kuitenkin, jos sovelluksesi muodostaa yhteyden etänä, sinun on erikseen sallittava tietyt IP-osoitteet.

1. Muokkaa kokoonpanotiedostoa:

   sudo nano /etc/mongod.conf

2. Etsi net-osio ja päivitä se:

   net:
     port: 27017
     bindIp: 127.0.0.1,192.168.10.50

   Korvaa 192.168.10.50 luotettavan sovelluspalvelimesi IP-osoitteella. Tämä varmistaa, että MongoDB hyväksyy yhteydet vain paikalliselta koneelta ja kyseiseltä etäisännältä.

3. Käynnistä palvelu uudelleen ottaaksesi muutokset käyttöön:

   sudo systemctl restart mongod

4. Vahvista aktiiviset sidokset:

   sudo ss -tulpn | grep mongod

Sinun pitäisi nähdä MongoDB kuuntelemassa sekä 127.0.0.1:27017:ssa että määrittämässäsi IP-osoitteessa.

Ubuntun palomuurin (UFW) määrittäminen

Vaikka MongoDB kuuntelisikin vain tietyillä rajapinnoilla, on paras käytäntö vahvistaa verkkoturvallisuus käyttöjärjestelmän tasolla.

Ubuntun UFW tarjoaa helpon tavan hallita saapuvia ja lähteviä yhteyksiä.

1. Varmista, että UFW on asennettu ja aktiivinen:

   sudo ufw status

   Jos se näkyy olevan pois käytöstä, ota se käyttöön:

   sudo ufw enable

2. Salli MongoDB-yhteydet vain luotetuista IP-osoitteista. Esimerkiksi, jos sovelluspalvelimesi IP on 192.168.10.50:

   sudo ufw allow from 192.168.10.50 to any port 27017

3. Tarkista, että sääntö on lisätty:

   sudo ufw status numbered

   Sinun pitäisi nähdä merkintä, joka sallii portin 27017 määritetystä lähteestä.

4. Valinnaisesti, estä kaikki muu liikenne MongoDB:hen nimenomaisesti:

   sudo ufw deny 27017/tcp

Tämä yhdistelmä, bindIp MongoDB:n asetuksissa ja valikoidut UFW-säännöt, varmistaa, että vain tunnetut järjestelmät voivat päästä tietokantaasi, vaikka muut prosessit yrittäisivät altistaa sen.

TLS/SSL-salauksen ottaminen käyttöön

Tähän mennessä olet varmistunut siitä, että vain luotetut käyttäjät ja IP-osoitteet voivat käyttää MongoDB:tä. Seuraava askel on suojata siirrettävät tiedot.

Kun asiakas yhdistää MongoDB:hen, kaikki tiedot (mukaan lukien todennustiedot ja kyselyt) välitetään oletuksena selväkielisinä. TLS salaa nämä tiedot estäen salakuuntelun tai tietojen väärentämisen.

Luo tai hanki todistus

Tuotannossa käytä luotetun varmenteen myöntäjän (CA) sertifikaattia. Testauksessa tai sisäisissä käyttöönotossa voit luoda itse allekirjoitetun sertifikaatin:

sudo mkdir -p /etc/ssl/mongodb

sudo openssl req -newkey rsa:4096 -new -x509 -days 365 -nodes -out /etc/ssl/mongodb/mongodb.crt -keyout /etc/ssl/mongodb/mongodb.key -subj "/CN=$(hostname)"

Tämä luo:

• mongodb.crt: julkinen varmenne
• mongodb.key: yksityinen avain

Yhdistä ne yhdeksi PEM-tiedostoksi (MongoDB vaatii sen):

sudo cat /etc/ssl/mongodb/mongodb.key /etc/ssl/mongodb/mongodb.crt | sudo tee /etc/ssl/mongodb/mongodb.pem

sudo chmod 600 /etc/ssl/mongodb/mongodb.pem

sudo chown mongodb:mongodb /etc/ssl/mongodb/mongodb.pem

Nämä käyttöoikeudet varmistavat, että vain mongodb-käyttäjä voi käyttää avaintiedostoa.

Päivitä asetustiedosto

Muokkaa /etc/mongod.conf-tiedostoa ja etsi net-osio. Lisää sen alle uusi tls-lohko:

net:
  port: 27017
  bindIp: 127.0.0.1,192.168.10.50
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb/mongodb.pem

• mode: requireTLS tarkoittaa, että MongoDB kieltäytyy kaikista salauksettomista yhteyksistä.
• certificateKeyFile määrittää yhdistetyn PEM-tiedoston polun.

Käynnistä MongoDB uudelleen muutoksen voimaantumiseksi:

sudo systemctl restart mongod

Yhdistä TLS:n avulla

Kun yhdistät mongosh-ohjelmalla, sinun on nyt määritettävä --tls-vaihtoehto:

mongosh --tls --host 192.168.10.50 -u admin -p --authenticationDatabase admin

Jos yhteys onnistuu ja kehotus ilmestyy, TLS-määrityksesi toimii oikein.

Voit varmistaa salauksen tarkistamalla yhteyden OpenSSL:llä:

openssl s_client -connect 192.168.10.50:27017

Tulosteen tulisi näyttää varmenneketju ja salauksen tiedot, esimerkiksi:

SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384

Tämä vahvistaa, että MongoDB-palvelimesi salaa nyt liikenteen päästä päähän.

Tietoturvan tarkistaminen

Kun kaikki on määritetty, kannattaa tarkistaa asennuksesi vielä kerran.

1. Tarkista, että MongoDB on sidottu vain sallittuihin IP-osoitteisiin:

   sudo ss -tulpn | grep mongod

   Sinun pitäisi nähdä yhteydet rajoitettuna vain 127.0.0.1:aan ja luotettuihin IP-osoitteisiisi.

2. Varmista, että todennus on pakollinen. Yritä yhdistää ilman tunnistetietoja:

   mongosh

   Sinun pitäisi saada todennusvirhe.

3. Varmista, että TLS on pakollinen. Yritä muodostaa yhteys ilman --tls:

   mongosh --host 192.168.10.50 -u admin -p --authenticationDatabase admin

   Jos yhteys epäonnistuu viestillä TLS-vaatimuksista, salauksesi on otettu oikein käyttöön.

4. Tarkista MongoDB:n sisäiset turvallisuusparametrit:

   mongosh -u admin -p --authenticationDatabase admin --eval "db.runCommand({ getParameter: 1, tlsMode: 1 })"

   Jos tlsMode palauttaa "requireTLS", salaamisen katsotaan olevan aktiivinen.

Kun todennus, käyttöoikeuksien hallinta, verkkorajoitukset ja TLS on kaikki määritetty, MongoDB-instanssisi on nyt suojattu tavallisimmilta hyökkäysvektoreilta.

Toiminnalliset parhaat käytännöt

Kun MongoDB on asennettu ja suojattu, seuraava tärkeä prioriteetti on sen tehokas ylläpito. Jopa tarkimmin konfiguroitu tietokanta voi muuttua epäluotettavaksi ilman säännöllistä huoltoa. Rutiinitoimet, kuten varmuuskopiot, seuranta ja järjestelmäpäivitykset, varmistavat, että MongoDB pysyy suorituskykyisenä, vakaana ja palautettavana ajan myötä.

MongoDB-tietojen varmuuskopiointi

Hyvin suunniteltu varmuuskopiointistrategia on perustavanlaatuinen jokaiselle tuotantotietokannalle. Varmuuskopiot mahdollistavat nopean palautumisen laitteistovioista, ohjelmistovirheistä tai vahingossa tapahtuneista poistoista. MongoDB tukee sekä loogisia että fyysisiä varmuuskopioita, ja kukin sopii erilaisiin tilanteisiin.

Loogiset varmuuskopiot käyttämällä mongodump-komentoa

Looginen varmuuskopio tallentaa tietokannan sisällön BSON-muodossa käyttäen mongodump-työkalua. Tämä lähestymistapa on siirrettävä, ihmisluettava ja helppo automatisoida.

Luo täydellinen varmuuskopio kaikista tietokannoista suorittamalla:

mongodump --out /backups/mongodb/$(date +%F)

Tämä komento luo hakemiston nimeltä nykyisen päivän mukaisesti polkuun /backups/mongodb/ ja tallentaa kaikki BSON-varmuuskopiot siihen.

Jos todennus on käytössä, käytä URI-yhteysmerkkijonoa, joka sisältää tunnistetiedot:

mongodump --uri="mongodb://admin:YourPassword@localhost:27017/admin" --out /backups/mongodb/$(date +%F)

Voit myös varmuuskopioida tietyn tietokannan:

mongodump --db=myappdb --out /backups/mongodb/$(date +%F)

Loogisen varmuuskopion palauttamiseksi käytä mongorestore:

mongorestore /backups/mongodb/2026-01-05/

Tai palauta yksittäinen tietokanta:

mongorestore --db=myappdb /backups/mongodb/2026-01-05/myappdb

Loogiset varmuuskopiot ovat joustavia ja helppoja skriptata, mutta ne voivat kestää kauemmin valmiiksi erittäin suurten tietomäärien kohdalla.

Fyysiset varmuuskopiot (tiedostojärjestelmän tilannevedokset)

Fyysiset varmuuskopiot tallentavat tietokantatiedostot suoraan tallennusvälineeltä. Tämä menetelmä on nopeampi ja tilaa säästävä suurelle tietokannalle, mutta se vaatii yhtenäisiä kuvakaappauksia korruption välttämiseksi.

Jos käytät lokikirjanpitoa (joka on oletuksena käytössä), voit ottaa volumekuvia MongoDB:n ollessa käynnissä. WiredTiger tukee virhetilanteen mukaisia kuvia MongoDB:n ollessa käynnissä, kunhan lokikirjanpito on käytössä. Täydellisten sovelluksen mukaisten kuvien ottamiseksi MongoDB:n pysäyttäminen on suositeltavaa, mutta ei pakollista:

sudo systemctl stop mongod

Ota tilannekuva pilvipalveluntarjoajasi tai tallennusjärjestelmäsi avulla ja käynnistä palvelu uudelleen:

sudo systemctl start mongod

Tallenna varmuuskopiot aina mahdollisuuksien mukaan toiselle paikkakunnalle tai erilliseen alueeseen. Tämä suojaa tietokeskuksen katkoksilta tai tahattomilta paikallisilta poistamisilta.

MongoDB:n tilan seuranta

Seuranta on kriittistä ongelmien ehkäisemiseksi ennen kuin ne vaikuttavat käyttäjiin. MongoDB tarjoaa sisäänrakennettuja komentorivityökaluja sekä tukea ulkoisille seurantajärjestelmille.

Sisäänrakennettujen työkalujen käyttö

mongostat-työkalu näyttää reaaliaikaisia tietokantamittareita, kuten sekunnissa tapahtuvat toiminnot, muistin käyttö ja aktiiviset yhteydet. Suorita se seuraavasti:

mongostat --uri "mongodb://admin@localhost:27017/?authSource=admin"

Tämä tuottaa reaaliaikaisen taulukon, joka näyttää lisäykset, kyselyt, päivitykset ja poistot. Jokainen sarake edustaa suorituskykymittaria, kuten likaisen muistisivun suhdetta tai aktiivisten yhteyksien määrää.

mongotop-työkalu keskittyy siihen, kuinka kauan MongoDB käyttää aikaa kunkin kokoelman lukemiseen ja kirjoittamiseen. Ajaaksesi sitä kahden sekunnin välein, käytä:

mongotop 2

Tämä on hyödyllistä, kun halutaan tunnistaa kokoelmia, joilla on raskas I/O-kuormitus.

Ulkoisten valvontatyökalujen käyttö

Jatkuvaa näkyvyyttä ja hälytystä varten voit integroida MongoDB:n ulkoisten järjestelmien kanssa, kuten:

• MongoDB Atlas -valvonta, myös itse isännöidyille klustereille.
• Prometheus ja Grafana, käyttäen MongoDB Exporteria aikasarjataulukoihin.
• Percona Monitoring and Management (PMM), täydellinen avoimen lähdekoodin valvontapaketti.
• Yleiset järjestelmätyökalut, kuten Netdata, Zabbix tai Datadog.

Tärkeitä seurattavia mittareita ovat:

• Muistin käyttö ja välimuistin osumatarkkuus
• Levyn I/O-viive ja läpäisykyky
• Yhteyksien määrä ja jonon pituus
• Toiminnon viive (lisäys, päivitys, hakuajat)
• Replika-viive (jos käytössä on replikkasarja)

Levyn tilan ja tallennuksen kasvun hallinta

MongoDB-tietokannat laajenevat dynaamisesti dokumenttien ja indeksien kasvaessa. Jos levyn käyttöä ei valvota, tietokanta saattaa loppua tilasta, mikä voi aiheuttaa sen lukkiutumisen tai kaatumisen.

Levyn käytön tarkistaminen

Tarkista nykyinen tiedostojärjestelmän käyttö komennolla:

df -h /var/lib/mongodb

Tämä näyttää MongoDB:n datakansion käytettävissä olevan ja käytetyn tilan.

Voit myös tarkistaa muistin ja välimuistin käytön suoraan MongoDB:stä:

mongosh --eval "db.serverStatus().wiredTiger.cache"

Arvo bytes currently in the cache osoittaa, kuinka paljon RAM-muistia WiredTiger-tallennusmoottori käyttää.

Levyn käytön hälytysten määrittäminen

Pysyäksesi ennakoivana, aseta hälytyksiä tai valvontatarkastuksia, jotka ilmoittavat, kun levyn käyttö ylittää 85 %. Esimerkiksi yksinkertainen skripti voidaan ajoittaa suoritettavaksi säännöllisesti:

df -h | awk '$5 > 85 {print $0}'

Voit integroida tämän systemd-ajastimiin tai valvontatyökaluihin automatisointia varten.

Vanhojen tietojen ja lokien hallinta

Suuret tai käyttämättömät kokoelmat ja lokitiedostot voivat ajan myötä kuluttaa merkittävästi tilaa. Hallitaksesi lokitiedostoja, määritä kierto tiedostossa /etc/logrotate.d/mongodb (kuten myöhemmin tässä osassa näytetään) tai siivoa ne manuaalisesti:

sudo journalctl --vacuum-time=7d

sudo rm -f /var/log/mongodb/*.gz

Sovellustietojen osalta harkitse TTL (time-to-live) -indeksien käyttöä kokoelmissa, jotka tallentavat väliaikaisia tai ajankohtaisia tietoja:

db.sessionLogs.createIndex({ "createdAt": 1 }, { expireAfterSeconds: 604800 })

Tämä poistaa automaattisesti yli seitsemän päivää vanhat asiakirjat.

Turvallisten päivitysten suorittaminen

MongoDB:n päivittäminen vaatii huolellista suunnittelua, erityisesti siirryttäessä suurten versioiden välillä. Seuraava prosessi minimoi käyttökatkot ja varmistaa yhteensopivuuden.

Tarkista nykyinen versio

Vahvista asennettu versio:

mongod --version

Varmuuskopioi ennen päivitystä

Luo aina täydellinen varmuuskopio ennen päivitystä:

mongodump --out /backups/mongodb/pre-upgrade-$(date +%F)

Päivitä pakettivarasto ja päivitä järjestelmä

Jos olet aiemmin lukinnut MongoDB-paketit estääksesi automaattiset päivitykset, poista lukitukset:

echo "mongodb-org install" | sudo dpkg --set-selections

Päivitä sitten pakettien luettelo ja päivitä MongoDB:

sudo apt update

sudo apt install -y mongodb-org

MongoDB säilyttää määritykset ja tietotiedostot päivitysten aikana, mutta varmuuskopio takaa, että voit palauttaa järjestelmän, jos jokin menee pieleen.

Vahvista päivitys

Päivityksen jälkeen:

1. Tarkista palvelun tila:

   sudo systemctl status mongod

2. Tarkista viimeisimmät lokit varoituksien tai siirtomerkintöjen varalta:

   sudo tail -n 30 /var/log/mongodb/mongod.log

3. Vahvista uusi versio:

   mongosh --eval "db.version()"

Rutiinihuollon automatisointi

Manuaalinen ylläpito toimii pienissä ympäristöissä, mutta automaatio takaa johdonmukaisuuden. Voit aikatauluttaa toistuvia varmuuskopiointeja, lokien kiertoja tai valvontatarkastuksia käyttämällä cron- tai systemd-ajastimia.

Aikatauluta automaattiset varmuuskopiot

Muokkaa rootin crontabia:

sudo crontab -e

Lisää seuraava rivi varmuuskopioidaksesi MongoDB-instanssisi joka yö klo 2:00:

0 2 * * * mongodump --out /backups/mongodb/$(date +\%F)

Tämä luo päivittäin päivätyn varmuuskopiokansion.

Määritä lokin kierto

Estääksesi lokitiedostojen kuluttamasta levytilaa, luo lokin kierrätysasetustiedosto:

sudo nano /etc/logrotate.d/mongodb

Lisää seuraava sisältö:

/var/log/mongodb/mongod.log {
    weekly
    rotate 5
    compress
    delaycompress
    missingok
    notifempty
    create 640 mongodb adm
    postrotate
        systemctl reload mongod > /dev/null 2>&1 || true
    endscript
}

Tämä kokoonpano säilyttää viiden viikon lokitiedostot, pakkaa vanhemmat tiedostot ja lataa MongoDB:n uudelleen kierron jälkeen.

Tarkan järjestelmäajan ylläpitäminen

MongoDB:n lokitus- ja replikaatio-ominaisuudet perustuvat tarkkoihin aikaleimoihin. Jos järjestelmäkello harhailee, voi tapahtua replikaation viivettä tai lokin vioittumista kaatumisen jälkeen.

Ubuntu 24.04 käyttää oletuksena systemd-timesyncd-ohjelmaa, mutta voit myös käyttää chrony-ohjelmaa tarkempaan ajan synkronointiin:

sudo apt install chrony -y

sudo systemctl enable --now chrony

Voit tarkistaa synkronoinnin seuraavasti:

timedatectl status

Jos NTP synchronized näyttää yes, järjestelmäkellosi on synkronoitu.

MongoDB:n tilan tarkistaminen reaaliajassa

MongoDB tarjoaa serverStatus-komennon kattavaa ajonaikaista diagnostiikkaa varten. Voit kysyä sitä suoraan komentoriviltä:

mongosh --eval "db.serverStatus()"

Tämä palauttaa yksityiskohtaisen JSON-objektin, joka sisältää mittareita, kuten:

• Muistin kulutus
• Välimuistin käyttö
• Yhteyksien määrä
• Toiminnon läpimeno
• Replikaatiotila

Voit poimia tiettyjä kenttiä kohdennettuihin tarkistuksiin. Esimerkiksi yhteysstatistiikan tarkasteluun:

mongosh --eval "db.serverStatus().connections"

Tämä mahdollistaa nopean käsityksen siitä, kärsiikö järjestelmä yhteyden ylikuormituksesta vai resurssien rajoituksista.

Valmistautuminen korkean käytettävyyden varmistamiseen

Yhden solmun MongoDB-asennukset toimivat hyvin kehityksessä tai vähemmän kriittisissä sovelluksissa. Tuotantoympäristöissä sinun tulisi ottaa käyttöön replikaattisarjat. Replikaattisarjat tarjoavat redundanssia ja automaattisen vikasietoisuuden, mikä varmistaa käytettävyyden, vaikka yksi solmu epäonnistuisi.

Tyypillisessä asetuksessa:

• Yksi solmu toimii ensisijaisena, käsitellen kaikki kirjoitukset ja suurimman osan luvuista.
• Yksi tai useampi toissijainen solmu kopioi tietoja reaaliajassa.
• Jos ensisijainen solmu menee offline-tilaan, yksi toissijaisista solmuista muuttuu automaattisesti uudeksi ensisijaiseksi.

Replica-setit helpottavat myös ylläpitotehtäviä, kuten varmuuskopioita ja skaalausta. Voit siirtää varmuuskopioita tai analytiikkakyselyjä toissijaisille solmuille vaikuttamatta pääsolmun suorituskykyyn.

MongoDB-instanssisi on nyt täysin toimintakunnossa ja asianmukaisesti ylläpidetty.

Skaalaus ja suorituskyvyn optimointi

MongoDB on suunniteltu skaalautumaan horisontaalisesti, mikä tarkoittaa, että kapasiteettia ja suorituskykyä voidaan lisätä lisäämällä enemmän palvelimia sen sijaan, että luotetaan vain yhteen tehokkaampaan koneeseen. Kun tietokanta kasvaa tai sovelluksesi alkaa käsitellä useampia samanaikaisia kyselyjä, skaalaaminen varmistaa, että MongoDB jatkaa luotettavaa ja tehokasta suorituskykyään.

MongoDB:n skaalaamiseen on kaksi pääasiallista tapaa:

1. Replica-sarjat, jotka lisäävät luotettavuutta ja lukunopeutta redundanssin avulla.
2. Sharding, joka jakaa tietoja useille palvelimille suurten tietomäärien ja kirjoituskuormien käsittelemiseksi.

Replica-pakettien ymmärtäminen

Replica-setti on ryhmä MongoDB-palvelimia, jotka ylläpitävät identtisiä kopioita tiedoistasi. Replica-setit tarjoavat korkean käytettävyyden ja suojaavat laitteisto- tai verkkovikoja vastaan. Jos ensisijainen solmu epäonnistuu, yksi toissijaisista solmuista ottaa automaattisesti hoitaakseen sen, mikä takaa minimaalisen käyttökatkon.

Tavallinen replikaattisarja koostuu seuraavista:

• Yksi pääsolmu, joka käsittelee kaikki kirjoitustoiminnot.
• Kaksi tai useampi toissijainen solmu, jotka kopioivat tietoja ensisijaiselta solmulta.
• Valinnaiset tuomarisolmut, jotka osallistuvat vaaleihin mutta eivät tallenna dataa.

Tuotantojärjestelmissä MongoDB suosittelee vähintään kolmea jäsentä replikaatiosarjassa.

Replikasetin määrittäminen

Replikasarjan luomiseksi tarvitset vähintään kaksi tai kolme palvelinta (fyysistä tai virtuaalista). Jokaisessa solmussa tulisi olla asennettuna ja konfiguroituna MongoDB.

1. Avaa jokaisessa solmussa konfiguraatiotiedosto /etc/mongod.conf ja lisää replikaation osio:

   replication:
     replSetName: "rs0"

2. Käynnistä MongoDB uudelleen jokaisella palvelimella:

   sudo systemctl restart mongod

3. Liity MongoDB:hen pääsolmussa ja alusta replikaattijoukko:

   mongosh

   Sitten suorita:

   rs.initiate({
     _id: "rs0",
     members: [
       { _id: 0, host: "mongodb1.example.com:27017" },
       { _id: 1, host: "mongodb2.example.com:27017" },
       { _id: 2, host: "mongodb3.example.com:27017" }
     ]
   })

4. Tarkista tila:

   rs.status()

   Tulosteen tulisi näyttää yksi ensisijainen ja kaksi toissijaista, joiden tila on merkitty sanoin "ENSISIJAINEN" ja "TOISSIJAINEN".

Replica-settien edut

Replica-setit tarjoavat useita tärkeitä etuja:

• Korkea käytettävyys: Automaattinen vikatilanteen hallinta varmistaa toiminnan jatkumisen, jos ensisijainen solmu menee offline-tilaan.
• Tiedon redundanssi: Jokainen solmu ylläpitää täyttä kopiota tiedoista.
• Lukujen skaalaaminen: Toissijaiset solmut voivat käsitellä lukuoperaatioita, mikä vähentää pääsolmun kuormitusta.
• Huollon joustavuus: Voit suorittaa varmuuskopiointeja tai järjestelmäpäivityksiä toissijaisissa solmuissa ilman, että saatavuus kärsii.

Shardingin ymmärtäminen

Sharding on MongoDBn strategia horisontaaliseen skaalaamiseen. Kun tietojoukko kasvaa liian suureksi yhdelle palvelimelle tallennettavaksi tai käsiteltäväksi tehokkaasti, MongoDB voi jakaa sen pienempiin osiin, joita jaetaan useille palvelimille, joita kutsutaan shardiksi.

Jokainen partitiokappale sisältää osajoukon tiedoista, ja klusteri käyttäytyy yhdessä yhtenä loogisena tietokantana.

Shardatun klusterin komponentit

Tyypillinen MongoDB:n shardattu klusteri sisältää:

• Shards: Tietoa sisältävät solmut, joita usein käytetään replikoitavina ryhminä varmuuskopioinnin vuoksi.
• Konfiguraatiopalvelimet: Tallentavat metatiedot ja klusterin kokoonpanon, mukaan lukien lohkojen jakautumisen.
• Mongos-reitittimet: Reitittävät asiakaskyselyt oikeaan lohkoon sharding-avaimen perusteella.

Shard-avaimen valinta

Shard-avain määrittää, miten MongoDB jakaa dataa shardeihin. Huonosti valittu shard-avain voi johtaa epätasaiseen datanjakautumiseen (tunnetaan nimellä data skew) tai kuumiin pisteisiin.

Hyvillä shard-avainilla on yleensä:

• Korkea kardinaliteetti (paljon yksilöllisiä arvoja).
• Jopa tietojen käyttötavat.
• Ennustettava kyselykuvio, joka sisältää useimmissa kyselyissä shard-avaimen.

Esimerkki tietokannan shardingin ottamisesta käyttöön:

sh.enableSharding("salesdb")
sh.shardCollection("salesdb.orders", { "customer_id": 1 })

Tämä komento ottaa shardingin käyttöön salesdb-tietokannassa ja hajauttaa orders-kokoelman customer_id-kentän perusteella.

Milloin käyttää shardingia

Sinun tulisi harkita shardingia, kun:

• Tietokanta lähestyy tai ylittää yhden palvelimen tallennuskapasiteetin rajan.
• Kirjoitusnopeus kuormittaa jatkuvasti CPU:ta tai levy-I/O:ta maksimiin.
• Työjoukko ei enää mahdu RAM-muistiin, mikä aiheuttaa usein sivujen vaihtumista.
• Odota eksponentiaalista kasvua tietojoukissasi.

Sharding lisää arkkitehtonista monimutkaisuutta, joten sitä kannattaa ottaa käyttöön vain silloin, kun se on tarpeen.

WiredTigerin viritys suorituskykyä varten

MongoDB käyttää oletuksena WiredTiger-tallennusmoottoria. Se on optimoitu nykyaikaiselle laitteistolle ja hyödyntää pakkausta, välimuistia ja monisäikeistä I/O:ta. Ymmärtäminen siitä, miten WiredTiger hallitsee muistia ja levy-I/O:ta, auttaa parantamaan suorituskykyä.

Muistin käyttö

WiredTiger käyttää tyypillisesti noin 50 % saatavilla olevasta RAM-muistista välimuistiinsa, ja MongoDB säätää tätä arvoa dynaamisesti järjestelmän muistin perusteella.

Voit säätää tätä asetustiedostossa:

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8

Tämä on hyödyllistä, jos järjestelmäsi käyttää muita muistia paljon kuluttavia palveluita MongoDB:n rinnalla. Omistetuilla MongoDB-palvelimilla oletusvälimuistin asetuksen pitäminen on yleensä paras vaihtoehto.

Voit tarkastella nykyistä välimuistin käyttöä suorittamalla:

mongosh --eval "db.serverStatus().wiredTiger.cache"

Puristus

WiredTiger tukee tietojen ja indeksien pakkausta levykäytön vähentämiseksi. Oletuksena se käyttää Snappy-pakkausta, joka tasapainottaa suorituskyvyn ja tilatehokkuuden. Voit vaihtaa zlib (parempaa pakkausta varten) tai zstd (uusille asennuksille), jos arvostat levytallennuksen säästöä nopeuden sijaan.

Esimerkkiasetus:

storage:
  wiredTiger:
    collectionConfig:
      blockCompressor: zstd

Päiväkirjan pitäminen ja kestävyys

Lokikirjaus varmistaa, että kirjoitusoperaatiot säilyvät, jopa sähkökatkosten sattuessa. Voit säätää commitIntervalMs-parametria hallitaksesi, kuinka usein lokikirjan kirjoituksia tapahtuu:

storage:
  journal:
    commitIntervalMs: 100

Matalammat aikavälit parantavat kestävyyttä, mutta voivat hieman heikentää kirjoitusnopeutta.

Valvonta- ja skaalauskäynnistimet

On tärkeää tunnistaa, milloin MongoDB-järjestelyä on skaalattava. Seuraamalla mittareita, kuten CPU-kuormitusta, muistinkäyttöä ja I/O-odotusaikoja, voidaan päätellä, milloin on aika lisätä kapasiteettia.

Yleisiä syitä ihon hilseilyyn

• CPU:n käyttöaste pysyvästi yli 80 %.
• Levyn I/O-viive ylittää hyväksyttävät rajat (esimerkiksi yli 10 ms).
• RAMin käyttö lähellä maksimiarvoa pitkien jaksojen ajan.
• Työjoukon koon nopea kasvu.
• Solmujen välinen replikaation viive kasvanut.

Kun nämä indikaattorit ilmestyvät, harkitse lisäsekundaarien (lukuja varten) tai sirpaleiden (kirjoitusrasitusta varten) lisäämistä.

Pystysuuntainen vs. vaakasuuntainen skaalaus

Vertikaalinen skaalaus tarkoittaa olemassa olevien palvelimien resurssien (CPU, RAM, nopeammat levyt) lisäämistä. Sen hallinta on yksinkertaisempaa, mutta se on rajoitettu laitteiston kapasiteetin mukaan.

Vaakasuuntainen laajentaminen tarkoittaa uusien palvelimien lisäämistä työkuorman jakamiseksi. Tämä on MongoDB:n vahvuus, sillä se skaalautuu lähes lineaarisesti, kun se on suunniteltu oikein.

Siirtyminen hallittuun MongoDB:hen

Kun järjestelmäsi kasvaa, itse ylläpidetyn klusterin hallinnasta voi tulla monimutkaista. Tässä vaiheessa siirtyminen hallittuun MongoDB-palveluun, kuten MongoDB Atlakseen, voi merkittävästi vähentää operatiivista kuormitusta.

Hallitut alustat hoitavat automaattiset varmuuskopiot, päivitykset, valvonnan, skaalaamisen ja salauksen. Ne voivat kuitenkin tuoda lisäkustannuksia ja hieman vähemmän joustavuutta verrattuna itsehallittuihin kokoonpanoihin.

<$> Suositus: Pysy itse isännöidyllä ratkaisulla, kunnes tiimisi kohtaa jatkuvia operatiivisia haasteita, kuten suorituskykyyn liittyviä pullonkauloja, klusterin hallinnan monimutkaisuutta tai vaatimustenmukaisuustarpeita, jotka hallinnoidut alustat hoitavat tehokkaammin. <$>

Vertailu: Itseisännöity vs Hallinnoitu MongoDB

MongoDB voidaan ottaa käyttöön kahdella pääasiallisella tavalla:

1. Itseisännöity, jossa asennat, konfiguroit ja ylläpidät tietokantaa itse (kuten tässä oppaassa on käsitelty).
2. Hallinnoitu, jossa kolmannen osapuolen tarjoaja ylläpitää ja käyttää MongoDB:tä puolestasi palveluna.

Jokaisella lähestymistavalla on omat etunsa ja kompromissinsa. Oikea valinta riippuu teknisestä osaamisestasi, työkuorman ominaisuuksista, vaatimustenmukaisuusvaatimuksista ja operatiivisista prioriteeteista.

Tutkitaan näitä kahta vaihtoehtoa tarkemmin.

Itseisännöity MongoDB

Kun isännöit MongoDB:tä itse, asennat sen suoraan omaan infrastruktuuriisi, olipa kyseessä fyysinen palvelin, virtuaalikone tai pilvi-instanssi, kuten Linux-Console.net Droplet. Hallitset ympäristön jokaista osa-aluetta asennuksesta päivityksiin ja valvontaan.

Itseisännöinnin edut

1. Täysi hallinta ja joustavuus: Sinulla on täydellinen valta määritysasetteluihin, tiedostojärjestelmiin, verkkoon ja suorituskyvyn hienosäätöön. Voit muokata mongod.conf-tiedostoa, valita tallennuspolkusi ja soveltaa mukautettuja turvallisuus- tai varmuuskopiointikäytäntöjä, jotka vastaavat organisaatiosi standardeja.
2. Kustannustehokkuus pienissä käyttöönotossa: Pienille tai keskisuurille työkuormille itseisännöinti voi olla edullisempaa kuin hallitun palvelun käyttö. Maksat vain peruslaskenta- ja tallennusresursseista sen sijaan, että lisäisit hallintakerroksen kustannukset.
3. Muokatut turvallisuuspolitiikat: Voit yhdistää MongoDB:n sisäisiin VPN-verkkoihin, palomuureihin tai yksityisiin verkkoihin, varmistaen täyden noudattamisen paikallisten tai toimialakohtaisten turvallisuusvaatimusten kanssa. Joidenkin organisaatioiden on käytettävä paikallista asennusta tietosijainti- tai sääntelyrajoitusten vuoksi, mikä tekee itseisännöinnistä ainoan toteuttamiskelpoisen vaihtoehdon.
4. Suorituskyvyn optimointi: Koska hallitset laitteistoa, voit hienosäätää järjestelmän parametreja, kuten I/O-ajastimia, välimuistin kokoa ja pakkausalgoritmeja. Voit myös sijoittaa MongoDB:n samalle palvelimelle siihen liittyvien palveluiden kanssa verkon viiveen minimoimiseksi.

Itseisännöinnin haasteet

• Toiminnallinen ylikuorma: Sinun vastuullasi on hallita kaikkea; päivitysten ja korjausten asentamisesta katkojen käsittelyyn ja suorituskyvyn optimointiin. Tämä vaatii omistautunutta henkilöstöä, jolla on asiantuntemusta tietokantahallinnasta ja Linux-järjestelmän hallinnasta.
• Skalautuvuuden monimutkaisuus: Itse isännöidyn MongoDB-klusterin skaalaaminen tarkoittaa uusien palvelimien pystyttämistä, tietojen tasapainottamista, kokoonpanojen päivittämistä ja replikaatio- tai sharding-topologioiden ylläpitoa manuaalisesti. Nämä tehtävät voivat olla virhealttiita ilman automaatiota.
• Varmuuskopiointi ja katastrofipalautus: Sinun on suunniteltava, testattava ja ylläpidettävä omat varmuuskopiointi-, palautus- ja offsite-tallennusprosessejasi. Vaikka MongoDB:n työkalut (mongodump, mongorestore ja levysnapshotit) tekevät tämän mahdolliseksi, se vaatii kurinalaista operatiivista suunnittelua.
• Valvonta ja hälytykset: Omatoimisesti isännöity MongoDB vaatii valvonta- ja hälytysjärjestelmien käyttöönoton työkaluilla kuten Prometheus, Grafana tai Percona PMM. Ilman jatkuvaa näkyvyyttä viat tai suorituskykyongelmat voivat jäädä huomaamatta, kunnes ne aiheuttavat käyttökatkon.

Yhteenvetona voidaan todeta, että itse isännöity MongoDB tarjoaa joustavuutta, riippumattomuutta ja alhaisemmat kustannukset pienessä mittakaavassa, mutta vaatii merkittävää jatkuvaa ylläpitotyötä.

Hallinnoidut MongoDB-palvelut

Hallinnoitu MongoDB-palvelu isännöi tietokantaa puolestasi hoitaen kaiken infrastruktuurin, päivitykset, skaalaamisen ja tietoturvapaikkaukset automaattisesti. Nämä palvelut poistavat suurimman osan hallinnollisesta työstä samalla kun ne tarjoavat korkean käytettävyyden ja globaalin skaalautuvuuden.

Hallinnoidun MongoDB:n edut

1. Minimaalinen operatiivinen vaiva: Palveluntarjoaja hoitaa tietokantojen käyttöönoton, varmuuskopiot, päivitykset ja vikasuojaukset automaattisesti. Voit ottaa käyttöön uusia klustereita vain muutamalla klikkauksella tai API-kutsuilla, mikä vähentää merkittävästi hallinnollista työkuormaa.
2. Automaattinen skaalaus: Hallinnoidut palvelut voivat dynaamisesti säätää laskenta- ja tallennusresursseja tietojoukon kasvaessa. Esimerkiksi MongoDB Atlas tukee automaattista shardingia ja pystysuuntaista skaalausta ilman käyttöhäiriöitä.
3. Sisäänrakennettu valvonta ja hälytykset: Hallinnoiduissa alustoissa on kojelaudat, joista näet suoritin- ja levyn käytön, yhteystilastot ja kyselyviiveet. Voit asettaa hälytysrajat kriittisille mittareille ilman erillisten valvontatyökalujen käyttöönottoa.
4. Korkea saatavuus oletuksena: Useimmat hallinnoidut palvelut ottavat käyttöön klustereita, joissa on kolme tai useampia replikaattorisolmua eri käytettävyysvyöhykkeillä. Tämä varmistaa automaattisen vikasietojärjestelmän ja korkean käyttöajan vähäisellä määrityksellä.
5. Turvallisuus ja vaatimustenmukaisuus: Hallinnoidut MongoDB-alustat tarjoavat sisäänrakennetun salauksen, roolipohjaisen pääsynhallinnan, verkkoeristyksen (VPC-peering) ja integraation identiteetin tarjoajien kanssa. Ne ovat myös sertifioituja sellaisiin standardeihin kuin SOC 2, GDPR, HIPAA ja ISO 27001, mikä yksinkertaistaa vaatimustenmukaisuustarkastuksia.
6. Maailmanlaajuinen jakelu: MongoDB Atlas ja vastaavat palvelut tukevat monialueisia klustereita. Data voidaan replikoida maantieteellisesti lähelle käyttäjiäsi, mikä parantaa viiveitä hajautetuissa sovelluksissa.

Hallitun palvelun rajoitukset

1. Korkeammat kustannukset mittakaavassa: Hallinnoidut palvelut veloittavat ylimääräistä automaatiosta ja mukavuudesta. Kun datamäärä ja liikenne kasvavat, kuukausikustannukset voivat ylittää itse isännöityjen instanssien käytön kustannukset, erityisesti suurten SSD:lle tallennettujen tietomäärien kohdalla.
2. Rajoitettu mukautettavuus: Hallitut ympäristöt rajoittavat pääsyä matalan tason asetuksiin. Et voi muokata tiedostojärjestelmätason asetuksia, välimuistin säätöjä tai käyttöjärjestelmän perustason parametreja.
3. Toimittajalukitus: Jokaisella palveluntarjoajalla on ainutlaatuiset API-rajapinnat ja käyttöönottoasetukset, mikä tekee palveluiden välillä siirtymisestä myöhemmin vaikeaa.
4. Verkkoriippuvuus: Hallitut tietokannat riippuvat ulkoisesta verkkoyhteydestä. Jos sovelluksesi toimii paikallisympäristössä, turvallinen yhteys hallittuun palveluun voi aiheuttaa viivettä tai riippuvuutta VPN-tunneleista.

Yhteenvetona voidaan todeta, että hallinnoidut MongoDB-palvelut vähentävät merkittävästi hallinnollista taakkaa ja parantavat luotettavuutta, mutta joustavuuden ja korkeampien toistuvien kustannusten hinnalla.

Ominaisuuksien vertailutaulukko

Oikean käyttöönottomallin valitseminen

Päätös itse-isännöidyn ja hallinnoidun MongoDB:n välillä riippuu pääasiassa organisaationne prioriteeteista, resursseista ja rajoitteista. Harkitse seuraavia tilanteita:

• Valitse itse isännöity MongoDB, jos:

  • Tarvitset täyden hallinnan infrastruktuuriin ja tietoihin.
  • Työmääräsi on kohtuullinen ja ennustettavissa.
  • Teillä on sisäistä osaamista Linuxin ja MongoDB:n hallinnassa.
  • Säännösten tai tietojen sijaintia koskevien lakien mukaan vaaditaan paikallista tallennusta.

• Valitse hallinnoitu MongoDB, jos:

  • Sinä keskityt mieluummin sovelluskehitykseen kuin infrastruktuuriin.
  • Tarvitset automaattisen skaalaamisen ja korkean käytettävyyden mahdollisimman vähäisellä asetuksella.
  • Tiimiltäsi puuttuvat omistautuneet tietokanta-administrattorit.
  • Tarvitset maailmanlaajuisesti jakautuneita klustereita tai noudattamiseen liittyviä sertifikaatteja (SOC 2, HIPAA, GDPR).

Vianmääritys ja huolto

Jopa tarkimmalla konfiguroinnilla ja valvonnalla MongoDB-asennuksessa voi ilmetä ongelmia. Näitä voivat olla esimerkiksi hidas suorituskyky, käynnistysvirheet, replikaation viive tai levyn tilan loppuminen. Avain vakaana MongoDB-ympäristön ylläpitämiseen on rakenteellinen lähestymistapa ongelmien diagnosointiin ja ennakoivien huoltotoimenpiteiden soveltamiseen.

Tarkistetaan MongoDB-palvelun tila

Ensimmäinen askel MongoDB:n vianmäärityksessä on varmistaa, että tietokantapalvelu toimii oikein.

Voit tarkistaa nykyisen tilan seuraavalla komennolla:

sudo systemctl status mongod

Jos MongoDB on käynnissä, sinun pitäisi nähdä tuloste, joka sisältää:

Active: active (running)

Main PID: 3564 (mongod)

Jos palvelu on epäaktiivinen, epäonnistunut tai pois käytöstä, käynnistä se uudelleen:

sudo systemctl restart mongod

Käynnistä uudelleen ja tarkista sen tila uudelleen. Jos se epäonnistuu heti, jatka tarkistamalla lokitiedosto erityisten virheiden varalta.

MongoDB-lokin tarkastelu

Lokit ovat suorin lähde diagnoosintietoon. MongoDB tallentaa kaikki merkittävät tapahtumat, varoitukset ja virheet pääasialliseen lokitiedostoonsa, joka sijaitsee osoitteessa:

/var/log/mongodb/mongod.log

Näyttääksesi viimeisimmät merkinnät, suorita:

sudo tail -n 30 /var/log/mongodb/mongod.log

Jos MongoDB ei käynnisty, näet tyypillisesti jonkin seuraavista virheistä:

• Lupa evätty: Virheelliset omistajuus- tai käyttöoikeudet hakemistoissa /var/lib/mongodb tai /var/log/mongodb. Tarkista käyttöoikeudet ja korjaa ne:

  sudo chown -R mongodb:mongodb /var/lib/mongodb /var/log/mongodb

• Tietohakemistoa ei löytynyt: Varmista, että /var/lib/mongodb on olemassa ja vastaa polkua, joka on määritelty tiedostossa /etc/mongod.conf.

• Osoite on jo käytössä: Toinen prosessi käyttää porttia 27017. Tunnista se seuraavasti:

  sudo lsof -i :27017

  ja pysäytä tai määritä ristiriitainen palvelu uudelleen.

• Vialliset tiedostot: Tämä voi tapahtua, jos MongoDB suljettiin äkillisesti. Tällaisissa tapauksissa journalin pitäisi palauttaa tiedot automaattisesti uudelleenkäynnistyksen yhteydessä. Jos se epäonnistuu, saatat joutua palauttamaan varmuuskopiosta.

sudo tail -f /var/log/mongodb/mongod.log

Yhteysongelmien diagnosointi

Yhteysongelmat ovat toinen yleinen ongelma. Kun asiakkaat eivät pääse MongoDB:hen, se johtuu yleensä verkko-, todennus- tai määritysongelmasta.

Varmista, että MongoDB kuuntelee oikeilla rajapinnoilla

Suorita :

sudo ss -tulpn | grep mongod

Tulosteen pitäisi näyttää MongoDB kytkettynä osoitteeseen 127.0.0.1 (paikallisia yhteyksiä varten) sekä kaikki määritetyt ulkoiset IP-osoitteet. Jos MongoDB ei kuuntele odotetulla IP-osoitteella, tarkista bindIp-kenttä tiedostosta /etc/mongod.conf:

net:
  bindIp: 127.0.0.1,192.168.10.50

Käynnistä MongoDB uudelleen muokkauksen jälkeen:

sudo systemctl restart mongod

Tarkista palomuurisäännöt

Jos etäyhteydet epäonnistuvat, varmista, että palomuurisi sallii liikenteen portissa 27017:

sudo ufw status

Jos ei, salli yhteydet tietyistä IP-osoitteista:

sudo ufw allow from 192.168.10.50 to any port 27017

Testaa yhteyttä Telnetillä tai Pingillä

Testaa asiakasjärjestelmästä, onko portti saavutettavissa:

telnet mongodb-server-ip 27017

tai

nc -vz mongodb-server-ip 27017

Jos yhteys onnistuu, ongelma liittynee todennukseen tai käyttäjäoikeuksiin.

Autentikointivirheiden vianmääritys

Todentamisongelmia esiintyy usein, kun käyttöoikeuksien valvonta otetaan käyttöön tai käyttäjätietoja muutetaan.

Vahvista, että todennus on käytössä

Yhdistä paikallisesti ja tarkista:

mongosh --eval "db.runCommand({ getParameter: 1, authenticationMechanisms: 1 })"

Jos tuloste sisältää "SCRAM-SHA-256", todennus on aktiivinen.

Vahvista kirjautumistiedot

Yritä muodostaa yhteys ylläpitäjätilillä:

mongosh -u admin -p --authenticationDatabase admin

Jos tämä epäonnistuu, yhdistä paikallisesti ilman todennusta (mahdollista vain localhostista, kun käyttäjiä ei ole) ja luo ylläpitäjätili uudelleen:

use admin

db.createUser({
  user: "admin",
  pwd: "NewStrongPassword",
  roles: ["userAdminAnyDatabase", "readWriteAnyDatabase"]
})

Tarkista tietokantayhteys

Jokainen MongoDB-käyttäjä määritellään tietyn tietokannan sisällä. Jos yrität tunnistautua väärässä tietokannassa, tunnistautuminen epäonnistuu. Esimerkiksi, jos käyttäjä luotiin admin-tietokannassa, sinun täytyy tunnistautua siihen nimenomaisesti:

mongosh -u admin -p --authenticationDatabase admin

Suorituskykyongelmien ratkaiseminen

Suorituskyvyn heikkeneminen voi johtua suuresta muistinkäytöstä, hitaasta levytulosta, optimoimattomista kyselyistä tai liiallisista samanaikaisista yhteyksistä. MongoDB sisältää useita diagnostiikkatyökaluja näiden ongelmien tunnistamiseen.

Tarkista resurssien käyttö

Käytä Linux-komentoja järjestelmätason mittareiden tarkistamiseen:

top

vmstat 2

iostat -x 2

Etsi suurta CPU:n käyttöä mongod-prosessilla tai levyn viivettä, joka ylittää 10 millisekuntia.

Seuraa tietokantatoimintoja

Suorita :

mongostat 2

Tämä näyttää reaaliaikaisia mittareita, mukaan lukien lisäykset, kyselyt, päivitykset ja poistot sekunnissa.

Jos tietyt toiminnot vaikuttavat hitailta, käytä MongoDB-profileria tunnistaaksesi pitkäkestoiset kyselyt.

Ota kyselyprofilointi käyttöön

Voit ottaa profilerin väliaikaisesti käyttöön hidastensa kyselyiden kirjaamiseksi:

use myappdb

db.setProfilingLevel(1, { slowms: 100 })

Tämä kirjaa kaikki kyselyt, jotka kestävät yli 100 millisekuntia.

Tarkista tulokset:

db.system.profile.find().sort({ ts: -1 }).limit(5).pretty()

Analysoi indeksin tehokkuus

Tehottomat kyselyt johtuvat usein puuttuvista indekseistä. Tarkistaaksesi, käyttääkö MongoDB indeksejä oikein, lisää explain() kyselysi alkuun:

db.orders.find({ customer_id: 12345 }).explain("executionStats")

Jos executionStages.stage näyttää "COLLSCAN", MongoDB suorittaa koko kokoelman läpikäynnin. Voit luoda indeksin suorituskyvyn parantamiseksi:

db.orders.createIndex({ customer_id: 1 })

Viallisten tietokantojen korjaaminen

Datan korruptoituminen on harvinaista, mutta sitä voi tapahtua sähkökatkoksen tai levyhäiriöiden vuoksi. Jos MongoDB kieltäytyy käynnistymästä ja lokit näyttävät korruptiota WiredTiger-tiedostoissa, noudata näitä ohjeita:

1. Pysäytä MongoDB:

   sudo systemctl stop mongod

2. Varmuuskopioi nykyinen tietohakemisto:

   sudo cp -r /var/lib/mongodb /var/lib/mongodb-corrupt-backup

3. Yritä korjausoperaatiota:

   sudo -u mongodb mongod --repair --config /etc/mongod.conf

4. Käynnistä MongoDB uudelleen:

   sudo systemctl start mongod

Jos korjaus epäonnistuu, palauta tiedot viimeisimmästä varmuuskopiostasi.

Rutiinihuoltotehtävät

Ennaltaehkäisevä kunnossapito vähentää huomattavasti odottamattomien vikojen riskiä.

Kierrätä lokeja säännöllisesti

Varmista, että lokin kierrätyskäytäntösi on aktiivinen. MongoDB tukee sekä sisäistä lokin kierrätystä (logRotate-komento) että ulkoista kierrätystä logrotate-komennon avulla, kun logAppend on käytössä. Voit käynnistää sen manuaalisesti, jos lokit kasvavat nopeasti:

sudo logrotate -f /etc/logrotate.d/mongodb

Kokoelmat

Kokoelmat voivat hajota monien lisäysten ja poistojen jälkeen. compact voi vapauttaa tilaa, mutta se on estävä toiminto ja sitä tulisi käyttää harvoin tuotannossa. WiredTiger käsittelee suurimman osan hajoamisesta automaattisesti, joten kokoelman pakkaaminen on yleensä turhaa.

Huomaa, että tämä toimenpide lukitsee tietokannan, joten suorita se vähän liikennöidyillä ajoilla.

Varmista kokoelmat

Suorita säännöllisiä tietojen eheystarkastuksia:

db.runCommand({ validate: "collection_name" })

Tämä varmistaa, että hakemistot ja asiakirjat ovat johdonmukaisia.

Valvo levyn ja muistin käyttöä

Käytä automatisoituja hälytyksiä varoittamaan, kun levyn käyttö ylittää 85 % tai muistin käyttö tulee kriittiseksi. Valvontatyökalut, kuten Prometheus, Percona PMM tai MongoDB Atlas Monitor, voivat seurata näitä mittareita ajan myötä.

Järjestelmäpäivitysten turvallinen asentaminen

Kun päivität MongoDB:tä tai taustalla olevaa Ubuntu-järjestelmää, noudata aina jäsenneltyä prosessia:

1. Varmuuskopioi tietosi ensin.

2. Pysäytä MongoDB-palvelu ennen ytimien tai kirjastojen päivityksiä:

   sudo systemctl stop mongod

3. Käytä päivitykset:

   sudo apt update && sudo apt upgrade -y

4. Käynnistä palvelu uudelleen ja varmista, että se toimii oikein:

   sudo systemctl start mongod
   
   sudo systemctl status mongod

Työkalut ennakoivaan ylläpitoon

Useita työkaluja helpottaa jatkuvaa ylläpitoa ja terveydentarkastuksia:

• MongoDB Compass: Graafinen käyttöliittymä tietojen ja suorituskykymittareiden visuaaliseen tarkasteluun.
• Atlas CLI: MongoDB Atlasin klustereiden, käyttäjien ja varmuuskopioiden hallintaan.
• Mongosh-skriptit: Mukautetut skriptit voivat automatisoida terveystarkastuksia tai luoda päivittäisiä raportteja yhteyksien määrästä ja levytilan käytöstä.
• Ansible Playbooks: Automaattiset asennukset, konfiguraation tarkastus ja varmuuskopiointiaikataulut.

Hätätilan palautustestaus

Viimeinen vaihe ylläpitosuunnittelussa on palautusmenetelmien testaaminen. Varmuuskopio on hyödyllinen vain, jos se palautuu oikein.

Vähintään kerran neljänneksessä:

1. Palauta viimeisin varmuuskopiosi välipalvelimelle.
2. Varmista, että hakemistot, käyttäjät ja käyttöoikeudet latautuvat oikein.
3. Mittaa palautumisaika varmistaaksesi, että se täyttää toipumisaikatavoitteesi (RTO).
4. Dokumentoi prosessi siten, että kuka tahansa ylläpitäjä voi suorittaa sen hätätilanteessa.

Pitkän aikavälin huoltolista

Noudattamalla näitä vianmääritys- ja ylläpitokäytäntöjä voit ylläpitää terveellistä MongoDB-asennusta Ubuntussa, joka säilyttää suorituskykynsä, turvallisuutensa ja kestävän toimintansa ajan myötä. Johdonmukainen seuranta ja ylläpito ovat huomattavasti edullisempia kuin toimintahäiriöstä tai tietojen menetyksestä toipuminen.

UKK

1. Miksi MongoDB:tä ei ole saatavilla Ubuntun oletusvarastoissa?

MongoDB poistettiin Ubuntun oletuspakettivarastoista version 18.04 jälkeen lisenssimuutosten vuoksi. MongoDB:n Server Side Public License (SSPL) ei ole Debianin ja Ubuntun projektien tunnustama avoimen lähdekoodin lisenssi. Tämän seurauksena Canonical ei enää jaa MongoDB:tä virallisissa pakettivarastoissaan, ja käyttäjien on asennettava se MongoDB:n omasta APT-varastosta.

2. Kuinka asennan MongoDB:n kokonaan uudelleen?

Poistaaksesi MongoDB:n ja kaikki siihen liittyvät tiedostot, suorita seuraavat komennot:

sudo systemctl stop mongod

sudo apt purge -y mongodb-org*

sudo rm -rf /var/lib/mongodb

sudo rm -rf /var/log/mongodb

sudo rm -f /etc/apt/sources.list.d/mongodb-org-*.list

sudo apt autoremove -y

Tämä pysäyttää MongoDB-palvelun, poistaa kaikki siihen liittyvät paketit, poistaa data- ja lokihakemistot sekä siivoaa arkistotiedon.

3. Miten tarkistan, onko MongoDB käynnissä?

Voit tarkistaa MongoDB-palvelun tilan käyttämällä:

sudo systemctl status mongod

Jos MongoDB on käynnissä, näet rivin, jossa lukee “Aktiivinen: aktiivinen (käynnissä)”. Vaihtoehtoisesti voit varmistaa yhteyden suorittamalla:

mongosh --eval "db.runCommand({ connectionStatus: 1 })"

Jos komento palauttaa "ok": 1, MongoDB on aktiivinen ja hyväksyy yhteyksiä.

4. Voiko MongoDB:n ajaa pienellä VPS:llä?

Kyllä, MongoDB voi toimia pienellä VPS:llä, mutta rajoituksin. Peruskehitykseen tai testauskuormiin riittää palvelin, jossa on 2 prosessoriydintä, 2 Gt RAM-muistia ja 10–20 Gt SSD-tallennustilaa.

Kuitenkin tuotantokäytössä MongoDB toimii parhaiten järjestelmissä, joissa on vähintään 4 suorittimen ydintä, 8 Gt RAM-muistia ja nopea SSD- tai NVMe-tallennustila. Vähäisen muistin ympäristöt saattavat vaatia WiredTiger-välimuistin koon säätämistä liiallisen sivutuksen estämiseksi.

5. Miksi MongoDB ei käynnisty korjausoperaation suorittamisen jälkeen?

MongoDB saattaa epäonnistua käynnistymään korjauksen jälkeen, jos korjausprosessi suoritettiin käyttäjänä root, jolloin tiedostojen omistajuus hakemistossa /var/lib/mongodb muuttuu käyttäjälle root:root. Koska mongod-palvelu toimii mongodb-käyttäjänä, sillä ei ole lupaa lukea tai muokata näitä tiedostoja. Korjataksesi tämän, varmista, että suoritat korjauskomennon mongodb-käyttäjänä tai palautat oikean omistajuuden sen jälkeen:

sudo chown -R mongodb:mongodb /var/lib/mongodb

6. Mistä voin tietää, kuunteleeko MongoDB oikeilla verkkoliitännöillä?

Voit tarkistaa MongoDB:n aktiiviset kuuntelijat käyttämällä:

sudo ss -tulpn | grep mongod

Tämä näyttää IP-osoitteet ja portit, joihin MongoDB on sidottu. Jos et näe odotettua IP-osoitetta (esimerkiksi sovelluspalvelimesi IP-osoitetta), tarkista bindIp-arvo tiedostossa /etc/mongod.conf ja käynnistä palvelu uudelleen.

7. Pitäisikö minun muuttaa MongoDB:n oletusarvoista WiredTiger-välimuistin kokoa?

Useimmissa tapauksissa ei. WiredTiger käyttää automaattisesti noin 50 % järjestelmän RAM-muistista ja säätää välimuistin käyttöä dynaamisesti käytettävissä olevan muistin perusteella. Säädä cacheSizeGB-asetusta vain, jos MongoDB jakaa palvelimen muiden muistikapasiteettia vaativien sovellusten kanssa. Omistetut MongoDB-palvelimet tulisi tyypillisesti säilyttää oletuskäytöksessä.

8. Miksi MongoDB-lokitiedostoni kasvavat niin suuriksi?

MongoDB kirjoittaa jatkuvasti operatiivisia tietoja lokitiedostoonsa /var/log/mongodb/mongod.log. Ilman lokin kiertoa tämä tiedosto voi kasvaa hyvin suureksi. Varmista, että sinulla on käytössä lokin kierto logrotate-työkalulla, kuten oppaan ylläpito-osiossa on kuvattu, jotta vanhat lokit pakataan tai poistetaan automaattisesti.

9. Milloin minun tulisi harkita lisää solmujen lisäämistä replikaatiosarjaani?

Sinun tulisi laajentaa replikaatioryhmääsi, kun huomaat jatkuvaa kasvua luku-liikenteessä, usein tapahtuvia solmuehdokkaita, replikaation viiveitä tai kun tarvitset korkeampaa saatavuutta useiden alueiden välillä. Toissijaisten solmujen lisääminen jakaa lukukuormaa ja parantaa vikasietoisuutta, erityisesti tuotantoympäristöissä.

10. Kuinka voin varmistaa, että TLS on otettu oikein käyttöön MongoDB-palvelimellani?

Kun TLS on määritetty tiedostossa /etc/mongod.conf, yhdistä käyttäen:

mongosh --tls --host <server-ip> -u admin -p --authenticationDatabase admin

Jos yhteys onnistuu, suorita:

openssl s_client -connect <server-ip>:27017

Kelvollinen TLS-kättely ja tiedot, kuten Protocol: TLSv1.3, vahvistavat, että salaus on käytössä.

Johtopäätös

MongoDB:n tehokas käyttö ei tarkoita pelkästään asennusta ja käyttöönottoa; kyse on suorituskyvyn, turvallisuuden ja luotettavuuden tasapainon ylläpitämisestä ajan myötä. Sinulla on nyt täysin toimiva MongoDB-järjestelmä, joka pystyy tukemaan tuotantotyökuormia, skaalautumaan kysynnän mukaan ja toipumaan odottamattomista virheistä.

Soveltamalla tämän oppaan periaatteita ja parhaita käytäntöjä, päivittäisestä seurannasta pitkän aikavälin kapasiteettisuunnitteluun, voit käyttää MongoDB:tä luottavaisin mielin missä tahansa ympäristössä. Olitpa sitten jatkamassa sen hallintaa itse tai siirtymässä hallittuun palveluun kuten MongoDB Atlas, ymmärryksesi MongoDB:n sisäisestä toiminnasta varmistaa, että pysyt aina datasi hallinnassa.

Lisätietoja tietokannoista saat seuraavista tutoriaaleista:

• Mitkä ovat eri tietokantatyypit? Selitetty käyttötapauksilla ja arkkitehtuureilla
• SQLite vs MySQL vs PostgreSQL: Relaatiotietokantajärjestelmien vertailu
• Kuinka asentaa Node.js Ubuntulle
• Kuinka päästä alkuun MERN-pinoon

Kiitos, että opiskelet Linux-Console.net-yhteisön kanssa.