외부 애플리케이션 데이터베이스를 MongoDB Ops Manager로 반환

MongoDB Ops Manager 리소스를 통해 외부 애플리케이션 데이터베이스를 내부 관리로 전환할 수 있습니다. MongoDB Ops Manager 리소스가 기존 애플리케이션 데이터베이스 StatefulSet를 회수합니다. 그리고 당신은 이를 managed한 MongoDB 리소스를 삭제합니다. Kubernetes 연산자는 사용자 데이터를 이동하거나 다시 만들지 않으며 MongoDB Ops Manager Pod를 다시 시작하지 않습니다.

마이그레이션 작동 방법

MongoDB Ops Manager 리소스는 외부 애플리케이션 데이터베이스로 시작합니다. 이 데이터베이스는 spec.role이 AppDB로 설정되고 <primary-om-name>-db로 이름 지정된 MongoDB 리소스이며, 애플리케이션 데이터베이스 StatefulSet의 소유자입니다. 마이그레이션은 다음과 같이 진행됩니다.

MongoDB Ops Manager 리소스에서 spec.externalApplicationDatabaseRef를 제거하고 spec.applicationDatabase.를 추가합니다.
Kubernetes Operator는 MongoDB 리소스에 StatefulSet을 해제하도록 요청합니다. MongoDB 리소스는 MongoDB Ops Manager 리소스가 이를 회수할 때까지 기다리는 동안 Pending 단계를 보고합니다.
Kubernetes 연산자는 StatefulSet을 회수하고 이를 내부 애플리케이션 데이터베이스로 관리합니다. 연결 문자열이 변경되지 않기 때문에 Ops Manager pod는 재시작되지 않습니다.
더 이상 소유한 항목이 없는 MongoDB 리소스를 삭제합니다.

경고

MongoDB Ops Manager 리소스가 내부 애플리케이션 데이터베이스를 다시 관리한 후에만 MongoDB 리소스를 삭제. MongoDB 리소스가 여전히 StatefulSet을 소유하고 있는 상태에서 삭제하면 Kubernetes가 애플리케이션 데이터베이스를 가비지 수집합니다. 해당 상태에서 복구하려면 유지된 Persistent Volume Claims에서 애플리케이션 데이터베이스를 다시 생성해야 하며, 이로 인해 가동 중지 시간이 발생하고 애플리케이션 데이터베이스 자격 증명이 교체됩니다.

전제 조건

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

Kubernetes 연산자를 설치하고 kubectl. 자세한 내용은 Kubernetes로 설치를 참조하세요.
프라이머리 MongoDB Ops Manager 리소스가 외부 애플리케이션 데이터베이스를 사용하는지 확인합니다. spec.externalApplicationDatabaseRef를 <primary-om-name>-db이라는 이름의 MongoDB 리소스로 설정하고, spec.applicationDatabase는 설정하지 않으며, status.applicationDatabase.phase 에서는 Disabled을 보고합니다.
MongoDB 리소스가 Running 단계에 있고 애플리케이션 데이터베이스 StatefulSet을 소유하는지 확인합니다.

고려 사항

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

애플리케이션 데이터베이스가 이미 실행 중인 버전으로 spec.applicationDatabase.version를 설정하세요. 동일한 버전을 재사용하면 동일한 바이너리와 데이터가 그대로 유지됩니다. 다른 버전은 핸드오버와 동시에 애플리케이션 데이터베이스 업그레이드를 시작합니다.
Kubernetes Operator는 외부 애플리케이션 데이터베이스를 위해 생성한 MongoDB Ops Manager 프로젝트를 삭제하지 않습니다. 해당 프로젝트를 제거하면 애플리케이션 데이터베이스의 과거 지표를 읽을 수 없게 되므로 정리 여부는 사용자가 결정해야 합니다.

절차

마이그레이션을 위한 환경 변수를 설정합니다.

export K8S_CTX="<your-kube-context>"export MDB_NS="mongodb"
export PRIMARY_OM_NAME="primary-om"export APPDB_NAME="${PRIMARY_OM_NAME}-db"export APPDB_VERSION="8.0.5-ent"

시작 상태를 확인합니다.

MongoDB Ops Manager 리소스가 외부 애플리케이션 데이터베이스를 참조하고 해당 애플리케이션 데이터베이스를 Disabled(으)로 보고하는지 확인합니다.
```
kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \  -o jsonpath='ref={.spec.externalApplicationDatabaseRef.name} appdb={.status.applicationDatabase.phase}{"\n"}'
```
확인하세요: 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}을(를) 반환합니다.

MongoDB Ops Manager 리소스가 내부 애플리케이션 데이터베이스를 사용하도록 재구성합니다.

이 패치는 spec.externalApplicationDatabaseRef를 제거하고 spec.applicationDatabase.를 추가합니다.

kubectl patch om "${PRIMARY_OM_NAME}" \  --context "${K8S_CTX}" -n "${MDB_NS}" \  --type merge \  -p "{\"spec\":{\"externalApplicationDatabaseRef\":null,\"applicationDatabase\":{\"members\":3,\"version\":\"${APPDB_VERSION}\"}}}"

MongoDB Ops Manager 리소스가 StatefulSet을 회수할 때까지 기다립니다.

MongoDB 리소스가 StatefulSet을 해제하는지 확인합니다. 리소스는 MongoDB Ops Manager 리소스로 역방향 마이그레이션 중이라는 메시지와 함께 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"}'
```
내부 애플리케이션 데이터베이스를 다시 관리할 수 있도록 MongoDB Ops Manager 리소스를 기다립니다.
```
kubectl wait --for=jsonpath='{.status.applicationDatabase.phase}'=Running \  om/"${PRIMARY_OM_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
```

MongoDB 리소스를 삭제합니다.

이전 단계에서 applicationDatabase.phase=Running이(가) 보고된 후에만 이 단계를 완료하세요.

kubectl delete mdb "${APPDB_NAME}" \  --context "${K8S_CTX}" -n "${MDB_NS}" --wait=true --timeout=300s

마이그레이션을 확인합니다.

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}을(를) 반환합니다.
MongoDB Ops Manager 리소스가 애플리케이션 데이터베이스를 Running으로 보고하고 MongoDB 리소스가 더 이상 존재하지 않는지 확인합니다.
```
kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \  -o jsonpath='{.status.applicationDatabase.phase}{"\n"}'
kubectl get mdb --context "${K8S_CTX}" -n "${MDB_NS}"
```
Ops Manager Pod의 age와 restart 횟수를 확인하여 Pod가 재시작되지 않았는지 확인합니다.
```
kubectl get pods --context "${K8S_CTX}" -n "${MDB_NS}"
```

멀티 클러스터 애플리케이션 데이터베이스 반환

프라이머리 Ops Manager 리소스 외부 MongoDBMultiCluster 애플리케이션 데이터베이스를 참조하는 경우, 이를 내부적으로 managed 멀티 클러스터 애플리케이션 데이터베이스로 반환할 수 있습니다. Kubernetes Operator는 MongoDBMultiCluster 리소스 각 멤버 클러스터 에서 애플리케이션 데이터베이스 StatefulSet를 출시하다 하도록 요청합니다. 그런 다음 Ops Manager 리소스 각 StatefulSet를 내부 애플리케이션 데이터베이스로 다시 채택합니다. 연결 문자열 변경되지 않으므로 Ops Manager pod가 다시 시작되지 않습니다.

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

멤버 클러스터 및 애플리케이션 데이터베이스 TLS 구성에 대해 다음과 같은 추가 환경 변수를 설정합니다. 외부 애플리케이션 데이터베이스에서 사용하는 것과 동일한 값을 사용합니다.
```
export K8S_CTX_MEMBER_1="<member-cluster-1-context>"export K8S_CTX_MEMBER_2="<member-cluster-2-context>"export APPDB_CERT_PREFIX="appdb"export APPDB_CA_CONFIGMAP="${APPDB_NAME}-ca"
```
복원된 spec.applicationDatabase는 topology를 MultiCluster로 설정하다 해야 하며, Ops Manager 리소스 기존 StatefulSet를 다시 채택할 수 있도록 외부 애플리케이션 데이터베이스와 동일한 멤버 레이아웃 및 TLS 구성을 사용해야 합니다.
```
kubectl patch om "${PRIMARY_OM_NAME}" \  --context "${K8S_CTX}" -n "${MDB_NS}" \  --type merge \  -p "{\"spec\":{\"externalApplicationDatabaseRef\":null,\"applicationDatabase\":{\"topology\":\"MultiCluster\",\"version\":\"${APPDB_VERSION}\",\"security\":{\"certsSecretPrefix\":\"${APPDB_CERT_PREFIX}\",\"tls\":{\"ca\":\"${APPDB_CA_CONFIGMAP}\"}},\"clusterSpecList\":[{\"clusterName\":\"${K8S_CTX_MEMBER_1}\",\"members\":2},{\"clusterName\":\"${K8S_CTX_MEMBER_2}\",\"members\":2}]}}}"
```
Ops Manager 리소스 StatefulSet를 회수하는 동안 MongoDBMultiCluster 리소스 Pending 단계를 보고합니다. status.applicationDatabase.phase가 Running를 보고한 후에만 MongoDBMultiCluster 리소스 삭제합니다.
마이그레이션 을 확인하려면 <primary-om-name>-db-<cluster-index>로 명명된 각 멤버 클러스터 의 애플리케이션 데이터베이스 StatefulSet를 검사합니다. 핸드오버 후 StatefulSet는 빈 ownerReferences을(를) 남기고 유지되며, Ops Manager 리소스 이를 내부 애플리케이션 데이터베이스로 관리합니다.

일반적인 마이그레이션 문제점

MongoDB 리소스가 StatefulSet을 해제하지 않습니다.

MongoDB 리소스가 Running 단계에 머물러 있고 여전히 StatefulSet을 소유하고 있다면, MongoDB Ops Manager 리소스가 릴리스를 요청하지 않은 것입니다. 패치 세트 spec.externalApplicationDatabaseRef가 null로 지정되었고 spec.applicationDatabase이(가) 추가되었는지 확인합니다.

애플리케이션 데이터베이스 버전이 일치하지 않습니다.

spec.applicationDatabase.version를 애플리케이션 데이터베이스가 이미 실행 중인 버전으로 설정하여 회수된 StatefulSet이 동일한 바이너리를 유지할 수 있도록 합니다.

MongoDB 리소스를 너무 일찍 삭제했습니다

StatefulSet을 여전히 소유하고 있는 상태에서 MongoDB 리소스를 삭제하면 Kubernetes는 StatefulSet과 MongoDB Ops Manager 리소스와 공유하는 비밀을 가비지 수집합니다. 복구하려면 유지된 Persistent Volume Claims에서 애플리케이션 데이터베이스를 다시 만듭니다. 이 경로는 가동 중지 시간을 유발하고 애플리케이션 데이터베이스 자격 증명을 순환합니다. 자세한 내용은 MongoDB Ops Manager의 재해 복구 및 AppDB 리소스를 참조하세요.

다음 단계

외부 애플리케이션 데이터베이스를 다시 사용하려면 애플리케이션 데이터베이스를 외부 배포서버로 마이그레이션을 참조하세요.

돌아가기

외부 애플리케이션 데이터베이스로 마이그레이션

업그레이드