초보자를 위한 필수 MongoDB 관리 명령어

MongoDB 관리는 mongosh에서 시작되지만, 모든 명령어를 암기하는 것이 목표는 아닙니다. 목표는 안전하게 둘러보고, 현재 위치를 확인하고, 신중하게 작은 변경을 수행하며, 잘못된 데이터베이스에서 파괴적인 명령어를 실행하지 않는 방법을 아는 것입니다.

MongoDB를 처음 사용하는 경우, 먼저 로컬 인스턴스나 임시 개발 데이터베이스에서 이 명령어들을 연습하세요. 이 가이드의 dropDatabase() 및 drop()과 같은 일부 명령어는 데이터를 영구적으로 제거합니다. MongoDB는 요청한 대로 수행하며, 다른 곳에서 실행하려 했다는 것을 알지 못합니다.

mongosh로 연결

기본 포트의 로컬 MongoDB 인스턴스에 연결하려면 다음을 사용하세요:

mongosh

원격 서버의 경우 관리자나 호스팅 제공업체가 제공한 연결 문자열을 사용하세요:

mongosh "mongodb://[email protected]:27017/admin"

TLS, 복제 세트 또는 MongoDB Atlas의 경우 URI에 더 많은 옵션이 포함됩니다. 가능하면 셸 기록에 비밀번호를 붙여넣지 마세요. 프롬프트, 환경별 비밀 처리 또는 플랫폼의 자격 증명 도구를 사용하세요.

연결되면 현재 위치를 확인하세요:

db

현재 데이터베이스 컨텍스트를 출력합니다. 많은 실수는 셸이 다른 데이터베이스를 가리키고 있다고 가정하는 데서 시작됩니다.

데이터베이스 나열 및 전환

표시 가능한 데이터베이스 보기:

show dbs

사용자에게 권한이 없으면 모든 데이터베이스가 표시되지 않을 수 있습니다. 보안 환경에서는 정상입니다.

use로 데이터베이스 컨텍스트 전환:

use myAppDB

use를 실행할 때 MongoDB가 즉시 데이터베이스를 생성하지는 않습니다. 데이터가 처음 기록될 때(예: 문서를 삽입하거나 컬렉션을 명시적으로 생성할 때) 생성됩니다.

현재 데이터베이스를 다시 확인하세요:

db

스크립트의 경우 명시적 데이터베이스 핸들을 사용하여 코드가 셸 컨텍스트에 덜 의존하도록 하세요:

const appdb = db.getSiblingDB("myAppDB")
appdb.getCollectionNames()

컬렉션: 나열, 생성, 검사, 제거

현재 데이터베이스의 컬렉션 나열:

show collections

또는 JavaScript 사용:

db.getCollectionNames()

유효성 검사, 캡 동작, 또는 MongoDB 버전에서 지원하는 클러스터/인덱스 옵션과 같은 옵션이 필요할 때 명시적으로 컬렉션을 생성하세요:

db.createCollection("logs")

대부분의 애플리케이션 컬렉션은 첫 번째 삽입 시 자동으로 생성되지만, 관리 설정에서는 명시적 생성이 더 명확합니다.

컬렉션 통계 검사:

db.orders.stats()

인덱스 보기:

db.orders.getIndexes()

컬렉션 삭제는 파괴적입니다:

db.logs.drop()

공유 환경에서 실행하기 전에 데이터베이스와 컬렉션을 확인하세요:

db
db.getCollectionNames()
db.logs.countDocuments({})

매우 큰 컬렉션의 경우 countDocuments({})는 비용이 많이 들 수 있습니다. 이 경우 피크 트래픽 중에는 광범위한 카운트를 실행하는 대신 메타데이터, 샘플링 또는 운영 대시보드를 사용하세요.

테스트 문서 삽입 및 쿼리

관리자도 확인을 위한 몇 가지 기본 CRUD가 필요합니다. 작은 문서를 삽입하세요:

db.healthcheck.insertOne({ source: "admin-test", createdAt: new Date() })

다시 읽기:

db.healthcheck.find({ source: "admin-test" }).sort({ createdAt: -1 }).limit(5)

테스트 문서만 제거:

db.healthcheck.deleteMany({ source: "admin-test" })

특정 필터를 사용하세요. 학습 중에는 광범위한 삭제를 피하세요. deleteMany({})와 같은 명령어는 컬렉션의 모든 문서를 제거합니다.

사용자 관리 기본

사용자 명령어는 사용자가 정의된 데이터베이스에 대해 실행됩니다. 관리 사용자는 종종 admin에 생성됩니다. 애플리케이션 사용자는 보안 모델에 따라 애플리케이션 데이터베이스에 생성될 수 있습니다.

admin으로 전환:

use admin

프롬프트된 비밀번호로 관리 사용자 생성:

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

일반 애플리케이션의 경우 더 좁은 권한을 사용하세요. 예를 들어, myAppDB만 읽고 쓰는 앱은 광범위한 관리자 역할을 받아서는 안 됩니다:

use myAppDB

db.createUser({
  user: "myAppUser",
  pwd: passwordPrompt(),
  roles: [
    { role: "readWrite", db: "myAppDB" }
  ]
})

현재 데이터베이스의 사용자 나열:

show users

역할을 신중하게 업데이트:

db.grantRolesToUser("myAppUser", [ { role: "read", db: "reporting" } ])

역할을 제거할 때도 신중하게:

db.revokeRolesFromUser("myAppUser", [ { role: "read", db: "reporting" } ])

가장 안전한 습관은 최소 권한입니다: 사용자에게 작업에 필요한 데이터베이스와 역할만 부여하세요.

서버 상태 및 현재 작업

serverStatus는 카운터와 런타임 정보가 포함된 큰 문서를 반환합니다:

db.serverStatus()

초보자는 일반적으로 전체 문서가 필요하지 않습니다. 관심 있는 섹션만 가져오세요:

db.serverStatus().connections
db.serverStatus().mem
db.serverStatus().opcounters

현재 작업은 무언가 멈추거나 느릴 때 도움이 될 수 있습니다:

db.currentOp()

바쁜 서버에서는 필터링하세요:

db.currentOp({ active: true, secs_running: { $gte: 5 } })

작업을 가볍게 종료하지 마세요. 종료해야 하는 경우 먼저 검사하고 사용자 쿼리, 인덱스 빌드, 백업, 마이그레이션 또는 내부 복제 작업인지 이해하세요.

복제 세트 확인

배포가 복제 세트인 경우 다음 명령어가 일반적입니다:

rs.status()
rs.conf()

rs.status()는 멤버, 상태, optime 정보 및 기본 노드를 보여줍니다. 애플리케이션이 쓰기 실패를 보고하거나, 노드가 재시작되었거나, 복제 지연이 의심될 때 실행하세요.

빠른 읽기 기본 설정 확인을 위해 현재 노드가 자신을 어떻게 생각하는지 물어보세요:

db.hello()

오래된 예제는 isMaster()를 사용할 수 있습니다. 최신 MongoDB 버전은 hello를 지원합니다. 기존 스크립트에서 이전 명령어를 여전히 볼 수 있습니다.

위험한 명령어에는 의식이 필요합니다

파괴적인 작업의 경우 속도를 늦추세요. 간단한 의식으로 실제 중단을 방지할 수 있습니다:

db
show collections
// 터미널 프롬프트나 노트에서 호스트 이름 또는 연결 문자열 확인
// 프로덕션인 경우 백업 또는 복원 계획 확인
db.collectionName.drop()

데이터베이스 제거의 경우:

use databaseToRemove
db.dropDatabase()

이 명령어는 현재 데이터베이스를 삭제합니다. 위험은 구문이 아니라 잘못된 컨텍스트에 있다는 것입니다.

초보자 친화적인 관리 체크리스트

MongoDB 환경에 연결할 때 이 순서에 익숙해지세요:

db
show dbs
use myAppDB
show collections
db.orders.getIndexes()
db.serverStatus().connections
db.currentOp({ active: true })

이 명령어들은 현재 위치, 존재하는 것, 기본 액세스가 작동하는지, 그리고 지금 명백한 일이 있는지 알려줍니다.

mongosh를 먼저 검사 도구로, 그 다음에 변경 도구로 취급하면 MongoDB 관리가 훨씬 덜 위협적으로 느껴집니다. 보고, 확인한 다음 행동하세요. 좁은 역할, 프롬프트된 비밀번호, 필터링된 쿼리 및 명시적 데이터베이스 이름을 사용하세요. 이 습관은 긴 명령어 목록을 암기하는 것보다 더 중요합니다.

데이터베이스 및 컬렉션 크기를 주의 깊게 읽으세요

초보자는 종종 show dbs를 크기 측정 도구로 사용하지만, 이는 시작점일 뿐입니다. 스토리지 엔진, 압축, 인덱스 및 삭제된 공간으로 인해 크기 숫자가 예상치 못할 수 있습니다. 더 자세한 정보가 필요하면 컬렉션 통계를 사용하세요:

db.orders.stats()

인덱스 크기도 확인하세요:

db.orders.totalIndexSize()

인덱스는 무료가 아닙니다. 읽기와 일부 정렬을 빠르게 하지만, 모든 인덱스는 쓰기 오버헤드와 스토리지를 추가합니다. 컬렉션에 인덱스가 많고 쓰기가 느린 경우, 인덱스를 나열하고 어떤 쿼리가 실제로 사용하는지 물어보세요:

db.orders.getIndexes()
db.orders.find({ customerId: "c123" }).explain("executionStats")

프로덕션에서 인덱스를 가볍게 삭제하지 마세요. 사용되지 않는 것처럼 보이는 인덱스가 월간 보고서나 드물게 사용되는 관리 화면을 지원할 수 있습니다. 제거하기 전에 쿼리 로그, 애플리케이션 소유자 및 모니터링을 확인하세요.

기본 백업 인식

명령줄 관리는 항상 백업 습관과 연결되어야 합니다. 파괴적인 유지보수 전에 데이터베이스가 어떻게 백업되고 복원이 테스트되었는지 알아두세요. 자체 관리 MongoDB에서는 논리적 백업을 위해 mongodump 및 mongorestore를 볼 수 있습니다:

mongodump --uri "mongodb://user@host:27017/myAppDB" --out ./backup

대규모 프로덕션 시스템의 경우 파일 시스템 스냅샷, 클라우드 제공업체 스냅샷, Ops Manager 또는 Atlas 백업이 더 적합할 수 있습니다. 초보자 수준의 요점은 간단합니다: 테스트된 복원 경로가 없으면 drop, deleteMany 또는 역할 변경을 되돌릴 수 있다고 취급하지 마세요.

복원한 적이 없는 백업은 가정일 뿐입니다. 사고 발생 전에 자격 증명, 네트워크 액세스 및 버전 호환성을 알기 위해 비프로덕션 환경에서 복원을 연습하세요.

명령어만으로 충분하지 않을 때 로그 확인

mongosh는 서버 응답을 표시하지만 로그를 대체하지는 않습니다. 사용자가 느린 쿼리, 인증 실패 또는 연결 변동을 보고하면 MongoDB 로그와 플랫폼 로그를 확인하세요. 자체 관리 Linux 배포에서 로그는 패키지 및 구성에 따라 /var/log/mongodb/ 아래에 있을 수 있습니다. 컨테이너에서는 컨테이너 런타임 로그를 사용하세요. Atlas에서는 Atlas UI 및 다운로드 가능한 로그를 사용하세요.

초보자의 일반적인 실수는 실제 단서가 MongoDB 외부의 로그에 있는 인증 실패, DNS 문제, TLS 불일치 또는 애플리케이션 연결 풀 고갈인데 serverStatus()를 응시하는 것입니다.

데이터베이스 역할과 운영 체제 액세스의 차이점 이해

MongoDB 사용자는 Linux 사용자가 아닙니다. MongoDB에서 myAppUser를 생성해도 셸 계정이 생성되지 않습니다. 누군가에게 데이터베이스 서버에 대한 SSH 액세스를 제공해도 자동으로 데이터베이스 권한이 부여되지는 않지만, 서버가 잘못 구성된 경우 위험한 간접 액세스를 제공할 수 있습니다.

이러한 계층을 분리하세요:

Linux 사용자: 호스트 및 파일에 대한 액세스 제어
MongoDB 사용자: 데이터베이스 인증 및 권한 부여 제어
네트워크 정책: MongoDB 포트에 도달할 수 있는 사람 제어
TLS: 트래픽 보호 및 인증서 기반 ID 지원

안전한 배포는 이 모든 것을 고려해야 합니다. 방화벽 규칙 없이 데이터베이스가 공개적으로 수신 대기하면 강력한 MongoDB 비밀번호만으로는 충분하지 않습니다. 모든 애플리케이션이 관리자 역할을 사용하면 개인 네트워크만으로는 충분하지 않습니다.

프로덕션 셸을 위한 더 안전한 습관

프로덕션에서 작업할 때 프롬프트와 연결을 명확하게 만드세요. 일부 팀은 터미널 색상, 셸 별칭 또는 검사용 읽기 전용 사용자를 사용합니다. 최소한 연결 후 몇 가지 ID 확인을 실행하세요:

db.runCommand({ connectionStatus: 1 })
db
db.hello()

connectionStatus는 인증된 사용자와 역할을 보여줍니다. db는 컨텍스트를 보여줍니다. hello는 토폴로지 정보를 제공합니다. 이 세 가지 확인은 놀라운 수의 실수를 방지합니다.

일상적인 검사에는 읽기 전용 계정을 사용하세요. 특정 변경 기간에만 권한 있는 계정으로 전환하세요. 그 작은 마찰이 유용합니다. 데이터를 변경할 수 있는 작업을 수행하려고 할 때 인지하도록 강제합니다.

도움을 요청해야 할 때

일부 MongoDB 명령어는 초보자에게 친숙합니다. 일부는 그렇지 않습니다. 복제 세트 재구성, 샤딩 메타데이터, 강제 재구성, 작업 종료, 컬렉션 압축 및 라이브 시스템에서 인증 설정 변경에 주의하세요. 이러한 작업은 가용성에 영향을 줄 수 있습니다.

명령어가 클러스터 토폴로지를 변경하거나 데이터를 제거하는 경우 잠시 멈추고 두 번째 검토를 받으세요. 가장 훌륭한 관리자는 가장 빠르게 입력하는 사람이 아닙니다. 그들은 명령어에 백업, 유지보수 기간 및 다른 사람의 검토가 필요한 시기를 아는 사람들입니다.

읽기 고려 및 쓰기 고려를 높은 수준에서 이해

초보자는 첫날부터 읽기 및 쓰기 고려를 조정할 필요가 없지만, 이러한 설정이 존재한다는 것을 알아야 합니다. 쓰기 고려는 MongoDB가 쓰기 후 제공하는 승인을 제어합니다. 더 강력한 쓰기 고려는 더 많은 멤버로의 복제를 기다릴 수 있습니다. 더 약한 쓰기 고려는 더 빨리 반환될 수 있지만 장애 시 내구성에 대한 보장이 적습니다.

읽기 고려는 읽기가 요청하는 데이터 일관성 수준을 제어합니다. 많은 간단한 애플리케이션에서 기본값은 괜찮지만, 복제 세트 및 분산 시스템에서 이러한 설정은 장애 조치 후 또는 복제 지연 중에 애플리케이션이 안전하게 가정할 수 있는 것에 영향을 미칩니다.

관리적 교훈은 실용적입니다: 누군가가 "MongoDB가 쓰기를 잃었습니다" 또는 "앱이 오래된 데이터를 읽었습니다"라고 보고하면 삽입 명령어만 보지 마세요. 드라이버 설정, 쓰기 고려, 읽기 기본 설정, 읽기 고려, 복제 세트 상태 및 애플리케이션 재시도 동작을 확인하세요.

인터넷에서 복사한 예제에 주의

MongoDB 구문은 시간이 지남에 따라 변경되었습니다. 오래된 블로그 게시물은 mongosh 대신 레거시 mongo 셸, 오래된 도우미 이름 또는 여전히 작동하지만 더 이상 선호되지 않는 명령어를 사용할 수 있습니다. 일부 예제는 인증을 비활성화한 상태로 실행되며, 이는 안전한 프로덕션 가정이 아닙니다.

명령어를 복사할 때 세 가지 질문을 하세요:

이 명령어는 어떤 MongoDB 버전을 위해 작성되었나요?
어떤 데이터베이스 컨텍스트에서 실행되나요?
연결된 사용자에게 어떤 권한이 필요하나요?

명령어가 파괴적인 경우 네 번째 질문을 추가하세요: 문제가 발생하면 어떻게 복원하나요?

셸을 포기하지 않고 Compass 및 Atlas 사용

그래픽 도구는 유용합니다. MongoDB Compass는 문서, 인덱스 및 쿼리 계획을 검사하는 데 도움이 될 수 있습니다. Atlas는 호스팅된 클러스터에 대한 모니터링, 백업, 알림 및 사용자 관리를 제공합니다. 이러한 도구는 종종 원시 셸 출력보다 시각적 검사에 더 쉽습니다.

그래도 셸 명령어를 배우세요. 사고, 자동화, SSH 전용 환경 또는 문서 검토 중에 정확한 mongosh 명령어는 "UI에서 세 번째 탭을 클릭하세요"보다 공유하기 쉽습니다. 최상의 워크플로는 셸 대 GUI가 아닙니다. GUI를 사용하여 탐색하고 셸을 사용하여 반복 가능한 작업을 명확하게 표현하세요.