1. [Strona główna](/) › 2. [Baza wiedzy](/baza-wiedzy/) › 3. MongoDB na VPS - instalacja # MongoDB na VPS - instalacja, konfiguracja i replica set Opublikowano: 10 kwietnia 2026 · Kategoria: VPS / Bazy danych ⚡ W skrócie · 8 min czytania - Instalacja MongoDB 7 na Ubuntu, konfiguracja mongod.conf (auth/TLS/bindIp), tworzenie użytkowników, replica set 3 węzły, backup mongodump, indeksy i explain(). - Instalacja MongoDB 7 na Ubuntu 22.04. - Konfiguracja mongod.conf - bezpieczeństwo i wydajność. - Tworzenie użytkowników i zarządzanie dostępem. - Replica Set - 3-węzłowy klaster z automatycznym failover. MongoDB to dokumentowa baza NoSQL, w której dane są przechowywane jako dokumenty BSON (Binary JSON). Zamiast tabel i wierszy masz kolekcje i dokumenty - każdy dokument może mieć inną strukturę, co daje ogromną elastyczność. Jest idealna do aplikacji z niejednorodną strukturą danych: katalogi produktów e-commerce, systemy CMS, IoT, logi zdarzeń. Ten artykuł przeprowadzi Cię przez instalację MongoDB 7 na Ubuntu, zabezpieczenie instancji, tworzenie użytkowników i konfigurację replica set dla wysokiej dostępności. ## Instalacja MongoDB 7 na Ubuntu 22.04 ``` # Importuj klucz GPG MongoDB curl -fsSL https://www.mongodb.org/static/pgp/server-7.0.asc | \ sudo gpg -o /usr/share/keyrings/mongodb-server-7.0.gpg --dearmor # Dodaj repozytorium MongoDB echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-7.0.gpg ] \ https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/7.0 multiverse" | \ sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list # Instalacja sudo apt update && sudo apt install -y mongodb-org # Uruchomienie i autostart sudo systemctl enable --now mongod sudo systemctl status mongod # Weryfikacja wersji mongod --version # db version v7.0.x ``` ## Konfiguracja mongod.conf - bezpieczeństwo i wydajność Domyślna konfiguracja MongoDB nasłuchuje na wszystkich interfejsach bez uwierzytelniania - to poważny błąd bezpieczeństwa. Poniżej kompletna konfiguracja dla VPS: ``` # /etc/mongod.conf storage: dbPath: /var/lib/mongodb wiredTiger: engineConfig: cacheSizeGB: 1 # 50% RAM domyslnie, zmniejsz na VPS 2GB systemLog: destination: file logAppend: true path: /var/log/mongodb/mongod.log logRotate: reopen net: port: 27017 bindIp: 127.0.0.1 # KRYTYCZNE: NIE 0.0.0.0 na produkcji! # Dla replica set dodaj: 127.0.0.1,10.0.0.1 (IP lokalne) security: authorization: enabled # ZAWSZE wlaczone na produkcji operationProfiling: slowOpThresholdMs: 100 # Loguj zapytania wolniejsze niz 100ms replication: replSetName: "rs0" # Tylko dla replica set ``` ## Tworzenie użytkowników i zarządzanie dostępem ``` # Polacz sie z mongoshellem (przed wlaczeniem auth) mongosh # Stworz uzytkownika administratora use admin db.createUser({ user: "adminUser", pwd: "TajneHaslo!123", roles: [ { role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase" ] }) # Wyjdz, uruchom mongod z auth i zaloguj sie exit mongosh -u adminUser -p --authenticationDatabase admin # Stworz uzytkownika aplikacji z ograniczonymi uprawnieniami use myapp_db db.createUser({ user: "appUser", pwd: "AppHaslo!456", roles: [ { role: "readWrite", db: "myapp_db" } ] }) # Weryfikacja uzytkownikow use admin db.system.users.find({}, {user: 1, roles: 1}).pretty() # String polaczenia dla aplikacji # mongodb://appUser:AppHaslo!456@127.0.0.1:27017/myapp_db ``` ## Replica Set - 3-węzłowy klaster z automatycznym failover Replica set to minimum, które należy wdrożyć w produkcji. Trzy węzły na trzech serwerach (lub jeden primary + dwa secondary na jednym VPS do testów) zapewniają automatyczny failover. Poniżej konfiguracja dla 3 VPS-ów z prywatnymi IP: ``` # Na KAZDYM z 3 wezlow: ustaw replSetName w mongod.conf # replication: # replSetName: "rs0" # net: # bindIp: 127.0.0.1,10.0.0.1 (IP prywatne tego wezla) # Na wezle PRIMARY (node1) - inicjalizuj replica set mongosh rs.initiate({ _id: "rs0", members: [ { _id: 0, host: "10.0.0.1:27017", priority: 2 }, { _id: 1, host: "10.0.0.2:27017", priority: 1 }, { _id: 2, host: "10.0.0.3:27017", priority: 1 } ] }) # Sprawdz status rs.status() # Szukaj: "stateStr": "PRIMARY" na jednym, "SECONDARY" na pozostalych # Sprawdz kto jest primary rs.isMaster() # lub: db.adminCommand({ isMaster: 1 }) # Testuj failover - zatrzymaj primary i obserwuj # sudo systemctl stop mongod (na node1) # rs.status() na node2/3 pokaze nowy PRIMARY po ~10s # Connection string z failover dla aplikacji: # mongodb://user:pass@10.0.0.1:27017,10.0.0.2:27017,10.0.0.3:27017/mydb?replicaSet=rs0 ``` ## Backup i restore - mongodump / mongorestore ``` # Backup calej instancji mongodump \ --uri="mongodb://adminUser:haslo@127.0.0.1:27017/?authSource=admin" \ --out=/backup/mongo-$(date +%Y%m%d) # Backup jednej bazy mongodump \ --uri="mongodb://appUser:haslo@127.0.0.1:27017/myapp_db" \ --out=/backup/myapp-$(date +%Y%m%d) # Kompresja mongodump --uri="..." --archive=/backup/mongo.gz --gzip # Restore mongorestore \ --uri="mongodb://adminUser:haslo@127.0.0.1:27017/?authSource=admin" \ --dir=/backup/mongo-20260410 # Restore z archiwum mongorestore \ --uri="mongodb://adminUser:haslo@127.0.0.1:27017/?authSource=admin" \ --archive=/backup/mongo.gz --gzip # Cron - codziennie o 3:00 # 0 3 * * * mongodump --uri="..." --archive=/backup/mongo-$(date +\%Y\%m\%d).gz --gzip # Czyszczenie po 7 dniach: # 0 4 * * * find /backup -name "mongo-*.gz" -mtime +7 -delete ``` ## Indeksy i optymalizacja zapytań z explain() ``` mongosh use myapp_db # Tworzenie indeksow db.users.createIndex({ email: 1 }, { unique: true }) db.orders.createIndex({ userId: 1, createdAt: -1 }) // indeks zlozony db.products.createIndex({ name: "text", description: "text" }) // full-text # Listowanie indeksow db.users.getIndexes() # Analiza zapytania - KLUCZOWE dla wydajnosci db.orders.find({ userId: "abc123" }).sort({ createdAt: -1 }).explain("executionStats") // Szukaj: "IXSCAN" (uzywa indeksu) vs "COLLSCAN" (pelny skan = wolno) // totalDocsExamined powinno byc bliskie nReturned // Znajdz wolne zapytania (profiler) db.setProfilingLevel(1, { slowms: 100 }) // loguj > 100ms db.system.profile.find().sort({ ts: -1 }).limit(5).pretty() // Statystyki kolekcji db.orders.stats() db.orders.totalIndexSize() ``` ## MongoDB vs PostgreSQL - kiedy co wybrać Kryterium MongoDB PostgreSQL Schemat danych Elastyczny (schemaless) Ściśle zdefiniowany Transakcje Od 4.0 (multi-document ACID) Pełne ACID od zawsze Skalowanie poziome Natywny sharding Citus lub partycjonowanie JOIN-y $lookup (wolniejsze) Natywne, wydajne Full-text search Wbudowany ($text) tsvector + GIN index Use case CMS, IoT, e-commerce, logi Finanse, ERP, relacyjne dane Licencja SSPL (ograniczenia cloud) PostgreSQL (permissive) ## Najczęstsze pytania Ile RAM potrzebuje MongoDB na VPS? + MongoDB z silnikiem WiredTiger domyślnie zajmuje do 50% dostępnej pamięci RAM dla cache. Dla instancji deweloperskiej wystarczy 1 GB RAM, dla produkcji z małą bazą - 2 GB RAM, dla aplikacji biznesowych - 4-8 GB RAM. Kluczowe jest to, żeby working set (często używane dane + indeksy) mieściło się w pamięci RAM. Jeśli working set przekracza RAM, MongoDB zaczyna intensywnie czytać z dysku, co dramatycznie obniża wydajność. Kiedy użyć MongoDB zamiast PostgreSQL? + MongoDB to dobry wybór gdy: schemat danych jest zmienny i trudny do zdefiniowania z góry (np. produkty e-commerce z różnymi atrybutami), dokumenty są naturalną jednostką danych (np. profile użytkowników, konfiguracje), potrzebujesz elastycznego skalowania przez sharding, budujesz system event sourcing lub logowania ze zmienną strukturą. PostgreSQL jest lepszy gdy: potrzebujesz silnych transakcji ACID z wieloma tabelami, dane są ściśle relacyjne, budujesz system finansowy lub ERP, potrzebujesz zaawansowanego SQL z JOIN-ami i window functions. Czym jest replica set w MongoDB i kiedy go używać? + Replica set to grupa węzłów MongoDB przechowujących tę samą kopię danych. Składa się z jednego primary (obsługuje zapisy) i jednego lub więcej secondary (mogą obsługiwać odczyty, służą jako failover). Replica set zapewnia: wysoką dostępność (jeśli primary padnie, jeden z secondary automatycznie staje się primary po maksymalnie 10 sekundach), redundancję danych i możliwość odczytu ze secondaries. Używaj replica set zawsze w produkcji - standalone MongoDB nie ma failover. Minimum 3 węzły (primary + 2 secondary lub primary + secondary + arbiter). Jak zabezpieczyć MongoDB przed atakami? + Kluczowe kroki zabezpieczenia MongoDB: (1) Włącz uwierzytelnianie - security.authorization: enabled w mongod.conf. (2) Zmień bindIp z 0.0.0.0 na 127.0.0.1 lub konkretne IP - MongoDB nie powinno być dostępne z internetu. (3) Użyj TLS/SSL dla połączeń szyfrowanych. (4) Stwórz osobnych użytkowników per baza z minimalnymi uprawnieniami (zasada least privilege). (5) Regularnie rób backup przez mongodump. (6) Monitoruj logi przez mongod.log. Tysiące instancji MongoDB zostało skompromitowanych przez brak uwierzytelniania i publiczny bindIp. ## Sprawdź oferty pasujące do tego scenariusza Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne. Contabo VPS z dużą ilością RAM dla MongoDB - working set w pamięci VPS + RAM [Aktywuj rabat →](/out/contabo/#reklama "Contabo") #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/contabo/) ProSerwer.pl Polski VPS pod MongoDB - zgodność z RODO i dane w Polsce Polski VPS [Aktywuj rabat →](/out/proserwer-pl/#reklama "ProSerwer.pl") #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/proserwer/) Mikr.us Budżetowy VPS do testów MongoDB standalone Dev/Test [Aktywuj rabat →](/out/mikrus/#reklama "Mikr.us") #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/mikrus/) ## Powiązane strony - [Ranking i porównanie VPS Aktualne ceny VPS z pełnym kosztem 2-letnim (TCO) i bez ukrytych opłat odnowienia. ](/vps/) - [PostgreSQL na VPS - instalacja i konfiguracja](/baza-wiedzy/postgresql-vps-instalacja-konfiguracja/) - [Redis Cluster - sharding danych](/baza-wiedzy/redis-cluster-konfiguracja/) - [Docker na VPS - instalacja i Compose](/baza-wiedzy/docker-na-vps/) - [Wszystkie artykuły](/baza-wiedzy/) - [CockroachDB - distributed SQL: PostgreSQL-compatible skalowalna baza CockroachDB: architektura multi-node, automatyczny sharding, kompatybilność PostgreSQL, geo-partitioning, backup S3.… ](/baza-wiedzy/cockroachdb-distributed-sql/) - [Nextcloud na VPS - instalacja z Nginx, PHP-FPM i PostgreSQL Nextcloud VPS krok po kroku: Nginx + PHP-FPM 8.2 + PostgreSQL, Redis cache i locking, occ CLI, aplikacje… ](/baza-wiedzy/nextcloud-instalacja-vps/) - [Jaki VPS wybrać?](/jaki-vps-wybrac/) Autor: [Redakcja HostGrade.pl](/autorzy/) Zespół redakcyjny · Aktualizacja: 10 kwietnia 2026 Artykuły HostGrade.pl przygotowuje i aktualizuje redakcja serwisu. Ceny startowe, ceny odnowienia i warunki planów sprawdzamy w cennikach i regulaminach dostawców, a potem liczymy całkowity koszt za 2 lata (cena startowa plus odnowienia). Zasady zbierania danych i liczenia kosztów opisujemy na stronie Metodologia. Linki partnerskie oznaczamy jako #reklama. [O redakcji i metodologii →](/autorzy/)