이 게시물에서 다음을 참조하겠습니다. 출처 목표 환경. 출처 현재 실행 중인 환경(우리가 벗어나고자 하는 환경)이고 목표 새로운 자체 호스팅 환경이므로 데이터를 마이그레이션하려고 합니다.

이름

시작하기 전에 데이터가 어떻게 관리되고 저장되는지 명확하게 이해하는 것이 중요합니다. Mendix. Mendix 데이터를 데이터베이스와 파일 저장소의 두 가지로 분리합니다.

데이터베이스

데이터베이스는 Studio Pro에서 생성된 도메인 모델을 반영하며 예상되는 모든 정보를 저장합니다.

• 엔터티는 데이터베이스 테이블에 매핑됩니다.
• 속성은 테이블 내의 열에 매핑됩니다.
• 커밋된 객체는 해당 테이블 내의 행에 매핑됩니다.

In Mendix 클라우드는 AWS Postgres 데이터베이스입니다.

파일 저장

반면 파일은 별도로 저장됩니다. 파일에 대한 메타데이터(파일 이름, 크기, UUID)는 데이터베이스에 저장되지만 바이너리 파일 콘텐츠 자체는 그렇지 않습니다. 바이너리 콘텐츠는 다음과 같이 저장됩니다. 파일 저장. FileDocument 데이터베이스 테이블 내의 UUID는 바이너리 콘텐츠의 파일 이름과 일대일로 매핑됩니다. Mendix 클라우드는 AWS S3의 객체 스토리지로 호스팅됩니다.

소개

이 튜토리얼의 범위는 라이브 환경의 데이터 및 파일 마이그레이션입니다. 대상 환경이 설정되어 있다고 가정합니다. Mendix 애플리케이션이 배포되고, 데이터베이스와 파일 저장소가 구성(비어있음)되어 작동 중입니다.

배포 방법에 대한 자세한 내용은 Mendix 응용 프로그램, 당신은 할 수 있습니다 이 가이드를 확인하십시오..

라이브 프로덕션 앱에서 마이그레이션을 시작하기 전에 다음 체크리스트를 검토하는 것이 좋습니다.

• 소스 및 대상 환경이 정확히 동일한 버전을 실행합니까? Mendix 앱(.mda)? (동일한 버전을 실행하지 않으면 데이터가 손실될 수 있습니다)
• 마이그레이션 기간이 예약되어 전달되었나요? (라이브 애플리케이션의 마이그레이션에는 다운타임이 필요하며, 일반적으로 근무 시간 외입니다. 마이그레이션을 계획하고 앱에 액세스할 수 없게 될 때 사용자에게 알립니다.)
• 스냅샷 날짜가 합의되었고 사용자에게 전달되었나요? (마이그레이션을 수행하려면 특정 시점의 데이터 백업 스냅샷을 만들어야 합니다. 이후의 변경 사항은 마이그레이션되지 않습니다. 마이그레이션할 때가 되면 라이브 환경을 중지하고 데이터 스냅샷을 찍은 다음 시작합니다.)
• 실제로 복원을 시작하기 전에 일회용 환경에서 복원 프로세스를 연습하여 단계에 익숙해지도록 하세요.
• 실제 마이그레이션 중에 참조할 수 있는 연습 단계를 문서화하는 런북을 만듭니다.

런북에는 다음 내용이 포함될 수 있습니다.

• 스모크 테스트: 마이그레이션 이후에 테스트 케이스를 실행하여 성공 여부를 확인합니다. (애플리케이션에 예상된 데이터가 포함되어 있는지 검증하고 데이터베이스와 파일 저장소가 모두 마이그레이션되어 동기화되었는지 확인하는 테스트입니다.)
• 사용자를 새로운 대상 환경으로 리디렉션하기 위해 DNS 레코드 및 로드 밸런서를 업데이트하는 단계입니다.
• 마이그레이션이 실패하거나 할당된 마이그레이션 창이 경과할 경우 최악의 상황에 대비한 계획입니다.
• 다양한 시나리오에 따른 사용자, 이해관계자 등과의 의사소통.

이주

As Mendix 광범위한 배열을 지원합니다 데이터베이스, 파일 저장소 및 배포 유형 외에도 마이그레이션에는 여러 가지 접근 방식이 있습니다. 사용자 지정 런타임 설정을 사용하여 가장 다재다능한 마이그레이션 접근 방식을 보여드리겠습니다.

이 예에서는 실행 중인 앱을 마이그레이션하려고 합니다. Mendix Azure Kubernetes Service(AKS)에서 실행되는 새로운 자체 호스팅 환경으로 클라우드를 전환합니다. 파일 저장을 위해 Azure SQL Database와 Azure Blob Storage를 실행합니다.

A Mendix 마이그레이션에는 두 가지 부분이 필요합니다. 먼저 데이터베이스 마이그레이션이 필요하고, 두 번째로 파일 저장소 마이그레이션이 필요합니다.

사용자 정의 런타임 설정

따라서 Mendix 런타임에는 다음을 통한 내장된 마이그레이션 기능이 있습니다. 사용자 정의 런타임 설정. 이러한 설정은 소스에서 대상 데이터베이스로 데이터를 전송합니다. 또한 데이터베이스를 변환합니다. 따라서 소스 데이터베이스가 PostgresSQL이고 대상이 MSSQL인 경우 런타임이 이를 처리합니다.

데이터베이스 마이그레이션에 가장 많이 사용되는 사용자 정의 설정은 다음과 같습니다.

• 소스데이터베이스 유형(HSQLDB, MYSQL, ORACLE, POSTGRESQL, SQLSERVER)
• 소스데이터베이스호스트
• 소스데이터베이스이름
• 소스데이터베이스사용자 이름
• 소스데이터베이스비밀번호

새로운 대상 환경은 Azure에서 실행 중입니다. 따라서 위와 같이 사용자 지정 런타임 설정을 구성하여 Mx Cloud의 소스 데이터베이스를 가리키기만 하면 되는 것 아니겠습니까?

네, 그러나 Mendix 클라우드는 데이터베이스에 직접 접근하는 것을 허용하지 않습니다.

따라서 우리는 우리만의 임시 PostgresSQL 데이터베이스를 만들고, Mx Cloud 백업을 여기에 복원한 다음, 이 임시 데이터베이스를 사용자 정의 런타임 설정의 소스로 사용해야 합니다.

대상 데이터베이스가 PostGresSQL인 경우 변환, 사용자 지정 런타임 설정 또는 임시 데이터베이스가 필요하지 않습니다. 간단히 복원합니다. Mendix 다음을 사용하여 대상 데이터베이스에 직접 클라우드 백업 PostgreSQL 복원 기능.

대상 데이터베이스 및 파일 저장소가 비어 있는지 확인합니다.

마이그레이션을 수행하기 전에 대상 파일 저장소와 데이터베이스가 비어 있어야 합니다.

아마도 당신은 목표를 시작했을 것입니다 Mendix 응용 프로그램, 작동을 확인하기 위해 테스트를 실행했고, 그렇게 함으로써 실수로 데이터를 생성했습니다. 이는 마이그레이션 전에 제거해야 합니다.

Azure 블로그 저장소(대상)

Azure SQL Server(대상)

내 대상 데이터베이스가 비어 있지 않습니다. 마이그레이션이 작동하려면 삭제해야 하는 애플리케이션 테이블이 포함되어 있습니다.

나는 빨리 썼다 Excel 기능 브라우저를 벗어나지 않고도 모든 테이블을 삭제하는 데 필요한 SQL 명령을 작성합니다.

대안은 다음과 같을 수 있습니다. SSMS(SQL 서버 관리 스튜디오) 몇 번의 클릭만으로 표를 놓을 수 있는 시각적 GUI가 있습니다.

이 명령을 실행한 결과, 데이터베이스가 비어 있습니다.

스냅샷을 찍어보세요 📸

이제 운영 데이터의 최종 백업을 취하고 마이그레이션을 시작할 때입니다. Mendix 클라우드는 셀프 서비스이므로 이를 실행하기가 쉽습니다.

에서 Mendix 클라우드 개발자 포털:

1. 백업 > 프로덕션 > 백업 생성 (Mendix (데이터 스냅샷을 생성합니다)
2. 백업 다운로드 > 전체 스냅샷 (신청서의 크기에 따라서는 몇 분에서 몇 시간까지 걸릴 수 있습니다.)

전체 스냅샷에는 Windows에서 7-zip을 사용하여 추출할 수 있는 압축된 *.tar.gz 아카이브가 포함되어 있습니다.

폴더 구조는 다음과 같습니다.

• db – postgres 데이터베이스 백업
• 트리 - 파일 저장소

임시 PostgresSQL 데이터베이스

PostgresSQL DB를 만듭니다. 이것은 우리가 제어하고 연결 세부 정보를 가지고 있는 데이터베이스를 얻기 위한 임시 솔루션입니다.

대상 환경이 Azure에 있으므로 Azure Postgres 데이터베이스 서버를 만들 것입니다.

참고: 데이터를 마이그레이션하려면 대상 환경에 임시 데이터베이스에 대한 네트워크 연결이 필요합니다.

임시 PostGresSQL DB가 소스 데이터베이스와 동일한 버전인지 확인하세요(Mx 개발자 포털의 환경 세부 정보 페이지에서 찾을 수 있음).

복원을 수행하려면 새로 만든 임시 데이터베이스와 상호 작용할 수 있어야 합니다. 간단한 GUI 인터페이스를 제공하므로 pgAdmin 4를 설치하겠습니다.

로컬 머신에 Postgres를 다운로드하고 설치하세요

(PostgreSQL: 다운로드) pgAdmin과 PostgreSQL Server가 선택되었는지 확인하세요(복원 기능에 필요).

pgAdmin을 처음 시작할 때 마스터 비밀번호를 설정하세요

연결 세부 정보를 사용하여 Azure PostgresSQL Server에 연결합니다.

임시 데이터베이스 생성

백업 복원

PostGresSQL로 복원하는 것은 간단합니다.
백업 파일 'db.backup'을 선택하고 "소유자 저장 안 함"이 true로 설정되어 있는지 확인하세요.
자세한 내용은 여기에서 확인할 수 있습니다.

임시 데이터베이스 복원 검증

데이터가 여기에 있으며, 임시 데이터베이스로의 복원이 성공적으로 완료되었습니다.

이제 우리는 우리가 제어하는 ​​데이터베이스에 생산 데이터를 보유하고 있으며 연결 세부 정보도 가지고 있습니다!

데이터베이스 마이그레이션

따라서 Postgres에서 Postgres로의 마이그레이션은 매우 쉽습니다. 대상 데이터베이스가 PostgresSQL인 경우 위의 단계를 대상 데이터베이스로 직접 따르면 됩니다..

저는 MS SQL Server(Azure SQL)로 변환하고 마이그레이션해야 합니다. 다행히도 사용자 지정 런타임 설정을 통해 이를 수행할 수 있습니다.

대상 애플리케이션이 중지되었는지 확인하세요.

사용자 정의 런타임 변수 설정

대상 환경을 시작하고 데이터베이스 복원이 제대로 작동하는지 확인합니다.

데이터가 성공적으로 이전되었습니다.

하지만 잠깐만요, 파일 문서가 표시되지만 다운로드되지 않습니다. 이는 메타데이터가 포함된 데이터베이스를 복원했지만 아직 파일 저장소를 마이그레이션하지 않았기 때문입니다.

파일 저장소 마이그레이션

이것은 두 마이그레이션 중 가장 간단한 것입니다. 스냅샷 내의 파일을 대상 파일 저장소에 업로드하기만 하면 되는데, 제 경우에는 Azure Blob Storage입니다.

폴더 구조 평면화(필요한 경우)

Azure Blob Storage 지원 Mendix 모든 객체가 하나의 폴더에서 사용 가능할 것으로 예상합니다. 따라서 모든 파일을 루트 디렉토리에 플래팅하여 저장해야 합니다. 저는 Windows 사용자이므로 간단한 PowerShell 스크립트 이것을하기 위해.

Get-ChildItem -Path SOURCE -Recurse -File | Move-Item -Destination DEST

Azure Blob Storage 컨테이너에 파일 업로드

100GB 이상에 달하는 수천 개의 파일이 있는 대규모 마이그레이션의 경우 다음을 사용하는 것이 좋습니다. 애저 CLI or Azure 저장소 탐색기.

제 시나리오에서는 파일이 두 개뿐이므로 Azure 웹 포털을 사용하겠습니다.

스모크 테스트
다시 애플리케이션을 실행하니 이제 내 데이터와 파일 내용에 모두 완벽하게 접근할 수 있게 됐습니다!

데이터 마이그레이션이 성공적이었습니다.

마무리

실제 프로덕션 데이터를 처리할 때는 마이그레이션 후 정리 활동을 실행하여 이 데이터가 안전하게 유지되도록 하는 것이 중요합니다. 여기에는 다음이 포함될 수 있습니다.

• 프로덕션 백업의 로컬 다운로드 삭제
• 임시 데이터베이스 파괴
• 대상 환경에서 사용자 정의 런타임 설정 제거

마무리 단어

잠재적인 마이그레이션 조합, 설정, 인프라 설계가 많아서 한 게시물에 모두 다루기란 불가능합니다. 저는 특히 복잡한 시나리오를 다루었는데, 동일한 기술을 사용하여 귀하의 데이터 마이그레이션 시나리오에 적용할 수 있습니다.

대체 접근법

• Mx4PC에서 Mx4PC로 마이그레이션 또는 Mendix PG 데이터베이스가 있는 클라우드에서 Mx4PC로? 새로운 기능을 활용할 수 있습니다. 프라이빗 클라우드 데이터 마이그레이션 도구 (이 글을 쓰는 시점에서는 미리보기 단계에 있습니다).
• 요새 호스트가 필요한 경우 Postgres의 로컬 설치로 Windows VM을 설정하고 사용할 수 있습니다. Mendix 서비스 콘솔 대상에 데이터베이스를 마이그레이션합니다.

마이그레이션 하세요!