Khắc phục lỗi MongoDB 'WiredTiger error: write failed: No space left on device' do đầy ổ đĩa

TL;DR Khắc phục nhanh

Lỗi WiredTiger error: write failed: No space left on device nghĩa là ổ đĩa của máy chủ MongoDB của bạn đã hết dung lượng. Để đưa MongoDB hoạt động trở lại nhanh chóng, bạn cần giải phóng dung lượng ổ đĩa ngay lập tức. Dưới đây là danh sách kiểm tra nhanh:

Kiểm tra dung lượng ổ đĩa: Sử dụng lệnh df -h để xác định phân vùng bị đầy.
Xác định các tệp/thư mục lớn: Sử dụng lệnh sudo du -sh /path/to/directory/* để khám phá những gì đang chiếm dung lượng. Hãy đặc biệt chú ý đến /var/lib/mongodb và /var/log.
Xóa nhật ký hệ điều hành: Xóa hoặc cắt bớt các tệp nhật ký hệ thống cũ, thường được tìm thấy trong /var/log.
Xóa nhật ký MongoDB: Xoay vòng hoặc xóa các tệp nhật ký MongoDB cũ (ví dụ: trong /var/log/mongodb).
Xóa các tệp không cần thiết: Xóa mọi bản sao lưu cũ, tệp tạm thời hoặc dữ liệu thử nghiệm không quan trọng cho hoạt động ngay lập tức.
Tăng dung lượng ổ đĩa: Để có giải pháp lâu dài, hãy mở rộng dung lượng ổ đĩa bằng cách sử dụng nhà cung cấp dịch vụ đám mây hoặc cài đặt máy ảo của bạn.

Nguyên nhân chi tiết

Thông báo WiredTiger error: write failed: No space left on device khá rõ ràng: ổ đĩa hệ thống của bạn đã đầy hoàn toàn. Điều này có nghĩa là công cụ lưu trữ WiredTiger của MongoDB không thể ghi thêm bất kỳ dữ liệu nào. WiredTiger, vốn là công cụ lưu trữ mặc định cho MongoDB kể từ phiên bản 3.2, quản lý cách dữ liệu được lưu trữ trên đĩa, bao gồm các tệp dữ liệu, tệp chỉ mục và tệp nhật ký.

Khi ổ đĩa hết dung lượng, WiredTiger không thể thực hiện các thao tác thiết yếu:

Nó không thể ghi dữ liệu mới hoặc cập nhật các tài liệu hiện có.
Nó không thể tạo hoặc cập nhật các mục chỉ mục.
Nó không thể ghi vào các tệp nhật ký của mình, vốn rất quan trọng cho độ bền và khả năng phục hồi dữ liệu.
Nó không thể thực hiện các thao tác nội bộ yêu cầu không gian đĩa tạm thời.

Vấn đề này có thể phát sinh từ một số yếu tố:

Tăng trưởng dữ liệu nhanh chóng: Cơ sở dữ liệu của bạn có thể đã mở rộng nhanh hơn nhiều so với dự kiến.
Các tệp nhật ký lớn: Nhật ký MongoDB hoặc nhật ký hệ thống (như syslog hoặc journald) có thể đã chiếm hết dung lượng khả dụng. Ví dụ, một tệp nhật ký journalctl có thể tăng lên vài gigabyte nếu không được quản lý.
Không gian chưa được phục hồi: Việc xóa dữ liệu không phải lúc nào cũng ngay lập tức giải phóng không gian cho hệ điều hành. WiredTiger cấp phát trước không gian và tái sử dụng nó một cách nội bộ. Ngoài ra, sự phân mảnh có thể làm cho các tệp dữ liệu có vẻ lớn, ngay cả khi chúng chứa một lượng lớn không gian trống bên trong.
Ảnh chụp nhanh/Sao lưu: Các bản sao lưu cơ sở dữ liệu cũ hoặc ảnh chụp nhanh ổ đĩa được lưu trữ trên cùng một đĩa có thể đang chiếm dung lượng đáng kể.
Các tệp tạm thời: Các ứng dụng khác trên cùng một máy chủ có thể đã tạo ra các tệp tạm thời lớn.

Khi lỗi này xảy ra, MongoDB thường ngừng phản hồi các thao tác ghi. Mặc dù các thao tác đọc có thể vẫn hoạt động trong thời gian ngắn, các thao tác ghi nội bộ như cập nhật nhật ký cuối cùng cũng sẽ thất bại. Mục tiêu trước mắt của bạn là giải phóng đủ dung lượng ổ đĩa để đưa MongoDB trở lại bình thường.

Các phương pháp khắc phục

1. Chẩn đoán mức sử dụng ổ đĩa hiện tại

Trước khi bạn làm bất cứ điều gì khác, điều quan trọng là phải hiểu điều gì đang thực sự làm đầy ổ đĩa của bạn.


df -h

Lệnh này hiển thị mức sử dụng không gian đĩa cho tất cả các hệ thống tệp đã được gắn. Xác định phân vùng đã đầy 100% (hoặc rất gần mức đó).


sudo du -sh /var/lib/mongodb
sudo du -sh /var/log
sudo du -sh /tmp

Sử dụng du -sh để tóm tắt mức sử dụng ổ đĩa cho các thư mục chính. Thư mục dữ liệu MongoDB (mặc định là /var/lib/mongodb) thường là nghi phạm chính và thường có thể chiếm hàng trăm gigabyte. Ngoài ra, hãy kiểm tra /var/log để tìm nhật ký hệ thống và ứng dụng, có thể chiếm hàng chục gigabyte, và /tmp để tìm các tệp tạm thời.

2. Xóa dữ liệu không phải MongoDB (Giải pháp tạm thời)

Việc giải phóng không gian bên ngoài MongoDB thường là cách nhanh nhất để đưa cơ sở dữ liệu của bạn hoạt động trở lại, đặc biệt nếu thư mục dữ liệu MongoDB không phải là vấn đề duy nhất.

Xóa nhật ký hệ thống:

sudo journalctl --vacuum-size=500M # Chỉ giữ 500MB nhật ký journal sudo journalctl --vacuum-time=7d # Chỉ giữ nhật ký trong 7 ngày qua sudo apt autoremove # Đối với Ubuntu/Debian, gỡ bỏ các gói không sử dụng sudo yum clean all # Đối với CentOS/RHEL, xóa bộ nhớ đệm gói

  
  - 
    **Xóa các tệp tạm thời:**

    ```bash

sudo rm -rf /tmp/*

Hãy thận trọng khi xóa các tệp khỏi /tmp, vì một số ứng dụng có thể đang sử dụng chúng một cách tích cực. Tuy nhiên, nhìn chung an toàn khi xóa các tệp cũ hơn không còn được sử dụng.

Xóa các bản sao lưu/ảnh chụp nhanh cũ: Nếu bạn có các bản sao lưu được lưu trữ trên cùng một ổ đĩa, hãy di chuyển chúng đến một vị trí lưu trữ khác hoặc xóa các bản cũ không còn cần thiết.

3. Dọn dẹp cụ thể cho MongoDB

3.1. Xoay vòng/Xóa nhật ký MongoDB

Các tệp nhật ký MongoDB có thể trở nên khá lớn, nhanh chóng chiếm dụng không gian đĩa. Bạn nên cấu hình xoay vòng nhật ký bằng các công cụ như logrotate trên Linux, hoặc tự xoay vòng và xóa các tệp nhật ký cũ hơn.


# Dừng MongoDB (nếu chưa dừng do đầy đĩa)
sudo systemctl stop mongod

# Di chuyển tệp nhật ký hiện tại sang bản sao lưu (hoặc xóa nếu không cần)
sudo mv /var/log/mongodb/mongod.log /var/log/mongodb/mongod.log.old

# Khởi động lại MongoDB
sudo systemctl start mongod

MongoDB sẽ tạo một tệp mongod.log mới. Sau đó, bạn có thể xóa an toàn mongod.log.old sau khi xác minh MongoDB khởi động đúng cách.

Để xoay vòng nhật ký mà không cần khởi động lại MongoDB, hãy kết nối với cơ sở dữ liệu admin và chạy:


db.adminCommand({ logRotate: 1 })

Lệnh này sẽ đổi tên tệp nhật ký hiện tại và tạo một tệp nhật ký mới. Sau đó, bạn có thể tự xóa tệp nhật ký cũ đã được xoay vòng khỏi hệ thống tệp.

3.2. Nén các Collection/Cơ sở dữ liệu

WiredTiger tái sử dụng không gian đĩa một cách thông minh trong nội bộ. Do đó, việc xóa tài liệu không phải lúc nào cũng ngay lập tức thu nhỏ các tệp dữ liệu ở cấp độ hệ điều hành. Lệnh compact giúp chống phân mảnh và thu hồi không gian không sử dụng này trong các tệp dữ liệu. Bạn có thể chạy nó trên các collection cụ thể hoặc toàn bộ cơ sở dữ liệu.

Cảnh báo: Hãy lưu ý: Việc nén có thể rất tốn tài nguyên, gây căng thẳng cho CPU và I/O, và nó có thể tạm thời làm giảm hiệu suất. Đối với các collection lớn, quá trình này có thể mất một khoảng thời gian đáng kể và đòi hỏi không gian đĩa trống bằng kích thước của collection trong quá trình hoạt động. Tốt nhất là nên lên lịch thực hiện trong các khoảng thời gian bảo trì hoặc thực hiện trên một node thứ cấp trong một replica set.


// Nén một collection cụ thể (khuyên dùng cho các collection lớn)
db.runCommand({ compact: "myCollection" })

// Nén toàn bộ cơ sở dữ liệu (hết sức thận trọng với các cơ sở dữ liệu lớn)
db.runCommand({ compact: 1 })

Sau khi nén, hãy nhớ kiểm tra lại dung lượng đĩa bằng df -h và du -sh /var/lib/mongodb.

3.3. Xóa dữ liệu không cần thiết

Nếu bạn có các collection cũ, không sử dụng hoặc thậm chí toàn bộ cơ sở dữ liệu, việc xóa chúng là một cách trực tiếp và thường mang lại hiệu quả đáng kể để giải phóng dung lượng. Đây là một hành động vĩnh viễn, vì vậy hãy luôn đảm bảo bạn có các bản sao lưu đáng tin cậy nếu có bất kỳ sự không chắc chắn nào về dữ liệu.


// Xóa một collection
db.myOldCollection.drop()

// Xóa toàn bộ cơ sở dữ liệu
use myOldDatabase
db.dropDatabase()

3.4. Sửa chữa cơ sở dữ liệu (Giải pháp cuối cùng)

Tùy chọn --repair xây dựng lại cơ sở dữ liệu của bạn từ đầu, có thể thu hồi không gian và khắc phục các lỗi có thể xảy ra. Tuy nhiên, đây là một biện pháp khắc nghiệt. Nó yêu cầu không gian đĩa trống tương đương với ít nhất kích thước thư mục dữ liệu hiện tại của bạn để hoàn tất, và nó cũng kéo theo thời gian ngừng hoạt động đáng kể.

Cảnh báo: Điều quan trọng là, đối với các replica set, nhìn chung an toàn hơn nhiều khi đồng bộ hóa lại một node thứ cấp từ một primary khỏe mạnh hơn là chạy --repair. Việc chạy --repair trên một primary chắc chắn sẽ dẫn đến thời gian ngừng hoạt động đáng kể.


# Dừng MongoDB
sudo systemctl stop mongod

# Chạy sửa chữa (đảm bảo bạn có đủ không gian trống, ít nhất bằng kích thước thư mục dữ liệu của bạn)
mongod --dbpath /var/lib/mongodb --repair

# Khởi động MongoDB
sudo systemctl start mongod

4. Tăng dung lượng ổ đĩa (Giải pháp vĩnh viễn)

Cuối cùng, giải pháp mạnh mẽ và lâu dài nhất liên quan đến việc cấp thêm dung lượng ổ đĩa cho phiên bản MongoDB của bạn.

Các nhà cung cấp đám mây (AWS, Azure, GCP): Bạn thường có thể thay đổi kích thước ổ đĩa EBS (AWS), managed disk (Azure) hoặc persistent disk (GCP) mà không cần thời gian ngừng hoạt động. Ví dụ, bạn có thể tăng ổ đĩa AWS EBS từ 100GB lên 200GB. Sau đó, bạn sẽ cần mở rộng hệ thống tệp (ví dụ: resize2fs hoặc xfs_growfs) trên hệ điều hành.
```
# Sau khi tăng kích thước đĩa trong bảng điều khiển/API đám mây
# Đối với hệ thống tệp ext4:
sudo resize2fs /dev/sda1 # Thay thế /dev/sda1 bằng thiết bị thực tế của bạn

# Đối với hệ thống tệp XFS:
sudo xfs_growfs /mount/point # Thay thế /mount/point bằng điểm gắn thực tế của bạn (ví dụ: /)
```

  
  - 
    **Máy ảo/Tại chỗ:** Điều này có thể liên quan đến việc thêm một ổ đĩa vật lý mới, mở rộng một ổ đĩa LVM hiện có hoặc di chuyển dữ liệu sang một ổ đĩa lớn hơn hoàn toàn.

  

### 5. Cấu hình nén WiredTiger (Phòng ngừa)
WiredTiger cung cấp các tùy chọn nén mạnh mẽ cho cả collection và chỉ mục, có thể giảm đáng kể mức sử dụng không gian đĩa. Hãy nhớ rằng đây là một biện pháp phòng ngừa cho sự phát triển dữ liệu trong tương lai, không phải là một giải pháp khắc phục ngay lập tức cho một ổ đĩa đã đầy.

Bạn có thể đặt nén mặc định cho các collection/chỉ mục mới hoặc thay đổi nó cho các collection/chỉ mục hiện có:

```javascript

// Đặt cấu hình nén mặc định cho các collection mới (trong mongod.conf)
storage:
  wiredTiger:
    engineConfig:
      defaultCollectionConfig:
        blockCompressor: snappy # or zlib, zstd, none
      defaultIndexConfig:
        blockCompressor: snappy

// Thay đổi cấu hình nén cho một collection hiện có
db.runCommand({
  collMod: "myCollection",
  storageEngine: {
    wiredTiger: {
      configString: "block_compressor=zlib"
    }
  }
})

Áp dụng nén cho một collection hiện có có nghĩa là ghi lại tất cả dữ liệu của nó. Đây có thể là một quá trình tốn thời gian và sẽ tiêu tốn đáng kể tài nguyên I/O. Do đó, tốt nhất nên cân nhắc thực hiện điều này trong một khoảng thời gian bảo trì đã lên lịch hoặc trên một node thứ cấp.

Các bước xác minh

Sau khi bạn đã áp dụng bất kỳ bản sửa lỗi nào trong số này, điều quan trọng là phải xác minh rằng không gian đĩa đã thực sự được thu hồi và MongoDB đang hoạt động chính xác.

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

df -h


Xác nhận rằng phân vùng đĩa hiện có đủ không gian trống, lý tưởng là 10-20% trống.

  
  - 
    **Kiểm tra nhật ký MongoDB:** Xem lại `/var/log/mongodb/mongod.log` để tìm bất kỳ lỗi mới hoặc dấu hiệu nào cho thấy MongoDB đã khởi động lại thành công và đang chấp nhận kết nối.

  
  - 
    **Thực hiện thao tác ghi:** Kết nối với MongoDB và thực hiện một thao tác ghi nhỏ để đảm bảo nó có thể ghi dữ liệu mà không gặp lỗi.

    ```javascript

    use admin
    db.testWrites.insertOne({ timestamp: new Date(), message: "Disk space test successful" })

Sau đó, kiểm tra nhật ký để tìm bất kỳ thông báo WiredTiger error nào, xác nhận rằng chúng không còn xuất hiện.

Giám sát trạng thái cơ sở dữ liệu: Kiểm tra trạng thái replica set (nếu có) và đảm bảo tất cả các thành viên đều khỏe mạnh và ở trạng thái PRIMARY hoặc SECONDARY.
```
rs.status()
```

  

## Đọc thêm

  - [MongoDB Manual: WiredTiger Storage Engine](https://www.mongodb.com/docs/manual/core/wiredtiger/)
  - [MongoDB Manual: compact Command](https://www.mongodb.com/docs/manual/reference/command/compact/)
  - [MongoDB Manual: logRotate Command](https://www.mongodb.com/docs/manual/reference/command/logRotate/)
  - [MongoDB Manual: WiredTiger Compression Configuration](https://www.mongodb.com/docs/manual/reference/configuration-options/#storage.wiredTiger.engineConfig.defaultCollectionConfig.blockCompressor)