2012-06-12 2 views
2

저는 Azure & SQL Azure를 사용하여 웹 응용 프로그램을 구축하고 있습니다. 나는 각 조직이 그들 만의 데이터베이스를 갖도록 설정하고있다. 고객 조직 당 트래픽이 적거나 중간입니다.웹 응용 프로그램 용 SQL Azure 장애 조치/백업 전략

SQL Azure가 다운되면 내 응용 프로그램을 내 온 - 프레미스 SQL Server (읽기 전용 모드)로 전환 할 수 있도록 SQL Azure Data Sync를 장애 조치/백업 계획의 일부로 사용하려고합니다.

비용을 부담시킬 수있는 클라우드가 아닌 온 - 내 백업을 모두 수행 할 수도 있습니다.

  • 한 가지 문제는 내 온 프렘 SQL 서버에 데이터 동기화에 여러 데이터베이스를 시도 할 수있다

  • (한계가 하나 개의 서버에 동기화 할 수있는 데이터베이스 의 숫자가 뭔지 확실하지)
  • 대역폭이 문제 일 수는 있지만 매일 동기화 만합니다.

누구나이 접근 방식에 다른 문제가 있습니까?

답변

1

데이터 동기화는 괜찮지 만 트랜잭션 동기화 모델이 아니기 때문에 특정 DR 계획에 좋지 않을 수도 있습니다. 고려해야 할

하나의 옵션은 데이터베이스 복사본을 만드는 :

CREATE DATABASE destination_database_name 
    AS COPY OF [source_server_name.]source_database_name 

는 그런 다음 데이터베이스 복사본을 삭제 BLOB 저장소에 백업을 저장,이 사본에서 백업을 생성하고 (선택적으로) 할 수 있습니다. 이로 인해 두 번째 데이터베이스가 가동되기 때문에 추가 비용이 추가되지만 백업을 생성하고 BLOB 저장소에 저장 한 후에 데이터베이스 인스턴스를 삭제하면 데이터베이스 비용이 최소한으로 유지됩니다. 데이터베이스는 매일 상환됩니다.

백업은 BLOB 저장소에 저장되므로 BLOB 저장소에 여러 백업을 유지하고 필요할 경우 사내 구축 형 서버로 백업을 가져올 수 있습니다.

+0

감사합니다. "트랜잭션 동기화 모델이 아닙니다"라는 의미를 설명 할 수 있습니까? 내 사내 db가 트랜잭션의 일부 데이터를 누락하고 있음을 의미합니까? – PeteShack

+0

또한 대역폭면에서 매일 전체 데이터베이스를 다운로드하는 것보다 데이터 동기화가 더 낫지 않습니까? (내가 1 일 밖에되지 않은 온 - 데이터베이스를 유지하려고한다고 가정 할 때) – PeteShack