자동 시드를 사용하여 Always On 가용성 그룹에 대한 보조 복제본 초기화
적용 대상:
SQL Server
SQL Server 2012 및 2014에서 SQL Server Always On 가용성 그룹의 보조 복제본을 초기화하는 유일한 방법은 백업, 복사 및 복원을 사용하는 것입니다. SQL Server 2016에는 보조 복제본을 초기화하는 자동 시드 기능을 새로 도입되었습니다. 자동 시드는 VDI를 사용하여 구성된 엔드포인트를 사용하는 가용성 그룹의 각 데이터베이스에 대한 보조 복제본으로 백업을 스트리밍하기 위해 로그 스트림 전송을 사용합니다. 새로운 이 기능은 가용성 그룹을 처음 만드는 중이거나 또는 데이터베이스가 하나에 추가될 때 사용할 수 있습니다. 자동 시드는 Always On 가용성 그룹을 지원하는 SQL Server의 모든 버전에 포함되어 있으며, 기존의 가용성 그룹 및 분산 가용성 그룹 모두에서 사용할 수 있습니다.
보안
보안 권한은 초기화되는 복제본의 유형에 따라 다릅니다:
- 기존 가용성 그룹의 경우 보조 복제본이 가용성 그룹에 가입될 때 해당 보조 복제본의 가용성 그룹에 권한을 부여해야 합니다. Transact-SQL에서 명령
ALTER AVAILABILITY GROUP [<AGName>] GRANT CREATE ANY DATABASE을 사용합니다. - 만들어지고 있는 복제본의 데이터베이스가 두 번째 가용성 그룹의 주 복제본에 있는 분산 가용성 그룹의 경우 이미 주 복제본이기 때문에 추가 권한은 필요하지 않습니다. 그러나 두 번째 가용성 그룹에 복제본이 하나만 있다면, 보조 가용성 그룹 이름에
CREATE ANY DATABASE권한을 부여해야 합니다. 부여하지 않으면 자동 시드가 실패하게 됩니다. - 분산 가용성 그룹의 두 번째 가용성 그룹에 있는 보조 복제본의 경우
ALTER AVAILABILITY GROUP [<2ndAGName>] GRANT CREATE ANY DATABASE명령을 사용해야 합니다. 이 보조 복제본에서는 두 번째 가용성 그룹의 주 데이터베이스에서 시드가 됩니다.
주 복제본에 대한 성능 및 트랜잭션 로그 영향
자동 시드는 데이터베이스의 크기, 네트워크 속도 및 주 복제본 사이 에서의 거리에 따라 보조 복제본(replica) 초기화하는 것에 실용적이거나 그렇지 않을 수 있습니다. 예를 들어 다음과 같은 조건이 있습니다.
- 데이터베이스 크기는 5TB입니다
- 네트워크 속도는 1Gb/초입니다
- 두 사이트 사이에서의 거리는 1000마일입니다
전체 대역폭을 사용할 수 있는 경우 1Gb/초의 네트워크는 125MB/초의 지속적인 처리량을 제공할 수 있습니다. 이 예제에서는 자동 시드에 11시간이 넘게 소요됩니다. 실제로 네트워크 신호가 더 먼 거리에서 걸쳐서 저하가 되며 링크는 네트워크의 다른 리소스와 공유가 되기 때문에 자자동 시스 프로세스가 더 느려지는 것입니다. 시드가 이뤄지는 동안 주 복제본에 있는 데이터베이스의 트랜잭션 로그는 계속 증가하게 되고 해당 데이터베이스의 자동 시드를 완료할 때까지 잘릴 수가 없습니다. 그런 후에는 트랜잭션 로그 백업을 사용하여 트랜잭션 로그를 잘라낼 수 있습니다.
자동 시드는 최대 다섯 개의 데이터베이스를 처리할 수 있는 단일 스레드 프로세스입니다. 특히 가용성 그룹에 둘 이상의 데이터베이스가 있는 경우 단일 스레딩이 성능에 영향을 미칠 수 있습니다.
압축은 자동 시드를 위해서 사용될 수 있지만 기본적으로 사용되지는 않습니다. 압축을 켜면 네트워크 대역폭을 줄이며 프로세스 속도가 빨라질 수 있지만 그에 따른 추가적인 프로세서 오버헤드가 발생하게 됩니다. 자동 시드 중에 압축을 사용하려면 9567 추적 플래그를 사용하도록 설정합니다. 가용성 그룹에 대한 압축 성능 조정을 참조해 주세요.
디스크 레이아웃
SQL Server 2016 및 이전 버전에서는 자동 시드로 데이터베이스를 만들어진 폴더가 이미 존재하고 있어야 하며 주 복제본의 경로와 동일해야 합니다.
SQL Server 2017에서는 가용성 그룹에 참여하는 모든 복제본에서 동일한 데이터 및 로그 파일 경로를 사용하는 게 좋겠지만 필요하면 다른 경로를 사용할 수도 있습니다. 예를 들어 플랫폼 간 가용성 그룹에서 SQL Server의 한 개의 인스턴스는 Windows에 있으며 다른 SQL Server의 인스턴스는 Linux에 있는 경우도 있습니다. 플랫폼별로 기본 경로가 다릅니다. SQL Server 2017은 기본 경로가 다른 SQL Server의 인스턴스에서 가용성 그룹 복제본을 지원합니다.
다음 표는 자동 시드를 지원할 수 있는 지원되는 데이터 디스크 레이아웃의 예를 보여줍니다.
| 주 인스턴스 기본 데이터 경로 |
보조 인스턴스 기본 데이터 경로 |
주 인스턴스 원본 파일 위치 |
보조 인스턴스 대상 파일 위치 |
|---|---|---|---|
| c:\data\ | /var/opt/mssql/data/ | c:\data\ | /var/opt/mssql/data/ |
| c:\data\ | /var/opt/mssql/data/ | c:\data\group1\ | /var/opt/mssql/data/group1/ |
| c:\data\ | d:\data\ | c:\data\ | d:\data\ |
| c:\data\ | d:\data\ | c:\data\group1\ | d:\data\group1\ |
주 및 보조 복제본 데이터 위치가 인스턴스 기본 경로가 아닌 시나리오는 이 변경 사항에 영향을 받지 않습니다. 주 복제본 파일 경로와 일치하는 보조 복제본 파일 경로에 대한 요구 사항은 동일하게 유지됩니다.
| 주 인스턴스 기본 데이터 경로 |
보조 인스턴스 기본 데이터 경로 |
주 인스턴스 파일 위치 |
보조 인스턴스 파일 위치 |
|---|---|---|---|
| c:\data\ | c:\data\ | d:\group1\ | d:\group1\ |
| c:\data\ | c:\data\ | d:\data\ | d:\data\ |
| c:\data\ | c:\data\ | d:\data\group1\ | d:\data\group1\ |
주 및 보조 복제본에서 기본 경로와 기본이 아닌 경로가 혼합된 경우 SQL Server 2017은 이전 릴리스와 다르게 동작합니다. 다음 표에서는 SQL Server 2017 동작을 보여줍니다.
| 주 인스턴스 기본 데이터 경로 |
보조 인스턴스 기본 데이터 경로 |
주 인스턴스 파일 위치 |
SQL Server 2016 보조 인스턴스 파일 위치 |
SQL Server 2017 보조 인스턴스 파일 위치 |
|---|---|---|---|---|
| c:\data\ | d:\data\ | c:\data\ | c:\data\ | d:\data\ |
| c:\data\ | d:\data\ | c:\data\group1\ | c:\data\group1\ | d:\data\group1\ |
SQL Server 2016 및 이전 버전의 동작을 되돌리려면 추적 플래그 9571을 설정합니다. 추적 플래그를 설정하는 방법에 대한 자세한 정보는 DBCC TRACEON(Transact-SQL)을 참조해 주세요.
자동 시드로 가용성 그룹 만들기
Transact-SQL 또는 SSMS(SQL Server Management Studio) 버전 17 이상에서 자동 시드를 사용하여 가용성 그룹을 만듭니다. SSMS에서 가용성 그룹 마법사를 사용하려면 여기에 나오는 지침을 따라 해 주세요. 9단계에 도달할 때 자동 시드는 첫 번째 및 기본 옵션으로 표시됩니다.
다음 예제에서는 Transact-SQL을 사용하여 자동 시드가 포함된 가용성 그룹을 만듭니다. 가용성 그룹 만들기(Transact-SQL) 항목도 참조해 주세요. SEEDING_MODE 옵션을 AUTOMATIC으로 설정하여 보조 복제본에서 시드를 사용하도록 설정합니다. 기본 동작은 MANUAL이며, 이는 주 복제본에 데이터베이스를 백업하고, 보조 복제본에 백업 파일을 복사하고, WITH NORECOVERY를 사용하여 백업을 복원해야 하는 SQL Server 2016 이전 버전의 동작입니다.
CREATE AVAILABILITY GROUP [<AGName>]
FOR DATABASE db1
REPLICA ON N'Primary_Replica'
WITH (
ENDPOINT_URL = N'TCP://Primary_Replica.Contoso.com:5022',
FAILOVER_MODE = AUTOMATIC,
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT
),
N'Secondary_Replica' WITH (
ENDPOINT_URL = N'TCP://Secondary_Replica.Contoso.com:5022',
FAILOVER_MODE = AUTOMATIC,
SEEDING_MODE = AUTOMATIC);
GO
주 복제본에 이미 데이터베이스의 기본 읽기/쓰기 복사본이 포함되어 있으므로SEEDING_MODE 문에서 CREATE AVAILABILITY GROUP기본 복제본을 설정한다고 하여도 아무런 영향을 받지 않습니다. SEEDING_MODE 는 다른 복제본이 주 복제본이 되고 데이이터베이스가 추가된 경우에만 적용됩니다. 시드 모드는 나중에 변경할 수 있습니다. 복제본의 시드 모드 변경을 참조해 주세요.
보조 복제본이 되는 인스턴스에서 인스턴스가 조인되면 다음 메시지는 SQL Server 로그에 추가됩니다:
가용성 그룹 'AGName'에 대해 로컬 가용성 복제본에 데이터베이스를 만드는 권한이 부여되지 않았지만,
SEEDING_MODE및AUTOMATIC가 있습니다. 기본 가용성 복제본으로 시드 된 데이터베이스의 생성을 허용하기 위하여ALTER AVAILABILITY GROUP ... GRANT CREATE ANY DATABASE을 사용합니다.
보조 복제본에서 가용성 그룹에 데이터베이스 만들기 권한 부여
조인한 후 SQL Server의 보조 복제본 인스턴스에서 가용성 그룹 권한을 부여하여 데이터베이스를 만드세요. 자동 시드를 실행하려면 가용성 그룹에 데이터베이스를 만들 수 있는 권한이 있어야 합니다.
팁
가용성 그룹이 보조 복제본에서 데이터베이스를 만들 때 데이터베이스 소유자로 ‘sa’(좀 더 구체적으로 0x01 sid를 사용하는 계정)를 설정합니다.
보조 복제본이 자동으로 데이터베이스를 만들어 낸 후 데이터베이스 소유자를 변경하려면 ALTER AUTHORIZATION을 실행합니다. ALTER AUTHORIZATION (Transact-SQL)를 참조해 보세요.
다음 예제에서는 AGName이라는 가용성 그룹에 권한을 부여합니다.
ALTER AVAILABILITY GROUP [<AGName>]
GRANT CREATE ANY DATABASE
GO
필요한 경우 보조 복제본에서 데이터베이스의 소유자를 설정합니다.
자동 시드 확인
성공하면 데이터베이스가 다음 중 하나의 상태로 보조 복제본에 자동으로 만들어지게 됩니다:
- SYNCHRONIZED(동기화됨) 보조 복제본이 동기로 구성되고 데이터가 동기화되면 동기화됩니다.
- SYNCHRONIZING(동기화 중) - 보조 복제본이 비동기 데이터 이동으로 구성되었거나 동기로 구성되었지만 주 복제본과 아직 동기화되지 않은 경우.
자동 시드의 시작과 완료는 아래에서 설명하는 동적 관리 뷰뿐만 아니라 SQL Server 로그에서도 확인할 수 있습니다.
자동 시드로 백업 및 복원 결합
기존의 백업, 복사 및 복원을 자동 시드와 결합할 수 있습니다. 이 경우 먼저 사용할 수 있는 모든 트랜잭션 로그를 포함하여 데이터베이스를 보조 복제본에 복원합니다. 다음으로 비상 로그 백업이 복원한 것처럼 보조 복제본의 데이터베이스를 "따라잡기" 위해서 가용성 그룹을 만들 때 자동 시드를 사용하도록 설정합니다(비상 로그 백업(SQL Serve)를 참조해 주세요).
자동 시드로 가용성 그룹에 데이터베이스 추가
Transact-SQL 또는 SSMS(SQL Server Management Studio) 버전 17 이상에서 자동 시드를 사용하여 가용성 그룹에 데이터베이스를 추가할 수 있습니다.
보조 복제본을 가용성 그룹에 추가할 때 자동 시드를 사용한 경우 추가로 작업을 실행해야만 하는 작업은 없습니다. 보조 복제본에서 백업, 복사 및 복원을 사용한 경우 먼저 시드 모드를 변경(다음 섹션 참조)한 다음 데이터베이스를 추가할 때 GRANT 문을 사용합니다. 가용성 그룹 - 데이터베이스 추가를 참조하세요.
복제본의 시드 모드 변경
가용성 그룹을 만든 후에 복제본의 시드 모드를 변경하여 자동 시드를 사용하거나 사용하지 않도록 설정할 수 있습니다. 가용성 그룹을 만든 후에 자동 시드를 사용하도록 설정하면 백업, 복사 및 복원으로 가용성 그룹을 만들었을 때 자동 시드를 사용하여 이 가용성 그룹에 데이터베이스를 추가할 수 있습니다. 예시:
ALTER AVAILABILITY GROUP [AGName]
MODIFY REPLICA ON 'Replica_Name'
WITH (SEEDING_MODE = AUTOMATIC)
자동 시드를 사용하지 않도록 설정하려면 MANUAL 값을 사용합니다.
가용성 그룹을 만든 후 자동 시드 방지
보조 복제본에 대해 자동 시드를 완전히 사용이 불가능하도록 설정하는 것이 아닌 보조 복제본에서 데이터베이스를 자동으로 작성을 할 수 없도록 하려면 가용성 그룹 CREATE 권한은 거부됩니다. 이 경우 새 데이터베이스를 가용성 그룹에 추가했지만 가용성 그룹에서 보조 복제본에 데이터베이스를 만들 수 없습니다.
ALTER AVAILABILITY GROUP [AGName]
DENY CREATE ANY DATABASE
GO
자동 시드 모니터링
자동 시드를 모니터링하고 문제를 해결하는 것에는 네 가지 방법이 있습니다:
- 이미 설명한 SQL Server 로그
- 동적 관리 뷰
- 백업 기록 테이블
- 확장 이벤트
동적 관리 뷰
시드를 모니터링하기 위한 두 가지 DMV(동적 관리 뷰)에는 sys.dm_hadr_automatic_seeding 및 sys.dm_hadr_physical_seeding_stats가 있습니다.
sys.dm_hadr_automatic_seeding은 자동 시드의 일반 상태를 포함하고 자동 시드가 실행될 때마다 기록을 유지합니다(성공 여부와 관계없이).current_state열에는 COMPLETED(완료) 또는 FAILED(실패) 값이 있습니다. 값이 FAILED인 경우failure_state_desc의 값을 사용하여 문제를 진단해 보세요. 무엇이 잘못되었는지 확인하기 위해서 SQL Server 로그의 에 있는 내용과 결합해야 할 수 있습니다. 이 DMV는 주 복제본과 모든 보조 복제본에 채워집니다.sys.dm_hadr_physical_seeding_stats는 자동 시드 작업이 실행 중일 때의 상태를 보여줍니다.sys.dm_hadr_automatic_seeding과 마찬가지로 주 및 보조 복제본 모두에 대해 값을 반환하지만 이 기록은 저장되지 않습니다. 값은 현재 실행 전용이며 유지되지 않습니다. 관심 있는 열에는start_time_utc,end_time_utc,estimate_time_complete_utc,total_disk_io_wait_time_ms,total_network_wait_time_ms에서는 시드 작업이 실패하는 경우 failure_message를 포함합니다.
백업 기록 테이블
자동 시드는 백업 및 복원 기록을 저장하는 msdb테이블에 항목을 저장합니다. 자동 시드를 받고 있는 보조 복제본에서 backupmediafamily 테이블의 physical_device_name 열에는 값에 대한 GUID가 있고, backupset의 해당 항목에는 server_name 및 machine_name에 대한 주 복제본의 이름이 있습니다.
확장 이벤트
자동 시드는 초기화 중에 상태 변경, 오류 및 성능 통계를 추적하기 위한 새로운 확장 이벤트를 추가합니다. 예를 들어 다음 스크립트에서는 자동 시드와 관련된 이벤트를 캡처하는 확장 이벤트 세션을 만듭니다.
CREATE EVENT SESSION [AlwaysOn_autoseed] ON SERVER
ADD EVENT sqlserver.hadr_automatic_seeding_state_transition,
ADD EVENT sqlserver.hadr_automatic_seeding_timeout,
ADD EVENT sqlserver.hadr_db_manager_seeding_request_msg,
ADD EVENT sqlserver.hadr_physical_seeding_backup_state_change,
ADD EVENT sqlserver.hadr_physical_seeding_failure,
ADD EVENT sqlserver.hadr_physical_seeding_forwarder_state_change,
ADD EVENT sqlserver.hadr_physical_seeding_forwarder_target_state_change,
ADD EVENT sqlserver.hadr_physical_seeding_progress,
ADD EVENT sqlserver.hadr_physical_seeding_restore_state_change,
ADD EVENT sqlserver.hadr_physical_seeding_submit_callback
ADD TARGET package0.event_file(
SET filename=N'autoseed.xel',
max_file_size=(5),
max_rollover_files=(4)
)
WITH (
MAX_MEMORY=4096 KB,
EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,
MAX_DISPATCH_LATENCY=30 SECONDS,
MAX_EVENT_SIZE=0 KB,
MEMORY_PARTITION_MODE=NONE,
TRACK_CAUSALITY=OFF,
STARTUP_STATE=ON
)
GO
ALTER EVENT SESSION AlwaysOn_autoseed ON SERVER STATE=START
GO
다음 표에서는 자동 시드와 관련된 확장 이벤트가 나열되어 있습니다.
| 속성 | 설명 |
|---|---|
| 시드 요청 메시지입니다 | 시드 요청 메시지입니다. |
| hadr_physical_seeding_backup_state_change | 물리적 시드 백업 쪽 상태가 변경됩니다. |
| 물리적 시드 복원 관련 상태 변경입니다 | 물리적 시드 복원 쪽 상태 변경입니다. |
| 물리적 시드 전달자 관련 상태 변경입니다 | 물리적 시드 전달자 대상 관련 상태 변경입니다. |
| 물리적 시드 전달자 대상 관련 상태 변경입니다 | 물리적 시드 전달자 대상 관련 상태 변경입니다. |
| hadr_physical_seeding_submit_callback | 물리적 시드 전송 콜백 이벤트입니다. |
| hadr_physical_seeding_failure | 물리적 시드 실패 이벤트입니다. |
| hadr_physical_seeding_progress | 물리적 시드 진행 이벤트입니다. |
| 물리적 시드 일정 장기 작업 오류 이벤트입니다 | 물리적 시드 일정 장기 작업 오류 이벤트입니다. |
| hadr_automatic_seeding_start | 자동 시드 작업이 제출되면 발생합니다. |
| hadr_automatic_seeding_state_transition | 자동 시드 작업 상태가 변경될 때 발생합니다. |
| hadr_automatic_seeding_success | 자동 시드 작업이 성공하면 발생합니다. |
| hadr_automatic_seeding_failure | 자동 시드 작업이 실패하면 발생합니다. |
| hadr_automatic_seeding_timeout | 자동 시드 작업이 시간제한이 될 때 발생합니다. |
참고 항목
ALTER AVAILABILITY GROUP(Transact-SQL)
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기