CUBRID사용 관련 장애 중 많은 부분에서 log손상 장애를 볼 수 있습니다. 여러 가지 이유가 있을 수 있겠으나 대표적인 이유 중 하나가 잘못 수행한 쿼리 또는 생각보다 오래 걸리는 쿼리를 중단 시키기 위한 Database강제 종료에 있는 경우가 많습니다. 본 내용에서는 쿼리 수행 중단 방법과 장애 발생 시 조치 방법에 대해서 간략하게 정리하도록 하겠습니다.
비정상적인 쿼리나 오려걸리는 쿼리를 수행했다고 느낀 경우 아래와 같이 확인을 하시기 바랍니다.
1. "cubrid broker status -s1 -f" 명령어를 이용하여 broker의 현재 상태를 파악합니다. 이 결과에서 눈 여겨 보아야 할 것은 아래와 같습니다.
A. STATUS -> 현재의 상태가 BUSY인지를 확인해야 합니다.
B. LAST ACCESS TIME -> LAST ACCESS TIME이 현재 시각과 얼마나 차이가 나는지를 확인합니다.
C. Query수행 여부 확인 -> 현재 쿼리가 수행 중이라면 해당 cas process에 쿼리문의 일부가 보일 것입니다.
2. 위의 두 가지 항목에 BUSY인 상태와 LAST ACCESS TIME이 오래된 경우(기대 수준에 따라 차이가 있습니다.) 쿼리 수행을 끊어줄 필요가 있습니다.
3. 위의 두 가지 경우는 Broker통하여 DB에 접속하는 경우이나 csql을 이용해서 쿼리를 수행한 경우라면 ctrl+C을 이용해서도 종료가 되지 않는 현상을 볼 수 있을 것입니다.
위와 같이 확인이 되었다면 아래와 같이 순차적으로 쿼리 수행을 취소하시기 바랍니다.
1. CUBRID BROKER의 cas process를 중단한다. 가장 최우선적인 방법으로 “cubrid broker status –s1 –f”의 결과로 나온 문제의 cas process를 중단하는 작업이 필요합니다. 중단 방법은 “cubrid broker status –s1 –f”의 결과 중 앞에서 둘째 항목인 pid를 kill명령어를 이용하여 중단합니다.
예) kill -9 2088
2. 특정 쿼리가 Broker전체에 영향을 주어 모든 cas process가 느려지는 현상이 발생할 수도 있습니다. 이때는 “cubrid broker off <broker_name>”명령어를 이용하여 해당 broker를 off시킨 다음 “cubrid broker on <broker_name>”명령어를 이용하여 구동합니다.
3. 전체적인 broker 재구동이 필요하다면 “cubrid broker restart”명령어를 이용하여 Broker를 재구동합니다.
4. csql을 통해 접속한 경우, Broker를 거치지 않고 접속한 경우는 killtran명령어를 이용하여 조치합니다. “cubrid killtran <db_name>”명령어를 사용하면 현재 DB와 접속해 있는 process에 대한 정보가 나타나게 됩니다. 여기에는 Broker를 통한 접속, csql을 통한접속 등이 보이게 됩니다. 연결을 종료할 프로그램이 보인다면 -i옵션을 주어 해당 연결을 종료합니다. 해당 작업은 dba만 가능하므로 dba password를 입력해 주어야 합니다.
5. 연결이 정상적으로 종료가 되었다면 DB가 transaction처리를 완료할 때 까지 조금만 기다려 주시면 됩니다.
어떠한 이유에서든 DB가 강제종료 되어 에러가 발생하며 구동이 안 되는 경우
1. “cubrid emergency_patchlog <db_name>” 명령어를 이용하여 손상된 log의 복구를 시도합니다.
2. “cubrid emergency_patchlog –r <db_name>” 명령어를 이용하여 손상된 log 재생성을 시도합니다.
3. 위의 방법으로 복구가 되지 않을 경우 백업 받은 파일로 복구합니다.
* 가장 확실하고 안전한 방법은 백업을 이용한 복구입니다. 안전한 복구를 위하여 반드시 규칙적인 백업을 받아 놓으시기 바랍니다.
