JetMongoDB journal files can unexpectedly consume massive amounts of disk space, often growing to 80GB or more in the /usr/local/jetapps/var/lib/mongod/journal directory. This common issue occurs when MongoDB journal files accumulate without proper cleanup, leading to critical disk space shortages that can affect system performance and stability.
This comprehensive guide provides a safe and systematic approach to fix JetMongoDB journal disk space issues without risking data loss or service interruption.
Understanding JetMongoDB Journal Files
MongoDB journal files are write-ahead log files that ensure data durability and crash recovery. In JetMongoDB installations, these files are stored in /usr/local/jetapps/var/lib/mongod/journal/ and can grow significantly over time.
What Are Journal Files?
| Component | Purpose | Location |
|---|---|---|
| Journal Files | Write-ahead logs for crash recovery | /usr/local/jetapps/var/lib/mongod/journal/ |
| WiredTiger Logs | Transaction logs for data consistency | journal/WiredTigerLog.* |
| Checkpoint Files | Database state snapshots | journal/WiredTigerPreplog.* |
| Lock Files | Database locking mechanisms | journal/WiredTiger.lock |
Why Journal Files Grow Large
Common causes of excessive journal file growth:
- High Write Operations: Frequent database writes increase journal size
- Checkpoint Delays: Delayed checkpoints prevent journal cleanup
- Service Interruptions: Improper shutdowns leave incomplete journal entries
- Backup Processes: JetBackup operations generate additional journal entries
- System Crashes: Unexpected shutdowns prevent journal rotation
Symptoms of Journal Space Issues
| Symptom | Description | Impact |
|---|---|---|
| High Disk Usage | /usr/local/jetapps/var/lib/mongod consuming 80GB+ |
System instability |
| Service Failures | JetMongoDB or JetBackup services failing | Application downtime |
| Disk Space Warnings | System alerts about low disk space | Potential data loss risk |
Prerequisites
Before proceeding with journal cleanup, ensure you have:
System Requirements
- Root Access: Administrative privileges required
- Service Control: Ability to stop/start system services
- Disk Space: Sufficient space for backup operations
- Backup Strategy: Current database backups available
Required Commands
- systemctl: Service management
- mongod: MongoDB repair operations
- mv/rm: File management operations
- du/df: Disk usage monitoring
Safety Checklist
- Database Backups: Recent backups available
- Service Dependencies: Understanding of affected services
- Maintenance Window: Low-traffic period scheduled
- Rollback Plan: Recovery procedures documented
Step-by-Step Journal Cleanup Process
Step 1: Stop Required Services
Safely stop JetMongoDB and JetBackup services to prevent data corruption:
# Stop JetMongoDB service
sudo systemctl stop jetmongod
# Stop JetBackup service
sudo systemctl stop jetbackup5d
# Verify services are stopped
sudo systemctl status jetmongod
sudo systemctl status jetbackup5d
Important: Ensure both services are completely stopped before proceeding. Running MongoDB repair while services are active can cause data corruption.
Step 2: Verify Service Status
Confirm all services are properly stopped:
# Check service status
sudo systemctl is-active jetmongod
sudo systemctl is-active jetbackup5d
# Check for any remaining MongoDB processes
ps aux | grep mongod
ps aux | grep jetbackup
# Verify no MongoDB connections
netstat -tlnp | grep 27017
Expected output: Services should show as "inactive" and no MongoDB processes should be running.
Step 3: Backup Journal Directory
Create backup of journal directory before removal:
# Create backup directory with timestamp
sudo mkdir -p /usr/local/jetapps/var/lib/mongod/journal.backup.$(date +%Y%m%d_%H%M%S)
# Move journal directory to backup location
sudo mv /usr/local/jetapps/var/lib/mongod/journal /usr/local/jetapps/var/lib/mongod/journal.backup.$(date +%Y%m%d_%H%M%S)
# Verify backup creation
ls -la /usr/local/jetapps/var/lib/mongod/
du -sh /usr/local/jetapps/var/lib/mongod/journal.backup.*
Backup naming convention:
- Format:
journal.backup.YYYYMMDD_HHMMSS - Example:
journal.backup.20241219_143022 - Retention: Keep for at least 7 days before removal
Step 4: Perform MongoDB Repair
Execute MongoDB repair to ensure database consistency:
# Navigate to JetMongoDB directory
cd /usr/local/jetapps/var/lib/mongod
# Run MongoDB repair operation
sudo /usr/local/jetapps/usr/bin/mongod --dbpath /usr/local/jetapps/var/lib/mongod --repair
Repair process details:
- Duration: Can take several minutes depending on database size
- Output: Look for "repair completed successfully" message
- Errors: Address any repair errors before continuing
- Logs: Monitor repair progress in terminal output
Common repair messages:
[initandlisten] MongoDB starting : pid=12345 port=27017 dbpath=/usr/local/jetapps/var/lib/mongod
[initandlisten] repair database local
[initandlisten] repair database admin
[initandlisten] repair database jetbackup
[initandlisten] repair completed successfully
Step 5: Restart Services
Safely restart JetMongoDB and JetBackup services:
# Start JetMongoDB service
sudo systemctl start jetmongod
# Wait for MongoDB to fully initialize
sleep 10
# Start JetBackup service
sudo systemctl start jetbackup5d
# Verify services are running
sudo systemctl status jetmongod
sudo systemctl status jetbackup5d
Service startup sequence:
- JetMongoDB first: Database must be available before JetBackup
- Wait period: Allow MongoDB to initialize journal files
- JetBackup second: Start after database is ready
Step 6: Verify Service Health
Confirm services are functioning correctly:
# Check service status
sudo systemctl is-active jetmongod
sudo systemctl is-active jetbackup5d
# Check MongoDB connection
/usr/local/jetapps/usr/bin/mongo --eval "db.runCommand('ping')"
# Monitor journal directory size
du -sh /usr/local/jetapps/var/lib/mongod/journal
# Check system logs for errors
sudo journalctl -u jetmongod -n 50
sudo journalctl -u jetbackup5d -n 50
Health indicators:
- Services: Both services show as "active"
- MongoDB: Responds to ping command
- Journal size: Should be minimal (few MB)
- Logs: No critical errors in service logs
Post-Cleanup Verification
Disk Space Recovery
Verify disk space has been recovered:
# Check overall disk usage
df -h
# Check specific directory sizes
du -sh /usr/local/jetapps/var/lib/mongod/*
du -sh /usr/local/jetapps/var/lib/mongod/journal*
# Compare before/after sizes
echo "Before cleanup: 80GB+ (estimated)"
echo "After cleanup: $(du -sh /usr/local/jetapps/var/lib/mongod/journal | cut -f1)"
Expected results:
- Journal directory: Few MB instead of 80GB+
- Total mongod directory: Significantly reduced size
- Available disk space: Substantially increased
Database Functionality Test
Test database operations to ensure functionality:
# Test basic MongoDB operations
/usr/local/jetapps/usr/bin/mongo --eval "
db.runCommand('ping');
db.adminCommand('listDatabases');
db.runCommand('dbStats');
"
# Test JetBackup functionality
sudo systemctl status jetbackup5d
Functionality checklist:
- MongoDB ping: Responds successfully
- Database listing: Shows all databases
- Statistics: Database stats accessible
- JetBackup: Service running normally
Journal Directory Management
Understanding Journal Structure
New journal directory will contain:
/usr/local/jetapps/var/lib/mongod/journal/
āāā WiredTiger.lock # Database lock file
āāā WiredTigerLog.0000000001 # Current log file
āāā WiredTigerPreplog.0000000001 # Preplog file
āāā WiredTiger.wt # WiredTiger metadata
Journal File Lifecycle
Journal files follow this lifecycle:
- Creation: New journal file created during startup
- Growth: File grows with database operations
- Checkpoint: MongoDB creates checkpoints periodically
- Cleanup: Old journal entries removed after checkpoint
- Rotation: New journal file created when needed
Preventing Future Issues
Implement these practices to prevent journal bloat:
# Regular monitoring script
#!/bin/bash
JOURNAL_SIZE=$(du -sh /usr/local/jetapps/var/lib/mongod/journal | cut -f1)
JOURNAL_SIZE_NUM=$(du -s /usr/local/jetapps/var/lib/mongod/journal | cut -f1)
# Alert if journal exceeds 10GB
if [ $JOURNAL_SIZE_NUM -gt 10485760 ]; then
echo "WARNING: Journal directory size: $JOURNAL_SIZE"
echo "Consider running journal cleanup procedure"
fi
Monitoring schedule:
- Daily: Check journal directory size
- Weekly: Review MongoDB logs for issues
- Monthly: Perform preventive maintenance
Troubleshooting Common Issues
Issue 1: Service Won't Start
Symptoms: JetMongoDB or JetBackup fails to start after cleanup
Solutions:
# Check service logs
sudo journalctl -u jetmongod -n 100
sudo journalctl -u jetbackup5d -n 100
# Verify directory permissions
ls -la /usr/local/jetapps/var/lib/mongod/
sudo chown -R jetapps:jetapps /usr/local/jetapps/var/lib/mongod/
# Check MongoDB configuration
sudo cat /etc/systemd/system/jetmongod.service
Issue 2: Database Corruption
Symptoms: MongoDB repair fails or database errors occur
Solutions:
# Restore from backup
sudo mv /usr/local/jetapps/var/lib/mongod/journal.backup.* /usr/local/jetapps/var/lib/mongod/journal
# Restart services
sudo systemctl restart jetmongod
sudo systemctl restart jetbackup5d
# Contact JetApps support if issues persist
Issue 3: Insufficient Disk Space
Symptoms: Not enough space for backup operations
Solutions:
# Clean up other large files
sudo find /var/log -name "*.log" -size +100M -delete
sudo find /tmp -type f -mtime +7 -delete
# Compress existing backups
sudo tar -czf /backup/journal-backup-$(date +%Y%m%d).tar.gz /usr/local/jetapps/var/lib/mongod/journal.backup.*
# Remove compressed backups after verification
sudo rm -rf /usr/local/jetapps/var/lib/mongod/journal.backup.*
Best Practices
Safety Best Practices
- Always Backup First: Never delete journal files without backup
- Service Order: Stop services before any file operations
- Verification: Test services after each step
- Documentation: Record all actions taken
- Rollback Plan: Know how to restore from backup
Performance Best Practices
- Regular Monitoring: Check journal size daily
- Scheduled Maintenance: Plan cleanup during low-traffic periods
- Automated Alerts: Set up disk space monitoring
- Preventive Actions: Address issues before they become critical
- Performance Testing: Verify system performance after cleanup
Maintenance Best Practices
- Backup Strategy: Maintain multiple backup copies
- Service Dependencies: Understand service relationships
- Log Analysis: Regular review of service logs
- Capacity Planning: Monitor disk usage trends
- Update Procedures: Keep JetApps software updated
Conclusion
JetMongoDB journal disk space issues can be safely resolved by following this systematic approach. The key is to stop services first, repair the database, backup journal files, and restart services in the correct order.
Key Benefits Achieved
- Disk Space Recovery: Reclaim 80GB+ of disk space
- Service Stability: Restore normal JetMongoDB and JetBackup operation
- Data Safety: Maintain database integrity throughout the process
- Prevention: Establish monitoring to prevent future issues
Success Indicators
| Metric | Before Cleanup | After Cleanup |
|---|---|---|
| Journal Size | 80GB+ | Few MB |
| Available Disk | Critical | Normal |
| Service Status | Failing | Running |
| System Performance | Degraded | Normal |
Maintenance Schedule
Recommended maintenance intervals:
- Daily: Monitor journal directory size
- Weekly: Review service logs and performance
- Monthly: Check disk usage trends
- Quarterly: Perform preventive journal cleanup
- As Needed: Address issues when journal exceeds 10GB
By following this guide, you can safely resolve JetMongoDB journal disk space issues while maintaining data integrity and service availability. Regular monitoring and preventive maintenance will help prevent these issues from recurring in the future.
Remember: Always backup before making changes, stop services before file operations, and verify functionality after each step. When in doubt, consult JetApps support or restore from backup.
