마이그레이션 고려사항
Microsoft SQL Server 데이터베이스는 기존 SQL Server 데이터베이스를 IBM Cloud VPC로 마이그레이션하는 여러 가지 방법을 지원합니다. 이 문서는 마이그레이션 시 깊이가 되지 않지만, 사용자의 요구사항 및 후속 평가를 기반으로 하나 이상의 메소드를 선택할 수 있는 여러 가지 방법에 대해 설명합니다.
- 기본 SQL Server 백업/복원입니다.
- 트랜잭션 복제.
- 데이터베이스 미러링.
- 로그 운송.
- 항상 가용성 그룹에 있습니다.
- 분산 가용성 그룹에서는 항상
데이터 이동 이외의 고려사항은 다음과 같은 마이그레이션에 필요합니다.
- 새 서버에서 SQL 작업을 다시 작성한다.
- 새 서버에서 로그인을 다시 작성하십시오.
- 데이터 암호화.
- 복제 중에 복구 옵션입니다.
- 전송할 데이터의 수량입니다.
- 현재 소프트웨어 버전 및 에디션에서 사용 가능한 기능입니다.
원시 SQL Server 백업/복원
Microsoft SQL Server 데이터베이스는 전체 및 차등분 백업 (.bak) 파일 또는 차등분 복원 및 로그 복원을 사용하는 기본 백업 및 복원 조작을 지원합니다. 원시 .bak 파일을 사용하는 것은 SQL Server 데이터베이스를 백업하고 복원하는 가장 간단한 방법이며 인스턴스의 단일 또는 다중 데이터베이스에 대한 단순 이주 메소드입니다. 기존 서버에 있는 데이터베이스의 전체 백업을 수행하고 IBM Cloud Object Storage 버킷에 복사합니다. 그런 다음 IBM Cloud VPC의 SQL Server 데이터베이스 인스턴스 가상 서버에서 s3fs 또는 복제하다 및 SMB\Samba 공유가 있는 스테이징 서버를 통해 복원됩니다.
트랜잭션 복제
트랜잭션 복제를 사용하면 하나의 데이터베이스와 다른 데이터베이스 간에 변경사항을 전송할 수 있습니다. 이러한 변경사항에는 데이터, 테이블, 스토어드 프로시저, 보기 등이 포함될 수 있습니다. 아키텍처는 다음과 같이 구성되어 있다.
- 발행자-데이터를 발행하는 기본 데이터베이스입니다.
- 구독자-복제된 데이터를 수신하는 보조 데이터베이스입니다.
- 배포자 - 트랜잭션 복제에 대한 메타데이터 및 트랜잭션을 저장하고 이상적으로는 발행자 또는 구독자에게 별도의 서버입니다.
이 프로세스는 다음과 같이 작동합니다.
- 트랜잭션 복제는 발행 데이터베이스에서 오브젝트 및 데이터의 스냅샷을 작성하고 이를 구독자 데이터베이스로 보냅니다. 스냅샷은 등록자 데이터베이스에 적용된다.
- 발행자에서 행해진 데이터 변화 및 스키마 수정은 그들이 발생하여 가입자에게 동일한 순서로 적용되는 순서로 가입자에게 전송된다.
- 두 데이터베이스가 동기화되고 유지보수 창에서 다음과 같은 경우:
- 게시자에 대한 액세스를 중지합니다.
- 복제가 완료되었는지 확인하십시오.
- 구독을 삭제한다.
- 등록자에 대한 액세스를 사용 가능하게 하십시오.
- 게시자가 무엇이었는지를 선언합니다.
자세한 정보는 트랜잭션 복제 를 참조하십시오.
데이터베이스 미러링
데이터베이스 미러링은 SQL Server 2012에서 더 이상 사용되지 않지만 SQL 2019문서에서 여전히 참조됩니다. SQL Server의 데이터베이스 미러링을 참조하십시오. 여기에서는 마이그레이션에 사용하려는 경우 마이그레이션 메소드의 완전성을 위해 이 방법을 주의깊게 연구하고 있다.
SQL Server 에서 데이터베이스 미러링을 사용하면 대기 서버에 있는 SQL Server 데이터베이스의 사본 또는 미러를 보존할 수 있습니다. 미러링은 데이터의 두 개의 별도 사본이 항상 존재하도록 보장합니다. 로그 제공과 비교하여 데이터베이스 미러링은 설정하기에는 조금 더 복잡하며, 더 많은 제한사항이 있습니다. 파트너십의 두 서버가 모두 동일한 Windows 도메인에 있는 경우 데이터베이스 미러링을 설정하는 것이 더 쉽지만, 그렇지 않은 경우에는 엔드포인트 인증에 인증서를 사용할 수 있습니다. 마이그레이션을 위한 기본 단계는 다음과 같다.
- 데이터베이스 미러링을 구성합니다.
- 필수 절단점에서 기본 서버의 프린시펄 데이터베이스를 사용하는 애플리케이션을 중지하십시오.
- 각 데이터베이스가 동기화된 상태인지 확인하십시오.
- 미러링된 각 사용자 데이터베이스에 장애가 발생했습니다.
- 미러링 파트너십을 제거하십시오.
- 애플리케이션을 새 데이터베이스 서버로 다시 보내십시오.
- 원래 서버를 분리하십시오.
로그 운송
SQL Server 로그 제공은 데이터베이스 레벨에서 구성할 수 있으며 지정된 기간에 SQL Server 트랜잭션 로그 백업이 수행되어 대상 서버로 복사되고 복원됩니다. 트랜잭션 로그에는 SQL Server 데이터베이스에서 발생하는 모든 트랜잭션의 로그가 포함됩니다. 트랜잭션 로그 백업이 제공되는 SQL Server 인스턴스를 기본이라고 하며 트랜잭션 로그 백업이 제공되는 SQL Server 인스턴스를 2차라고 합니다. 로그 제공을 구성하기 전에 데이터베이스가 전체 복구 모델 또는 벌크 로그 모드에 있어야 합니다.
SQL Server 트랜잭션 로그 백업 설정을 사용하여 네트워크 경로에 대한 주소 지정을 허용하고 백업 작업 스케줄러를 정의하여 백업 작업을 실행할 수 있습니다. 기본적으로 설정은 15분마다 백업 작업을 실행하는 것입니다. 데이터베이스 백업이 스케줄되면, 보조 서버에서 복구해야 하는 데이터베이스의 전체 백업을 하나 작성합니다. 유지보수 시간 동안 1차 서버에서 2차 서버로의 전환을 수행할 수 있으며, 로그 선적이 사용 불가능하며 기본 서버가 사용중지됩니다.
항상 가용성 그룹에 있는 경우
SQL Server 가용성 그룹은 항상 고가용성 및 재해 복구 솔루션을 제공하며 SQL Server 2012이상 버전에서 사용 가능합니다. 이 기능을 사용하여 기존 SQL Server 데이터베이스를 최소 다운타임으로 IBM Cloud 로 마이그레이션할 수 있습니다. 항상 가용성 그룹이 있는 기존 Windows 서버 장애 조치 클러스터가 있는 경우, 비동기 복제를 사용하여 추가 2차 복제본을 작성하여 마이그레이션 중 임시로 클러스터를 확장할 수 있습니다. 유지보수 창 중에, 수동 장애 복구를 수행하여 절단점을 사용 가능하게 할 수 있습니다.
분산 가용성 그룹에서 항상
SQL Server 항상 분배된 가용성 그룹은 두 개의 고유한 가용성 그룹에 걸쳐 있습니다. 각 가용성 그룹은 두 개의 다른 Windows 서버 장애 조치 클러스터 (WSFC) 에서 구성되며, 하나는 소스 위치에 있고 하나는 IBM Cloud VPC에 있습니다. 운영 체제 및 SQL Server 버전은 WSFC및 가용성 그룹을 지원할 수 있는 한 동일한 버전일 필요는 없습니다. 이 마이그레이션 메소드는 미션 크리티컬 SQL Server 데이터베이스를 다시 호스트하기에 적합합니다. 분산 가용성 그룹 아키텍처는 1차 복제본이 IBM Cloud의 전달자 복제본만 데이터를 전송할 때 효율적인 데이터 전송 방법이며 전달자는 IBM Cloud의 2차 복제본과 데이터를 동기화해야 합니다. 일반적인 아키텍처는 다음과 같다.
- 소스 WSFC 클러스터는 항상 가용성 그룹을 호스트하며 두 개의 노드를 가지고 있으며 자동 페일오버를 사용하여 동기식 복제를 사용한다.
- IBM Cloud 에서 호스트되는 대상 WSFC 클러스터에는 항상 가용성 그룹이 있고 두 개의 노드가 있으며 하나는 MZR (Multi Zone Region) 의 가용성 구역 (AZ) 에 있으며 자동 장애 조치와 함께 동기 복제를 사용합니다.
- 일반적으로 직접 링크 연결인 네트워크 연결은 두 클러스터를 연결합니다.
- 항상 분배된 가용성 그룹이 구성되고 데이터가 소스 WSFC 클러스터의 1차 복제본에서 대상 WSFC 클러스터의 1차 복제본 (전달자) 로 전송됩니다.
- 전달자는 대상 WSFC 클러스터의 2차 복제본으로 데이터를 전송합니다.
유지보수 창 중에 수동 장애 복구를 수행하여 대상 WSFC의 기본 데이터베이스가 애플리케이션에서 읽기/쓰기 액세스를 위한 소스가 되도록 하기 위해 수동 장애 복구를 수행할 수 있습니다.
자세한 정보는 분산 가용성 그룹을 참조하십시오.