AI 에이전트의 경우: 문서 인덱스는 https://www.mongodb.com/ko-kr/docs/llms.txt에서 사용할 수 있으며, 모든 페이지의 마크다운 버전은 어떤 URL 경로에 .md를 추가하여 사용할 수 있습니다.
Docs Menu

애플리케이션 데이터베이스를 외부 배포서버로 마이그레이션

내부적으로 managed 된 애플리케이션 데이터베이스를 사용하는 MongoDB Ops Manager 리소스를 spec.role이 AppDB(으)로 설정된 MongoDB 사용자 지정 리소스인 외부 애플리케이션 데이터베이스를 사용하는 리소스로 변환할 수 있습니다. 이렇게 하면 MongoDB Ops Manager는 애플리케이션 데이터베이스를 백업하고 복원할 수 있습니다. 더 자세히 알아보려면, Ops Manager 애플리케이션 데이터베이스 백업을 참조하세요.

마이그레이션 은 기존 애플리케이션 데이터베이스 StatefulSet 및 해당 Persistent Volumes의 소유권을 Ops Manager 리소스 에서 MongoDB 리소스 로 다시 지정합니다. Kubernetes Operator는 데이터를 이동하거나 다시 생성하지 않으며, Ops Manager 포드를 다시 시작하지 않습니다.

MongoDB Ops Manager 리소스는 내부적으로 managed 되는 애플리케이션 데이터베이스로 시작하며, Kubernetes 연산자는 <primary-om-name>-db 이라는 이름의 StatefulSet을 소유합니다. 마이그레이션은 다음과 같이 진행됩니다.

  1. 관리 Ops Manager 인스턴스 가 관리하는 프로젝트 에서 spec.role가 AppDB로 설정하다 StatefulSet와 동일한 이름을 사용하여 MongoDB 리소스 생성합니다. MongoDB 리소스 아직 StatefulSet의 소유권을 가질 수 없으므로 애플리케이션 데이터베이스 StatefulSet의 소유권을 가져올 수 없다는 메시지와 함께 Pending 단계에 머물러 있습니다.

  2. Ops Manager 리소스 에 spec.externalApplicationDatabaseRef를 추가합니다. Kubernetes Operator는 Ops Manager 리소스의 소유자 참조를 제거하고 StatefulSet를 마이그레이션 준비 완료로 표시하여 StatefulSet를 분리합니다. 그러면 MongoDB 리소스 소유권을 갖습니다.

Kubernetes Operator는 동일한 호스트 이름을 사용하는 이전과 동일한 연결 문자열 계산하기 때문에 Ops Manager 포드가 다시 시작되지 않습니다.

시작하기 전에 다음 작업을 완료하세요.

마이그레이션하기 전에 다음 고려 사항을 검토합니다.

  • MongoDB 리소스 에 설정하다 애플리케이션 데이터베이스 버전은 내부적으로 managed 애플리케이션 데이터베이스가 실행하는 버전과 일치해야 하며, 관리 Ops Manager 인스턴스 가 제공하는 MongoDB 버전이어야 합니다.

  • Kubernetes 연산자는 마이그레이션 중에 spec.applicationDatabase.passwordSecretKeyRef을(를) 지원하지 않습니다. Kubernetes 연산자는 새 비밀번호를 생성하고, 제공한 비밀번호를 로테이션합니다.

  • MongoDB 리소스 구성이 내부적으로 managed 애플리케이션 데이터베이스 구성과 다른 경우(예: 다른 포드 템플릿 또는 다른 컨테이너 설정하다 ) 애플리케이션 데이터베이스를 1~2분 동안 사용하지 못할 수 있습니다. 두 구성이 의미적으로 동일하더라도 애플리케이션 데이터베이스는 계속 사용할 수 있습니다.

  • Kubernetes 연산자는 단일 Kubernetes 클러스터에서의 마이그레이션만 지원합니다.

1
export K8S_CTX="<your-kube-context>"
export MDB_NS="mongodb"
export MANAGEMENT_OM_NAME="management-om"
export PRIMARY_OM_NAME="primary-om"
export APPDB_NAME="${PRIMARY_OM_NAME}-db"
export APPDB_VERSION="8.0.5-ent"
export MANAGEMENT_OM_URL="http://${MANAGEMENT_OM_NAME}-svc.${MDB_NS}.svc.cluster.local:8080"
export MANAGEMENT_OM_ADMIN_KEY_SECRET="<your-operator-credentials-secret>"
export APPDB_PROJECT_CONFIGMAP="${APPDB_NAME}-config"
export APPDB_PROJECT_NAME="external-appdb"
2
  1. 프라이머리 Ops Manager 리소스 와 내부적으로 managed 애플리케이션 데이터베이스가 Running 단계에 있는지 확인합니다.

    kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \
    -o jsonpath='{.status.opsManager.phase} / appdb={.status.applicationDatabase.phase}{"\n"}'
  2. MongoDB Ops Manager 리소스가 애플리케이션 데이터베이스 StatefulSet을 소유하고 있는지 확인합니다.

    kubectl get statefulset "${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \
    -o jsonpath='{range .metadata.ownerReferences[*]}{.kind}/{.name}{"\n"}{end}'

    이 명령은 MongoDBOpsManager/${PRIMARY_OM_NAME}을(를) 반환합니다.

3

orgId 값은 필수입니다. 빈 문자열로 설정하다 하면 Kubernetes Operator는 프로젝트 와 동일한 이름으로 조직 생성합니다.

kubectl create configmap "${APPDB_PROJECT_CONFIGMAP}" \
--context "${K8S_CTX}" -n "${MDB_NS}" \
--from-literal=baseUrl="${MANAGEMENT_OM_URL}" \
--from-literal=projectName="${APPDB_PROJECT_NAME}" \
--from-literal=orgId=""
4

리소스 기존 애플리케이션 데이터베이스 StatefulSet와 동일한 이름을 지정합니다.

kubectl apply --context "${K8S_CTX}" -n "${MDB_NS}" -f - <<EOF
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
name: ${APPDB_NAME}
spec:
members: 3
version: ${APPDB_VERSION}
type: ReplicaSet
role: AppDB
opsManager:
configMapRef:
name: ${APPDB_PROJECT_CONFIGMAP}
credentials: ${MANAGEMENT_OM_ADMIN_KEY_SECRET}
persistent: true
security:
authentication:
enabled: true
modes: ["SCRAM"]
ignoreUnknownUsers: true
EOF
5

MongoDB Ops Manager 리소스가 StatefulSet을 해제하지 않는 한 MongoDB 리소스는 Pending 단계에 머물러 있습니다. 이것은 예상되는 동작이며 오류가 아닙니다.

kubectl wait --for=jsonpath='{.status.phase}'=Pending \
mdb/"${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" --timeout=300s
kubectl get mdb "${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \
-o jsonpath='{.status.message}{"\n"}'

상태 메시지에서 리소스가 애플리케이션 데이터베이스 StatefulSet의 소유권을 확보할 수 없다고 보고합니다.

6
kubectl patch om "${PRIMARY_OM_NAME}" \
--context "${K8S_CTX}" -n "${MDB_NS}" \
--type merge \
-p "{\"spec\":{\"externalApplicationDatabaseRef\":{\"name\":\"${APPDB_NAME}\",\"kind\":\"MongoDB\"}}}"

동일한 패치에서 spec.applicationDatabase를 제거할 수 있습니다. 그대로 두어도 효과가 없습니다. spec.externalApplicationDatabaseRef를 설정하면 Kubernetes 연산자가 이 리소스에 대한 내부 애플리케이션 데이터베이스 관리를 중단합니다.

7
kubectl wait --for=jsonpath='{.status.phase}'=Running \
mdb/"${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" --timeout=1200s
kubectl wait --for=jsonpath='{.status.opsManager.phase}'=Running \
om/"${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" --timeout=1800s
8
  1. MongoDB 리소스 애플리케이션 데이터베이스 StatefulSet를 소유하고 있는지 확인합니다.

    kubectl get statefulset "${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \
    -o jsonpath='{range .metadata.ownerReferences[*]}{.kind}/{.name}{"\n"}{end}'

    이 명령은 MongoDB/${APPDB_NAME}을(를) 반환합니다.

  2. Ops Manager 리소스가 자신의 애플리케이션 데이터베이스를 Disabled(으)로 표시하는지 확인합니다. 이는 Kubernetes Operator가 더 이상 자신을 위해 내부 애플리케이션 데이터베이스를 관리하지 않음을 의미합니다.

    kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \
    -o jsonpath='{.status.applicationDatabase.phase}{"\n"}'
  3. 기간 및 재시작 횟수를 확인하여 Ops Manager pod가 다시 시작되지 않았는지 확인합니다.

    kubectl get pods --context "${K8S_CTX}" -n "${MDB_NS}"

MongoDB 리소스 MongoDB 버전을 사용할 수 없다는 메시지와 함께 Failed를 보고하는 경우,spec.version를 관리 Ops Manager 인스턴스 가 제공하는 버전으로 설정하다 , Ops Manager 버전과 애플리케이션 데이터베이스 버전을 동일한 주요 버전으로 유지하세요. 버전.

Kubernetes 연산자는 MongoDB 리소스가 StatefulSet의 소유권을 가지기 전에 StatefulSet을 분리해야 합니다. 프라이머리 MongoDB Ops Manager 리소스에 spec.externalApplicationDatabaseRef를 적용했는지 확인합니다. 그리고 spec.externalApplicationDatabaseRef.name의 값이 정확히 <primary-om-name>-db인지 확인합니다.

프로젝트 또는 등록 오류로 인해 MongoDB 리소스 Pending 단계로 유지되는 경우, 리소스 생성할 때 관리 Ops Manager 공개 API 준비되지 않았을 수 있습니다. 관리 Ops Manager 리소스 Running 단계에 있고 해당 API 요청에 응답하는지 확인한 다음, 리소스 다시 조정합니다.

Ops Manager 포드가 다시 시작되면 계산된 연결 문자열 변경됩니다. 기본값 포트를 사용하는 복제본 세트 의 경우 연결 문자열 마이그레이션 전후 동일합니다. Kubernetes Operator는 이 마이그레이션 에 대해 기본이 아닌 포트를 지원 하지 않습니다.