26.3. 장애처리 failover

운영 중인 서버가 장애로 멈췄다면, 대기 중인 서버를 운영 서버로 사용할 장애처리 작업을 해야한다. 이것을 failover 절체라고 한다. (절체라는 단어가 국어사전에 없는 단어라서 한자가 어떻게 되는지는 모르겠다.)

대기 서버가 장애일 경우는 운영 서버에 영향을 주지 않기 때문에, 이 작업이 필요 없다. 그냥 재실행 할 수 있다면, 그렇게 하면 되고, 재구축이 필요하면, 대기 서버 구축 방법에 따라 진행하면 된다. 대기 서버는 실행 순서에 따라 자동으로 운영 서버와 동기화를 할 것이다.

장애처리 작업이 일어나서 새로운 운영 서버가 그 역할을 하기 시작했는데, 장애가 생겼던 옛 운영 서버가 다시 실행되는 경우라면, 클라이언트가 그 옛 운영 서버를 사용할 수 없도록 조치할 필요가 있다. 이것을 흔히 STONITH (Shoot The Other Node In The Head) 기능이라고 한다. 두 개의 운영 서버가 실행 되고, 서로 자신이 운영 역할을 하기 때문에, 심각한 경우는 자료 손실이 일어난다. 이 문제를 어떻게 막을 것인지를 고려해야한다.

많은 장애처리 기반 시스템은 두 개의 시스템으로 구성된다. 이 시스템은 어떤 종류의 하트비트 메카니즘으로 주기적으로 장애처리를 해야하는지를 검사한다. 서로 하트비트 검사를 하는 방식 말고, 이 검사를 제 3의 서버(이것을 감시 서버라고 한다)를 맡아 보다 안전한 장애처리를 할 수 있도록 하기도 한다. 이 경우는 전자 방식보다 더 세밀한 테스트와 구축 비용이 더 많이 들것이다.

PostgreSQL에서는 이 장애처리를 판단하고, 대기 서버에게 운영 서버 역할을 맡도록 알리는 시스템 프로그램을 제공하지는 않는다. 시스템 의존적인 작업이기 때문이기도 하고, 이미 이런 소프트웨어는 많이 있다.

운영, 대기 각각 하나의 서버로 구성했을 경우, 대기 서버가 운영을 맡게 되면, 그 운영 서버에 대한 대기 서버가 없는 단독 운영 서버 환경이 되어버린다. 원래 구축 하려고 했던 가용성이 높은 시스템 환경 구축이라는 목표에서 벗어나게 됨을 의미한다. 간단하게 생각하면, 멈추웠는 옛 운영 서버를 대기 서버로 사용하면 될 것이다고 하지만, 실무에서는 대기 서버가 어떤 문제로 운영을 맡게 될지 아무도 모르기 때문에, 이 생각은 위험하다. 만일 하드웨어 장애였다면, 그것을 고치고, 대기 서버로 새로 구축해서, 대기 서버로 실행해야하기 때문에, 꽤 많은 시간을 운영 서버 혼자 감당해야한다. pg_rewind 명령을 이용하면, 하드웨어 장애가 아닌 경우, 대용량 클러스터 시스템에서 대기 서버 구축 시간을 단축 시킬 수 있다. 운영적인 입장에서는 이런 경우 어떻게 최소한의 비용으로 빠르게 대기 서버를 구축할 것인가도 준비해야한다. 비용이 넉넉하다면, 제 3의 대기 서버를 준비해 두었다가, 이런 상황에서 대기 서버로 작동할 수 있도록 한다.

결론적으로 장애처리 작업은 대기 서버가 운영 역할을 맡는 작업은 비교적 짧은 시간 안에 일어나지만, 다시 원래 환경과 같은 환경을 만드는 작업에는 꽤 많은 시간이 걸린다. 또한 대기 서버가 그 역할을 제대로 할 수 있는지 주기적으로 확인하는 작업도 필요하다. 확인 작업은 장애처리에 필요한 모든 작업이 될 것이다. 운영 서버 장애를 감지 할 수 있는지, 대기 서버는 잘 복제를 하고 있는지, 대기 서버가 운영 서버 역할을 맡고 별 이상이 없는지, 등등이 될 것이다.

로그 전달 방식을 이용한 대기 서버환경이면, 이 대기 서버가 운영 서버 역할을 하게 하려면, pg_ctl promote 명령을 실행하거나, recovery.conf 파일에 있는 trigger_file 설정값으로 지정한 파일을 만들어주면 된다. pg_ctl promote 명령을 사용할 경우에는 trigger_file 설정값이 지정되어 있지 않아도 된다. 고가용성을 고려한 구축이 아니라, 그냥 읽기 전용 쿼리를 사용하기 위해서 구축한 로그 전달 방식의 대기 서버라면, 굳이 이 작업을 하지 않고, 그냥 운영 서버 장애를 직접 복구 하는 것이 나을 것이다.