- 다음 내용은 Microsoft TechNet Magazine Q&A 내용중 SQL Server 와 관련된 일부 항목을 발췌하였습니다. 실제 이러한 고민은 대부분의 관리자들이 직면해 있는 최적의 방안을 찾아내야 하는 문제 이기도 합니다.
참고로, 제가 운영하는 서버중에 DB크기 약 20G 내외의 15개 데이터베이스에 대해서 미러링이 설정되어 있으며, 트랜잭션 로그는 일 약 3G 정도, 비동기모드 환경에서도 안정적으로 운영되고 있습니다.-
답변:
이 질문에 대한 답변은 제가 자주 쓰는 말로 해야겠군요. 그때 그때 다릅니다.
안내서에는 미러링하는 데이터베이스가 인스턴스당 10개를 넘지 않도록 하라고 되어 있지만, 여기서 10개는 대부분의 사용자에게 해당되는 최대값을 추정한 수입니다. 여러분은 하드웨어 상황을 토대로 다음 요소를 고려해야 합니다.
- 주 인스턴스와 미러 인스턴스의 메모리 용량은 얼마입니까? (동일한 것이 이상적입니다.)
- 주 인스턴스와 미러 인스턴스의 처리 성능은 얼마입니까? (이것도 동일해야 합니다.)
- 미러 인스턴스의 I/O 하위 시스템 대역폭은 얼마나 됩니까? (주 인스턴스와 동일해야 합니다.)
- 각 데이터베이스에서 작업 부하로 생성되는 트랜잭션 로그는 얼마나 됩니까?
- 주 인스턴스와 미러 인스턴스 간에 사용할 수 있는 네트워크 대역폭은 얼마나 됩니까?
마지막 두 요소가 가장 중요합니다.
두 인스턴스 간에 사용할 수 있는 네트워크 대역폭이 미러링되는 모든 데이터베이스에서 초당 생성되는 트랜잭션 로그를 처리하기에 부족하면 주 데이터베이스의 성능이 저하됩니다. SQL Server 2008에서는 로그 스트림 압축으로 이 부담을 어느 정도 줄일 수 있습니다.
다음으로 중요한 문제는 미러링에 필요한 메모리 및 스레드 요구 사항입니다. 미러링된 각 데이터베이스는 스레드 하나와 약간의 메모리를 사용합니다. 저성능의 서버에 미러링되는 데이터베이스가 많고 여기에 통상적인 작업 부하가 더해지면 서버에 너무 큰 부담이 될 수 있습니다.
또한 데이터베이스 미러링의 실행 방법도 고려해야 합니다.
동기 모드에서는 모든 트랜잭션 로그 레코드가 미러링된 데이터베이스의 트랜잭션 로그에 복사될 때까지 주 데이터베이스에서 트랜잭션을 커밋할 수 없습니다. 따라서 네트워크 과부하로 인한 지연 때문에 주 데이터베이스에서 작업 부하 성능 문제가 발생할 수 있습니다.
비동기 모드에서는 주 데이터베이스에서 기다리지 않고 트랜잭션을 커밋할 수 있지만, 네트워크 지연으로 인해 미러 데이터베이스로 전송 대기 중인 트랜잭션 로그의 양이 증가할 수 있습니다.
이 경우 트랜잭션 로그 크기 문제가 발생할 수 있습니다. 더욱이, 전송되지 않은 트랜잭션 로그는 오류 발생 시 손실되므로 전송되지 않은 트랜잭션 로그가 많아질수록 복구 상황에서 데이터 손실 가능성이 높아집니다.
상황에 따라 매우 다양한 시나리오가 가능하며, 실제 프로덕션 환경에서 흥미로운 상황을 여러 번 목격했습니다.
일례로, 작업량이 매우 적고 동시에 모두 사용하는 일도 없는 데이터베이스 150개로 구성된 환경이 있었습니다. 이 환경에서는 150개의 데이터베이스가 모두 문제 없이 미러링되었습니다.
반대로, 부하가 매우 큰 데이터베이스 3개뿐이지만 네트워크 연결이 좋지 않은 환경도 있었습니다. 이 환경에서는 네트워크 대역폭 부족으로 작업 부하 성능 저하가 발생하여 하나의 데이터베이스도 제대로 미러링할 수 없었습니다.
성공의 관건은 다름 아닌 로그 생성을 계산하는 것입니다.
미러링하려는 데이터베이스 수를 지원하기에 충분한 네트워크 대역폭이 확보된다면 괜찮습니다. 실전에 들어가기 전에 구성을 테스트하여 데이터베이스 유지 관리 작업을 비롯하여 트랜잭션 로그가 생성될 수 있는 모든 작업이 포함되도록 하십시오.
12-TechNetB_masthead_ltr.gif
댓글 없음:
댓글 쓰기