두 MCK 인스턴스 간 마이그레이션

시작하기 전에

두 Kubernetes Operator 설치 간에 배포서버 마이그레이션 하기 전에 다음 사항을 확인하세요.

• A Ops Manager or Cloud Manager connection ConfigMap with the keys baseUrl, orgId, and projectName.

• An API key Secret with the keys publicKey and privateKey.

• The Kubernetes Operator ServiceAccount has batch/jobs permissions (create, get, list, watch, and delete) for the dry-run connectivity Job.

• The project contains exactly one deployment.

또한 다음이 필요합니다.

• 실행 Kubernetes Operator 설치가 관리하는 소스 배포서버 입니다.

• 소스와 다른 네임스페이스 또는 Kubernetes 클러스터 에 대상이 되려는 두 번째 Kubernetes Operator 설치.

• Both installations configured against the same Ops Manager or Cloud Manager project ConfigMap and credentials.

• 항상 투표권이 있는 멤버를 최소 3명으로 유지합니다. Kubernetes Operator가 7 이상의 투표 멤버를 거부합니다. 7를 초과하는 경우, 투표권이 없는 Kubernetes 멤버를 추가하거나 투표권이 있는 외부 멤버를 제거 .

• 한 번에 한 가지 종류의 변경만 수행할 수 있습니다: Kubernetes 멤버를 추가하거나, 외부 멤버를 정리하거나, 한 번에 한 멤버의 투표 및 우선 순위 만 변경할 수 있습니다. 허용 유효성 검사 마이그레이션 시작되면 혼합된 변경 사항을 거부하며, 마이그레이션 중에 Kubernetes 멤버를 제거하거나 외부 멤버를 추가하는 것도 거부합니다.

• 배포서버 목표 상태 인 경우에만 작동합니다.

• 프라이머리 마지막으로 마이그레이션합니다. 투표와 우선 순위 를 멤버로 옮기면 투표 트리거하다 될 수 있으며, 복제본 세트 새 프라이머리 선택하는 동안 쓰기가 잠시 실패할 수 있습니다. 프라이머리 마지막으로 마이그레이션하면 최종 단계까지 해당 투표 및 이로 인해 발생하는 쓰기 (write) 다운타임이 트리거되는 것을 방지할 수 있습니다.

  참고

  Kubernetes 에서 멤버의 우선 순위 를 높여 재선을 트리거하다 할 수도 있습니다.

• While spec.externalMembers is non-empty, Kubernetes Operator forces one-member-at-a-time scaling. This is why each change needs its own wait for goal state.

가상 머신에서 마이그레이션할 때와 다른 점

An MCK-to-MCK migration uses the same extend, promote, and prune loop as migrating a virtual machine deployment. Source members appear as spec.externalMembers in the target resource, the same as they do when migrating from virtual machines. For the detailed step-by-step mechanics of that loop, see Migrate a Replica Set to Kubernetes.

이 마이그레이션 가상 머신 마이그레이션 에 적용 않는 추가 요구 사항이 있습니다.

• Stop or scope down the source operator first. Before you begin, stop the source Kubernetes Operator installation, or otherwise ensure it stops reconciling the deployment. Two operators must never reconcile the same Ops Manager or Cloud Manager project at the same time.

• Both operators must share the same project ConfigMap and credentials. The source and target Kubernetes Operator installations connect to the same Ops Manager or Cloud Manager project.

• 클러스터 범위 Helm 리소스 이름이 충돌하지 않아야 합니다. 두 개의 연산자 Helm 설치는 모든 클러스터 범위 리소스 에 대해 고유한 이름을 사용해야 합니다.

• 네임스페이스는 달라야 합니다. 소스 설치와 대상 설치가 네임스페이스 를 공유하는 경우 프로세스 이름이 충돌합니다.

배포서버 마이그레이션

Follow the same extend, promote, and prune sequence described in Migrate a Replica Set to Kubernetes, generating the target MongoDB custom resource against the target Kubernetes Operator installation's namespace and cluster. The source members appear in spec.externalMembers on the target resource until you prune them.

Precedence is Validating > Extending > Pruning > InProgress. A prune that also grows the Kubernetes side reports Extending, which is another reason to make one change at a time.

가지 치기와 확장은 동시에 허용되지 않습니다.

To script against migration completion, use kubectl wait --for=condition=Migrating=False rather than polling status.phase.

소스 정리

After migration finishes, delete the source MongoDB custom resource. Do not delete the Ops Manager or Cloud Manager project, and do not delete the underlying data. Deleting the source custom resource removes only the source Kubernetes Operator installation's management of that resource.

자세히 알아보기

• Migrate a Self-Managed Deployment to Kubernetes

• Migrate a Replica Set to Kubernetes