네트워크를 통해 중단 시간이 적은 거대한 SQL Server 데이터베이스를 마이그레이션하는 가장 좋은 방법

문제 정의

데이터베이스 서버를 다른 데이터 센터로 전송해야합니다. Microsoft SQL Server 2012 Enterprise (64 비트)에서 실행되며 약 2TB 및 1TB의 두 데이터베이스가 포함되어 있습니다.

다운 타임이 적거나없는 것이 이상적입니다.

작업량

이러한 데이터베이스는 .NET 웹 사이트에 사용되며 지속적으로 업데이트되고 있습니다.

주말 동안 사용할 수없는 것은 허용 될 것입니다. 현재 사용중인 DB는 새 데이터베이스로 전환 할 때까지 사용중인 유일한 데이터베이스입니다.

이 스위치는 DB가 업데이트되지 않도록 확인하면서 DNS 항목을 새 DB 서버를 가리 키도록 변경하는 것이 이상적입니다.

또한 한 서버에서 다른 서버로의 전환 (다운 타임)이 낮게 유지되는 한이 작업에 걸리는 시간은 실제로 중요하지 않습니다.

고려 된 접근법

• 백업 및 복원

  과거에는이 작업을 수행했지만 인터넷 보다 효율적으로 내부 네트워크를 통해 수행 되었더라도 높은 다운 타임이 발생했습니다.

• 로그 배송

  내가 이해하는 한,이 접근법은 마스터 / 슬레이브를 구성하고 마스터 DB의 정확한 사본을 읽기 전용 슬레이브로 전송하여 다운 타임을 최소화합니다. 위에서 언급했듯이 슬레이브에 액세스 할 필요가 없으며 데이터 손상없이 마스터 DB의 복제본을 가질 수있는 방법이 필요합니다.

  또한 리소스 활용 측면에서 매우 효율적인 것으로 보이며 마스터 성능에 큰 영향을 미치지 않습니다.

  나는이 접근법에 대해 틀릴 수 있으므로 자유롭게 수정하십시오.

• 데이터베이스 미러링

  나는 그 접근 방식을 너무 잘 알지 못하지만 유효한 옵션처럼 보입니다. 실시간 동기화를 할 필요가 없으며 마스터의 성능이 매우 중요하므로이 방법을 선택하면 비동기 방식이 사용됩니다.

• 다른 옵션?

  이 서버는 베어 메탈 하드웨어에서 직접 실행되므로 낮은 수준의 솔루션은 불행히도 옵션이 아닙니다. 이 작업을 수행하는 더 좋은 방법이 있습니까?

제약

설명했듯이, 이러한 데이터베이스는 유지 관리하기가 쉽지 않을 정도로 큰 규모이지만 다른 문제입니다.

SQL Server 버전은 동일합니다 (Microsoft SQL Server 2012 Enterprise 64 비트).

두 데이터 센터간에 네트워크를 통해 전송해야하므로 인터넷을 통해 전송해야합니다. 초기 동기화를 위해 한 사이트에서 다른 사이트로 디스크를 보내는 것은 불행히도 옵션이 아닙니다. 양도에 대한 일종의 보안을 유지하는 것이 이상적이지만 최선을 다할 것입니다.

그것은이 과제에 대한 우리의 요구에 대해 아주 좋은 개요를 제공해야하며 여러분 중 일부는 그 상황에 직면하기를 바랍니다.

직접적인 백업 및 복원은 분명히 불가능합니다. 또한 어떤 종류의 복제도 고려하지 않습니다.

데이터베이스 미러링은 설정이 비교적 간단하지만 두 서버 간의 실시간 연결, 파트너 및 엔드 포인트 설정 등이 필요합니다. 가용성 그룹은 옵션 일 수 있지만 네트워킹 문제로 인해 두 서버가 모두 있어야합니다. 동일한 WSFC의 멤버로서-같은 도메인에 있어야합니다. 이는 데이터 센터 이동에 대한 일반적인 설정이 아니거나 일시적으로 작동 할 수도 있습니다.

내 투표는 통나무 운송에 대한 것입니다. 이것에 대한 좋은 점은 이미 수행중인 백업 및 로그 백업을 사용할 수 있으며 (오른쪽?) 두 데이터베이스 사이에 반드시 실시간 연결이 필요하지는 않습니다. 각 데이터베이스에 대해 알 필요는 없습니다. 미러링, 파트너, 보안 등을 위해 엔드 포인트를 설정할 필요가 없습니다. 기존 서버에서 새 서버로 복원 할 수있는 위치로 파일을 가져 오는 방법 만 있으면됩니다. 미리 전체 백업을 가져 와서 새 서버로 가져 와서 복원 한 다음 해당 시점부터 컷 오버 시점까지 증분 로그 백업을 적용 (아마도 차이가있을 수 있음) 할 수 있습니다. 이 과정은 실제로 매우 간단하며 어려움을 겪을 경우 온라인으로 로그 전달에 대한 많은 자습서가 있습니다.

웹 응용 프로그램이 데이터베이스와 함께 이동하는 경우 DNS가 전파하는 데 시간이 걸릴 수 있으므로 이전 응용 프로그램의 연결 문자열을 전환하여 새 데이터베이스 서버가 쓰기 가능하면 새 데이터베이스 서버의 IP를 가리 키도록 전환 할 수 있습니다 스위치 이후에도 TTL 설정이 빡빡하더라도 클라이언트는 계속해서 기존 웹 서버에 충돌 할 수 있습니다. 그것은 공급자가 귀하의 TTL을 얼마나 존중하는지에 달려 있습니다.

최근에 미러링을 사용하여 6 개의 데이터베이스에서 15TB를 마이그레이션했습니다. 단 몇 초의 장애 조치 시간으로 매우 간단하고 완벽하게 작동했습니다.

편집 :

두 개의 새로운 가상화 된 SQL Server가있었습니다. 데이터베이스는 방금 자란 서버 3 대에서 왔으며 호스트 된 소규모 데이터베이스의 성능에 영향을 미쳤습니다.

과정은 매우 간단했습니다.

1. 주말 전체 백업이 완료 될 때까지 기다립니다
2. 새 서버로 복구하지 않고 복원
3. 복원이 완료되면 백업을 일시 중지하십시오
4. 원본에서 최신 로그 백업까지 하나의 추가 복원을 실행하여 복구하지 않음
5. 6 개 모두에서 미러링 시작
6. 백업 재개

네트워크 등의 부하를 줄이기 위해 장애 조치 (failover)를 수행 할 준비가 될 때까지 비동기 모드로두기로 선택했습니다. 미러링은 유지 관리 (지표 / 통계) 및 기타 대량 작업 중 대기 시간을 유발하는 것으로 유명하지만 그렇지 않았습니다. 그 사실을 찾으십시오. 수동 장애 조치 전에 동기 모드로 전환해야합니다.

다음 유지 관리 기간 동안 각 데이터베이스를 수동으로 장애 조치하고 일부 연기 테스트 후 미러링을 해제 한 후 원래 서버에서 이전 데이터 파일을 제거했습니다. 이 프로세스의 한 가지 단점은 미러링 된 데이터베이스를 장애 복구하면 이전 기본 데이터베이스를 복구 상태로 유지한다는 것입니다. 따라서 단순히 삭제하는 것이 편하지 않으면 다시 온라인 상태로 전환 한 다음 분리하거나 원하는 제거 방법이 무엇이든간에 . 또한 자동 장애 조치를 원하지 않기 때문에 이것에 대한 감시를 구성하지 않았습니다. 이것은 통제 된 사건이었습니다.

더 자세한 내용을 원하시면 알려주세요. 서버 및 네트워크 사양은 생략했지만 원하는 경우 제공 할 수 있습니다.

감사