기업 내에서 Exchange 2007 서버를 운용하는 경우 보안 업데이트를 적용하거나 재부팅을 하기 위해 CCR Failover로 Active-Passive 상태를 전환하는 경우가 종종 있다. (사실, 서버를 다중 노드로 구성하는 이유가 그럴 때 별 생각 없이, 잠깐 몇 분 정도 서비스에 지장이 생기더라도 안전하게, 효율적으로, 수고로움을 덜 목적으로 관리하기 위함인데, 어찌된 것이 오히려 관리할 내용만 늘어난 것이 현실이긴 하다.)


그럴 경우 아래의 EMS Powershell CmdLet이나 아니면 EMC 화면에서 "Manage Clustered Mailbox Server" 마법사 화면을 통해 간단하게 실행할 수 있다.

Move-ClusteredMailboxServer – Identity {Exch1} –TargetMachine {Exch2}


그런데, 물론 실행하기에 앞서 양쪽 서버의 StoragyGroup Copy Status 및 Queue 상태를 확인하지도 않고 위 명령을 무턱대고 실행하면 안되지만, 모든 확인이 끝나고 모든 것이 정상인 경우에 실행했더라도 재수 없는 경우, "Failed" 오류가 나면서 CCR Failover가 중지되어 버리는 황당한 경우가 있다. (정말 재수 없는 경우다. 이런 경우, 마운트가 되지 않는(umounted) 메일 박스 그룹은 그야 말로 서비스 중지니까... 하드디스크가 깨졌다면 몰라도, 정상 운용 중에 이런 일이 벌어진다는 건, 이건, 아무리 생각해봐도 21세기 서버에서는 있어서는 안 되는 치명적인 버그 같다. 그래서 나중에 DAG같은 개념이 나온 건지도...)

그럴 경우 아래 URL을 참조해서 복구 작업을 진행하면 된다.


 



특히 위 두 번째 참조 URL이 아주 유용한데,

CCR Failover가 실패했더라도 메일 박스 데이터베이스 상태가 정상인 경우(Clean shutdown)라면, 그냥 트랙잭션 로그 파일들을 삭제(다른 폴더로 이동)하고 데이터베이스를 마운트(mount)시키기만 하면 된단다. 생각해 보니 정말 그렇다. 이렇게 실패하는 대부분의 경우 트랙잭션 로그 일부가 깨져서 실패하게 되는 것인데, DB가 정상이라면 로그 따위 아무 것도 아니기 때문이다. DB를 마운트시키면 알아서 트랜잭션 로그는 저절로 다시 자동 재생성된다. (이 경우, 이후 Re-seeding 작업은 불필요하다. 이미 정상인데 굳이 DB를 지우고 새로 만들 이유가 없으니까. 이걸 몰라서 지난 밤 새 아까운 시간 버려가며 쓸 데 없이 엉뚱한 삽질을...;;;;)



아... 위 참조 URL들이 나중에 링크가 깨질 것에 대비해 미리 펌질을 해 놓을까 말까 손이 근질근질하다. 보면 볼 수록 정말 좋은 정보가 가득 들어 있다.




Posted by 떼르미
,


자바스크립트를 허용해주세요!
Please Enable JavaScript![ Enable JavaScript ]