[SQL SERVER] Always On, 미러링 데이터 동기화 방식

Always On 데이터 동기화 방식

1. Record the data changes that occur on the primary replica.
2. Transfer the records to each secondary replica.
3. Complete the data changes on the secondary replica.

The three tasks are mainly completed by the following four threads:

1. Log Writer: It is responsible for recording the modified log information into a log buffer in memory and then written into the physical log file.
2. Log Scanner: It is responsible for packing log records from the log buffer or log files into log blocks and then send them to each secondary replica.
3. Harden: It will write the log blocks from Log Scanner into log files in the disk of secondary replica.
4. Redo: It is responsible for reading the log blocks from disk and translating into data modification operations.

즉 Primary 에서의 변경 로그를 Secondary에 던지고 Secondary 에선 받은 로그를 반영하는 방식으로 트랜잭션 로그에 대한 사용이다. 동기화 모드의 경우 Secondary는 LogCache 내용을 Flush 하면 ACK 를 넘긴다.

(기록기가 변경 내용을 작성하고 스캐너가 정리 및 복제본에 던지고 Harden이 받은 로그를 복제본의 로그 파일에 기록하고 Redo는 복제본에서 해당 내용을 반영하는 방식)

 

복제본의 데이터 파일이 Redo Log를 사용하여 동기화가 되는건 특이하다고 생각이 들었는데 어찌보면 당연한 것 같다.

왜냐하면 데이터 파일의 변경은 버퍼캐시의 더티 페이지가 체크포인트 등의 방식으로 동기화 되는데 복제본은 버퍼 캐시의 사용이 없는 상태일 것이기 때문에 리두 로그를 사용하여 변경을 해주어야만 한다. (AWS Aurora와 비슷하다고 느낌)

--2024/06/05 primary에서 데이터 insert 의 경우도 버퍼캐시를 사용하는데 복제본에서도 버퍼캐시를 사용하지 않는건 불가능할 것 같다. Redo를 사용하여 데이터를 동기화 하는 이유는 내 생각에는 데이터 정합성을 높이기 위해서 (버퍼 캐시에서 플러시하는 형식은 특정 주기를 통해 진행이 되니까 Primary와 정합성이 안 맞을 수 있을 것 같다) + ACK를 빠르게 넘겨주기 위해서가 아닐까 싶다.

 

 

미러링

 

1. 주 서버는 클라이언트로부터 커밋 트랜잭션을 수신합니다.
2. 주 서버는 트랜잭션에 대한 로그 레코드를 로그 파일에 기록하고 로그 레코드를 미러 서버로 전송합니다.
3. 주 서버는 I/O를 완료하지만 현재 클라이언트에 확인을 보낼 수 없습니다.
4. 미러 서버는 디스크에 로그를 씁니다
5. 미러 서버의 I/O가 완료됩니다.
6. 미러서버가 주 서버에 완료 응답을 보냅니다.
7. 주 서버는 미러 서버로부터 완료 응답 을 수신하면 클라이언트에게 완료 응답 을 보냅니다.

 

AG와 미러링의 차이점 : AG의 경우 Log Cache라는 요소가 추가되었다.

해당 요소로 인해서 동기화 부분이 미러링은 데이터 파일까지 동기화가 된 이후에 ACK를 할 수 있는 반면

AG의 경우 Log Cache에 내용이 반영이 되면 ACK를 받을 수 있다. 이 형상으로 인해 프라이머리의 지연이 더 낮아진다

 

(AlwaysOn 기능에 새롭게 도입되었으며 Primary에서 Secondary로 Log Record를 넘길 때 사용됨. Secondary에서는 여기에 Record가 장기간 보관되어 복구나 rollback될 때 Disk가 아니라 Log cache에서 복구가 가능하게 됨
Log cache이 없었을 경우 Mirroring 같은 걸 할 때 Primary에서 Index Rebuild/Reorg 작업을 할 경우 latency가 너무 길어졌었으나 Log Cache가 따로 생기고 나서는 분리했기 때문에 이슈가 없음 ) 

 

 

 

참조

https://blog.naver.com/heyjieun/221007720713

https://dba.stackexchange.com/questions/176566/data-synchronization-process-in-database-mirroring-and-alwayson-groups-sql-serve

https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/monitor-performance-for-always-on-availability-groups?view=sql-server-ver16&tabs=new-limits

https://sqlgeekspro.com/synchronous_mirroring/

https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups?view=sql-server-ver16https://learn.microsoft.com/ko-kr/sql/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups?view=sql-server-ver16