Database Mirroring Dynamics
SQL Server 2005 데이터베이스 미러링을 자세히 이해하려면 데이터베이스 미러링 세션이 시간이 지남에 따라 어떻게 변하는 지 확인하는 것이 도움이 됩니다. 이 절에서는 데이터베이스 미러링 세션의 여러 가지 데이터베이스 상태, 동기 및 비동기 로그 레코드 전송의 메커니즘, 장애 조치 순서를 다룰 것입니다.
설정 및 보안
주 서버, 미러 서버 및 선택적으로 감시 서버를 식별한 후에 Database Mirroring 설정은 세 단계로 구성됩니다.
데이터베이스를 백업하고 복구 없이 원하는 미러 서버로 복원해야 합니다.
주: 데이터베이스를 백업하여 미러 서버에 복원하기 전에 주 데이터베이스는 FULL 복구 모델에 있어야 합니다. 트랜잭션 로그에서 대량 로그 레코드를 전송해야 하는 경우 데이터베이스 미러링이 작동하지 않습니다. 미러 서버에는 주 데이터 베이스만큼 파일이 확장될 충분한 여유 공간이 있어야 합니다. 미러에 데이터베이스 스냅샷을 만들려면 추가 여유 공간을 제공해야 합니다.
백업, 복사 및 복원에 상대적으로 오랜 시간이 걸리는 경우 로그 크기를 제어하기 위해 원본 데이터베이스에서 트랜잭션 로그 백업을 수행해야 합니다. 그러나 트랜잭션 로그 레코드가 로그 백업에 의해 로그에서 잘린 경우 데이터베이스 미러링 을 초기화하지 못할 수 있습니다. 따라서 데이터베이스 미러링을 초기화하기 전에 복구 없이 원하는 미러 데이터베이스로 이러한 트랜잭션 로그 백업을 순서대로 복원해야 합니다.
데이터베이스 미러링 세션에 관련된 서버를 서로를 신뢰해야 합니다. 도메인 같은 로컬 통신의 경우 신뢰는 각 SQL Server 인스턴스 로그인이 다른 미러링 서버에 연결할 권리가 있어야 하며 해당 종점을 수행하는 것을 의미합니다. 각 서버에서 먼저 CREATE LOGIN 명령을 사용한 다음 GRANT CONNECT ON ENDPOINT 명령을 사용하여 이를 설정합니다. SQL Server 온라인 설명서의“Example of Setting Up Database Mirroring Using Windows Authentication”을 참조하십시오.
신뢰하지 않는 도메인을 통해 통신하는 경우 인증서를 사용해야 합니다. CREATE CERTIFICATE 문을 사용하여 자체 서명 된 인증서를 만드는 경우 대부분의 데이터베이스 미러링 인증서 요구 사항이 만족됩니다. 또한 CREATE CERTIFICATE 문에서 인증서가 ACTIVE FOR BEGIN_DIALOG로 표시되었는지도 확인해야 합니다.
다음 단계는 데이터베이스 미러링 종단을 설정하는 것입니다. 종단점을 설정하려면 SQL Server 인스턴스에 대해 시스템 관리자 권한이 필요합니다. 데이터베이스 미러링 종단점으로 명시적으로 만든 각 서버에서 종단점을 설정해야 합니다. 종단점을 설정하는 가장 간단한 방법은 Configure Database Mirroring Security Wizard를 사용하는 것입니다. Database Properties 대화 상자의 Mirroring 페이지에서 Configure Security 단추를 클릭하여 실행할 수 있습니다. Configure Security 대화 상자는 CREATE ENDPOINT 명령을 구성하고 실행하기 전에 컴퓨터 이름과 포트 번호 및 선택적으로 로그인을 묻습 니다. Transact-SQL을 사용하여 CREATE ENDPOINT 명령을 실행할 수도 있습니다. SQL Server 온라인 설명서의“How to: Create a Mirroring Endpoint (Transact-SQL)”를 참조하십시오.
도메인에 데이터베이스 미러링을 설정하고 있고 모든 SQL Server 인스턴스가 같은 서비스 로그인과 암호를 사용하는 경우 각 서버에 로그인을 만들 필요는 없습니다. 마찬가지로 작업 그룹에서 모든 SQL Server 인스턴스가 같은 서비스 로그인과 암호를 사용하는 경우 서버에 로그인을 만들 필요가 없습니다. 종단점을 설정할 때 Configure Database Mirroring Security Wizard에 서 로그인을 비워두면 됩니다.
각 데이터베이스 종단점은 서버에 고유한 포트를 지정해야 합니다. 개별 시스템에서 SQL Server 인스턴스 작업을 수행하면 이러한 포트 번호는 모두 같을 수 있으며 Configure Database Mirroring Security Wizard는 포트로 포트 5022를 자동으로 제안 합니다. SQL Server 인스턴스가 같은 시스템에 있는 경우 각 인스턴스는 개별 포트를 가져야 하며 포트 번호는 고유해야 합니다.
고가용성 미러링 세션에서 세 개의 서버를 사용한다고 가정합시다. 서버 A는 주 서버, 서버 B는 미러, 서버 W는 감시 서버가 됩니다. 서버 A의 경우 다음 명령은 포트 5022에 종단점을 만듭니다.
CREATE ENDPOINT [Mirroring]
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (ROLE = PARTNER, ENCRYPTION = ENABLED);
역할이 PARTNER로 지정되었으므로, 이 서버는 해당 데이터베이스 미러링 데이터베이스에 대해 주 또는 미러 서버의 역할을 맡을 수 있습니다. 서버 B에 같은 명령이 실행됩니다. 서버 B는 개별 실제 시스템에 있는 SQL Server 인스턴스이므로 포트 번호는 동일합니다. 서버 W의 경우 다음 명령을 실행할 수 있습니다.
CREATE ENDPOINT [Mirroring]
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (ROLE = WITNESS, ENCRYPTION = ENABLED);
서버 W의 경우 역할은 WITNESS로 지정되었습니다. 기본적으로 종단점은 시작되지 않습니다. 다음에 각 서버에서 다음 쿼리를 사용하여 각 종단점을 시작할 수 있습니다.
ALTER ENDPOINT [Mirroring] STATE = STARTED;
선택적으로 CREATE ENDPOINT 명령에 STATE 옵션을 삽입할 수 있습니다. 이 프로세스는 각 서버에서 반복됩니다. CREATE ENDPOINT를 사용하여 종단점을 만들 때 프로토콜 관련 인수를 사용하여 IP 주소로 액세스를 제한할 수 있습니다. RESTRICT_IP를 ALL 옵션과 함tabase_mirroring_endpoints 카탈로그 뷰를 쿼리하여 서버에서 데이터베이스 미러링 종단점을 검사할 수 있습니다.
SELECT *
FROM sys.database_mirroring_endpoints;
4. 데이터베이스 미러링을 시작하려면 파트너와 감시를 지정합니다. 해당 데이터베이스 미러링 세션을 시작하고 관리하려면 데이터베이스 소유자 권한이 있어야 합니다. 원하는 주 서버인 서버 A에서 SQL Server가 특정 데이터베이스에 주 서버 역할을 부여하고 어느 것을 파트너(미러) 서버로 할 것인지 지정하도록 합니다.
-- 주 서버에서 파트너 지정
ALTER DATABASE [AdventureWorks] SET PARTNER=
N’TCP://B.corp.mycompany.com:5022’;
파트너??니다. 정규화된 이름을 찾는 것은 어려울 수 있지만 종단점을 설정하면 Configure Database Mirroring Security Wizard가 이를 자동으로 찾아줍니다.
각 서버의 정규화된 컴퓨터 이름은 명령 프롬프트에서 다음 명령을 실행하여 찾을 수도 있습니다.
IPCONFIG /ALL
"Host Name"및"Primary DNS Suffix"를 연결합니다. 다음과 같은 내용이 표시되는 경우
Host Name . . . . . . . . . . . . : A
Primary Dns Suffix . . . . . . . : corp.mycompany.com
그러면 컴퓨터 이름은 A.corp.mycompany.com이고 접두사‘TCP://’및 접미사는‘:’이며 파트너 이름이 있습니다.
미러 서버에서는 같은 명령을 반복하지만 주 서버 이름은 다음과 같습니다.
-- 미러 서버에서 파트너 지정
ALTER DATABASE [AdventureWorks] SET PARTNER =
N’TCP://A.corp.mycompany.com:5022’;
주 서버에서 감시 서버를 지정합니다.
-- 주 서버에서 감시 서버 지정
ALTER DATABASE [AdventureWorks] SET WITNESS =
N’TCP://W.corp.mycompany.com:5026’;
초기 CREATE ENDPOINT 다음에 감시 서버에서 추가 명령을 실행할 필요는 없습니다.
마지막으로 주 서버에서 세션의 안전성을 지정합니다.
-- 주 서버의 안전성 설정
ALTER DATABASE [AdventureWorks] SET SAFETY FULL;
이 시점에서 미러링이 자동으로 시작되며 주 서버와 미러 서버는 동기화됩니다.
TIMEOUT 매개 변수를 사용하여 파트너 중단을 결정하는 시간 초과 값을 ALTER DATABASE로 조정할 수 있습니다. 예를 들어, TIMEOUT 값을 20초(기본값은 10)로 변경하려면 주 서버에서 다음 명령을 실행합니다.
-- Issue from the principal server
ALTER DATABASE [AdventureWorks] SET PARTNER TIMEOUT 20;
마지막으로 주 서버에서 ALTER DATABASE에 REDO_QUEUE 옵션을 실행하여 미러에서 재실행 큐의 크기를 조정할 수 있습니다. 다음 쿼리는 미러에서 재실행 큐를 100MB로 설정합니다.
-- Issue from the principal server
ALTER DATABASE [AdventureWorks] SET PARTNER REDO_QUEUE 100MB;
파트너를 지정했으면 미러링이 즉시 시작됩니다.
Database Mirroring 카탈로그 뷰
데이터베이스 미러링 세션은 파트너 서버와 감시 서버 사이에 구성된 관계로 구성됩니다. 각각의 참가하는 서버는 세션에 대한 일부 메타데이터와 데이터베이스의 현재 상태를 유지합니다. sys.database_mirroring 카탈로그 뷰를 쿼리하여 주 서버나 미러 서버에서 세션을 검사할 수 있습니다. 다른 카탈로그 뷰를 사용하여 감시 서버 메타데이터가 반환됩니다.
sys.database_mirroring_witnesses. 두 카탈로그 뷰에서 사용할 수 있는 모든 열에 대한 자세한 내용은 SQL Server 온라인 설명서의““sys.database_mirroring”and“ sys.database_mirrroing_witnesses”를 참조하십시오.
데이터베이스 미러링 세션의 작동 방식과 데이터베이스의 가능한 상태를 이해하는 좋은 방법은 카탈로그 뷰에서 데이터를 검사하는 것입니다. 안전성이 FULL이고 감시 서버가 있는 고가용성 세션부터 시작하겠습니다. 다음 쿼리는 주 또는 미러 서버에 대한 기본 데이터베이스 미러링 세션 정보에 대한 설명을 반환합니다
SELECT
DB_NAME(database_id) AS‘ DatabaseName’
, mirroring_role_desc
, mirroring_safety_level_desc
, mirroring_state_desc
, mirroring_safety_sequence
, mirroring_role_sequence
, mirroring_partner_instance
, mirroring_witness_name
, mirroring_witness_state_desc
, mirroring_failover_lsn
FROM sys.database_mirroring
WHERE mirroring_guid IS NOT NULL;
다음은 감시에서 실행되는 감시 서버에 대한 관련 설명 세션을 반환하는 유사 쿼리입니다.
SELECT
Database_name
, safety_level_desc
, safety_sequence_number
, role_sequence_number
, is_suspended
, is_suspended_sequence_number
, principal_server_name
, mirror_server_name
FROM sys.database_mirroring_witnesses;
이제 일반적인 데이터베이스 미러링 세션에서 두 쿼리의 출력을 비교할 수 있습니다. 서버 A에서 안전성이 FULL인 서버 B로 미러링을 설정했습니다. 다음 구성을 설정하는 예제 코드는 뒷부분에 있는 데이터베이스 미러링 구현의“설정 및 보안”을 참조 하십시오. 감시 서버는 서버 W이고 AdventureWorks 데이터베이스를 미러링합니다. 표 3은 두 파트너에 대한 위 쿼리의 가능한 출력을 보여줍니다.
표 3. 두 파트너에 대한 예제 고가용성 세션에서 sys.database_mirroring의 출력
| 파트너 메타데이터 열 |
주 서버 값: 서버 A |
미러 서버 값: 서버 B |
| db_name(database_id) |
AdventureWorks |
AdventureWorks |
| mirroring_role_desc |
PRINCIPAL |
MIRROR |
| mirroring_safety_level_desc |
FULL |
FULL |
| mirroring_state_desc |
SYNCHRONIZED |
SYNCHRONIZED |
| mirroring_safety_sequence |
1 |
1 |
| mirroring_role_sequence |
1 |
1 |
| mirroring_partner_instance |
TCP://B.corp.mycompany.com:5022 |
TCP://A. .corp.mycompany.com:5022 |
| mirroring_witness_name |
TCP://W.corp.mycompany.com:5022 |
TCP://W.corp.mycompany.com:5022 |
| mirroring_witness_state_desc |
CONNECTED |
CONNECTED |
| mirroring_failover_lsn |
95000000007300001 |
95000000007300001 |
데이터베이스 미러링 세션의 각 파트너는 파트너의 관점에서 모두 같은 메타데이터를 유지합니다. 각 파트너는 자체 데이터베이스 이름, 전체 세션의 안전성 설정, 데이터베이스의 미러링 상태 및 두 시퀀스 카운터를 유지합니다.
- mirroring_safety_sequence 카운터는 두 파트너에서 유지되며 안전성 설정이 변경될 때마다 증분됩니다.
- mirroring_role_sequence 카운터는 두 파트너에서 유지되며 장애 조치가 발생할 때마다 증분됩니다.
두 파트너 데이터베이스 상태와 감시 상태는 각 파트너 서버에서 유지합니다.
- mirroring_state_desc는 파트너 데이터베이스가 세션 중에 있는 상태를 보여줍니다.
- mirroring_witness_state_desc는 세션에서 감시의 상태를 보여줍니다.
마지막으로 각 파트너에는 mirroring_failover_lsn이 포함되어 있습니다. LSN은 로그 순서 번호입니다. 이 번호는 각 트랜잭션 로그 레코드를 고유하게 식별합니다. 밀링 파트너는 세션에 대해 저장된 로그 레코드의 마지막 집합에 주 데이터베이스의 작업량이 적었기 때문에 미러링 장애 조치 lsn은 주 서버와 감시 서버에서 동일 했습니다. 많은 데이터를 전송할 때는 미러는 다소 뒤에서 실행되기 때문에 주 서버의 값이 미러 서버의 값보다 앞선 것을 알 수 있습니다.
이제 감시 서버에서 발견된 메타데이터를 비교해 봅시다. 다음 표는 감시 서버 메타데이터의 유사한 정보를 보여줍니다.
표 4. 파트너 메타데이터와 관련된 감시 서버에서 sys.database_mirroring_witnesses의 출력
| Witness 메타데이터 열 |
Witness 값: |
해당 파트너 메타데이터 열 |
| database_name |
AdventureWorks |
db_name(database_id) |
| safety_level_desc |
FULL |
mirroring_safety_level_desc |
| safety_sequence_number |
1 |
mirroring_safety_sequence |
| role_sequence_number |
1 |
mirroring_role_sequence |
| is_suspended |
0 |
|
| is_suspended_sequence_number |
1 |
|
| principal_server_name |
TCP://A. .corp.mycompany.com:5022 |
|
| mirror_server_name |
TCP://B.corp.mycompany.com:5022 |
|
감시 서버의 메타데이터에는 이름은 약간 다르지만 안전성 설명, 안전성 시퀀스 번호 및 역할 시퀀스 번호가 포함되어 있습니다. 감시 서버는 세션의 일시 중단 여부에 대한 데이터와 주 서버 및 미러 서버 이름을 유지합니다. 감시 서버 카탈로그 뷰는 미러 링 장애 조치 lsn을 보고하지 않으며 데이터베이스 상태를 유지하지 않습니다.
데이터베이스 미러링에 필요한 모든 메타데이터(특히, 미러링 장애 조치 lsn 및 파트너 서버 이름)를 미러링 파트너가 유지합니다. 감시 서버는 고가용성 모드에서 특히 세션에서 역할 변경 수를 추적하는 역할 시퀀스 번호 등 감시 역할에 필요한 데이터만 유지합니다. 이 카운터는 주 서버가 역할을 변경할 때를 결정하는 데 사용됩니다. 다음 절에서 시나리오를 배울 것입니다.
Database Mirroring 상태 및 전환
각 서버에 대한 데이터베이스 상태는 데이터베이스 미러링 세션 동안 유지되며, 각 파트너 서버에 기록되고 sys.database_mirroring 카탈로그 뷰에 의해 보고됩니다. mirroring_state 열은 많은 상태를 반환하고 mirroring_state_desc 열은 상태에 대한 설명 이름을 반환합니다. 데이터베이스 상태 번호와 설명 이름의 전체 목록은 SQL Server 온라인 설명서의 "sys.database_mirroring"을 참조하십시오. 감시에 대한 상태 정보도 동일한 카탈로그 뷰에서 보고됩니다.
- 주 서버의 데이터는 트랜잭션을 처리 중이지만 로그 데이터가 미러로 보내지지 않을 때 표시됩니다.
- 주 서버가 데이터베이스에 대한 사용자 연결과 트랜잭션 처리를 허용하지 않을 때 데이터베이스를 서비스할 수 없습니다.
- 데이터베이스 미러링 세션에서 다른 서버에 연결할 수 없고 다른 서버가 데이터베이스에 연결할 수 없을 때 서버는 격리됩니다.
주 데이터베이스가 표시되면 사용자 연결과 트랜잭션 처리를 위해 활성화됩니다. 그러나 로그 레코드가 미러 데이터베이스에 보내지지 않고 주 서버에 오류가 발생하는 경우 미러는 표시된 상태로 들어온 지점에서 주 서버의 트랜잭션이 없습니다. 또한 운영 서버의 트랜잭션 로그가 잘리지 않기 때문에 로그 파일의 크기가 무한대로 증가하게 됩니다.
안전성이 FULL이면 주 서버가 다른 서버와 쿼럼을 구성할 수 없는 경우 데이터베이스 서비스가 중지됩니다. 주 데이터베이스에서 사용자 연결과 트랜잭션이 허용되지 않고 모든 현재 사용자의 연결이 끊어집니다. 다시 쿼럼을 구성할??.
서버는 작동할 수 있지만 서버와 데이터베이스 미러링 세션에 있는 다른 두 서버 사이의 통신 회선이 다운됩니다. 이 경우 서버가 격리되었다고 합니다. 안전성이 FULL일 때 주 서버가 격리되면 세션에 쿼럼을 구성할 수 있는 서버가 없기 때문에 데이터베이스를 더 이상 서비스할 수 없게 됩니다.
이제 주 서버와 데이터베이스에서 시작하여 데이터베이스 미러링 상태에 집중해 보도록 합시다.
주 서버 데이터베이스 상태
안전성이 FULL이면 주 데이터베이스의 정상 작동 상태는 SYNCHRONIZED 상태입니다. 안전성이 OFF이면 주 데이터베이스의 정상 작동 상태는 SYNCHRONZING 상태입니다.
- 안전성이 FULL이면 주 데이터베이스는 항상 SYNCHRONIZING 상태에서 시작하고 주 서버와 미러 서버 트랜잭션 로그가 동기화되면 SYNCHRONIZED 상태로 전환됩니다.
- 안전성이 FULL 이고 주 서버가 감시 서버에서 연결이 끊어졌지만 여전히 트랜잭션을 처리할 수 있는 경우 데이터베이스가 표시됩니다.
- 안전성이 FULL 이고 주 서버가 다른 서버와 쿼럼을 구성할 수 없는 경우 데이터베이스를 서비스할 수 없습니다. 사용자가 연결할 수 없고 트랜잭션을 처리하지 않습니다.
다음 표는 주 데이터베이스가 있을 수 있는 상태 및 다른 상태로 전환될 수 있는 일부 이벤트를 보여줍니다.
표 5. 안전성이 FULL이고 안전성이 OFF인 주 데이터베이스 상태
| 안전성 |
주 서버 초기 상태 |
이벤트 |
결과 상태 |
쿼럼 |
표시 |
db를
서비스 가능 |
| FULL |
SYNCHRONIZING |
동기화 발생 |
SYNCHRONIZED |
Y |
N |
Y |
| FULL |
SYNCHRONIZED |
세션 일시 중지 |
SUSPENDED |
Y |
Y |
Y |
| FULL |
SYNCHRONIZED |
미러 서버상의 다시 실행 오류 |
SUSPENDED |
Y, 감시 서버 있음 |
Y |
Y |
|
|
|
|
N, 감시 서버 없음 |
- |
N |
| FULL |
SYNCHRONIZED |
미러 서버 사용 불가능 |
DISCONNECTED |
Y, 감시 서버 있음 |
Y |
Y |
|
|
|
|
N, 감시 서버 없음 |
- |
N |
| OFF |
SYNCHRONIZING |
세션 일시 중지 |
SUSPENDED |
- |
Y |
Y |
| OFF |
SYNCHRONIZING |
미러 서버상의 다시 실행 오류 |
Y |
- |
Y |
Y |
| OFF |
SYNCHRONIZING |
미러 서버 사용 불가능 |
Y |
- |
Y |
Y |
안전성이 FULL이면 먼저 주 서버는 SYNCHRONIZING 상태가 되고 미러와 동기화되는 즉시 두 파트너 모두 SYNCHRONIZED 상태가 됩니다. 안전성이 OFF이면 파트너 데이터베이스는 SYNCHRONIZING 상태로 시작하고 정상적인 미러링 동안 상태를 유지합니다.
두 안전성 설정 모두의 경우 세션이 일시 중단되거나 미러에 재실행 오류가 있는 경우 주 서버는 SUSPENDED 상태가 됩니다. 미러를 사용할 수 없게 되는 경우 주 서버는 DISCONNECTED 상태가 됩니다.
DISCONNECTED 및 SUSPENDED 상태에서:
- 안전성이 FULL일 때 주 서버가 감시 또는 미러 서버와 쿼럼을 구성할 수 있는 경우 주 데이터베이스는 표시된 것으로 간주됩니다. 즉, 사용자 연결과 트랜잭션 처리를 위해 주 데이터베이스가 활성화됩니다. 그러나 로그 레코드가 미러 데이터베이스에 보내지지 않고 주 서버에 오류가 발생하는 경우 미러는 해당 상태로 들어온 지점에서 주 서버의 트랜잭션이 없습니다.
또한 운영 서버의 트랜잭션 로그가 잘리지 않기 때문에 로그 파일의 크기가 무한대로 증가하게 됩니다.
- 안전성이 FULL이고 주 서버가 다른 서버와 쿼럼을 구성할 수 없는 경우 데이터베이은 끊어지고 새 트랜잭션이 처리되지 않습니다.
- 안전성이 OFF이면 트랜잭주 데이터베이스는 표시된 것으로 간주됩니다.
주: Management Studio의 Object Explorer는 Server 트리 그래프에서 데이터베이스 이름 옆에 주 데이터베이스 상태를 보고합니다. 주 서버의 SYNCHRONIZED 상태를‘Principal, Synchronizing’로, DISCONNECTED 상태를‘Principal, Disconnected’로 보고합니다.
미러 서버 데이터베이스 상태
미러 데이터베이스는 주 데이터베이스와 같은 데이터베이스 상태를 가지지만 미러는 항상 nonrecovered 상태에 있기 때문에 미러 역할에 있는 동안에는 데이터베이스를 서비스하지 못합니다. 다음 표는 미러 서버와 데이터베이스의 데이터베이스 상태를 변경시킬 수 있는 가장 일반적인 이벤트를 보여줍니다.
표 6. 안정성이 FULL 및 OFF인 미러 데이터베이스 미러링 상태
| 안전성 |
미러 서버 상태 |
이벤트 |
결과 상태 |
| FULL |
SYNCHRONIZED |
세션 일시 중지 |
SUSPENDED |
| FULL |
SYNCHRONIZED |
미러 서버상의 다시 실행 오류 |
SUSPENDED |
| FULL |
SYNCHRONIZED |
Principal database unavailable |
DISCONNECTED |
| OFF |
SYNCHRONIZING |
세션 일시 중지 |
SUSPENDED |
| OFF |
SYNCHRONIZING |
미러 서버상의 다시 실행 오류 |
SUSPENDED |
주 서버와 마찬가지로 Management Studio의 Object Explorer는 Server 트리의 데이터베이스 이름 옆에 일부 미러 데이터베이 스 상태를 보고합니다. 미러 서버의 SYNCHRONIZED 상태를‘Mirror, Synchronizing’로, DISCONNECTED 상태를‘Mirror, Disconnected’로 보고합니다.
감시 서버 상태
감시 서버에는 sys.database_mirroring 카탈로그 뷰에 CONNECTED, DISCONNECTED 및 UNKNOWN의 세 가지 상태가 있습니다.
표 7. 파트너 서버에 기록된 감시 서버 상태
| 감시 서버 상태 |
이벤트 |
결과 상태 |
| CONNECTED |
감시 서버 사용 불가능 |
DISCONNECTED |
|
주 서버가 미러를 초기화할 수 없음 |
UNKNOWN |
감시 서버의 상태가 실제로 파트너 서버에 기록되고 감시 서버에는 기록되지 않기 때문에 이러한 상태는 파트너의 유리한 지점에서 설정됩니다. 따라서 감시 서버의 상태가 DISCONNECTED이면 파트너가 감시 서버에서 연결이 끊어진 것을 의미합니다.
데이터베이스 미러링이 시작될 때 미러가 주 서버와 초기화할 수 없는 경우 감시 서버 상태는 UNKNOWN이 됩니다.
트랜잭션 로그 레코드 전송
주 및 미러 SQL Server가 메시지와 로그 레코드 블록을 전송하는 데 사용하는 작업 순서는 안전성 설?음 비동기 전송을 검사합니다.
SQL Server가 트랜잭션 로그에 트랜잭션 이벤트를 기록하면 로그 레코드는 디스크에 기록하기 전에 로그 버퍼에 잠시 저장됩니다. 데이터베이스 미러링에서 로그 버퍼를 디스크에 기록(저장)할 때마다 주 서버는 미러 서버에 동일한 로그 레코드 블록을 보냅니다.
1. 안정성이 FULL일 때 주 SQL Server가 로그 레코드 블록을 저장하면 동일한 블록을 미러로 보내고 로컬 I/O를 로그로, 원격미러 서버의 I/O를 로그에 처리합니다. 트랜잭션이 완료된 것으로 간주되려면 I/O(저장)가 완료되었다는 로컬 I/O(저장)와 미러의 응답을 주 서버가 기다리기 때문에 전송을 동기화라고 부그 버퍼를 저장할 때마다 메타베이스에 있는 버퍼의 가장 높은 로그 시퀀스 번호(LSN) + 1을 mirroring_failover_lsn으로 기록합니다. mirroring_failover_lsn은 트랜잭션 로그에서 최신의 보장되는 지점을 협상하는데 사용 되므로 두 파트너 데이터베이스는 초기에 동기화하고 장애 조치 후에 동기화할 수 있습니다.
미러링 장애 조치 lsn은 주 서버가 미러에 로그 레코드를 보낼 때 항상 주 서버에 미리 있게 됩니다. 로그 레코드를 저장할 때 미러는 mirroring_failover_lsn을 기록하고 주 서버에 응답하지만 주 서버가 미러로부터 승인을 받으면 주 서버는 새로운 로그 레코드 집합을 저장할 수 있습니다.
표 8은 안전성이 FULL인 주 서버와 미러 사이의 예제 이벤트 시퀀스를 보여줍니다.
표 8. 이벤트의 안전성 FULL(동기 전송) 예제 시퀀스
| 서버 A |
서버 B |
| 주 서버, Synchronized |
미러 서버, Synchronized |
| 여러 명령문의 트랜잭션이 데이터 변경 내용을 포함하기 시작합니다. |
|
| 주 데이터베이스의 트랜잭션 로그 레코드가 트랜잭션 로그 버퍼에 삽입됩니다. |
|
트랜잭션 로그 버퍼는 디스크(하드엔디드)에 작성되고 로그 레코드 블록은 미러 서버로 전송됩니다. 및 주 서버는 해당 로그 블록의 mirroring_failover_lsn을
기록합니다. 및 주 서버는 미러 서버의 확인을 기다립니다 |
|
|
미러 서버는 로그 레코드 블록을 트랜잭션 로그 버퍼로 수신합니다. |
|
미러 서버는 로그 버퍼를 디스크에 작성하고
mirroring_failover_lsn을 기록하며
및 로그 블록이 보호되고 있다는 것을 운영 서버에 알립니다. |
| 운영 서버에 작성되었다는 알림 메시지를 받습니다. |
미러 서버는 REDO 대기열에서 계속해서 트랜잭션 로그 레코드를 재실행합니다. |
트랜잭션에 대한 COMMIT이 트랜잭션 로그 버퍼에
입력됩니다.
트랜잭션 로그 버퍼는 디스크(하드엔디드)에 작성되고 COMMIT이 들어 있는 로그 레코드 블록은 미러 서버로 전송됩니다.
주 서버는 해당 블록의 mirroring_failover_lsn을 기록합니다. |
|
|
미러 서버는 로그 레코드 블록을 트랜잭션 로그 버퍼로 수신합니다. |
|
미러 서버는 로그 버퍼를 디스크에 작성하고
mirroring_failover_lsn을 기록하며
및
로그 블록이 보호되고 있다는 것을 운영 서버에 알립니다. |
| 운영 서버는 로그 레코드 블록이 미러 서버에 의해 디스크에 작성되었다는 알림 메시지를 받습니다. 및 트랜잭션은 커밋된 것으로 간주됩니다. |
미러 서버는 REDO 대기열에서 COMMIT을 포함한 트랜잭션 로그 레코드를 재생하여 데이터 페이지가 변경됩니다. |
| 새로운 트랜잭션은 주 서버의 로그 버퍼에 기록됩니다. |
|
앞의 시퀀스에서 중요한 점은 안전성이 FULL이고, 주 서버가 로그 버퍼를 저장하고 동시에 버퍼에서 미러 서버로 로그 레코드 의 복사본을 보낸다는 것입니다. 그런 다음 트랜잭션이 완료되었다고 간주하기 전에 자체 I/O 및 미러 서버의 I/O가 완료되기를 기다립니다. 주 서버가 미러 서버에서 응답을 받으면 주 서버는 다음 저장으로 진행할 수 있습니다.
안전성이 FULL일 때 주 서버와 미러 서버 사이의 밀접한 협력에도 불구하고 데이터베이스 미러링은 배포된 트랜잭션이 아니고 두 단계 커밋을 사용하지 않습니다.
- 데이터베이스 미러링에서는 두 서버에서 한 트랜잭션이 배포되는 것이 아니라 두 트랜잭션이 재생됩니다.
- 데이터베이스 미러링은 배포된 트랜잭션에서 파트너 서버를 리소스 관리자로 사용하지 않습니다.
- 데이터베이스 미러링 트랜잭션은 준비와 커밋 단계를 거치지 않습니다.
- 가장 중요한 것은 배포된 트랜잭션과 달리 미러 서버에서 커밋하지 못하면 주 서버에서 트랜F이면 주 서버가 미러 서버의 승인을 기다리지 않으므로 주 서버에서 커밋된 트랜잭션 수는 표 9에 표시된 대로 미러에 앞서 얻을 수 있습니다.
표 9. 이벤트의 안전성 OFF(비동기 전송) 예제 시퀀스
| 서버 A |
서버 B |
| 주 서버, Synchronizing |
미러 서버, Synchronizing |
| 여러 명령문의 트랜잭션이 데이터 변경 내용을 포함하기 시작합니다. |
|
| 데이터 수정을 위한 트랜잭션 로그 레코드가 트랜잭션 로그 버퍼에 기록됩니다. |
|
트랜잭션 로그 버퍼는 디스크(하드엔디드)에 플러시되고 로그 레코드 블록은 미러 서버로 전송됩니다.
주 서버는 해당 블록의 mirroring_failover_lsn을 기록합니다. |
|
| 트랜잭션의 COMMIT는 다른 트랜잭션 작업과 함께 트랜잭션 로그 버퍼에 입력됩니드 블록을 트랜잭션 로그 버퍼로 수신합니다 |
|
| 트랜잭션 로그 버퍼는 디스크에 저장됩니다. |
미러 서버는 로그 버퍼를 디스크에 작성하고 mirroring_failover_lsn을 기록하며
로그 블록이 보호되고 있다는 것을 운영 서버에 알립니다. |
| 트랜잭션은 커밋된 것으로 간주됩니다. |
미러 서버는 REDO 대기열에서 계속해서 트랜잭션 로그 레코드를 재실행합니다. |
|
미러 서버는 로그 레코드 블록을 트랜잭션 로그 버퍼로 수신합니다. |
|
미러 서버는 디스크에 기록하여 로그 블록을 저장합니다.
mirroring_failover_lsn을 기록합니다.
로그 블록이 보호되고 있다는 것을 운영 서버에 알립니다. |
데이터베이스 미러링 역할 변경
데이터베이스 미러링 장애 조치는 데이터베이스 미러링 서버 또는 응용 프로그램의 관점에서 문제점으로 간주될 수 있습니다.
데이터베이스 미러링 서버의 관점에서 장애 조치는 미러 서버를 주 서버로 변환하고 새로 복구한 데이터베이스를 세션의 주 데이터베이스로 사용합니다. 장애 조치는 자동, 수동 또는 강제가 될 수 있습니다.
- 자동 - 고가용성 모드에서만 발생합니다(안전성은 FULL이고 감시 서버가 세션의 일부입니다).
- 수동 - 고가용성 및 높은 수준의 보호 작동 모드(안전성이 FULL)에서 발생하며 파트너 데이터베이스 둘 모두 동기화됩니다.
- 강제 서비스(데이터 손실 허용) - 고성능(안전성이 OFF) 모드에서 주로 사용되며 미러 데이터베이스를 즉시 수동으로 복구합 니다.
안전성이 FULL이면 서버의 역할을 반대로 바꾸는 가장 좋은 방법은 강제 서비스가 아닌 수동 장애 조치를 사용하는 것입니다.
자동 장애 조치
자동 장애 조치는 고가용성 모드(감시 서버의 안전성이 FULL)에서 데이터베이스 미러링의 기능입니다. 대부분의 경우 SQL Server는 몇 초 내에 자동 데이터베이스 미러링 장애 조치를 수행할 수 있습니다. 데이터베이스 미러링 세션에 참여하는 SQL Server가 모두 서로의 존재를 테스트하기 때문에 부분적으로 이것을 수행할 수 있습니다. 이 프로세스는 일반적인 IP 주소 ping보다 훨씬 많이 관련되지만‘ping’이라고 합니다. 미러 서버와 감시 서버는 실제 서버가 있는지, SQL Server 인스턴스가 있는지, 주 데이터베이스의 가용성 확인을 위해 주 서버에 연결합니다. 마찬가지로, 실제 서버의 가용성, SQL Server 인스턴스 및 미러 데이터베이스의 복구 상태 확인을 위해 주 서버와 감시 서버는 미러 서버에 핑(ping)합니다.
데이터베이스 미러링 세션이 안전성이 FULL이고 감시 서버를 사용하도록 설정되었다고 가정합시다. 미러 서버인 서버 B는 주 서버 A를 사용할 수 없다는 것을 ping을 통해 발견합니다. 서버 B는 감시 서버와 통신하며 감시 서버가 서버 A를 볼 수 없다 는 확인을 받습니다. 그러면 서버 B는 감시 서버와 쿼럼을 구성하며 주 서버로 수준이 올라갑니다. 데이터베이스는 연결이 끊어진 상태이고 새로운 주 데이터베이스의 트랜잭션 로그를 잘라낼 수는 없지만 데이터베이스를 복구하고 이제 주 서버 역할 을 갖게 되었음을 감시 서버에 알립니다.
서버 B의 새로운 주 데이터베이스는 트랜잭션 로그 작업을 계속 재생하지만 지속적으로 재실행 상태에 있었으며 대부분의 경우 수행할 일이 거의 남아 있지 않습니다. 모든 SQL Server 버전의 데이터베이스 미러링에서 새로운 주 데이터베이스는 재실행 상태를 완료하는 즉시 사용할 수 있게 됩니다. 데이터베이스가 실행 취소 상태가 되면 사용자 연결을 사용할 수 있게 됩니다. 남아 있는 실행 취소 단계는 훨씬 오래 걸릴 수 있지만 재실행 상태를 완료하는 데 보통 몇 초 정도 걸립니다. 데이터 베이스 미러링에서 새로운 주 데이터베이스는 재실행 프로세스가 완료되는 즉시 사용자 연결을 서비스하는데 사용할 수 있게 됩니다. 새로운 주 서버 B의 데이터베이스는 DISCONNECTED 상태에 있고 표시되지만 재실행 단계가 완료되는 즉시 데이터 베이스를 서비스할 수 있습니다.
대개 데이터베이스 미러링 자동 장새로운 주 서버로 전체 응용 프로그램을 리디렉션하는 데 더 많은 시간이 걸립니다. 응용 프로그램은 연결을 감지하고 재시도해야 하며, 이는 프로세스에 약간의 시간 을 추가할 수 있습니다. 또한 SQL Server 인증을 사용한 새로운 로그인이 서버에 추가된 경우 시스템 저장 프로시저 sp_change_users_login 을 사용하여 이러한 로그인을 새로운 주 서버에 매핑해야 할 수 있습니다. SQL 에이전트 작업 같이 이전 서버의 중요한 개체가 새로운 주 서버에 복사되지 않은 경우 전체 응용 프로그램 장애 조치는 지연될 수도 있습니다. 자세 한 내용은 뒷부분의 구현 절에서"장애 조치를 위해 미러 서버 준비"를 참조하십시오.
이제 기존의 주 서버가 온라인이 되는 것을 가정합시다. 수동 장애 조치에서처럼 역할이 반대이거나 기존의 주 서버가 아주 빨리 복구되는 자동 장애 조치인 경우 두 서버 간에 발생해야 하는 협상 프로세스가 있습니다. 미러링을 다시 시작하기 전에 두 파트너 서버는 서로 동기화하는 방법을 찾아야 합니다. 미러링 장애 조치 lsn은 이 프로세스에서 중요한 역할을 수행합니다.
서버 A(새로운 미러)는 뒤에 있지만 어느 정도인지는 확실하지 않습니다. 서버 A는 서버 B(새로운 주 서버)에 서버 B로부터 받은 마지막 미러링 장애 조치를 보고합니다. 반면에 서버 B에는 미러링 장애 조치 lsn을 최신 상태로 만든 커밋된 작업이 있습 니다. 두 서버는 서버 B에 올바른 장애 조치 lsn이 있고 서버 A를 추적해야 한다는 것에 동의합니다. 서버 B는 동기화하기 위해 재생할 수 있는 충분한 수의 트랜잭션 레코드를 서버 A로 전송합니다.
수동 장애 조치
수동 장애 조치는 두 파트너 서버가 순서대로 오류 없이 자신의 역할을 바꾸는 방법입니다. 안전성이 FULL로 설정되고 주 데이 터베이스와 미러 데이터베이스가 SYNCHRONIZED 상태에 있어야 합니다.
주 서버에서 ALTER DATABASE 명령을 호출하여 수동 장애 조치를 수행합니다.
ALTER DATABASE AdventureWorks SET PARTNER FAILOVER;
또는 Management Studio의 Database Properties/Mirroring 대화 상자에서 Failover 단추를 클릭합니다. 수동 장애 조치를 수행 하면 현재 사용자의 연결이 끊어지고 기존의 주 데이터베이스에서 완료되지 않은 트랜잭션이 롤백됩니다. 재실행 대기열에서 모든 완료된 트랜잭션을 완료하고 실행 취소 단계에서 완료되지 않은 트랜잭션을 롤백하여 미러 데이터베이스를 복구합니다. 기존의 미러는 주 역할이 할당되고 기존의 주 데이터베이스는 미러의 새 역할을 맡습니다. 두 서버는 미러링 장애 조치 lsn을 기반으로 미러링의 새로운 시작점을 협상하고 반대의 역할을 사용하여 처리됩니다.
미러링을 초기화하기 전에 먼저 미또는 SQL Server 인스턴스에‘롤링 업그레 이드’를 수행하는 방법으로 수동 장애 조치를 사용할 수 있습니다. 자세한 내용은 SQL Server 온라인 설명서의‘Manual Failover’를 참조하십시오.
강제 서비스(Forced Service)
ALTER DATABASE 명령을 호출하여 미러에서 강제 서비스를 수행할 수 있습니다.
ALTER DATABASE AdventureWorks SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS;
일반적으로 이것은 안전성이 OFF이고 주 서버가 더 이상 작동하지 않는 경우에만 유용합니다. 또한 안전성이 FULL일 때 이 명령을 사용할 수도 있지만 복구된 미러 서버가 쿼럼을 구성할 수 없는 경우 데이터베이스를 서 모드)인 상태에서만 이 명령을 사용하는 것이 좋습니다. 비동기 데이터 전송은 주 서버에서 트랜잭션이 커밋된 날짜까지 미러를 유지할 수 없기 때문에 일부 데이터가 손실될 수 있습니다.
