우리는 곧 새로운 프로덕션 서버로 이동할 두 개의 SQL Server 2005 데이터베이스를 보유하고 있습니다. 이러한 데이터베이스는 규모가 크지는 않지만 가동 중지 시간을 최소화하면서 수행하기가 까다로울 만큼 충분히 큽니다.
가장 중요하므로 먼저 이동될 세 개의 데이터베이스는 크기가 5, 9, 25GB입니다(로그가 없는 데이터만).
이제 몇 가지 가능성이 있지만 저는 본격적인 DBA가 아니기 때문에 여기에 있는 일부 사람들이 더 나은 아이디어/제안을 가지고 있을 것이라고 생각했습니다. 우리가 생각해낸 것은 다음과 같습니다.
* Create a full backup, move the file and restore the backup.
이는 가능하지만 데이터베이스가 상당히 크기 때문에 데이터베이스를 이동해야 하기 때문에 시스템 가동 중지 시간이 꽤 심각(몇 시간) 걸릴 수 있습니다.
오늘 백업을 생성 및 복원한 다음 실제 이동 시 차등 복원을 수행할 수 있습니까? 지금까지 차등 복원에서 찾을 수 있는 문제는 차등 복원이 항상 전체 백업에 추가되어 파일 크기를 동일하게 유지하고 서버에서 서버로 파일을 이동하는 데 따른 가동 중지 시간을 줄이지 않는다는 것입니다.
이를 "더" 까다롭게 만들기 위해 새 데이터베이스는 이전 환경이 미러링되지 않는 미러링으로 구성됩니다. 즉, 주 서버에서 차등 백업을 복원해야 한다는 뜻입니다. (이로 인해 문제가 발생하지는 않을 것 같지만 물어봐야겠다고 생각했습니다.)
가동 중지 시간을 최소화하면서 이 작업을 수행할 수 있는 더 쉽고 더 좋은 다른 방법이 있다면 물론 듣고 싶습니다.
StackOverflow의 사용자는 "이 작업을 수행하려면 미러링을 사용할 수 있습니다"라고 간단히 대답했습니다. 많은 세부 사항을 다루지 않고도 제가 볼 수 있는 방식은 새로운 원칙에 따라 미러를 생성한 다음 미러가 이전 프로덕션 서버에서 인계받도록 강제할 수 있다는 것입니다. 그런 다음 미러링을 비활성화하고 새 미러 서버에 대한 미러링을 다시 활성화합니다.
그렇게 작동할까요?
답변1
나는 이러한 유형의 마이그레이션을 여러 번 수행했으며 가장 좋은 방법은 다음과 같습니다.
전체 백업(데이터베이스 사용 중)
n분마다 트랜잭션 로그 백업(n은 전체 백업을 복사하는 시간에 따라 다름)
전체 백업을 새 서버에 복사한 다음 복구하지 않고 데이터베이스 복원(
RESTORE....NORECOVERY)트랜잭션 로그 복사 및 복원(항상 복구하지 않음)
새 데이터베이스가 거의 온라인 상태가 되면 기존 데이터베이스를 사용하는 애플리케이션을 중지하고 마지막 트랜잭션 로그를 백업한 후 새 서버에 복사하고 복구를 통해 복원합니다.
이제 가동 중지 시간이 거의 없이 새 서버에 데이터베이스가 있습니다.
답변2
데이터베이스 백업 및 이동과 관련하여 저는 30분 이내에 30GB 데이터베이스를 정기적으로 백업합니다. 현재 서버에 연결된 외부 USB 드라이브에 백업하고 USB 드라이브를 통해 새 서버로 전송하고 복원하는 경우 약 1시간 이상 걸리지 않으며 몇 분 정도 걸립니다.
답변3
요점을 말씀드리고 싶습니다.
제가 틀렸을 수도 있습니다. 이것이 일반적인 방법이 아니라면 다른 사람들이 말하도록 하십시오. 새 서버에 트랜잭션 복제를 설정하고 데이터베이스를 게시 및 구독하면 두 데이터베이스가 몇 초보다 짧은 지연 시간에 지속적으로 실행될 수 있습니다. .
그런 다음 클라이언트에서 이전 데이터베이스에 대한 연결을 닫고 몇 초 정도 기다립니다.
복제를 비활성화하고 새 데이터베이스 사용을 시작합니다.