SQL Server 2016 가용성 그룹-분산된 가용성그룹편

   

[참고문서]

분산된 가용성 그룹(Always On 가용성 그룹)

https://msdn.microsoft.com/ko-kr/library/mt651673.aspx

분산된 가용성 그룹을 사용하면 서로 다른 Windows Server 장애 조치 클러스터(WSFC)에 있는 두 가용성 그룹을 연결할 수 있습니다. 분산된 가용성 그룹 배포의 주요 용도 중 하나는 기본 사이트가 DR 사이트로부터 지리적으로 분산된 곳의 문제 해결를 위한 것입니다.

One of the main uses of Distributed Availability Groups is for disaster recovery where the primary site is geographically dispersed from the DR site.

원하는 데이터를 지속적으로 DR 사이트에 복제 하지 않으려는 잠재적인 네트워크 문제 또는 기본 사이트에 종료 DR 사이트에서 문제입니다.

   

[장점]

1개의 FCI로 구축하여 DR replica 로 구성했을 경우에 해당 클러스터가 뭉개졌을때 복구가 어려울 수 있다 ??

그래서 2개의 FCI 로 자체 DR WSFC 로 구성하는 방안이다 ??

그럼 클러스터가 뭉개질 경우가 많을까?

   

[단점]

관리하기 어려울 듯하다.

전체적인 개념을 알고 있어야 장애 시 적절하게 대응이 가능할 것 같다.

   

   

일단 기능이 잘되는지를 알아보는 단계이므로 장/단점을 아직 모르겠다.

   

[환경]

WSFC1, WSFC2 의 별도 클러스터 환경에서 각 주 복제본, 보조 복제본이 존재하는 구성이다.

각 클러서터의 가용성그룹을 또 다른 가용성그룹으로 생성하는 기능이다.

   

   

   

   

   

[구축하기]

T-SQL로만 구성이 가능한 것 같다.

#.1 첫번째 클러스터 에서 가용성그룹을 생성한다.

아래 쿼리 참고.

   

#.2 두번째 클러스터에서 가용성그룹을 생성한다.

   

-- 두번째 클러스터의 주 복제복에서 가용성 그룹을 생성한다.

CREATE AVAILABILITY GROUP [AG2-Seeding]

FOR

REPLICA ON N'SQL2016-AG1' WITH (ENDPOINT_URL = N'TCP://SQL2016-AG1.overtop.local:5022',

FAILOVER_MODE = MANUAL,

AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,

BACKUP_PRIORITY = 50,

SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),

SEEDING_MODE = AUTOMATIC),

N'SQL2016-AG2' WITH (ENDPOINT_URL = N'TCP://SQL2016-AG2.overtop.local:5022',

FAILOVER_MODE = MANUAL,

AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,

BACKUP_PRIORITY = 50,

SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),

SEEDING_MODE = AUTOMATIC);

GO

   

   

-- 두번째 클러스터의 보조복제복에서 수행

ALTER AVAILABILITY GROUP [AG2-Seeding] JOIN

ALTER AVAILABILITY GROUP [AG2-Seeding] GRANT CREATE ANY DATABASE

GO

   

-- 수신기를 만든다. 필수

ALTER AVAILABILITY GROUP [AG2-Seeding]

    ADD LISTENER 'AG2SeedLsn' ( WITH IP ((N'10.1.14.83',N'255.255.255.0')) , PORT = 1433);

GO

   

   

#.3 분산 가용성 그룹 생성하기

   

-- 첫번째 클러스터에의 주 복제복에서 실행한다.

-- 분산된 가용성 그룹을 생성한다.

CREATE AVAILABILITY GROUP [distributedag]

   WITH (DISTRIBUTED)

   AVAILABILITY GROUP ON

      'AG-Seeding' WITH

   (

         LISTENER_URL = 'tcp://AGSeedLsn:5022',

         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,

         FAILOVER_MODE = MANUAL,

         SEEDING_MODE = AUTOMATIC

      ),

      'AG2-Seeding' WITH

      (

         LISTENER_URL = 'tcp://AG2SeedLsn:5022',

         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,

         FAILOVER_MODE = MANUAL,

         SEEDING_MODE = AUTOMATIC

      );

GO

   

-- 두번째 클러스터의 주 복제본에서 분산된 가용성그룹 조인하기

ALTER AVAILABILITY GROUP [distributedag]

   JOIN

   AVAILABILITY GROUP ON

      'AG-Seeding' WITH

   (

         LISTENER_URL = 'tcp://AGSeedLsn:5022',

         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,

         FAILOVER_MODE = MANUAL,

         SEEDING_MODE = AUTOMATIC

      ),

      'AG2-Seeding' WITH

      (

         LISTENER_URL = 'tcp://AG2SeedLsn:5022',

         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,

         FAILOVER_MODE = MANUAL,

         SEEDING_MODE = AUTOMATIC

      );

GO

   

   

#.4 완료.

   

간단하다.

   

실제 구축된 화면을 보면 그냥 가용성그룹이 한 개 더 생긴 것이다.

• 분산 가용성그룹에 복제본을 확인하면 수신기 이름으로 생성이 된다.
• 가용성 데이터베이스는 없다.
• 수신기도 없다.
• 가용성 그룹 옆에 (분산된, Distributed) 로 표기된다.

   

분산된 가용성 그룹 삭제는 간단하게 삭제가 된다.

-- 분산 가용성 그룹 삭제

DROP AVAILABILITY GROUP [distributedag]

   

   

또 하나,

DML은 어디서 수행해야 하는지가 궁금할 것이다.

주 가용성 그룹의 주 복제본에서 하면 된다.

보조 가용성 그룹의 주 복제본에서 DML을 하게 되면 오류가 발생한다.

상태가 Read-only 상태가 된다.

   

insert into tbl values(1, getdate())

/*

Msg 3906, Level 16, State 2, Line 6

Failed to update database "AGDirectSeeding01" because the database is read-only.

*/

   

이런 각각의 복제본의 구성값들의 정의가 명확하게 해야지만 가용성 그룹을 제대로 사용하며,

장애 대응도 빠르게 할 수 있다.

   

   

[추후 할일]

#.1 Direct Seeding 방식으로만 가능한가 ? 다른 동기방식으로 구현해보자.

#.2 각 가용성 그룹 및 분산 가용성 그룹을 모니터링하는 쿼리를 만들어보자.

키워드 : 분산가용성그룹