조직에서 SQL Server 2012 가용성 그룹을 채택 할 계획이며 응용 프로그램 업그레이드 프로세스에 미치는 영향 (있는 경우)을 이해하려고합니다.
애플리케이션 업데이트는 8 주 주기로 릴리스되며 모든 릴리스에는 스키마 변경 및 / 또는 데이터 마이그레이션이 포함될 수 있습니다.
내가 이해하려고하는 것은 HA / DR 솔루션이 스키마 변경을 투명하게 처리하는지 (새로운 열, 인덱스가 보조에 추가되는지) 또는 각 인스턴스에서 스키마를 생성 한 다음 Always On을 다시 켜기 위해 수동 개입이 필요한지 여부입니다.
내가 가정하고있는 데이터 마이그레이션 조각은 투명하게 처리되지만 확인하고 싶습니다.
또한 가용성 그룹 구성에 따라 이러한 동작에 차이가 없다고 가정합니다. 알려주세요.
간단히 말해서; 내 응용 프로그램의 특정 릴리스에서 열을 추가하여 매우 큰 테이블 (10 ~ 1 억 레코드)을 변경할 수 있습니다. 일부 열은 “net new”일 수 있으므로 Enterprise Online 스키마 변경 기능을 사용할 수 있습니다. 다른 열은 기존 열의 리팩토링 (FullName이 FirstName과 LastName으로 분할 됨) 일 수 있으며 테이블의 각 행에 대해 마이그레이션이 실행되어 이러한 필드를 채 웁니다. 이러한 동작 중 DBA가 AlwaysOn 구성을 변경해야합니까? 아니면 기본적으로 처리되며 모든 보조는 “무료”로 DDL 및 DML 문을 가져 옵니까?
제공 할 수있는 명확성에 감사드립니다.
답변
스키마 변경과 데이터 변경은 본질적으로 동일합니다. 오늘날의 미러링과 동일하게 작동합니다. 기본 로그에 발생한 작업은 보조 미러에서 발생합니다. 라스베가스에서 일어나는 모든 것이 라스베가스에 머물 필요는 없습니다. 🙂
주의해야 할 곳은 기본을 가리키는 응용 프로그램이 있고 스키마 변경 사항과 일치하도록 응용 프로그램을 업데이트하는 경우입니다. 그러나 보조 응용 프로그램을 가리키는 다른 응용 프로그램이있을 수 있으며 (예 : 읽기 전용 의도로) 해당 응용 프로그램 변경도 동기화되어야합니다.
가용성 그룹의 일부인 데이터베이스에 다른 데이터베이스의 개체 (예 : 유틸리티 데이터베이스에 저장된 정적 조회 테이블)에 대한 참조가있는 경우 또 다른 가능성이 있습니다. 이러한 변경 사항과 AG가 해당 개체에 의존하는 경우 해당 변경 사항을 수동으로 적용해야합니다. 작업, 서버 수준 로그인, 연결된 서버 등의 경우에도 마찬가지입니다. 데이터베이스 외부에 있거나 거래 할 수없는 모든 것. 데이터베이스 사용자는 분리되어있을 수 있습니다 (포함 된 사용자 제외). 나는 이것이 명백한 것을 알고 있지만 완전성을 위해 명시 적으로 나열하고 싶었습니다.
답변
Remus의 더 많은 답변은 사용자가 보조 복제본에서 쿼리를 제거하고 테이블에서 리두 큐 크기 상태를 확인하도록 요청합니다. sys.dm_hadr_database_replica_states AlwaysOn DDL 및 스키마 변경