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

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

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

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

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

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

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

Kubernetes Operator는 이전과 동일한 연결 문자열을 계산하며, 이 문자열은 동일한 호스트 이름을 사용하므로 MongoDB Ops Manager Pod는 다시 시작되지 않습니다.

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

  • Kubernetes 연산자를 설치하고 kubectl. 자세한 내용은 Kubernetes로 설치를 참조하세요.

  • 내부적으로 managed 애플리케이션 데이터베이스를 사용하는 프라이머리 MongoDB Ops Manager 리소스를 배포합니다. 이 리소스는 spec.applicationDatabase를 설정하고, Kubernetes 연산자는 <primary-om-name>-db이라는 이름의 StatefulSet을 소유합니다. 자세히 알아보려면 Ops Manager 리소스 배포를 참조하세요.

  • Running 단계에 있고 외부 애플리케이션 데이터베이스에 대한 프로젝트를 소유하는 관리 Ops Manager 리소스를 배포합니다. 자세한 내용은 외부 애플리케이션 데이터베이스를 사용하여 Ops Manager 배포를 참조하세요.

  • Create credentials for the Kubernetes Operator. The secret holds the programmatic API key pair that the Kubernetes Operator uses to authenticate to the management Ops Manager API on your behalf. You can give the secret any name. To learn more, see Create Credentials for the Kubernetes Operator.

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

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

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

  • MongoDB 리소스 구성이 내부적으로 managed되는 애플리케이션 데이터베이스 구성(예: 다른 Pod 템플릿 또는 다른 컨테이너 세트)과 다른 경우 애플리케이션 데이터베이스를 1~2분 동안 사용할 수 없을 수 있습니다. 두 구성이 의미상 동일하면 애플리케이션 데이터베이스는 계속 사용할 수 있습니다.

  • 멀티 클러스터 애플리케이션 데이터베이스를 마이그레이션 하려면 내부적으로 managed 애플리케이션 데이터베이스는 spec.applicationDatabase.topology을 MultiCluster로 설정하다 하고 외부 애플리케이션 데이터베이스는 MongoDBMultiCluster 리소스 여야 합니다. Kubernetes Operator는 현재 애플리케이션 데이터베이스의 토폴로지 외부 애플리케이션 데이터베이스의 종류와 일치하지 않는 경우 마이그레이션 을 거부합니다. 자세한 학습 은 멀티 클러스터 애플리케이션 데이터베이스 마이그레이션을 참조하세요.

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. 프라이머리 MongoDB 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 값은 필수입니다. 이를 빈 string으로 설정하면 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 - <<EOFapiVersion: mongodb.com/v1kind: MongoDBmetadata: 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: trueEOF
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의 age와 restart 횟수를 확인하여 Pod가 재시작되지 않았는지 확인합니다.

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

프라이머리 Ops Manager 리소스 내부적으로 managed 멀티 클러스터 애플리케이션 데이터베이스를 사용하는 경우, 이를 외부 MongoDBMultiCluster 리소스 로 마이그레이션 할 수 있습니다. Kubernetes Operator는 각 멤버 클러스터 에서 애플리케이션 데이터베이스 StatefulSet를 분리하고, MongoDBMultiCluster 리소스 각 멤버를 채택합니다. 연결 문자열 변경되지 않으므로 Ops Manager pod가 다시 시작되지 않습니다.

이 절차는 이 페이지의 단일 클러스터 절차와 일치하지만 다음과 같은 차이점이 있습니다.

  • 내부적으로 managed 애플리케이션 데이터베이스는 spec.applicationDatabase.topology을 MultiCluster로 설정하다 해야 합니다.

  • 외부 애플리케이션 데이터베이스는 내부적으로 managed 애플리케이션 데이터베이스와 이름, 멤버 레이아웃 및 TLS 구성이 동일한 spec.role가 AppDB로 설정하다 MongoDBMultiCluster 리소스 여야 합니다. 멀티 클러스터 외부 애플리케이션 데이터베이스에는 서비스 메시 유무에 관계없이 멤버 클러스터 간의 TLS 암호화 및 클러스터 간 네트워킹이 필요합니다. 자세한 학습 은 멀티 클러스터 외부 애플리케이션 데이터베이스 배포를 참조하세요.

  • spec.externalApplicationDatabaseRef를 추가할 때 kind을 MongoDBMultiCluster로 설정합니다:

    kubectl patch om "${PRIMARY_OM_NAME}" \ --context "${K8S_CTX}" -n "${MDB_NS}" \ --type merge \ -p "{\"spec\":{\"externalApplicationDatabaseRef\":{\"name\":\"${APPDB_NAME}\",\"kind\":\"MongoDBMultiCluster\"}}}"
  • Kubernetes Operator는 각 멤버 클러스터 에서 소유권 이양을 수행합니다. 마이그레이션 을 확인하려면 <primary-om-name>-db-<cluster-index>로 명명된 각 멤버 클러스터 에서 애플리케이션 데이터베이스 StatefulSet를 검사합니다.

    kubectl get statefulset "${APPDB_NAME}-0" --context "${K8S_CTX_MEMBER}" -n "${MDB_NS}" \ -o jsonpath='{.metadata.labels.mongodbmulticluster}{"\n"}'

    이 명령은 <namespace>-<appdb-name>을 반환하고 mongodb.com/appdb-migration-ready 주석이 지워집니다. 멀티 클러스터 배포에서의 소유권 추적에 대해 자세히 학습 보려면 마이그레이션 주석을 참조하세요.

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

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

MongoDB 리소스가 프로젝트 또는 등록 오류로 Pending 단계에 머물러 있는 경우, 관리 MongoDB Ops Manager 공개 API가 리소스를 만들 때 준비되지 않았을 수도 있습니다. 관리 MongoDB Ops Manager 리소스가 Running 단계에 있는지 및 해당 API가 요청에 답변하는지 확인한 다음 리소스를 다시 조정합니다.

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