Cách Cài Đặt MongoDB trên Ubuntu

Giới thiệu

MongoDB là một trong những cơ sở dữ liệu NoSQL mã nguồn mở phổ biến nhất, được sử dụng rộng rãi cho các ứng dụng cần cấu trúc dữ liệu linh hoạt, khả năng mở rộng cao và hiệu suất nhanh. Nó lưu trữ dữ liệu dưới dạng tài liệu sử dụng các đối tượng giống JSON, điều này làm cho nó lý tưởng cho các khối lượng công việc hiện đại trên web, di động và phân tích. Các nhà phát triển ưa chuộng MongoDB nhờ vào lược đồ động, chia vùng tự động và các tính năng sao chép tích hợp sẵn, hỗ trợ cả mở rộng theo chiều ngang và khả năng cao. Khi kết hợp với tính ổn định và bảo mật của Ubuntu, MongoDB cung cấp một nền tảng vững chắc để chạy các ứng dụng sử dụng cơ sở dữ liệu một cách đáng tin cậy và hiệu quả.

Trong bài viết này, chúng tôi giải thích cách cài đặt, cấu hình và duy trì MongoDB 8.2 trên Ubuntu 24.04 LTS. Chúng tôi bao quát từng bước quan trọng, từ chuẩn bị máy chủ và kích hoạt các tính năng bảo mật đến tối ưu hóa hiệu suất, thiết lập sao chép và sao lưu, cũng như khắc phục các sự cố phổ biến. Cuối cùng, bạn sẽ có một triển khai MongoDB sẵn sàng cho sản xuất, được bảo mật, giám sát và điều chỉnh phù hợp cho sử dụng lâu dài. Dù bạn đang thiết lập MongoDB cho phát triển, thử nghiệm hay môi trường sản xuất đầy đủ, hướng dẫn này cung cấp các chỉ dẫn chi tiết và các thực hành vận hành tốt nhất cần thiết để vận hành nó hiệu quả.

Điều kiện tiên quyết

Để theo dõi hướng dẫn này, bạn sẽ cần:

• Một máy chủ chạy Ubuntu 24.04 LTS. Máy chủ này nên có một người dùng không phải root với quyền quản trị và UFW (Tường lửa Không phức tạp) được cài đặt và cấu hình. Tham khảo Hướng dẫn Thiết lập Máy chủ Ban đầu của chúng tôi với Ubuntu để thiết lập điều này.

Cài đặt MongoDB từ Kho chính thức

Ubuntu 24.04 bao gồm một phiên bản MongoDB trong kho gói mặc định của nó, nhưng thường đã lỗi thời. Đối với hệ thống sản xuất, bạn luôn nên cài đặt MongoDB trực tiếp từ kho chính thức của MongoDB. Điều này đảm bảo bạn nhận được phiên bản ổn định mới nhất (8.2 tại thời điểm viết bài) cùng với các bản cập nhật bảo mật và bảo trì kịp thời.

Hãy thêm kho lưu trữ MongoDB vào nguồn APT của hệ thống, nhập khóa GPG được sử dụng để xác minh các gói, sau đó cài đặt cơ sở dữ liệu.

1. Nhập Khóa GPG của MongoDB

APT sử dụng khóa GPG để xác minh tính xác thực của các gói. Nếu không có điều này, hệ thống của bạn sẽ không tin tưởng kho lưu trữ của MongoDB.

Chạy lệnh sau để nhập khóa công khai cho MongoDB 8.0:

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

Đây là những gì điều này làm:

• curl -fsSL nhẹ nhàng lấy khóa GPG từ các máy chủ chính thức của MongoDB.
• --dearmor chuyển khóa từ định dạng ASCII-armored sang định dạng keyring nhị phân tương thích với APT.
• Đầu ra được lưu tại /usr/share/keyrings/mongodb-server-8.0.gpg, một vị trí tiêu chuẩn cho các khóa tin cậy.

Nếu lệnh hoàn tất mà không có lỗi, key đã được thêm thành công.

2. Thêm Kho Lưu trữ MongoDB

Tiếp theo, tạo một tệp danh sách kho lưu trữ mới trỏ đến nguồn gói chính thức của MongoDB cho Ubuntu 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

Mỗi phần của lệnh này đều có một mục đích rõ ràng:

• deb cho APT biết đây là kho lưu trữ gói nhị phân (khác với deb-src cho mã nguồn).
• arch=amd64,arm64 giới hạn nó chỉ với các kiến trúc Intel/AMD và ARM 64-bit được MongoDB hỗ trợ.
• signed-by=... đảm bảo APT sử dụng khóa MongoDB cụ thể (đã thêm ở trên) để xác minh các bản tải xuống.
• https://repo.mongodb.org/apt/ubuntu là URL cơ sở của kho lưu trữ APT chính thức của MongoDB.
• noble/mongodb-org/8.2 chỉ định cả tên mã phát hành của Ubuntu (noble=Ubuntu 24.04) và phiên bản MongoDB (8.2).
• multiverse là phần thành phần của Ubuntu dành cho phần mềm của bên thứ ba.

3. Cập nhật chỉ mục gói của bạn

Sau khi thêm một kho lưu trữ mới, bạn phải làm mới danh sách gói cục bộ của hệ thống để APT nhận diện nguồn mới:

sudo apt update

APT sẽ tải xuống danh sách gói mới nhất và xác minh chúng bằng khóa GPG. Nếu bạn thấy MongoDB được liệt kê trong các kho lưu trữ, cấu hình của bạn là chính xác.

4. Cài đặt MongoDB

Bây giờ hãy cài đặt MongoDB và các công cụ liên quan:

sudo apt install -y mongodb-org

Cờ -y tự động xác nhận các thông báo cài đặt.

Điều này sẽ cài đặt một bộ các gói liên quan, bao gồm:

• mongodb-org-server: Chương trình nền máy chủ MongoDB (mongod), chịu trách nhiệm lưu trữ cơ sở dữ liệu và thực hiện các thao tác.
• mongodb-org-mongos: Bộ định tuyến sharding được sử dụng trong các triển khai phân tán.
• mongodb-org-shell: Trình khách dòng lệnh tương tác (mongosh) được sử dụng để kết nối với MongoDB.
• mongodb-org-tools: Công cụ sao lưu và khôi phục (mongodump, mongorestore, bsondump, v.v.).

Sau khi cài đặt, các tệp nhị phân sẽ được đặt dưới /usr/bin/, và các tệp cấu hình nằm trong /etc/mongod.conf.

5. Xác minh việc cài đặt

Bạn có thể xác minh rằng MongoDB 8.2 đã được cài đặt thành công bằng cách kiểm tra phiên bản của nó:

mongod --version

Bạn nên thấy một kết quả tương tự như sau:

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"
    }
}

Nếu bạn thấy điều này, MongoDB đã được cài đặt đúng cách và sẵn sàng để khởi động như một dịch vụ.

Khởi động và Quản lý Dịch vụ MongoDB

Khi bạn cài đặt MongoDB trên Ubuntu, gói phần mềm tự động bao gồm một đơn vị dịch vụ systemd có tên mongod.service. Sự tích hợp này cho phép MongoDB khởi động, dừng và khởi động lại một cách trơn tru bằng các lệnh quản lý dịch vụ tiêu chuẩn của Ubuntu, giống như Nginx, PostgreSQL hoặc bất kỳ daemon quan trọng nào khác.

Khởi động Dịch vụ MongoDB

Theo mặc định, MongoDB sẽ không tự động khởi động sau khi cài đặt. Để khởi động nó thủ công, hãy sử dụng lệnh sau:

sudo systemctl start mongod

Nếu lệnh chạy mà không có lỗi, dịch vụ bây giờ nên đang hoạt động. Bạn có thể xác nhận bằng:

sudo systemctl status mongod

Ví dụ kết quả:

● 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

Dòng “Active: active (running)” xác nhận rằng cơ sở dữ liệu đang hoạt động và hoạt động tốt.

Nếu thay vào đó bạn thấy “failed” hoặc “inactive”, hãy bỏ qua và đến phần Kiểm tra nhật ký MongoDB để khắc phục sự cố.

Bật MongoDB khởi động cùng máy

Hầu hết các hệ thống sản xuất yêu cầu cơ sở dữ liệu khởi động tự động sau khi khởi động lại. Để cho phép MongoDB khởi chạy khi bật máy, hãy chạy:

sudo systemctl enable mongod

Điều này tạo ra một liên kết tượng trưng trong /etc/systemd/system/multi-user.target.wants/, thông báo cho systemd tự động khởi động dịch vụ mỗi khi hệ thống vào chế độ đa người dùng (chế độ vận hành tiêu chuẩn cho các máy chủ).

Bạn có thể xác nhận thay đổi bằng:

systemctl is-enabled mongod

Kết quả dự kiến:

enabled

Nếu bạn muốn tắt khởi động tự động (để bảo trì hoặc thử nghiệm), hãy sử dụng:

sudo systemctl disable mongod

Xác minh hoạt động MongoDB

Khi MongoDB đang chạy, tốt nhất bạn nên xác nhận xem nó có phản hồi đúng cách hay không.

Chạy lệnh sau để kết nối với cơ sở dữ liệu và kiểm tra trạng thái kết nối của nó:

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

Lệnh này:

• Mở một phiên shell tạm thời (mongosh là shell MongoDB mới, thay thế cho client mongo cũ).
• Chạy lệnh connectionStatus trực tiếp trên phiên bản cục bộ.
• Hiển thị kết quả kết nối mà không yêu cầu bạn ở lại trong shell.

Ví dụ kết quả:

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

Một giá trị "ok": 1 xác nhận rằng máy chủ đang hoạt động bình thường và chấp nhận kết nối trên cổng 27017.

Quản lý Chu kỳ Dịch vụ MongoDB

Khi bạn đã xác nhận MongoDB đang chạy, sẽ rất hữu ích nếu biết cách quản lý nó một cách an toàn trong các hoạt động hàng ngày.

Đây là các lệnh chính:

sudo systemctl stop mongod

sudo systemctl start mongod

sudo systemctl restart mongod

sudo systemctl reload mongod

sudo systemctl disable mongod

sudo systemctl status mongod

Khởi động lại dịch vụ (restart) đặc biệt quan trọng sau khi chỉnh sửa /etc/mongod.conf. Điều này đảm bảo các thay đổi cấu hình của bạn được áp dụng.

Kiểm tra nhật ký MongoDB

Nếu MongoDB không khởi động được hoặc hoạt động bất thường, bước xử lý sự cố đầu tiên của bạn nên là kiểm tra các nhật ký.

Các bản ghi của MongoDB nằm tại:

/var/log/mongodb/mongod.log

Bạn có thể xem 20 dòng cuối cùng bằng:

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

Các thông điệp nhật ký phổ biến bao gồm:

• "Đang chờ kết nối trên cổng 27017": MongoDB đã khởi động thành công và sẵn sàng.
• "Thư mục dữ liệu /var/lib/mongodb không tìm thấy": Kiểm tra xem đường dẫn dữ liệu có tồn tại và có quyền truy cập đúng không.
• "Địa chỉ đã được sử dụng": Một tiến trình khác đang sử dụng cổng 27017.
• "Từ chối quyền truy cập": Đảm bảo người dùng MongoDB (mongodb) sở hữu các thư mục dữ liệu và nhật ký của nó.

Bạn cũng có thể sử dụng journalctl để xem nhật ký riêng của dịch vụ do systemd quản lý:

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

Kiểm tra MongoDB khi Khởi động Hệ thống

Thường xuyên kiểm tra việc MongoDB có tự động khởi động sau khi máy tính khởi động lại là điều tốt, đặc biệt là trước khi triển khai các ứng dụng.

Để khởi động lại, chạy:

sudo reboot

Sau khi máy chủ của bạn khởi động lại, đăng nhập lại và kiểm tra dịch vụ:

sudo systemctl status mongod

Nếu nó hiển thị “active (running)”, cấu hình của bạn là chính xác và bền vững.

Hiểu các thiết lập cấu hình của MongoDB

Khi bạn cài đặt MongoDB, hành vi của nó được điều khiển bởi một tệp cấu hình duy nhất nằm tại /etc/mongod.conf.

Tệp này định nghĩa cách MongoDB hoạt động: từ nơi lưu trữ dữ liệu, cách ghi nhật ký hoạt động, các địa chỉ IP mà nó lắng nghe, đến các cơ chế bảo mật đang hoạt động. Hiểu rõ tệp này là rất quan trọng, đặc biệt nếu bạn có kế hoạch chạy MongoDB trong môi trường sản xuất. Các thiết lập trong tệp này tương đương với các tùy chọn dòng lệnh tương ứng, nhưng sử dụng tệp cấu hình sẽ làm quản lý máy chủ trở nên đơn giản hơn, đặc biệt đối với các triển khai lớn hoặc tự động hóa.

Tổng quan về Tệp Cấu hình

Tệp cấu hình của MongoDB sử dụng cú pháp YAML, vốn nhạy cảm với thụt lề. Điều này có nghĩa là bạn phải dùng dấu cách (không phải tab) khi chỉnh sửa, ngay cả một dấu cách sai vị trí cũng có thể làm hỏng cấu hình.

Bạn có thể xem nội dung hiện tại của tệp bằng:

sudo cat /etc/mongod.conf

Tệp mặc định trông giống như sau:

# 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

Hãy phân tích điều này từng phần một.

Phần storage

Phần này định nghĩa nơi MongoDB lưu trữ dữ liệu của nó và cách nó quản lý ghi nhật ký (đảm bảo độ bền của dữ liệu).

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

• dbPath: Đây là thư mục nơi MongoDB lưu trữ cơ sở dữ liệu, các bộ sưu tập và chỉ mục của nó. Mặc định, nó trỏ tới /var/lib/mongodb. Nếu bạn thay đổi đường dẫn này, hãy đảm bảo thư mục tồn tại và thuộc sở hữu của người dùng mongodb:

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

• journal.enabled: Khi được đặt thành true, MongoDB duy trì một tệp nhật ký giúp phục hồi sau sự cố hoặc tắt máy đột ngột. Ghi nhật ký thực hiện việc ghi các thay đổi vào một bản ghi riêng trước khi cam kết vào các tệp dữ liệu, ngăn ngừa hư hại. Luôn giữ tính năng này bật cho các hệ thống sản xuất.

Phần systemLog

Điều này kiểm soát cách thức và vị trí MongoDB ghi nhật ký của nó.

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

• destination: Chỉ định nơi ghi nhật ký. Giá trị mặc định file ghi nhật ký vào một tệp; bạn có thể đổi thành syslog nếu muốn nhật ký MongoDB được tích hợp với nhật ký hệ thống của bạn.
• logAppend: Khi true, MongoDB sẽ thêm các mục nhật ký mới vào tệp hiện có thay vì ghi đè lên nó khi khởi động lại.
• path: Đường dẫn tuyệt đối của tệp nhật ký.

Bạn có thể xem nhật ký trực tiếp với:

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

Nếu nhật ký của bạn trở nên quá lớn, hãy cân nhắc bật luân phiên nhật ký bằng một công cụ như logrotate hoặc cấu hình nhật ký hệ thống của bạn để tự động luân phiên.

Phần net

Phần này định nghĩa cách MongoDB lắng nghe các kết nối mạng đến.

net:
  port: 27017
  bindIp: 127.0.0.1

• port: Cổng mặc định của MongoDB là 27017. Bạn có thể thay đổi điều này nếu bạn đang chạy nhiều dịch vụ cơ sở dữ liệu trên cùng một máy chủ.
• bindIp: Tham số này kiểm soát các giao diện mạng mà MongoDB lắng nghe.

Theo mặc định, nó bị giới hạn ở 127.0.0.1 (địa chỉ vòng lặp cục bộ), có nghĩa là chỉ chấp nhận các kết nối từ máy cục bộ. Đây là một cài đặt bảo mật quan trọng ngăn chặn truy cập từ xa cho đến khi bạn cho phép rõ ràng.

Nếu bạn dự định kết nối từ một máy khác (ví dụ, máy chủ web hoặc ứng dụng từ xa), bạn có thể sửa nó như sau:

bindIp: 127.0.0.1,192.168.1.100

Hoặc, để lắng nghe trên tất cả các giao diện (sử dụng thận trọng trong môi trường sản xuất):

bindIp: 0.0.0.0

Phần bảo mật

MongoDB được cài đặt với xác thực bị tắt theo mặc định. Bất kỳ ai có thể kết nối với cơ sở dữ liệu đều có thể đọc hoặc chỉnh sửa dữ liệu. Điều đó ổn cho việc thử nghiệm, nhưng là một mối đe dọa bảo mật đối với bất kỳ hệ thống thực nào. Để bật xác thực dựa trên người dùng, hãy thêm phần sau:

security:
  authorization: enabled

Khi tùy chọn này được bật, MongoDB sẽ yêu cầu người dùng xác thực bằng tên đăng nhập và mật khẩu trước khi thực hiện các thao tác.

Các cài đặt tùy chọn khác trong phần này bao gồm:

• keyFile: Được sử dụng cho các bộ sao chép để xác thực giữa các nút trong cụm.
• javascriptEnabled: Bật hoặc tắt việc thực thi JavaScript phía máy chủ (khuyến nghị để tắt trừ khi cần thiết).

Phần processManagement

Phần này điều khiển cách MongoDB quản lý tiến trình và thông tin thời gian chạy.

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

Điều này chủ yếu mang tính thông tin; nó đảm bảo rằng MongoDB có thể truy cập dữ liệu múi giờ để chuyển đổi dấu thời gian. Trong các triển khai nâng cao, bạn cũng có thể bật forking tại đây (cho hoạt động nền) nếu MongoDB được khởi động thủ công mà không dùng systemd.

Các mục replication và sharding (Tùy chọn)

Bạn sẽ không thấy các phần này trong một cài đặt mới, nhưng chúng được sử dụng trong các thiết lập nhiều nút hoặc phân tán.

Ví dụ về cách bật một bộ sao chép:

replication:
  replSetName: "rs0"

Điều này hướng dẫn MongoDB khởi động như một phần của bộ sao chép có tên rs0. Sau đó, bạn sẽ khởi tạo và thêm các thành viên từ bên trong shell của MongoDB.

Đối với phân mảnh:

sharding:
  clusterRole: "shardsvr"

Điều này xác định vai trò của nút trong một cụm phân mảnh.

Phần setParameter

Phần tùy chọn này cho phép bạn ghi đè các tham số chạy để tinh chỉnh hành vi của MongoDB.

Ví dụ :

setParameter:
  enableLocalhostAuthBypass: false

Đặt giá trị này thành false đảm bảo rằng ngay cả các kết nối từ localhost cũng yêu cầu xác thực. Các tham số khác có thể điều khiển thời gian chờ truy vấn, hành vi con trỏ hoặc ghi lại thông tin chẩn đoán.

Thực hiện và Áp dụng Thay đổi

Mỗi khi bạn chỉnh sửa /etc/mongod.conf, bạn cần khởi động lại MongoDB để các thay đổi có hiệu lực:

sudo systemctl restart mongod

Sau đó kiểm tra xem dịch vụ có đang chạy hay không:

sudo systemctl status mongod

Nếu MongoDB không thể khởi động lại, hãy kiểm tra các lỗi cú pháp (thường gặp lỗi thụt lề trong YAML) hoặc xem lại nhật ký:

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

Ví dụ: Cấu hình An toàn và Sẵn sàng cho Sản xuất

Dưới đây là một ví dụ về mongod.conf sạch, hướng tới môi trường sản xuất cho Ubuntu 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

Cấu hình này:

• Cho phép xác thực
• Sử dụng WiredTiger (bộ máy lưu trữ mặc định)
• Chỉ liên kết với các giao diện đáng tin cậy cụ thể
• Chuẩn bị phiên bản cho việc khởi tạo bộ sao chép
• Ghi lại tất cả các hoạt động vào một tệp nhật ký riêng

Bảo mật MongoDB

Sự linh hoạt của MongoDB khiến nó mạnh mẽ, nhưng cũng đồng nghĩa với việc một cấu hình không an toàn có thể dễ dàng dẫn đến việc lộ dữ liệu. Vào những ngày đầu của MongoDB, nhiều máy chủ được để mở trên internet mà không có xác thực, cho phép các kẻ tấn công liệt kê, sửa đổi hoặc thậm chí xóa cơ sở dữ liệu chỉ bằng cách kết nối tới cổng 27017.

Ngày nay, MongoDB được cung cấp với các thiết lập mặc định an toàn hơn, nhưng vẫn phụ thuộc vào bạn để thực thi xác thực, hạn chế mạng và mã hóa.

Bật Xác Thực

Theo mặc định, MongoDB khởi động với tính năng xác thực bị tắt. Điều đó có nghĩa là bất kỳ ai có thể kết nối với cơ sở dữ liệu đều có thể chạy các lệnh quản trị, xóa các bộ sưu tập, hoặc chỉnh sửa dữ liệu mà không bị hạn chế. Để ngăn chặn điều này, MongoDB sử dụng một hệ thống Kiểm soát truy cập dựa trên vai trò (RBAC) mà bạn phải bật một cách rõ ràng.

1. Mở tệp cấu hình MongoDB:

   sudo nano /etc/mongod.conf

2. Tìm phần security, hoặc tạo một phần nếu nó chưa tồn tại:

   security:
     authorization: enabled

3. Lưu và thoát (Ctrl+O, rồi Ctrl+X).

4. Khởi động lại MongoDB để thay đổi có hiệu lực:

   sudo systemctl restart mongod

MongoDB cung cấp một lỗ hổng tạm thời để vượt qua xác thực localhost trên một triển khai mới để người dùng quản trị đầu tiên có thể được tạo. Lỗ hổng này sẽ tự động bị vô hiệu hóa khi đã có người dùng quản trị hoặc nếu một số cài đặt bảo mật nhất định (như keyFile hoặc clusterAuthMode) được bật.

Điều đó có nghĩa là bạn có thể tạo người dùng quản trị đầu tiên một cách an toàn trước khi việc thực thi đầy đủ bắt đầu.

Tạo Người Dùng Quản Trị Đầu Tiên

Người dùng quản trị là nền tảng của hệ thống xác thực của MongoDB. Người dùng này có quyền tạo người dùng khác, định nghĩa các vai trò và cấp quyền truy cập cho các cơ sở dữ liệu cụ thể.

Để tạo tài khoản này:

1. Bắt đầu một shell MongoDB cục bộ:

   mongosh

2. Chuyển sang cơ sở dữ liệu admin, nơi lưu trữ thông tin đăng nhập của người dùng và định nghĩa vai trò:

   use admin

3. Tạo người dùng bằng lệnh sau:

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

   Hãy phân tích điều này:

   • userAdminAnyDatabase cho phép người dùng này tạo, sửa đổi và xóa người dùng trên tất cả các cơ sở dữ liệu.
   • readWriteAnyDatabase cung cấp quyền đọc và ghi trên toàn hệ thống. (Bạn có thể bỏ qua điều này nếu muốn tạo người dùng chỉ dành cho quản trị viên nghiêm ngặt.)

   Lệnh này ghi một tài liệu mới vào collection system.users trong cơ sở dữ liệu admin của MongoDB. Bạn có thể xác minh điều này bằng cách liệt kê người dùng sau đó:

   show users

4. Thoát khỏi shell:

   exit

5. Kết nối lại với tư cách là người dùng quản trị để xác nhận rằng việc xác thực hiện đã được thực thi:

   mongosh -u admin -p --authenticationDatabase admin

Khi đã xác thực, bạn có thể chạy các lệnh quản trị như:

show dbs

Nếu MongoDB yêu cầu mật khẩu và chỉ cấp quyền truy cập sau khi xác thực, RBAC đang hoạt động đúng cách.

Tạo người dùng theo vai trò cho ứng dụng

Trong môi trường sản xuất, ứng dụng của bạn không bao giờ nên sử dụng tài khoản quản trị. Thay vào đó, hãy tạo người dùng riêng cho từng ứng dụng, mỗi người chỉ có các quyền cần thiết.

Ví dụ, để tạo một người dùng cho một ứng dụng web quản lý dữ liệu trong một cơ sở dữ liệu cụ thể:

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

• readWrite cho phép ứng dụng thực hiện tất cả các thao tác CRUD tiêu chuẩn (chèn, truy vấn, cập nhật, xóa) chỉ trên cơ sở dữ liệu này.
• Nó không thể tạo người dùng khác, sửa đổi các bộ sưu tập hệ thống hoặc truy cập các cơ sở dữ liệu khác.

Bạn có thể liệt kê tất cả người dùng cho một cơ sở dữ liệu bằng:

show users

Hạn chế truy cập mạng

Ngay cả khi đã kích hoạt xác thực, việc để MongoDB trực tiếp ra Internet là rất nguy hiểm. Các công cụ quét tự động thường xuyên tìm kiếm các cổng mở (đặc biệt là 27017, cổng mặc định của MongoDB) và cố gắng thực hiện các cuộc tấn công brute-force hoặc khai thác các phiên bản cấu hình sai.

Theo mặc định, MongoDB chỉ lắng nghe trên 127.0.0.1, tức là giao diện cục bộ. Nếu ứng dụng của bạn và máy chủ MongoDB cùng chạy trên một máy, bạn không cần thay đổi gì. Tuy nhiên, nếu ứng dụng của bạn kết nối từ xa, bạn sẽ cần phải thêm rõ ràng các địa chỉ IP cụ thể vào danh sách trắng.

1. Chỉnh sửa tệp cấu hình:

   sudo nano /etc/mongod.conf

2. Xác định phần net và cập nhật nó:

   net:
     port: 27017
     bindIp: 127.0.0.1,192.168.10.50

   Thay thế 192.168.10.50 bằng địa chỉ IP của máy chủ ứng dụng mà bạn tin cậy. Điều này đảm bảo MongoDB chỉ chấp nhận kết nối từ localhost và máy chủ từ xa cụ thể đó.

3. Khởi động lại dịch vụ để áp dụng các thay đổi:

   sudo systemctl restart mongod

4. Xác nhận các liên kết đang hoạt động:

   sudo ss -tulpn | grep mongod

Bạn nên thấy MongoDB đang lắng nghe trên cả 127.0.0.1:27017 và địa chỉ IP bạn đã chỉ định.

Cấu hình Tường lửa của Ubuntu (UFW)

Ngay cả khi MongoDB chỉ lắng nghe trên một số giao diện nhất định, tốt nhất là nên củng cố bảo mật mạng ở cấp hệ điều hành.

UFW của Ubuntu cung cấp một cách dễ dàng để kiểm soát các kết nối đến và đi.

1. Kiểm tra xem UFW đã được cài đặt và đang hoạt động:

   sudo ufw status

   Nếu nó hiển thị là không hoạt động, hãy bật nó lên:

   sudo ufw enable

2. Chỉ cho phép kết nối MongoDB từ các IP đáng tin cậy. Ví dụ, nếu IP của máy chủ ứng dụng của bạn là 192.168.10.50:

   sudo ufw allow from 192.168.10.50 to any port 27017

3. Kiểm tra xem quy tắc đã được thêm chưa:

   sudo ufw status numbered

   Bạn nên thấy một mục cho phép cổng 27017 từ nguồn đã chỉ định.

4. Tùy chọn, từ chối tất cả các lưu lượng khác đến MongoDB một cách rõ ràng:

   sudo ufw deny 27017/tcp

Sự kết hợp này, bindIp trong cấu hình MongoDB và các quy tắc UFW chọn lọc, đảm bảo rằng chỉ các hệ thống đã biết mới có thể truy cập cơ sở dữ liệu của bạn, ngay cả khi các tiến trình khác cố gắng mở nó ra.

Bật mã hóa TLS/SSL

Cho đến nay, bạn đã đảm bảo rằng chỉ những người dùng và địa chỉ IP đáng tin cậy mới có thể truy cập MongoDB. Bước tiếp theo là bảo mật dữ liệu đang truyền.

Khi một khách hàng kết nối với MongoDB, tất cả dữ liệu (bao gồm thông tin xác thực và các truy vấn) được truyền dưới dạng văn bản thuần theo mặc định. TLS mã hóa dữ liệu này, ngăn chặn việc nghe trộm hoặc giả mạo.

Tạo hoặc Lấy Chứng Chỉ

Trong môi trường sản xuất, hãy sử dụng chứng chỉ từ một Cơ quan chứng thực (CA) đáng tin cậy. Đối với thử nghiệm hoặc triển khai nội bộ, bạn có thể tạo chứng chỉ tự ký:

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)"

Điều này tạo ra:

• mongodb.crt: chứng chỉ công khai
• mongodb.key: khóa riêng

Kết hợp chúng thành một tệp PEM duy nhất (bắt buộc cho MongoDB):

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

Những quyền này đảm bảo chỉ người dùng mongodb mới có thể truy cập tệp khóa.

Cập nhật Tệp Cấu hình

Chỉnh sửa /etc/mongod.conf và tìm đến phần net. Thêm một khối tls mới bên dưới nó:

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

• mode: requireTLS có nghĩa là MongoDB sẽ từ chối bất kỳ kết nối nào không được mã hóa.
• certificateKeyFile chỉ định đường dẫn tới tệp PEM kết hợp.

Khởi động lại MongoDB để áp dụng thay đổi:

sudo systemctl restart mongod

Kết nối bằng TLS

Khi kết nối với mongosh, bạn bây giờ phải chỉ định tùy chọn --tls:

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

Nếu kết nối thành công và lời nhắc xuất hiện, cấu hình TLS của bạn đang hoạt động đúng.

Bạn có thể xác minh mã hóa bằng cách kiểm tra kết nối sử dụng OpenSSL:

openssl s_client -connect 192.168.10.50:27017

Đầu ra nên hiển thị chuỗi chứng chỉ và chi tiết mã hóa, ví dụ:

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

Điều này xác nhận rằng máy chủ MongoDB của bạn hiện đang mã hóa lưu lượng truy cập từ đầu đến cuối.

Xác minh Tư thế Bảo mật của Bạn

Khi mọi thứ đã được cấu hình xong, đáng để kiểm tra lại thiết lập của bạn một lần nữa.

1. Kiểm tra rằng MongoDB chỉ được liên kết với các IP được phép:

   sudo ss -tulpn | grep mongod

   Bạn nên chỉ xem các kết nối giới hạn ở 127.0.0.1 và các địa chỉ IP đáng tin cậy của bạn.

2. Đảm bảo xác thực được thực thi. Thử kết nối mà không có thông tin đăng nhập:

   mongosh

   Bạn nên nhận được thông báo lỗi xác thực.

3. Xác nhận rằng TLS là bắt buộc. Thử kết nối mà không sử dụng --tls:

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

   Nếu kết nối thất bại kèm theo thông báo về yêu cầu TLS, điều đó có nghĩa là mã hóa của bạn được áp dụng đúng.

4. Xem xét các tham số bảo mật nội bộ của MongoDB:

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

   Nếu tlsMode trả về "requireTLS", điều đó xác nhận rằng mã hóa đang được kích hoạt.

Với việc cấu hình xác thực, kiểm soát truy cập, hạn chế mạng và TLS, phiên bản MongoDB của bạn giờ đây đã được bảo mật chống lại các phương thức tấn công phổ biến nhất.

Thực hành tốt nhất trong vận hành

Khi MongoDB đã được cài đặt và bảo mật, ưu tiên lớn tiếp theo là duy trì nó một cách hiệu quả. Ngay cả cơ sở dữ liệu được cấu hình cẩn thận nhất cũng có thể trở nên không đáng tin cậy nếu không được bảo trì thường xuyên. Các hoạt động định kỳ như sao lưu, giám sát và cập nhật hệ thống đảm bảo rằng MongoDB vẫn hoạt động hiệu quả, ổn định và có thể khôi phục theo thời gian.

Sao lưu dữ liệu MongoDB

Một chiến lược sao lưu được lên kế hoạch tốt là nền tảng cho bất kỳ cơ sở dữ liệu sản xuất nào. Sao lưu giúp bạn khôi phục nhanh chóng từ các sự cố phần cứng, lỗi phần mềm hoặc xóa nhầm. MongoDB hỗ trợ cả sao lưu logic và vật lý, mỗi loại phù hợp với các tình huống khác nhau.

Sao lưu Logic Sử dụng mongodump

Sao lưu logic ghi lại nội dung cơ sở dữ liệu ở định dạng BSON bằng tiện ích mongodump. Phương pháp này có thể di chuyển được, dễ đọc bởi con người và dễ tự động hóa.

Để tạo bản sao lưu đầy đủ của tất cả các cơ sở dữ liệu, hãy chạy:

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

Lệnh này tạo một thư mục có tên theo ngày hiện tại dưới /backups/mongodb/ và lưu tất cả các bản sao lưu BSON bên trong đó.

Nếu xác thực được bật, hãy sử dụng chuỗi kết nối URI có bao gồm thông tin đăng nhập:

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

Bạn cũng có thể sao lưu một cơ sở dữ liệu cụ thể:

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

Để khôi phục từ bản sao lưu logic, hãy sử dụng mongorestore:

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

Hoặc khôi phục một cơ sở dữ liệu duy nhất:

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

Sao lưu logic linh hoạt và dễ viết script, nhưng chúng có thể mất nhiều thời gian hơn để hoàn thành đối với các bộ dữ liệu rất lớn.

Sao lưu vật lý (Ảnh chụp hệ thống tệp)

Sao lưu vật lý ghi lại các tệp cơ sở dữ liệu trực tiếp từ ổ lưu trữ. Phương pháp này nhanh hơn và tiết kiệm không gian hơn cho các cơ sở dữ liệu lớn, nhưng nó yêu cầu các bản chụp nhất quán để tránh hỏng dữ liệu.

Nếu bạn sử dụng ghi nhật ký (mặc định được bật), bạn có thể chụp ảnh nhanh các ổ đĩa trong khi MongoDB đang chạy. WiredTiger hỗ trợ các ảnh chụp nhất quán khi xảy ra sự cố trong khi MongoDB đang chạy, miễn là ghi nhật ký được bật. Đối với các ảnh chụp nhất quán toàn bộ ứng dụng, việc dừng MongoDB được khuyến nghị nhưng không bắt buộc:

sudo systemctl stop mongod

Chụp ảnh nhanh bằng nhà cung cấp đám mây hoặc hệ thống lưu trữ của bạn và khởi động lại dịch vụ:

sudo systemctl start mongod

Lưu các ảnh chụp nhanh ở một nơi ngoài trụ sở hoặc khu vực riêng biệt bất cứ khi nào có thể. Điều này giúp bảo vệ chống lại sự cố trung tâm dữ liệu hoặc xóa nhầm dữ liệu tại chỗ.

Giám sát sức khỏe MongoDB

Giám sát là rất quan trọng để ngăn ngừa các vấn đề trước khi chúng ảnh hưởng đến người dùng. MongoDB cung cấp các công cụ dòng lệnh tích hợp sẵn cũng như hỗ trợ các hệ thống giám sát bên ngoài.

Sử dụng Công cụ Tích hợp

Công cụ mongostat hiển thị các số liệu cơ sở dữ liệu trực tiếp như số thao tác trên giây, mức sử dụng bộ nhớ và các kết nối đang hoạt động. Chạy nó như sau:

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

Điều này tạo ra một bảng thời gian thực hiển thị các thao tác chèn, truy vấn, cập nhật và xóa. Mỗi cột đại diện cho một chỉ số hiệu suất chính, chẳng hạn như tỷ lệ các trang bộ nhớ bẩn hoặc số lượng kết nối đang hoạt động.

Tiện ích mongotop tập trung vào thời gian MongoDB dành để đọc và ghi trên mỗi bộ sưu tập. Để chạy nó mỗi hai giây, hãy sử dụng:

mongotop 2

Điều này hữu ích để xác định các bộ sưu tập thường gặp phải I/O nặng.

Sử dụng Công cụ Giám sát Bên ngoài

Để có khả năng hiển thị và cảnh báo liên tục, bạn có thể tích hợp MongoDB với các hệ thống bên ngoài như:

• Giám sát MongoDB Atlas, ngay cả đối với các cụm tự lưu trữ.
• Prometheus và Grafana, sử dụng MongoDB Exporter cho các bảng điều khiển theo chuỗi thời gian.
• Percona Monitoring and Management (PMM), một bộ công cụ giám sát mã nguồn mở đầy đủ.
• Các công cụ hệ thống chung như Netdata, Zabbix hoặc Datadog.

Các chỉ số quan trọng cần theo dõi bao gồm:

• Sử dụng bộ nhớ và tỷ lệ truy cập bộ nhớ đệm
• Độ trễ và thông lượng I/O của ổ đĩa
• Số lượng kết nối và độ dài hàng đợi
• Độ trễ thao tác (thời gian chèn, cập nhật, truy vấn)
• Độ trễ bản sao (nếu đang chạy bộ bản sao)

Quản lý Dung lượng Ổ đĩa và Tăng trưởng Lưu trữ

Cơ sở dữ liệu MongoDB mở rộng một cách động khi các tài liệu và chỉ mục tăng lên. Nếu việc sử dụng đĩa không được kiểm soát, cơ sở dữ liệu có thể hết dung lượng, dẫn đến khóa hoặc bị lỗi.

Kiểm tra dung lượng đĩa

Kiểm tra việc sử dụng hệ thống tệp hiện tại bằng:

df -h /var/lib/mongodb

Điều này hiển thị không gian khả dụng và đã sử dụng cho thư mục dữ liệu của MongoDB.

Bạn cũng có thể kiểm tra việc sử dụng bộ nhớ và bộ nhớ đệm thông qua chính MongoDB:

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

Giá trị bytes currently in the cache cho biết lượng RAM mà engine lưu trữ WiredTiger đang sử dụng.

Thiết lập cảnh báo sử dụng đĩa

Để duy trì tính chủ động, hãy thiết lập cảnh báo hoặc kiểm tra giám sát thông báo cho bạn khi mức sử dụng đĩa vượt quá 85%. Ví dụ, một tập lệnh đơn giản có thể được lập lịch để chạy định kỳ:

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

Bạn có thể tích hợp điều này vào các bộ hẹn giờ systemd hoặc công cụ giám sát để tự động hóa.

Quản lý Dữ liệu và Nhật ký Cũ

Các bộ sưu tập lớn hoặc không sử dụng và các tệp nhật ký có thể chiếm nhiều dung lượng theo thời gian. Để quản lý nhật ký, cấu hình xoay vòng trong /etc/logrotate.d/mongodb (như được trình bày sau trong phần này) hoặc dọn dẹp thủ công:

sudo journalctl --vacuum-time=7d

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

Đối với dữ liệu ứng dụng, hãy cân nhắc sử dụng chỉ mục TTL (thời gian tồn tại) cho các bộ sưu tập lưu trữ dữ liệu tạm thời hoặc nhạy cảm với thời gian:

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

Điều này sẽ tự động xóa các tài liệu có tuổi đời hơn bảy ngày.

Thực hiện nâng cấp an toàn

Nâng cấp MongoDB đòi hỏi phải lập kế hoạch cẩn thận, đặc biệt khi chuyển giữa các phiên bản chính. Quy trình sau đây giúp giảm thời gian ngưng hoạt động và đảm bảo tính tương thích.

Kiểm tra Phiên bản Hiện tại

Xác nhận phiên bản đã cài đặt:

mongod --version

Sao lưu trước khi nâng cấp

Luôn tạo một bản sao lưu đầy đủ trước khi nâng cấp:

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

Cập nhật kho gói và nâng cấp

Nếu trước đây bạn đã khóa các gói MongoDB để ngăn tự động cập nhật, hãy gỡ bỏ các khóa:

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

Sau đó cập nhật danh sách gói và nâng cấp MongoDB:

sudo apt update

sudo apt install -y mongodb-org

MongoDB giữ lại các tệp cấu hình và dữ liệu của bạn trong quá trình nâng cấp, nhưng việc sao lưu đảm bảo bạn có thể khôi phục nếu có sự cố xảy ra.

Xác nhận việc nâng cấp

Sau khi nâng cấp:

1. Xác minh trạng thái dịch vụ:

   sudo systemctl status mongod

2. Kiểm tra các bản ghi gần đây để xem cảnh báo hoặc ghi chú di chuyển:

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

3. Xác nhận phiên bản mới:

   mongosh --eval "db.version()"

Tự động hóa công việc bảo trì thường xuyên

Việc bảo trì thủ công phù hợp với các môi trường nhỏ, nhưng tự động hóa đảm bảo tính nhất quán. Bạn có thể lên lịch sao lưu định kỳ, xoay vòng nhật ký hoặc kiểm tra giám sát bằng cách sử dụng cron hoặc systemd timers.

Lên lịch sao lưu tự động

Chỉnh sửa crontab của root:

sudo crontab -e

Thêm dòng sau để sao lưu cơ sở dữ liệu MongoDB của bạn mỗi đêm lúc 2 giờ sáng:

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

Điều này tạo ra một thư mục sao lưu có ngày mỗi ngày.

Cấu hình Xoay nhật ký

Để ngăn các tệp nhật ký chiếm dung lượng đĩa, hãy tạo một tệp cấu hình xoay vòng nhật ký:

sudo nano /etc/logrotate.d/mongodb

Thêm nội dung sau:

/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
}

Cấu hình này giữ lại năm tuần nhật ký, nén các tệp cũ hơn và nạp lại MongoDB sau khi luân phiên.

Duy trì thời gian hệ thống chính xác

Các tính năng ghi nhật ký và sao chép của MongoDB phụ thuộc vào dấu thời gian chính xác. Nếu đồng hồ hệ thống bị trôi, tình trạng trễ sao chép hoặc hỏng nhật ký có thể xảy ra sau khi hệ thống bị sự cố.

Ubuntu 24.04 mặc định sử dụng systemd-timesyncd, nhưng bạn cũng có thể sử dụng chrony để đồng bộ thời gian chính xác hơn:

sudo apt install chrony -y

sudo systemctl enable --now chrony

Bạn có thể xác minh việc đồng bộ hóa bằng:

timedatectl status

Nếu NTP synchronized hiển thị là yes, đồng hồ hệ thống của bạn đang được đồng bộ.

Kiểm tra sức khỏe MongoDB theo thời gian thực

MongoDB cung cấp lệnh serverStatus để chẩn đoán toàn diện thời gian chạy. Bạn có thể truy vấn trực tiếp từ shell:

mongosh --eval "db.serverStatus()"

Điều này trả về một đối tượng JSON chi tiết chứa các chỉ số như:

• Tiêu thụ bộ nhớ
• Sử dụng bộ nhớ đệm
• Số lượng kết nối
• Thông lượng hoạt động
• Trạng thái sao chép

Bạn có thể trích xuất các trường cụ thể để kiểm tra mục tiêu. Ví dụ, để xem thống kê kết nối:

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

Điều này cho phép nhận biết nhanh chóng liệu hệ thống có đang gặp tình trạng bão hòa kết nối hay giới hạn về tài nguyên hay không.

Chuẩn bị cho tính khả dụng cao

Triển khai MongoDB trên một nút đơn hoạt động tốt cho phát triển hoặc các ứng dụng không quan trọng. Đối với môi trường sản xuất, bạn nên triển khai replica sets. Replica sets cung cấp khả năng dự phòng và tự động chuyển đổi khi xảy ra sự cố, đảm bảo tính khả dụng ngay cả khi một nút gặp sự cố.

Trong một thiết lập điển hình:

• Một nút hoạt động như chính, xử lý tất cả các thao tác ghi và hầu hết các thao tác đọc.
• Một hoặc nhiều nút phụ sao chép dữ liệu theo thời gian thực.
• Nếu nút chính bị ngắt kết nối, một trong các nút phụ sẽ tự động trở thành nút chính mới.

Các bộ sao chép cũng đơn giản hóa các nhiệm vụ bảo trì như sao lưu và mở rộng. Bạn có thể chuyển các tác vụ sao lưu hoặc truy vấn phân tích sang các nút phụ mà không ảnh hưởng đến hiệu suất của nút chính.

Phiên bản MongoDB của bạn hiện đã hoạt động đầy đủ và được duy trì đúng cách.

Tối ưu hóa hiệu suất và mở rộng

MongoDB được thiết kế để mở rộng theo chiều ngang, nghĩa là bạn có thể tăng công suất và hiệu suất bằng cách thêm nhiều máy chủ thay vì chỉ dựa vào một máy mạnh hơn. Khi dữ liệu của bạn tăng lên hoặc ứng dụng của bạn bắt đầu xử lý nhiều truy vấn đồng thời hơn, việc mở rộng giúp MongoDB tiếp tục hoạt động một cách đáng tin cậy và hiệu quả.

Có hai cách chính để mở rộng MongoDB:

1. Bộ sao chép, giúp tăng độ tin cậy và hiệu năng đọc thông qua tính dư thừa.
2. Sharding, phân bố dữ liệu trên nhiều máy chủ để xử lý các bộ dữ liệu lớn hơn và tải ghi cao hơn.

Hiểu về Replica Set

Một bộ sao chép là một nhóm các máy chủ MongoDB duy trì các bản sao giống hệt dữ liệu của bạn. Bộ sao chép cung cấp khả năng sẵn sàng cao và bảo vệ chống lại sự cố phần cứng hoặc mạng. Nếu nút chính gặp sự cố, một trong các nút phụ sẽ tự động tiếp quản, đảm bảo thời gian gián đoạn tối thiểu.

Một bộ bản sao chuẩn bao gồm:

• Một nút chính xử lý tất cả các hoạt động ghi.
• Hai nút phụ trở lên sao chép dữ liệu từ nút chính.
• Các nút trọng tài tùy chọn tham gia bầu cử nhưng không lưu trữ dữ liệu.

Đối với các hệ thống sản xuất, MongoDB khuyến nghị ít nhất ba thành viên trong một bộ sao chép.

Cấu hình một Replica Set

Để tạo một replica set, bạn cần ít nhất hai hoặc ba máy chủ (vật lý hoặc ảo). Mỗi nút nên được cài đặt và cấu hình MongoDB.

1. Trên mỗi nút, mở tệp cấu hình /etc/mongod.conf và thêm phần sao chép:

   replication:
     replSetName: "rs0"

2. Khởi động lại MongoDB trên mỗi máy chủ:

   sudo systemctl restart mongod

3. Trên nút chính, kết nối với MongoDB và khởi tạo bộ sao chép:

   mongosh

   Sau đó chạy:

   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. Xác minh trạng thái:

   rs.status()

   Đầu ra sẽ hiển thị một máy chủ chính và hai máy chủ phụ có trạng thái được gắn nhãn là 'CHÍNH CHÍNH' và 'THỨ CẤP'.

Lợi ích của các bộ sao chép

Các bộ sao chép mang lại một số lợi ích quan trọng:

• Khả năng cao sẵn có: Chuyển đổi dự phòng tự động đảm bảo hoạt động liên tục nếu nút chính bị ngắt kết nối.
• Dữ liệu dư thừa: Mỗi nút duy trì một bản sao đầy đủ của dữ liệu.
• Khả năng mở rộng đọc: Các nút phụ có thể xử lý các thao tác đọc, giảm tải cho nút chính.
• Tính linh hoạt trong bảo trì: Bạn có thể thực hiện sao lưu hoặc cập nhật hệ thống trên các nút phụ mà không ảnh hưởng đến khả năng sẵn sàng.

Hiểu về Sharding

Sharding là chiến lược mở rộng theo chiều ngang của MongoDB. Khi một tập dữ liệu trở nên quá lớn để một máy chủ đơn lẻ có thể lưu trữ hoặc xử lý hiệu quả, MongoDB có thể chia nó thành các phần nhỏ hơn được phân phối trên nhiều máy chủ gọi là các shard.

Mỗi mảnh giữ một phần dữ liệu, và cụm máy chủ hoạt động như một cơ sở dữ liệu logic duy nhất.

Các thành phần của một cụm Sharded

Một cụm MongoDB phân mảnh điển hình bao gồm:

• Shards: Các nút chứa dữ liệu, thường được triển khai dưới dạng bộ sao chép để dự phòng.
• Máy chủ cấu hình: Lưu trữ siêu dữ liệu và cấu hình cụm, bao gồm phân phối phân đoạn.
• Bộ định tuyến Mongos: Chuyển các truy vấn của khách hàng đến phân mảnh chính xác dựa trên khóa phân mảnh.

Chọn Khóa Shard

Khóa phân mảnh xác định cách MongoDB phân phối dữ liệu trên các phân mảnh. Một khóa phân mảnh được chọn kém có thể dẫn đến phân phối dữ liệu không đều (được gọi là lệch dữ liệu) hoặc các điểm nóng.

Các khóa phân mảnh tốt thường có:

• Độ đa dạng cao (nhiều giá trị duy nhất).
• Ngay cả các mô hình truy cập dữ liệu.
• Một mẫu truy vấn dễ dự đoán bao gồm khóa phân mảnh trong hầu hết các truy vấn.

Ví dụ về việc bật sharding cho cơ sở dữ liệu:

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

Lệnh này kích hoạt sharding trên cơ sở dữ liệu salesdb và phân mảnh bộ sưu tập orders bằng cách sử dụng trường customer_id.

Khi nào nên sử dụng Sharding

Bạn nên cân nhắc việc phân mảnh khi:

• Cơ sở dữ liệu đang tiếp cận hoặc vượt quá giới hạn dung lượng lưu trữ của một máy chủ đơn.
• Thông lượng ghi liên tục đạt mức tối đa CPU hoặc I/O đĩa.
• Tập hợp dữ liệu làm việc không còn vừa với RAM, gây ra việc hoán đổi trang thường xuyên.
• Bạn dự đoán sự tăng trưởng theo cấp số nhân trong bộ dữ liệu của mình.

Sharding làm tăng độ phức tạp về kiến trúc, vì vậy tốt nhất chỉ nên áp dụng khi thật sự cần thiết.

Tối ưu hóa WiredTiger để tăng hiệu suất

MongoDB sử dụng engine lưu trữ WiredTiger theo mặc định. Nó được tối ưu hóa cho phần cứng hiện đại và sử dụng nén, bộ nhớ đệm, cũng như I/O đa luồng. Hiểu cách WiredTiger quản lý bộ nhớ và I/O đĩa sẽ giúp cải thiện hiệu suất.

Sử dụng bộ nhớ

WiredTiger thường sử dụng khoảng 50% RAM có sẵn làm bộ nhớ đệm, với MongoDB điều chỉnh giá trị này một cách linh hoạt dựa trên bộ nhớ hệ thống.

Bạn có thể điều chỉnh điều này trong tệp cấu hình:

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8

Điều này hữu ích nếu hệ thống của bạn chạy các dịch vụ tiêu tốn bộ nhớ khác cùng với MongoDB. Đối với các máy chủ MongoDB chuyên dụng, việc để cài đặt bộ nhớ đệm mặc định thường là tốt nhất.

Bạn có thể xem mức sử dụng bộ nhớ đệm hiện tại bằng cách chạy:

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

Nén

WiredTiger hỗ trợ nén dữ liệu và chỉ mục để giảm dung lượng ổ đĩa. Theo mặc định, nó sử dụng nén Snappy, cân bằng giữa hiệu suất và hiệu quả về không gian. Bạn có thể chuyển sang zlib (cho nén tốt hơn) hoặc zstd (cho các cấu hình mới hơn) nếu ưu tiên tiết kiệm dung lượng ổ đĩa hơn tốc độ.

Ví dụ cấu hình:

storage:
  wiredTiger:
    collectionConfig:
      blockCompressor: zstd

Viết nhật ký và độ bền

Ghi nhật ký đảm bảo rằng các thao tác ghi sẽ bền vững, ngay cả trong trường hợp mất điện. Bạn có thể điều chỉnh tham số commitIntervalMs để kiểm soát tần suất ghi nhật ký xảy ra:

storage:
  journal:
    commitIntervalMs: 100

Các khoảng thời gian thấp hơn cải thiện độ bền nhưng có thể làm giảm hiệu suất ghi một chút.

Giám sát và Kích hoạt Tăng trưởng

Điều quan trọng là nhận biết khi nào cần mở rộng triển khai MongoDB của bạn. Việc theo dõi các chỉ số như tải CPU, sử dụng bộ nhớ và thời gian chờ I/O sẽ giúp xác định khi nào cần tăng thêm dung lượng.

Các tác nhân phổ biến gây tăng trưởng

• Sử dụng CPU luôn trên 80%.
• Độ trễ I/O đĩa vượt quá ngưỡng chấp nhận được (ví dụ, hơn 10 ms).
• Sử dụng RAM gần mức tối đa trong thời gian dài.
• Tăng trưởng nhanh về kích thước bộ làm việc.
• Tăng độ trễ sao chép giữa các nút.

Khi những chỉ số này xuất hiện, hãy cân nhắc thêm nhiều máy phụ (cho việc đọc) hoặc phân mảnh (cho khối lượng ghi nặng).

Mở rộng theo chiều dọc vs. Mở rộng theo chiều ngang

Phép mở rộng theo chiều dọc liên quan đến việc thêm nhiều tài nguyên hơn (CPU, RAM, ổ đĩa nhanh hơn) vào các máy chủ hiện có. Nó dễ quản lý hơn nhưng bị giới hạn bởi khả năng phần cứng.

Mở rộng theo chiều ngang bao gồm việc thêm các máy chủ mới để phân phối khối lượng công việc. Đây là điểm mạnh của MongoDB, vì nó có khả năng mở rộng gần như tuyến tính khi được thiết kế đúng cách.

Di cư sang MongoDB được quản lý

Khi hệ thống của bạn phát triển, việc quản lý một cụm máy chủ tự lưu trữ có thể trở nên phức tạp. Ở giai đoạn này, chuyển sang dịch vụ MongoDB được quản lý, như MongoDB Atlas, có thể giảm đáng kể gánh nặng vận hành.

Các nền tảng được quản lý thực hiện sao lưu tự động, vá lỗi, giám sát, mở rộng quy mô và mã hóa. Tuy nhiên, chúng có thể làm tăng chi phí và giảm đôi chút tính linh hoạt so với các thiết lập tự quản lý.

<$> Khuyến nghị: Hãy tự lưu trữ cho đến khi đội ngũ của bạn gặp các thách thức vận hành thường xuyên như tắc nghẽn hiệu suất, sự phức tạp trong quản lý cụm, hoặc các yêu cầu tuân thủ mà các nền tảng được quản lý có thể xử lý hiệu quả hơn. <$>

So sánh: MongoDB Tự Lưu trữ vs MongoDB Quản lý

MongoDB có thể được triển khai theo hai cách chính:

1. Tự lưu trữ, nơi bạn cài đặt, cấu hình và quản lý cơ sở dữ liệu tự mình (như được hướng dẫn trong bài viết này).
2. Được quản lý, nơi một nhà cung cấp bên thứ ba lưu trữ và vận hành MongoDB cho bạn dưới dạng dịch vụ.

Mỗi phương pháp đều có những ưu điểm và nhược điểm riêng. Lựa chọn phù hợp phụ thuộc vào trình độ kỹ thuật, đặc điểm khối lượng công việc, yêu cầu tuân thủ và các ưu tiên vận hành của bạn.

Hãy cùng xem xét kỹ hai lựa chọn này.

MongoDB Tự Lưu Trữ

Khi bạn tự lưu trữ MongoDB, bạn cài đặt nó trực tiếp trên cơ sở hạ tầng của mình, cho dù đó là máy chủ vật lý, máy ảo hay một phiên bản trên đám mây như một Droplet của Linux-Console.net. Bạn kiểm soát mọi khía cạnh của môi trường, từ cài đặt đến nâng cấp và giám sát.

Ưu điểm của việc Tự Lưu trữ

1. Toàn quyền kiểm soát và linh hoạt: Bạn có toàn quyền điều khiển các thiết lập cấu hình, hệ thống tệp, mạng và tối ưu hiệu suất. Bạn có thể chỉnh sửa tệp mongod.conf, chọn đường dẫn lưu trữ, và áp dụng các chính sách bảo mật hoặc sao lưu tùy chỉnh phù hợp với tiêu chuẩn của tổ chức bạn.
2. Hiệu quả chi phí cho các triển khai nhỏ: Đối với các khối lượng công việc nhỏ hoặc vừa, việc tự lưu trữ có thể rẻ hơn so với việc sử dụng dịch vụ được quản lý. Bạn chỉ trả tiền cho các tài nguyên tính toán và lưu trữ cơ bản mà không phải trả thêm cho một lớp quản lý.
3. Chính sách Bảo mật Tùy chỉnh: Bạn có thể tích hợp MongoDB với VPN nội bộ, tường lửa hoặc mạng riêng, đảm bảo tuân thủ đầy đủ các yêu cầu bảo mật theo địa phương hoặc theo ngành. Một số tổ chức yêu cầu triển khai tại chỗ do các hạn chế về nơi lưu trữ dữ liệu hoặc quy định, điều này khiến việc tự lưu trữ trở thành lựa chọn khả thi duy nhất.
4. Tối ưu hiệu suất: Vì bạn kiểm soát phần cứng, bạn có thể tinh chỉnh các tham số hệ thống như bộ lập lịch I/O, kích thước bộ nhớ đệm và các thuật toán nén. Bạn cũng có thể đặt MongoDB cùng với các dịch vụ liên quan để giảm thiểu độ trễ mạng.

Những thách thức của việc tự lưu trữ

• Chi phí vận hành: Bạn chịu trách nhiệm quản lý mọi thứ; từ cài đặt các bản cập nhật và vá lỗi đến xử lý sự cố và tối ưu hiệu suất. Điều này đòi hỏi đội ngũ nhân viên chuyên môn về quản trị cơ sở dữ liệu và quản lý hệ thống Linux.
• Độ phức tạp khi mở rộng: Việc mở rộng một cụm MongoDB tự lưu trữ có nghĩa là cung cấp các máy chủ mới, cân bằng lại dữ liệu, cập nhật cấu hình và duy trì các cấu trúc nhân bản hoặc phân mảnh theo cách thủ công. Những nhiệm vụ này có thể dễ mắc lỗi nếu không có tự động hóa.
• Sao lưu và Phục hồi thảm họa: Bạn phải tự thiết kế, kiểm tra và duy trì các quy trình sao lưu, phục hồi và lưu trữ ngoài trụ sở. Mặc dù các công cụ của MongoDB (mongodump, mongorestore và chụp ảnh ổ đĩa) có thể thực hiện được điều này, nhưng nó đòi hỏi kế hoạch vận hành nghiêm túc.
• Giám sát và Cảnh báo: MongoDB tự lưu trữ yêu cầu bạn thiết lập hệ thống giám sát và cảnh báo bằng các công cụ như Prometheus, Grafana hoặc Percona PMM. Nếu không có khả năng giám sát liên tục, các sự cố hoặc tắc nghẽn hiệu suất có thể không được phát hiện cho đến khi chúng gây ra thời gian chết.

Tóm lại, MongoDB tự lưu trữ mang lại sự linh hoạt, độc lập và chi phí thấp ở quy mô nhỏ nhưng đòi hỏi nỗ lực bảo trì liên tục đáng kể.

Dịch vụ MongoDB được quản lý

Dịch vụ MongoDB được quản lý lưu trữ cơ sở dữ liệu thay bạn, tự động xử lý tất cả cơ sở hạ tầng, cập nhật, mở rộng và các bản vá bảo mật. Những dịch vụ này loại bỏ hầu hết gánh nặng quản trị trong khi vẫn cung cấp khả năng sẵn sàng cao và khả năng mở rộng toàn cầu.

Ưu điểm của MongoDB được quản lý

1. Yêu cầu vận hành tối thiểu: Nhà cung cấp dịch vụ sẽ tự động quản lý việc cung cấp cơ sở dữ liệu, sao lưu, nâng cấp và xử lý khi gặp sự cố. Bạn có thể triển khai các cụm mới chỉ với vài thao tác nhấp chuột hoặc gọi API, giúp giảm đáng kể khối lượng công việc quản trị.
2. Tự động mở rộng: Dịch vụ được quản lý có thể điều chỉnh linh hoạt các tài nguyên tính toán và lưu trữ khi dữ liệu của bạn tăng lên. Ví dụ, MongoDB Atlas hỗ trợ phân mảnh tự động và mở rộng theo chiều dọc mà không gây gián đoạn.
3. Giám sát và cảnh báo tích hợp sẵn: Các nền tảng được quản lý bao gồm bảng điều khiển cho việc sử dụng CPU, hiệu suất ổ đĩa, thống kê kết nối và độ trễ truy vấn. Bạn có thể đặt ngưỡng cảnh báo cho các chỉ số quan trọng mà không cần triển khai công cụ giám sát riêng.
4. Sẵn sàng hoạt động cao theo mặc định: Hầu hết các dịch vụ được quản lý triển khai các cụm với ba hoặc nhiều nút bản sao (replica set) trên các vùng khả dụng khác nhau. Điều này đảm bảo tự động chuyển đổi khi sự cố và thời gian hoạt động cao với cấu hình tối thiểu.
5. Bảo mật và Tuân thủ: Các nền tảng MongoDB được quản lý cung cấp mã hóa tích hợp, quyền truy cập dựa trên vai trò, cách ly mạng (VPC peering) và tích hợp với các nhà cung cấp định danh. Chúng cũng được chứng nhận theo các tiêu chuẩn như SOC 2, GDPR, HIPAA và ISO 27001, giúp đơn giản hóa việc kiểm toán tuân thủ.
6. Phân phối toàn cầu: MongoDB Atlas và các dịch vụ tương tự hỗ trợ các cụm đa vùng. Dữ liệu có thể được nhân bản gần vị trí địa lý của người dùng, cải thiện độ trễ cho các ứng dụng phân tán.

Hạn chế của Dịch vụ Quản lý

1. Chi phí cao hơn khi mở rộng quy mô: Dịch vụ được quản lý thường tính phí cao cho việc tự động hóa và tiện lợi. Khi khối lượng dữ liệu và lưu lượng tăng lên, chi phí hàng tháng có thể vượt quá chi phí vận hành các phiên bản tự lưu trữ, đặc biệt là đối với các bộ dữ liệu lớn được lưu trên SSD.
2. Tùy chỉnh hạn chế: Các môi trường được quản lý giới hạn quyền truy cập vào các tùy chọn cấu hình cấp thấp. Bạn không thể thay đổi các cài đặt cấp hệ thống tệp, điều chỉnh bộ nhớ đệm hoặc các thông số của hệ điều hành cơ sở.
3. Khóa nhà cung cấp: Mỗi nhà cung cấp có các API và cấu hình triển khai riêng, làm cho việc di chuyển giữa các dịch vụ trở nên khó khăn sau này.
4. Phụ thuộc vào mạng: Các cơ sở dữ liệu được quản lý phụ thuộc vào kết nối mạng bên ngoài. Nếu ứng dụng của bạn chạy trong môi trường tại chỗ, việc kết nối an toàn với dịch vụ được quản lý có thể gây ra độ trễ hoặc phụ thuộc vào các đường hầm VPN.

Tóm lại, các dịch vụ MongoDB được quản lý giảm đáng kể gánh nặng quản trị và cải thiện độ tin cậy nhưng đi kèm với chi phí cao hơn và tính linh hoạt thấp hơn.

Bảng So Sánh Tính Năng

Lựa chọn mô hình triển khai phù hợp

Quyết định giữa việc tự lưu trữ MongoDB và sử dụng MongoDB được quản lý chủ yếu phụ thuộc vào ưu tiên, nguồn lực và các hạn chế của tổ chức bạn. Hãy xem xét các tình huống sau:

• Chọn MongoDB Tự Lưu Trữ nếu:

  • Bạn cần có toàn quyền kiểm soát cơ sở hạ tầng và dữ liệu.
  • Khối lượng công việc của bạn vừa phải và có thể dự đoán được.
  • Bạn có chuyên môn nội bộ về quản trị Linux và MongoDB.
  • Các luật về tuân thủ hoặc cư trú dữ liệu yêu cầu lưu trữ tại chỗ.

• Chọn MongoDB được quản lý nếu:

  • Bạn thích tập trung vào phát triển ứng dụng hơn là hạ tầng.
  • Bạn cần khả năng tự động mở rộng và tính khả dụng cao với cấu hình tối thiểu.
  • Nhóm của bạn thiếu các quản trị viên cơ sở dữ liệu chuyên trách.
  • Bạn cần các cụm máy chủ phân tán toàn cầu hoặc các chứng nhận tuân thủ (SOC 2, HIPAA, GDPR).

Xử lý sự cố và Bảo trì

Ngay cả với cấu hình và giám sát cẩn thận nhất, các vấn đề vẫn có thể xảy ra trong triển khai MongoDB. Những vấn đề này có thể bao gồm hiệu suất chậm, khởi động thất bại, độ trễ sao chép hoặc hết dung lượng đĩa. Chìa khóa để duy trì một môi trường MongoDB ổn định là có một phương pháp có cấu trúc để chẩn đoán sự cố và thực hiện các quy trình bảo trì phòng ngừa.

Kiểm tra trạng thái dịch vụ MongoDB

Bước đầu tiên khi khắc phục sự cố MongoDB là kiểm tra xem dịch vụ cơ sở dữ liệu có đang chạy đúng không.

Bạn có thể kiểm tra trạng thái hiện tại bằng lệnh sau:

sudo systemctl status mongod

Nếu MongoDB đang chạy, bạn sẽ thấy đầu ra bao gồm:

Active: active (running)

Main PID: 3564 (mongod)

Nếu dịch vụ không hoạt động, thất bại hoặc đã dừng, hãy khởi động lại nó:

sudo systemctl restart mongod

Sau khi khởi động lại, hãy kiểm tra trạng thái của nó một lần nữa. Nếu nó ngay lập tức gặp sự cố, hãy tiến hành kiểm tra tệp nhật ký để tìm các lỗi cụ thể.

Xem lại nhật ký MongoDB

Nhật ký là nguồn thông tin chẩn đoán trực tiếp nhất. MongoDB ghi lại tất cả các sự kiện quan trọng, cảnh báo và lỗi trong tệp nhật ký chính của nó nằm tại:

/var/log/mongodb/mongod.log

Để xem các mục mới nhất, hãy chạy:

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

Nếu MongoDB không thể khởi động, bạn thường sẽ thấy một trong các lỗi sau:

• Quyền truy cập bị từ chối: Quyền sở hữu hoặc quyền truy cập không đúng trên /var/lib/mongodb hoặc /var/log/mongodb. Kiểm tra quyền và sửa chúng:

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

• Không tìm thấy thư mục dữ liệu: Đảm bảo /var/lib/mongodb tồn tại và khớp với đường dẫn được định nghĩa trong /etc/mongod.conf.

• Địa chỉ đã được sử dụng: Một tiến trình khác đang sử dụng cổng 27017. Xác định nó bằng:

  sudo lsof -i :27017

  và dừng hoặc cấu hình lại dịch vụ xung đột.

• Tệp dữ liệu bị hỏng: Điều này có thể xảy ra nếu MongoDB bị tắt đột ngột. Trong những trường hợp như vậy, nhật ký sẽ tự động khôi phục dữ liệu khi khởi động lại. Nếu không thành công, bạn có thể cần khôi phục từ bản sao lưu.

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

Chẩn đoán sự cố kết nối

Các vấn đề về kết nối là một vấn đề thường gặp khác. Khi khách hàng không thể kết nối đến MongoDB, thường là do sự cố về mạng, xác thực hoặc cấu hình.

Xác minh rằng MongoDB đang lắng nghe trên các giao diện đúng

Chạy :

sudo ss -tulpn | grep mongod

Kết quả đầu ra nên hiển thị MongoDB được liên kết với 127.0.0.1 (cho các kết nối cục bộ) và bất kỳ địa chỉ IP bên ngoài nào đã được cấu hình. Nếu MongoDB không lắng nghe trên IP mong đợi, hãy kiểm tra trường bindIp trong /etc/mongod.conf:

net:
  bindIp: 127.0.0.1,192.168.10.50

Khởi động lại MongoDB sau khi chỉnh sửa:

sudo systemctl restart mongod

Kiểm tra Quy tắc Tường lửa

Nếu kết nối từ xa thất bại, hãy xác nhận rằng tường lửa của bạn cho phép lưu lượng trên cổng 27017:

sudo ufw status

Nếu không, cho phép kết nối từ các IP cụ thể:

sudo ufw allow from 192.168.10.50 to any port 27017

Kiểm tra kết nối bằng Telnet hoặc Ping

Từ hệ thống khách, kiểm tra xem cổng có thể truy cập được hay không:

telnet mongodb-server-ip 27017

hoặc

nc -vz mongodb-server-ip 27017

Nếu kết nối thành công, vấn đề có khả năng liên quan đến xác thực hoặc quyền của người dùng.

Khắc phục sự cố xác thực thất bại

Các sự cố xác thực thường xảy ra sau khi bật kiểm soát truy cập hoặc thay đổi thông tin đăng nhập của người dùng.

Xác nhận rằng xác thực đã được bật

Kết nối tại chỗ và xác minh:

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

Nếu đầu ra bao gồm "SCRAM-SHA-256", xác thực đang được kích hoạt.

Xác minh thông tin đăng nhập

Thử kết nối bằng tài khoản quản trị:

mongosh -u admin -p --authenticationDatabase admin

Nếu việc này thất bại, hãy kết nối cục bộ mà không cần xác thực (chỉ có thể thực hiện từ localhost khi chưa có người dùng nào) và tạo lại tài khoản quản trị:

use admin

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

Kiểm tra ngữ cảnh cơ sở dữ liệu

Mỗi người dùng MongoDB được định nghĩa trong một cơ sở dữ liệu cụ thể. Nếu bạn xác thực với cơ sở dữ liệu sai, việc xác thực sẽ thất bại. Ví dụ, nếu người dùng được tạo trong cơ sở dữ liệu admin, bạn phải xác thực với nó một cách rõ ràng:

mongosh -u admin -p --authenticationDatabase admin

Khắc phục các vấn đề về hiệu suất

Hiệu suất có thể suy giảm do sử dụng bộ nhớ cao, đầu vào/đầu ra đĩa chậm, truy vấn chưa tối ưu hoặc quá nhiều kết nối đồng thời. MongoDB bao gồm một số công cụ chẩn đoán để xác định các vấn đề này.

Kiểm tra Sử dụng Tài nguyên

Sử dụng các lệnh Linux để kiểm tra các chỉ số cấp hệ thống:

top

vmstat 2

iostat -x 2

Tìm kiếm việc sử dụng CPU cao bởi mongod hoặc độ trễ của đĩa vượt quá 10 mili giây.

Giám sát các hoạt động cơ sở dữ liệu

Chạy :

mongostat 2

Điều này hiển thị các chỉ số theo thời gian thực, bao gồm số lần chèn, truy vấn, cập nhật và xóa mỗi giây.

Nếu một số thao tác có vẻ chậm, hãy sử dụng MongoDB profiler để xác định các truy vấn chạy lâu.

Bật phân tích truy vấn

Bạn có thể tạm thời bật trình phân tích để ghi lại các truy vấn chậm:

use myappdb

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

Điều này ghi lại bất kỳ truy vấn nào mất hơn 100 mili giây.

Xem lại kết quả:

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

Phân tích hiệu quả chỉ mục

Các truy vấn kém hiệu quả thường xuất phát từ việc thiếu chỉ mục. Để kiểm tra xem MongoDB có đang sử dụng chỉ mục đúng cách hay không, hãy thêm explain() vào trước truy vấn của bạn:

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

Nếu executionStages.stage hiển thị "COLLSCAN", MongoDB đang thực hiện quét toàn bộ bộ sưu tập. Bạn có thể tạo một chỉ mục để cải thiện hiệu suất:

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

Sửa Chữa Cơ Sở Dữ Liệu Bị Hỏng

Mất dữ liệu hiếm khi xảy ra, nhưng điều này có thể xảy ra do mất điện hoặc lỗi đĩa. Nếu MongoDB từ chối khởi động và nhật ký hiển thị bị hỏng trong các tệp WiredTiger, hãy làm theo các bước sau:

1. Dừng MongoDB:

   sudo systemctl stop mongod

2. Sao lưu thư mục dữ liệu hiện tại:

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

3. Thử thực hiện thao tác sửa chữa:

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

4. Khởi động lại MongoDB:

   sudo systemctl start mongod

Nếu việc sửa chữa thất bại, hãy khôi phục dữ liệu từ bản sao lưu gần nhất của bạn.

Các nhiệm vụ bảo trì định kỳ

Bảo trì phòng ngừa giúp giảm đáng kể khả năng xảy ra sự cố bất ngờ.

Xoay nhật ký thường xuyên

Đảm bảo rằng chính sách xoay nhật ký của bạn đang hoạt động. MongoDB hỗ trợ cả xoay nhật ký nội bộ (lệnh logRotate) và xoay bên ngoài thông qua logrotate khi logAppend được bật. Bạn có thể kích hoạt thủ công nếu nhật ký phát triển nhanh:

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

Bộ sưu tập gọn gàng

Các bộ sưu tập có thể trở nên phân mảnh sau nhiều lần chèn và xóa. compact có thể thu hồi không gian nhưng là một thao tác chặn và nên hiếm khi sử dụng trong môi trường sản xuất. WiredTiger tự động xử lý hầu hết các tình trạng phân mảnh, vì vậy việc compact thường không cần thiết.

Lưu ý rằng thao tác này sẽ khóa cơ sở dữ liệu, vì vậy hãy thực hiện nó vào những thời điểm ít lưu lượng.

Xác nhận bộ sưu tập

Thực hiện kiểm tra tính toàn vẹn dữ liệu định kỳ:

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

Điều này xác minh rằng các chỉ mục và tài liệu nhất quán.

Theo dõi Sử dụng Ổ đĩa và Bộ nhớ

Sử dụng cảnh báo tự động để thông báo khi việc sử dụng ổ đĩa vượt quá 85% hoặc mức sử dụng bộ nhớ trở nên quan trọng. Các công cụ giám sát như Prometheus, Percona PMM hoặc MongoDB Atlas Monitor có thể theo dõi các chỉ số này theo thời gian.

Áp dụng các bản cập nhật hệ thống an toàn

Khi cập nhật MongoDB hoặc hệ thống Ubuntu cơ sở, luôn tuân theo một quy trình có cấu trúc:

1. Hãy sao lưu dữ liệu của bạn trước.

2. Dừng dịch vụ MongoDB trước khi nâng cấp nhân hoặc thư viện:

   sudo systemctl stop mongod

3. Áp dụng các bản cập nhật:

   sudo apt update && sudo apt upgrade -y

4. Khởi động lại dịch vụ và xác nhận nó chạy đúng cách:

   sudo systemctl start mongod
   
   sudo systemctl status mongod

Công cụ cho Bảo trì Chủ động

Một số công cụ giúp đơn giản hóa việc bảo trì và kiểm tra tình trạng sức khỏe định kỳ:

• MongoDB Compass: Giao diện đồ họa để khám phá dữ liệu và các chỉ số hiệu suất một cách trực quan.
• Atlas CLI: Dùng để quản lý các cụm, người dùng và sao lưu trên MongoDB Atlas.
• Kịch bản Mongosh: Các kịch bản tùy chỉnh có thể tự động kiểm tra sức khỏe hoặc tạo báo cáo hàng ngày về số lượng kết nối và sử dụng ổ đĩa.
• Ansible Playbooks: Tự động hóa việc cài đặt, kiểm tra cấu hình và lập lịch sao lưu.

Kiểm tra Khôi phục Thảm họa

Bước cuối cùng trong lập kế hoạch bảo trì là kiểm tra các quy trình phục hồi. Một bản sao lưu chỉ hữu ích nếu nó khôi phục đúng cách.

Ít nhất một lần mỗi quý:

1. Khôi phục bản sao lưu mới nhất của bạn lên máy chủ thử nghiệm.
2. Xác minh rằng các chỉ mục, người dùng và quyền được tải đúng cách.
3. Đo thời gian khôi phục để đảm bảo nó đáp ứng các mục tiêu thời gian khôi phục (RTO) của bạn.
4. Ghi chép lại quy trình để bất kỳ quản trị viên nào cũng có thể thực hiện trong trường hợp khẩn cấp.

Danh sách kiểm tra bảo trì dài hạn

Bằng cách tuân thủ các phương pháp khắc phục sự cố và bảo trì này, bạn có thể duy trì một triển khai MongoDB khỏe mạnh trên Ubuntu, đảm bảo hiệu suất, bảo mật và khả năng phục hồi theo thời gian. Việc giám sát và bảo trì thường xuyên ít tốn kém hơn nhiều so với việc khôi phục sau sự cố ngừng hoạt động hoặc mất dữ liệu.

Câu hỏi thường gặp

1. Tại sao MongoDB không có sẵn trong các kho mặc định của Ubuntu?

MongoDB đã bị loại khỏi các kho mặc định của Ubuntu sau phiên bản 18.04 vì thay đổi giấy phép. Giấy phép Công khai Máy chủ MongoDB (SSPL) không được các dự án Debian và Ubuntu công nhận là mã nguồn mở. Do đó, Canonical không còn phân phối MongoDB trong các kho chính thức của mình, và người dùng phải cài đặt nó từ kho APT riêng của MongoDB.

2. Làm thế nào để gỡ cài đặt hoàn toàn MongoDB?

Để gỡ cài đặt MongoDB và xóa tất cả các tập tin liên quan, chạy các lệnh sau:

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

Điều này sẽ dừng dịch vụ MongoDB, gỡ bỏ tất cả các gói liên quan, xóa thư mục dữ liệu và nhật ký, và làm sạch mục kho lưu trữ.

3. Làm thế nào để kiểm tra xem MongoDB có đang chạy không?

Bạn có thể kiểm tra trạng thái của dịch vụ MongoDB bằng cách sử dụng:

sudo systemctl status mongod

Nếu MongoDB đang chạy, bạn sẽ thấy một dòng hiển thị “Active: active (running) ”. Ngoài ra, bạn có thể xác nhận kết nối bằng cách chạy:

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

Nếu lệnh trả về "ok": 1, MongoDB đang hoạt động và chấp nhận các kết nối.

4. MongoDB có thể chạy trên một VPS nhỏ không?

Đúng, MongoDB có thể chạy trên một VPS nhỏ, nhưng sẽ có giới hạn. Đối với các công việc phát triển hoặc thử nghiệm cơ bản, một máy chủ với 2 lõi CPU, 2 GB RAM và 10–20 GB lưu trữ SSD là đủ.

Tuy nhiên, đối với việc sử dụng trong môi trường sản xuất, MongoDB hoạt động tốt nhất trên các hệ thống có ít nhất 4 lõi CPU, 8 GB RAM và ổ lưu trữ SSD hoặc NVMe tốc độ cao. Các môi trường có bộ nhớ thấp có thể cần điều chỉnh kích thước bộ nhớ đệm WiredTiger để ngăn chặn việc hoán đổi quá mức.

5. Tại sao MongoDB không khởi động sau khi thực hiện một thao tác sửa chữa?

MongoDB có thể không khởi động được sau khi thực hiện sửa chữa nếu quá trình sửa chữa được chạy dưới quyền root, điều này sẽ thay đổi quyền sở hữu của các tập tin dữ liệu trong /var/lib/mongodb thành root:root. Vì dịch vụ mongod chạy dưới quyền người dùng mongodb, nên nó sẽ không có quyền đọc hoặc ghi các tập tin này. Để khắc phục, hãy đảm bảo bạn chạy lệnh sửa chữa với quyền người dùng mongodb hoặc khôi phục quyền sở hữu chính xác sau đó:

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

6. Làm thế nào tôi có thể biết MongoDB đang lắng nghe trên các giao diện mạng đúng không?

Bạn có thể kiểm tra các bộ lắng nghe đang hoạt động của MongoDB bằng cách sử dụng:

sudo ss -tulpn | grep mongod

Điều này hiển thị các địa chỉ IP và cổng mà MongoDB đang kết nối. Nếu bạn không thấy địa chỉ IP mong đợi (ví dụ, địa chỉ IP của máy chủ ứng dụng của bạn), hãy kiểm tra giá trị bindIp trong /etc/mongod.conf và khởi động lại dịch vụ.

7. Tôi có nên thay đổi kích thước bộ nhớ đệm WiredTiger mặc định của MongoDB không?

Trong hầu hết các trường hợp, không. WiredTiger tự động sử dụng khoảng 50% RAM hệ thống và điều chỉnh việc sử dụng bộ nhớ đệm dựa trên bộ nhớ sẵn có. Chỉ điều chỉnh thiết lập cacheSizeGB nếu MongoDB chia sẻ máy chủ với các ứng dụng tiêu tốn nhiều bộ nhớ khác. Các máy chủ MongoDB riêng biệt thường nên giữ hành vi mặc định.

8. Tại sao nhật ký MongoDB của tôi lại ngày càng lớn?

MongoDB liên tục ghi dữ liệu vận hành vào tệp nhật ký tại /var/log/mongodb/mongod.log. Nếu không có cơ chế xoay nhật ký, tệp này có thể trở nên rất lớn. Hãy đảm bảo bạn đã cấu hình xoay nhật ký bằng logrotate, như được mô tả trong phần bảo trì của hướng dẫn, để các nhật ký cũ được nén hoặc xóa tự động.

9. Khi nào tôi nên xem xét thêm nhiều nút vào bộ sao chép của mình?

Bạn nên mở rộng bộ bản sao khi nhận thấy lưu lượng đọc tăng liên tục, các cuộc bầu chọn nút diễn ra thường xuyên, độ trễ sao chép hoặc khi bạn cần khả năng sẵn sàng cao hơn trên nhiều vùng hoặc khu vực. Việc thêm các bản sao phụ sẽ phân tán tải đọc và cải thiện khả năng chịu lỗi, đặc biệt là đối với môi trường sản xuất.

10. Làm thế nào tôi có thể xác nhận rằng TLS đã được bật đúng cách trên máy chủ MongoDB của mình?

Sau khi cấu hình TLS trong /etc/mongod.conf, kết nối bằng:

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

Nếu kết nối thành công, hãy chạy:

openssl s_client -connect <server-ip>:27017

Một quá trình bắt tay TLS hợp lệ và các chi tiết như Protocol: TLSv1.3 xác nhận rằng mã hóa đang hoạt động.

Kết luận

Vận hành MongoDB hiệu quả không chỉ là về cài đặt và thiết lập; mà còn là duy trì sự cân bằng giữa hiệu suất, bảo mật và độ tin cậy theo thời gian. Bây giờ bạn đã có một hệ thống MongoDB hoàn chỉnh có thể hỗ trợ khối lượng công việc trong môi trường sản xuất, mở rộng theo nhu cầu và phục hồi sau các sự cố bất ngờ.

Bằng cách áp dụng các nguyên tắc và thực tiễn tốt nhất được nêu trong hướng dẫn này, từ việc giám sát hàng ngày đến lập kế hoạch năng lực dài hạn, bạn có thể vận hành MongoDB với sự tự tin trong bất kỳ môi trường nào. Dù bạn tiếp tục tự quản lý hay chuyển sang dịch vụ được quản lý như MongoDB Atlas, sự hiểu biết về cách hoạt động bên trong của MongoDB đảm bảo rằng bạn sẽ luôn kiểm soát được dữ liệu của mình.

Để tìm hiểu thêm về cơ sở dữ liệu, hãy xem các hướng dẫn sau:

• Các loại cơ sở dữ liệu khác nhau là gì? Giải thích với các trường hợp sử dụng và kiến trúc
• SQLite vs MySQL vs PostgreSQL: So sánh các Hệ quản trị Cơ sở dữ liệu Quan hệ
• Cách cài đặt Node.js trên Ubuntu
• Cách Bắt Đầu với MERN Stack

Cảm ơn bạn đã học cùng cộng đồng Linux-Console.net.