SQL Server 데이터베이스 동기화


21

문제 정의

우리 사용자는 대부분 최신 데이터베이스를 쿼리 할 수 ​​있어야합니다. 데이터는 최대 24 시간까지 오래 될 수 있으며 허용됩니다. 프로덕션 사본을 사용하여 두 번째 데이터베이스를 최신 상태로 유지하는 가장 저렴한 방법은 무엇입니까? 내가 생각하지 않는 접근법이 있습니까?

작업량

주식 거래 활동을 모니터링하는 데 사용하는 타사 응용 프로그램이 있습니다. 낮에는 다양한 작업 흐름의 일부로 작은 변화가 많이 발생합니다 (예,이 거래는 유효했습니다. 아니오, 의심스러운 것 등). 밤에는 대규모 세트 기반 작업을 수행합니다 (전날 거래로드).

현재 솔루션 및 문제

우리는 데이터베이스 스냅 샷 을 사용 합니다 . 오후 10시에 스냅 샷을 삭제하고 다시 만듭니다. 그런 다음 ETL 처리가 시작됩니다. 이것은 분명히 디스크에 부담을 주지만 사용자가 데이터베이스를 잠그지 않고 데이터베이스를 쿼리 할 수있게합니다 (액세스 프론트 엔드 사용). 그들은 늦은 밤과 이른 아침에 그것을 사용하여 가동 중지 시간을 알 수 있습니다.

이 접근법의 문제점은 두 가지입니다. 첫 번째는 야간 처리가 실패하는 경우와 마찬가지로 드물지 않게 데이터베이스를 복원하여 스냅 샷이 삭제되는 것입니다. 다른 문제는 처리 시간이 SLA를 초과하여 미끄러 져 가고 있다는 것입니다. 잘못 작성된 쿼리와 인덱싱 부족을 식별 한 후 공급 업체와 협력하여이 문제를 해결하려고합니다. 데이터베이스 스냅 샷은 또한 현재와 비교할 때의 속도 차이에 의해 입증 된이 속도 저하의 원인이기도합니다.

고려 된 접근법

클러스터링

데이터베이스 클러스터링을 사용하도록 설정했지만 데이터를 사용할 수있게하는 요구를 해결하지 못했으며 일반적으로 관리자의 삶을 복잡하게 만들었습니다. 그 이후에 꺼졌습니다.

SQL Server 복제

지난주 에 복제를 살펴보기 시작 했습니다. 우리의 이론은 두 번째 카탈로그를 만들어 생산 데이터베이스와 동기화 할 수 있다는 것입니다. ETL을 시작하기 전에 연결을 끊고 ETL 프로세스가 완료된 후에 만 ​​다시 활성화합니다.

관리자는 스냅 샷 복제로 시작 했지만 스냅 샷 및 필요한 디스크 소비를 생성하는 데 며칠 동안 높은 CPU 사용량이 소요되는 것에 대해 우려하고 있습니다. 그는 .6TB 데이터베이스는 1.8TB의 스토리지 비용이 들기 때문에 가입자에게 배송하기 전에 실제 파일에 모든 데이터를 기록하는 것으로 보입니다. 또한 스냅을 생성하는 데 며칠이 걸리면 원하는 SLA에 맞지 않습니다.

훌륭한 기사를 읽은 후에는 Snapshot이 구독자를 초기화하는 방법 인 것처럼 보이지만 그 이후에 동기화를 유지하기 위해 트랜잭션 복제 로 전환하고 싶습니다 . 트랜잭션 복제를 설정 / 해제해도 전체 재 초기화가 수행되지 않습니까? 그렇지 않으면, 우리는 우리의 시간 창을 날려 버리겠다

데이터베이스 미러링

우리 데이터베이스는 전체 복구 모드에 있으므로 데이터베이스 미러링 은 옵션이지만 복제보다 데이터베이스 에 대해 덜 알고 있습니다. "데이터베이스 미러링으로 데이터에 직접 액세스 할 수 없으며 미러 된 데이터는 데이터베이스 스냅 샷을 통해서만 액세스 할 수 있습니다." 라는 SO 답변 을 찾았습니다 .

로그 배송

로그 전달 도 옵션 처럼 들리지만 이것은 내가 알지 못하는 것 중 하나입니다. 다른 것보다 저렴한 솔루션 (구현 및 유지 보수)입니까? Remus의 설명 에 따르면 "로그 전달은 복제본 사본에 대한 읽기 전용 액세스를 허용하지만 수신 된 다음 백업 로그를 적용 할 때 (예 : 15-30 분마다) 모든 사용자의 연결을 끊습니다." 가동 중지 시간이 얼마나 오랫동안 변환되어 사용자를 괴롭힐 수 있는지 잘 모르겠습니다.

MS 동기화

지난 주말 동기화 사용에 대해서만 들었고 아직 조사하지 않았습니다. 나는이 문제와 같이 가시성이 높은 무언가를위한 새로운 기술을 소개하고 싶지 않지만 최선의 접근 방법이라면 그렇게하십시오.

SSIS

우리는 여기서 많은 SSIS를 수행하므로 보조 동기화를 유지하기 위해 수백 개의 SSIS 패키지를 생성하는 것은 추악한 옵션이지만 우리에게는 선택 사항입니다 . 팀원이 맡지 않은 유지 보수 오버 헤드가 많기 때문에 저는이 일을 좋아하지 않습니다.

SAN "매직"스냅 샷

과거에는 관리자가 일부 SAN 기술을 사용하여 전체 디스크를 즉시 백업한다고 들었습니다. 아마도 mdf / ldf의 uberquick 사본을 만드는 데 사용할 수있는 EMC 매직이있을 수 있으며 대상 데이터베이스를 분리 / 연결할 수 있습니다.

백업 및 복원

우리는 일주일에 한 번 전체 백업을 수행하고 밤마다 차이를 내며 15 분마다 로그를 기록한다고 생각합니다. 사용자가 전체 복원을 위해 3-4 시간의 정전으로 살 수 있다면 이것이 접근 방법이라고 생각합니다.

제약

Windows 2008 R2, SQL Server 2008 R2 (Enterprise Edition), VMWare v5 Enterprise Edition, vmdk 파일에 매핑 된 드라이브가있는 EMC SAN 스토리지, commvault 처리 백업 및 소스 카탈로그에 .6TB의 데이터. 이것은 우리가 사내에서 호스팅하는 타사 응용 프로그램입니다. 그들의 구조를 수정하는 것은 일반적으로 눈살을 찌푸립니다. 사용자는 데이터베이스를 조회하지 않고 갈 수 없으며 작업을 수행하기 위해 모니터링하는 테이블을 사전에 식별하여 제한을 거부합니다.

우리의 DBA는 순전히 계약자입니다. 풀 타이머가 항해를 시작했으며 아직 교체하지 않았습니다. 응용 프로그램 관리자는 SQL Server 문제에 정통하지 않으며 이러한 노력을 도와 줄 수있는 스토리지 / VM 관리자 팀이 있습니다. 개발 팀은 현재 참여하지 않지만 접근 방식에 따라 참여할 수 있습니다. 따라서 솔루션을 구현하고 유지 관리하는 것이 더 간단합니다.

나, 나는 hosue의 개발 측면에있어서 접근 방식 만 제안 할 수 있으며 관리 측면을 다루지 않아도됩니다. 따라서 관리자 안장에 시간이 없어서 한 가지 접근 방식이 다른 접근 방식보다 우수 할 것이라고 주저합니다. 내가 보았을 때 DB 전문가로서 더 가치가 있기 때문에 나는 당신이 제안하는 모든 방향을 기꺼이 이행 할 것입니다. 나는 수레가 있지만 홀로 코스트 망토는 없습니다 .

관련 질문

편집

@onpnt의 질문을 해결하기 위해

데이터 대기 시간 수용

사용자는 현재 최대 24 시간이 지난 데이터를 봅니다. 데이터는 2200 현재 최신입니다

주어진 분, 시간 및 일의 데이터 양 변경 방법을 잘 모르겠습니다. 영업 시간, 시간당 수백 가지의 변화. 야간 처리, 영업 일당 수백만 행

보조에 연결

내부 네트워크, 별도의 가상 호스트 및 전용 스토리지

보조 인스턴스에 대한 읽기 요구 사항

Windows 그룹은 모든 보조 테이블에 대한 읽기 액세스 권한을 갖습니다.

보조 인스턴스의 가동 시간

가동 시간 요구 사항에 대한 강력한 정의는 없습니다. 사용자는 항상 사용할 수 있기를 원하지만 그 비용을 기꺼이 지불하지 않을 것입니다. 실제로 하루 중 23 시간이면 충분할 것입니다.

기존 스키마 및 모든 객체에 대한 변경

테이블 개체에 대해 분기별로 한 번씩 드물게 수정하는 경우가 있습니다. 코드 객체의 경우 한 달에 한 번입니다.

보안

특별한 보안 요구가 없습니다. 프로덕션 권한은 사본의 권한과 일치합니다. 내가 생각할 때, 우리는 사용자에게 prod에 대한 읽기 권한을 취소하고 사본을 읽도록 허용 할 수는 있지만 ... 요구 사항은 아닙니다.

@darin 해협

스냅 샷으로 되 돌리는 것은 선택 사항이 될 수 있지만, 그들이 그것을 추구하지 않은 이유가 있다고 생각합니다. 관리자에게 확인하겠습니다

@cfradenburg

우리는 이러한 접근 방식 중 하나만 사용한다고 가정했지만 복원으로 인해 "기타"동기화 기술이 손상 될 수 있다는 것이 좋습니다. 그들은 EMC 스냅 샷 매직 사용을 조사하고 있습니다. 관리자가 설명했듯이 1900에서 스냅 샷을 찍고 이미지를 보조 영역으로 마이그레이션합니다. 2200 년에 완료된 다음 보조 데이터베이스를 분리했다가 다시 연결합니다.

마무리

2012-10-29 EMC 스냅 샷 매직 및 기타 복제 옵션을 평가했지만 DBA는 미러링을 가장 잘 파악할 수 있다고 결정했습니다. 그들은 모두 도움이되었고 조사 할 "숙제"뿐만 아니라 많은 옵션을 주었기 때문에 답을 찬성했습니다.


문제가있을 때 데이터베이스 스냅 샷을 되돌릴 수 있습니까? 그러면 스냅 샷을 만들 때 db가 있던 위치로 되돌아갑니다. 그런 다음 새 스냅 샷을 작성하고 처리 문제를 해결 한 후 계속할 수 있습니다. W / R / T 로그 쉽핑은 로그 백업을 매일 같은 시간에 사본으로 복원 할 필요는 없습니다. 당신은 그들을 구축하고 무리로 그들을 복원 할 수 있습니다. 이렇게하면 복사본을 느리게 선택할 수 있으므로 복사본의 사용자 중단이 최소화되며 복사본이 하루 종일 변경되지 않습니다.
darin strait

데이터베이스를 주기적으로 복원해야하는 경우 빠른 방법을 다시 초기화해야합니다. DIFF 또는 LOG 백업을 복원하는 경우 DB를 다시 동기화하려면 전체 복원을 수행해야합니다. 미러링과 동일하며 복제에 대해 잘 모르겠습니다. 최선의 방법은 EMC가 무엇을 할 수 있는지 알아 보는 것입니다. NetApp과 대화 할 때 원하는 것을 수행 할 수있는 솔루션이 있지만 추가 도구입니다.
cfradenburg

답변:


6

그들의 구조를 수정하는 것은 일반적으로

복제가 가능성이 높으며 그 전에 동기화를 중단합니다. (Sync Framework의 실제 높은 초음속 테스트에서)

3-4 시간이 데이터 대기 시간을 제외하고는 로그 전달이 읽기 전용 복사본에 가장 적합 할 것입니다. 그러나 로그에서 얼마나 많은 변화가 일어나고 있습니까? 얼마나 빠르고 얼마나 많이 밀어야하는지 확인하기 위해 모니터링해야합니다.

미러링으로 이동할 수 없거나 2012 엔터프라이즈로 업그레이드 할 수없는 경우 엔터프라이즈가 아닌 경우 엔터프라이즈로 이동할 수 있으면 올바른 전략 일 것입니다.

SSIS는 단순히 데이터를 덤프하지 않고 수행 할 수 있습니다. 조회 변환 측면에서 너무 많이보고 있으므로 시간과 자원이 많이 소요됩니다. 내가 말했듯이 할 수 있습니다.

실제로 몇 가지 질문에 대한 답변을 바탕으로 선택의 폭이 좁아 질 것입니다.

  • 데이터 대기 시간 수용
  • 주어진 분, 시간 및 일의 데이터 변경 량 보조에 대한 연결
  • 보조 인스턴스에 대한 읽기 요구 사항
  • 보조 인스턴스의 가동 시간
  • 기존 스키마 및 모든 객체에 대한 변경
  • 보안

4

이것은 가장 효과적인 것을 찾기 위해 스스로 시도해야 할 것들 중 하나가 될 것입니다. 복제는 까다로울 수 있으므로 직접적인 금전적 비용은 없지만 관리상의 오버 헤드가 발생합니다.

로그 전달을 확장하려면 15-30 분마다 로그를 복원 할 필요가 없습니다. 원하는 경우 4 시간마다 또는 하루에 한 번 할 수 있습니다. 내가 구현 한 것과 비슷한 솔루션은 매주 전체 백업을 수행하고보고 DB에 복원하는 것입니다 (시간이 걸리고 주말에 발생합니다). 주 동안 차등 백업이 수행되고 매일 밤보고 데이터베이스에 복원됩니다. 복원하기 전에 사용자를 부팅해야하지만보고 DB는 업무 시간 응용 프로그램이므로 문제가 없습니다. 데이터는 하루가 지나서 요구 사항에 따라 문제가되지 않아야합니다.

이를 위해 데이터베이스 미러링을 사용하려면 Enterprise를 아직 구입하지 않은 경우 스냅 샷을 사용할 수 있도록 Enterprise를 구입해야합니다. 또한 스냅 샷을 삭제해야하고 (모든 사용자가 나가야 함을 의미) 새 데이터를 가져 오기 위해 다시 생성해야하기 때문에 데이터를 100 % 최신 상태로 유지하지 않습니다. 그러나 이것은 로그 복원이나 위에서 설명한 방법보다 시간이 덜 걸립니다.

SQL 2012로 업그레이드하는 것이 옵션 인 경우 기본 데이터베이스와 함께 최신 상태로 유지되는 읽기 전용 보조를 설정할 수 있습니다. 나는 이것이 가장 부드러운 솔루션 일 가능성이 있기 때문에 이것을 언급합니다.


4

사람들이 트랜잭션 복제에 대해 걱정하는 것처럼 상황에 맞는 것처럼 들립니다. 몇 가지 메모 :

  1. 스냅 샷으로 구독자를 초기화하지 않아도됩니다. 게시자의 백업을 가져 와서 초기화 할 수 있습니다.
  2. 배포 작업을 중지하기 만하면 구독자에게 명령 전달을 일시 중지 할 수 있습니다 (각각 푸시 또는 풀 구독으로 설정했는지 여부에 따라 배포자 또는 구독자에서 일반 SQL 에이전트 작업 임). 배급 할 수있는 충분한 이력을 유지하도록 배급사에 머무는 것을 염두에 두십시오.
  3. 원하는 경우 게시자의 색인 생성 (아마도 OLTP 유형)을 수행하지 않고 구독자에서 색인 생성을 변경하여보고 유형으로 수행 될 워크로드를 수용 할 수 있습니다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.