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

멀티 클러스터 외부 애플리케이션 데이터베이스 배포

멀티 클러스터 외부 애플리케이션 데이터베이스를 사용하는 Ops Manager 리소스 , 즉 spec.role가 AppDB로 설정하다 MongoDBMultiCluster 사용자 지정 리소스 배포 할 수 있습니다. 이 리소스 애플리케이션 데이터베이스 멤버를 여러 Kubernetes 클러스터에 분산시킵니다. 두 번째 Ops Manager 인스턴스 리소스 프로젝트 로 관리하여 Ops Manager 애플리케이션 데이터베이스를 백업 및 복원 수 있도록 합니다. 자세한 학습 은 Ops Manager 애플리케이션 데이터베이스 백업을 참조하세요.

이 절차에서는 새 Ops Manager 인스턴스 배포합니다. 내부적으로 managed 멀티 클러스터 애플리케이션 데이터베이스를 사용하는 기존 Ops Manager 인스턴스 변환하려면 멀티 클러스터 애플리케이션 데이터베이스 마이그레이션을 참조하세요. 이 절차의 단일 클러스터 변형에 대해서는 외부 애플리케이션 데이터베이스를 사용하여 Ops Manager 배포를 참조하세요.

이 절차는 다음 리소스를 배포합니다.

  • 내부적으로 managed 자체 애플리케이션 데이터베이스가 있는 관리 Ops Manager 인스턴스 ,중앙 클러스터 에서 실행 . 이 인스턴스 외부 애플리케이션 데이터베이스가 포함된 프로젝트 관리합니다.

  • 외부 애플리케이션 데이터베이스: spec.role이(가) AppDB(으)로 설정하다 MongoDBMultiCluster 복제본 세트 (<primary-om-name>-db)입니다. Kubernetes Operator는 <primary-om-name>-db-<cluster-index>라는 이름의 클러스터 멤버당 하나의 StatefulSet를 생성합니다.

  • spec.applicationDatabase를 생략하고 spec.externalApplicationDatabaseRef가 MongoDBMultiCluster 종류로 설정하다 외부 애플리케이션 데이터베이스를 참조하는 프라이머리 Ops Manager 인스턴스 .

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

  • 세 개의 Kubernetes 클러스터를 배포하며, 각 클러스터에는 기본값 StorageClass가 있으며,중앙 클러스터 1개와 멤버 클러스터 2개입니다.

  • 클러스터에 걸쳐 있고 클러스터 간 서비스 검색을 제공하는 서비스 메시를 배포합니다. 애플리케이션 데이터베이스 멤버는 메시를 통해 클러스터 간에 통신합니다.

    이 절차에서는 Istio를 사용하지만, cluster 전체의 Pod 간에 FQDN 호스트 이름 확인을 제공하는 모든 서비스 메시를 사용할 수 있습니다. 서비스 메시는 멀티 클러스터 외부 애플리케이션 데이터베이스 자체의 요구 사항이 아닙니다. no-mesh 배포서버 패턴 에 대해서는 서비스 메시가 없는 Multi-Cluster Ops Manager 참조하세요.

  • kubectl, helm 및 kubectl mongodb 플러그인을 설치하고 세 클러스터 모두에 대해 구성합니다.

  • Kubernetes 연산자 Helm 차트에 대한 액세스 권한을 얻습니다.

배포 전에 다음 고려 사항을 검토하세요.

  • Ops Manager 버전과 애플리케이션 데이터베이스 버전을 일관적인 쌍으로 설정합니다. 관리 MongoDB Ops Manager 인스턴스는 외부 애플리케이션 데이터베이스를 관리하므로 애플리케이션 데이터베이스 버전은 관리 MongoDB Ops Manager 인스턴스가 버전 매니페스트에서 제공하는 MongoDB 버전이어야 합니다. 예시, 8.0.x MongoDB Ops Manager 인스턴스는 8.0.x를 제공합니다. MongoDB 버전이지만 7.0.x MongoDB Ops Manager 인스턴스는 그렇지 않습니다. 호환되는 쌍을 찾으려면 애플리케이션 데이터베이스 호환성 매트릭스를 참조하세요.

  • 멀티 클러스터 외부 애플리케이션 데이터베이스에는 TLS 암호화 필요합니다. 애플리케이션 데이터베이스가 TLS를 사용할 경우, MongoDB Agent downloads.mongodb.com에서 MongoDB 바이너리 다운로드 포함하여 spec.security.tls.ca의 CA 번들에 대해 모든 아웃바운드 HTTPS 연결의 유효성을 검사합니다. CA 번들은 자체 CA와 함께 downloads.mongodb.com에 서명하는 공개 루트를 포함해야 합니다. 멀티 클러스터 배포서버 위한 TLS 인증서를 구성하려면 TLS 인증서 관리를 참조하세요.

  • 중앙 클러스터 Ops Manager 인스턴스인 Kubernetes Operator를 실행하며 MongoDBMultiCluster 리소스 보유합니다.멤버 클러스터는 애플리케이션 데이터베이스 데이터 파드를 실행 .

1
export K8S_CTX_0="<central-cluster-context>"export K8S_CTX_1="<member-cluster-1-context>"export K8S_CTX_2="<member-cluster-2-context>"export MDB_NS="mongodb" export OPERATOR_HELM_CHART="oci://quay.io/mongodb/helm-charts/mongodb-kubernetes" export OM_VERSION="8.0.7"export APPDB_VERSION="8.0.5-ent" export MANAGEMENT_OM_NAME="management-om"export PRIMARY_OM_NAME="primary-om" export APPDB_NAME="${PRIMARY_OM_NAME}-db"export APPDB_MEMBERS_C1=2export APPDB_MEMBERS_C2=2 export MANAGEMENT_OM_URL="http://${MANAGEMENT_OM_NAME}-svc.${MDB_NS}.svc.cluster.local:8080"export MANAGEMENT_OM_ADMIN_KEY_SECRET="${MDB_NS}-${MANAGEMENT_OM_NAME}-admin-key" export APPDB_PROJECT_CONFIGMAP="${APPDB_NAME}-config"export APPDB_PROJECT_NAME="external-appdb"export APPDB_CONNECTION_STRING_SECRET="${APPDB_NAME}-connection-string" export CERT_MANAGER_NAMESPACE="cert-manager"export APPDB_TLS_SELF_SIGNED_ISSUER="mongodb-self-signed-issuer"export APPDB_TLS_CA_CERT_NAME="mongodb-ca"export APPDB_TLS_CA_SECRET_NAME="mongodb-ca-key-pair"export APPDB_TLS_CA_ISSUER="mongodb-ca-issuer"export APPDB_CERT_PREFIX="appdb"export APPDB_CA_CONFIGMAP="${APPDB_NAME}-ca" export OM_ADMIN_EMAIL="admin@example.com"export OM_ADMIN_PASSWORD="<your-password>"export OM_ADMIN_FIRST_NAME="Admin"export OM_ADMIN_LAST_NAME="User"

Kubernetes Operator는 외부 애플리케이션 데이터베이스의 이름을 <primary-om-name>-db으로 지정해야 하므로 APPDB_NAME은 PRIMARY_OM_NAME에서 파생됩니다.

2

네임스페이스 는 중앙 클러스터 와 두 멤버 클러스터에 모두 존재해야 합니다. istio-injection=enabled 레이블은 애플리케이션 데이터베이스 파드에 사이드카를 추가하여 에이전트가 클러스터 전체에서 관리 Ops Manager 서비스를 확인할 수 있도록 합니다.

for ctx in "${K8S_CTX_0}" "${K8S_CTX_1}" "${K8S_CTX_2}"; do kubectl create namespace "${MDB_NS}" --context "${ctx}" --dry-run=client -o yaml \ | kubectl apply --context "${ctx}" -f - kubectl label namespace "${MDB_NS}" istio-injection=enabled --overwrite --context "${ctx}"done
3

kubectl mongodb 플러그인을 사용하여 클러스터 전체에서 서비스 계정 및 역할을 구성한 다음, 멤버 클러스터가 등록된 중앙 클러스터 에 Kubernetes Operator를 설치합니다. 자세한 학습 은 멀티 클러스터 배포 필수 구성 요소를 참조하세요.

kubectl mongodb multicluster setup \ --central-cluster="${K8S_CTX_0}" \ --member-clusters="${K8S_CTX_0},${K8S_CTX_1},${K8S_CTX_2}" \ --member-cluster-namespace="${MDB_NS}" \ --central-cluster-namespace="${MDB_NS}" \ --create-service-account-secrets \ --install-database-roles=true helm upgrade --install --kube-context "${K8S_CTX_0}" \ --create-namespace --namespace "${MDB_NS}" \ mongodb-kubernetes-operator-multi-cluster \ --set operator.name=mongodb-kubernetes-operator-multi-cluster \ --set operator.createOperatorServiceAccount=false \ --set operator.createResourcesServiceAccountsAndRoles=false \ --set "multiCluster.clusters={${K8S_CTX_0},${K8S_CTX_1},${K8S_CTX_2}}" \ "${OPERATOR_HELM_CHART}" kubectl rollout status deployment/mongodb-kubernetes-operator-multi-cluster \ --context "${K8S_CTX_0}" -n "${MDB_NS}" --timeout=300s
4

양쪽의 MongoDB Ops Manager 리소스는 spec.adminCredentials로 이 시크릿을 참조합니다.

kubectl create secret generic ops-manager-admin-secret \ --context "${K8S_CTX_0}" -n "${MDB_NS}" \ --from-literal=Username="${OM_ADMIN_EMAIL}" \ --from-literal=Password="${OM_ADMIN_PASSWORD}" \ --from-literal=FirstName="${OM_ADMIN_FIRST_NAME}" \ --from-literal=LastName="${OM_ADMIN_LAST_NAME}"
5

멀티 클러스터 애플리케이션 데이터베이스 멤버는 TLS를 사용하므로 cert-manager가 CA 및 애플리케이션 데이터베이스 서버 인증서를 발급해야 합니다.

helm upgrade --install --kube-context "${K8S_CTX_0}" \ cert-manager jetstack/cert-manager \ --namespace "${CERT_MANAGER_NAMESPACE}" --create-namespace \ --set crds.enabled=true
6

서명 체인을 생성한 다음, Kubernetes Operator가 spec.security.tls.ca로 참조하는 ConfigMap에 CA를 게시합니다. 번들은 자체 서명된 CA와 호스트의 공용 CA 번들을 결합하는데, 이는 MongoDB Agent 이 번들에 대해 downloads.mongodb.com에서 다운로드 MongoDB 바이너리의 유효성을 검사하기 때문입니다. 결합된 번들이 클라이언트 사이드 kubectl apply 주석의 크기 제한을 초과하므로 ConfigMap 서버 사이드를 적용 .

kubectl apply --context "${K8S_CTX_0}" -f - <<EOFapiVersion: cert-manager.io/v1kind: ClusterIssuermetadata: name: ${APPDB_TLS_SELF_SIGNED_ISSUER}spec: selfSigned: {}EOF kubectl apply --context "${K8S_CTX_0}" -n "${CERT_MANAGER_NAMESPACE}" -f - <<EOFapiVersion: cert-manager.io/v1kind: Certificatemetadata: name: ${APPDB_TLS_CA_CERT_NAME}spec: isCA: true commonName: mongodb-ca secretName: ${APPDB_TLS_CA_SECRET_NAME} duration: 87600h renewBefore: 8760h privateKey: algorithm: ECDSA size: 256 issuerRef: name: ${APPDB_TLS_SELF_SIGNED_ISSUER} kind: ClusterIssuerEOF kubectl wait --for=condition=Ready certificate/"${APPDB_TLS_CA_CERT_NAME}" \ -n "${CERT_MANAGER_NAMESPACE}" --context "${K8S_CTX_0}" --timeout=120s kubectl apply --context "${K8S_CTX_0}" -f - <<EOFapiVersion: cert-manager.io/v1kind: ClusterIssuermetadata: name: ${APPDB_TLS_CA_ISSUER}spec: ca: secretName: ${APPDB_TLS_CA_SECRET_NAME}EOF ca_crt=$(kubectl get secret "${APPDB_TLS_CA_SECRET_NAME}" \ -n "${CERT_MANAGER_NAMESPACE}" --context "${K8S_CTX_0}" \ -o jsonpath='{.data.ca\.crt}' | base64 -d) system_ca=""for candidate in /etc/ssl/certs/ca-certificates.crt /etc/pki/tls/certs/ca-bundle.crt /etc/ssl/cert.pem; do [[ -r "${candidate}" ]] && { system_ca=$(cat "${candidate}"); break; }done ca_bundle_file=$(mktemp)printf '%s\n%s\n' "${ca_crt}" "${system_ca}" > "${ca_bundle_file}" kubectl create configmap "${APPDB_CA_CONFIGMAP}" \ --context "${K8S_CTX_0}" -n "${MDB_NS}" \ --from-file=ca-pem="${ca_bundle_file}" \ --from-file=mms-ca.crt="${ca_bundle_file}" \ --dry-run=client -o yaml \ | kubectl apply --server-side --force-conflicts --context "${K8S_CTX_0}" -n "${MDB_NS}" -f - rm -f "${ca_bundle_file}"
7

인증서 시크릿 이름은 Kubernetes 연산자 규칙 <certs-secret-prefix>-<appdb-name>-cert을 따릅니다. 와일드카드 dnsNames 항목은 모든 클러스터 에 있는 모든 애플리케이션 데이터베이스 멤버의 서비스 FQDN을 다룹니다.

kubectl apply --context "${K8S_CTX_0}" -n "${MDB_NS}" -f - <<EOFapiVersion: cert-manager.io/v1kind: Certificatemetadata: name: ${APPDB_CERT_PREFIX}-${APPDB_NAME}-certspec: secretName: ${APPDB_CERT_PREFIX}-${APPDB_NAME}-cert duration: 8760h renewBefore: 720h privateKey: algorithm: RSA size: 2048 usages: ["server auth", "client auth"] dnsNames: - "*.${MDB_NS}.svc.cluster.local" issuerRef: name: ${APPDB_TLS_CA_ISSUER} kind: ClusterIssuerEOF kubectl wait --for=condition=Ready certificate/"${APPDB_CERT_PREFIX}-${APPDB_NAME}-cert" \ -n "${MDB_NS}" --context "${K8S_CTX_0}" --timeout=120s
8
kubectl apply --context "${K8S_CTX_0}" -n "${MDB_NS}" -f - <<EOFapiVersion: mongodb.com/v1kind: MongoDBOpsManagermetadata: name: ${MANAGEMENT_OM_NAME}spec: replicas: 1 version: ${OM_VERSION} adminCredentials: ops-manager-admin-secret applicationDatabase: members: 3 version: ${APPDB_VERSION} backup: enabled: false configuration: automation.versions.source: mongodb mms.ignoreInitialUiSetup: "true" mms.adminEmailAddr: admin@example.com mms.fromEmailAddr: admin@example.com mms.replyToEmailAddr: admin@example.com mms.mail.hostname: email-smtp.us-east-1.amazonaws.com mms.mail.port: "465" mms.mail.ssl: "true" mms.mail.transport: smtp mms.minimumTLSVersion: TLSv1.2EOF

mms.* 메일 설정이 필요합니다. mms.ignoreInitialUiSetup이(가) true인 경우, mms.fromEmailAddr 및 관련 메일 설정이 없으면 MongoDB Ops Manager 사전 검사에서 MongoDB Ops Manager가 시작되지 않습니다.

9
  1. 내부적으로 managed 애플리케이션 데이터베이스 및 MongoDB Ops Manager 리소스를 기다립니다:

    kubectl wait --for=jsonpath='{.status.applicationDatabase.phase}'=Running \ om/"${MANAGEMENT_OM_NAME}" --context "${K8S_CTX_0}" -n "${MDB_NS}" --timeout=1200s kubectl wait --for=jsonpath='{.status.opsManager.phase}'=Running \ om/"${MANAGEMENT_OM_NAME}" --context "${K8S_CTX_0}" -n "${MDB_NS}" --timeout=1800s
  2. MongoDB Ops Manager 공개 API가 요청에 응답하는지 확인하세요. opsManager.phase 의 Running는 MongoDB Ops Manager 팟이 작동 중이지만 Kubernetes 연산자가 애플리케이션 데이터베이스 프로젝트를 만들때 사용하는 API는 수 초 지연될 수 있습니다. 401 응답은 예상되는 인증되지 않은 응답이며, API가 준비되었음을 의미합니다.

    om_pod="${MANAGEMENT_OM_NAME}-0"until [ "$(kubectl exec "${om_pod}" -c mongodb-ops-manager --context "${K8S_CTX_0}" -n "${MDB_NS}" -- \ curl -s -o /dev/null -w '%{http_code}' \ "http://$(kubectl get pod "${om_pod}" --context "${K8S_CTX_0}" -n "${MDB_NS}" \ -o jsonpath='{.status.podIP}'):8080/api/public/v1.0" 2>/dev/null)" = "401" ]; do echo "waiting for management Ops Manager public API..."; sleep 10done
  3. Kubernetes 연산자가 관리 MongoDB Ops Manager 인스턴스용 프로그래밍 방식 API 키 보안 비밀을 생성했는지 확인합니다.

    kubectl get secret "${MANAGEMENT_OM_ADMIN_KEY_SECRET}" \ --context "${K8S_CTX_0}" -n "${MDB_NS}"
10

sslMMSCAConfigMap 항목은 TLS지원 애플리케이션 데이터베이스 에이전트가 관리 Ops Manager 인스턴스 에 연결할 때 신뢰해야 하는 CA를 알립니다.

kubectl create configmap "${APPDB_PROJECT_CONFIGMAP}" \ --context "${K8S_CTX_0}" -n "${MDB_NS}" \ --from-literal=baseUrl="${MANAGEMENT_OM_URL}" \ --from-literal=projectName="${APPDB_PROJECT_NAME}" \ --from-literal=sslMMSCAConfigMap="${APPDB_CA_CONFIGMAP}" \ --from-literal=orgId="" \ --dry-run=client -o yaml \ | kubectl apply --context "${K8S_CTX_0}" -n "${MDB_NS}" -f -
11

중앙 클러스터 에 MongoDBMultiCluster 리소스 적용합니다. Kubernetes Operator는 멤버 클러스터에 애플리케이션 데이터베이스 멤버를 생성합니다.

kubectl apply --context "${K8S_CTX_0}" -n "${MDB_NS}" -f - <<EOFapiVersion: mongodb.com/v1kind: MongoDBMultiClustermetadata: name: ${APPDB_NAME}spec: version: ${APPDB_VERSION} type: ReplicaSet role: AppDB persistent: true credentials: ${MANAGEMENT_OM_ADMIN_KEY_SECRET} opsManager: configMapRef: name: ${APPDB_PROJECT_CONFIGMAP} security: certsSecretPrefix: ${APPDB_CERT_PREFIX} tls: enabled: true ca: ${APPDB_CA_CONFIGMAP} clusterSpecList: - clusterName: ${K8S_CTX_1} members: ${APPDB_MEMBERS_C1} - clusterName: ${K8S_CTX_2} members: ${APPDB_MEMBERS_C2}EOF kubectl wait --for=jsonpath='{.status.phase}'=Running \ mdbmc/"${APPDB_NAME}" --context "${K8S_CTX_0}" -n "${MDB_NS}" --timeout=1200s

spec.role를 AppDB로 설정하다 Kubernetes Operator가 리소스 에 대한 SCRAM 인증 구성합니다. 자세한 학습 은 사양을 참조하세요. 역할.

12

이 리소스 spec.applicationDatabase를 생략하고 kind가 MongoDBMultiCluster로 설정하다 외부 애플리케이션 데이터베이스를 참조합니다.

kubectl apply --context "${K8S_CTX_0}" -n "${MDB_NS}" -f - <<EOFapiVersion: mongodb.com/v1kind: MongoDBOpsManagermetadata: name: ${PRIMARY_OM_NAME}spec: replicas: 1 version: ${OM_VERSION} adminCredentials: ops-manager-admin-secret externalApplicationDatabaseRef: name: ${APPDB_NAME} kind: MongoDBMultiCluster backup: enabled: false configuration: automation.versions.source: mongodb mms.ignoreInitialUiSetup: "true" mms.adminEmailAddr: admin@example.com mms.fromEmailAddr: admin@example.com mms.replyToEmailAddr: admin@example.com mms.mail.hostname: email-smtp.us-east-1.amazonaws.com mms.mail.port: "465" mms.mail.ssl: "true" mms.mail.transport: smtp mms.minimumTLSVersion: TLSv1.2EOF

MongoDB 배포서버의 백업을 활성화하려면, 이 리소스에서 spec.backup.enabled를 true으로 설정하고 스냅샷 저장을 구성합니다. 자세한 학습 은 Kubernetes 연산자로 파일 시스템 백업 저장 구성을 참조하세요.

13
kubectl wait --for=jsonpath='{.status.opsManager.phase}'=Running \ om/"${PRIMARY_OM_NAME}" --context "${K8S_CTX_0}" -n "${MDB_NS}" --timeout=1800s kubectl wait --for=jsonpath='{.status.applicationDatabase.phase}'=Disabled \ om/"${PRIMARY_OM_NAME}" --context "${K8S_CTX_0}" -n "${MDB_NS}" --timeout=600s

Kubernetes 연산자는 외부 애플리케이션 데이터베이스를 사용하는 MongoDB Ops Manager 리소스에 대해 내부 애플리케이션 데이터베이스를 관리하지 않습니다. 따라서 status.applicationDatabase.phase에서 Disabled이(가) 보고됩니다. 이것은 예상되는 동작이며 오류가 아닙니다.

14

멀티 클러스터 배포서버 에서 애플리케이션 데이터베이스 StatefulSet는 멤버 클러스터에서 실행 , Kubernetes Operator는 소유자 참조 대신 mongodbmulticluster 레이블을 사용하여 소유권을 추적합니다.

  1. 애플리케이션 데이터베이스 파드가 각 멤버 클러스터 에서 실행 중이고 각 StatefulSet가 <namespace>-<appdb-name>로 설정하다 mongodbmulticluster 레이블을 전달하는지 확인합니다.

    idx=0for ctx in "${K8S_CTX_1}" "${K8S_CTX_2}"; do sts="${APPDB_NAME}-${idx}" kubectl get pods --context "${ctx}" -n "${MDB_NS}" \ -l "mongodbmulticluster=${MDB_NS}-${APPDB_NAME}" kubectl get statefulset "${sts}" --context "${ctx}" -n "${MDB_NS}" \ -o jsonpath='{.metadata.labels.mongodbmulticluster}{"\n"}' idx=$((idx + 1))done
  2. Kubernetes Operator가 프라이머리 Ops Manager 인스턴스용 연결 문자열 보안 비밀을 생성했는지 확인합니다.

    kubectl get secret "${APPDB_CONNECTION_STRING_SECRET}" \ --context "${K8S_CTX_0}" -n "${MDB_NS}"

애플리케이션 데이터베이스 에이전트가 x509: certificate signed by unknown authority을(를) 사용하여 MongoDB 바이너리를 다운로드 하지 못하는 경우, spec.security.tls.ca의 CA 번들은 downloads.mongodb.com에 서명한 공개 루트를 포함하지 않습니다.TLS를 활성화하면 MongoDB Agent 시스템 신뢰 저장 대신 이 번들에 대해 다운로드 의 유효성을 검사합니다.TLS CA 단계에 표시된 대로 자체 서명된 CA와 호스트의 공용 CA 번들을 모두 사용하여 ConfigMap을 다시 만듭니다.

애플리케이션 데이터베이스 에이전트가 관리 Ops Manager 서비스에 대해 Could not resolve host을 로그 경우, 구성원 클러스터 네임스페이스 istio-injection=enabled 레이블이 누락된 것입니다. 사이드카가 없으면 포드는 메시를 통해 중앙 클러스터 Ops Manager 서비스를 확인할 수 없습니다. 네임스페이스 단계에 표시된 대로 레이블을 적용합니다.

Kubernetes 가 metadata.annotations: Too long을(를) 사용하여 CA ConfigMap을 거부하는 경우, 결합된 CA 번들이 클라이언트 사이드 kubectl apply 주석의 크기 제한을 초과합니다. kubectl apply --server-side --force-conflicts로 ConfigMap을 적용하거나 kubectl create로 생성합니다.

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

spec.externalApplicationDatabaseRef.name의 값은 정확히 <primary-om-name>-db이어야 하며, MongoDBMultiCluster 리소스 Ops Manager 리소스 와 동일한 네임스페이스 에 있어야 합니다.

외부 애플리케이션 데이터베이스를 백업하려면 관리 Ops Manager 인스턴스 가 관리하는 프로젝트 의 MongoDBMultiCluster 리소스 에서 백업 활성화 . 자세한 학습 은 MongoDB 데이터베이스 백업 구성을 참조하세요.