이 이슈는 "데이터베이스의 모든 데이터를 삭제"와 "지정한 프로토콜의 데이터베이스만 삭제"를 분리해서 생각할 필요가 있을 것 같습니다. 전자의 경우 데이터베이스에서 데이터를 읽어가고 있는 외부 프로그램(hog, reconverge, crusher 등)에 영향을 줄 수 있기 때문에 해당 프로그램에 데이터베이스를 초기화한다는 메시지를 보내주고 연결을 모두 끊은 다음에 삭제하는 것이 필요합니다. 데이터베이스에 데이터를 쓰는 프로그램(piglet, reproduce 등)의 경우는 역시 연결을 끊고 처리하는 것이 나을 것 같긴 한데, 이건 데이터베이스 초기화의 요구 사항이 어떤가에 따라 다를 수 있을 것 같습니다.

후자의 경우는 giganto가 정상 동작하면서 실행해야 하는 작업인 듯 한데, 이건 어떤 경우에 필요한 건가요? 배경을 알지 못해서 #234 의 구현 방법이 바람직한지 아닌지 판단하기가 어렵습니다.

@msk

데이터베이스를 모두 삭제하는 경우는

• 장비를 이동형으로 사용할 때.
  • 한 지역에서 일정 기간 데이터를 분석한 후 초기화하고, 다른 지역으로 이동해서 같은 작업을 반복하는 고객이 있습니다. 대표적으로 --가 그런 경우입니다.
• 파일럿 운용 시험
  • 상당수의 고객은 제품을 직도입하기 보다는 파일럿 운영기간을 가진 후에 도입여부를 결정합니다. 파일럿 기간이 끝날 때 초기화해야 합니다.

특정 데이터베이스만 삭제하는 경우는

• 고객이 특정 프로토콜에 관심이 있는 경우 혹은 시험(운영) 환경이 특정 프로토콜에 집중되어 있는 경우
  • 몇 달 전에 설치한 파일럿 환경에서는 내부에 Time server가 있는데, 한국 전체에 서비스하는 서버라서 NTP 이벤트만으로 몇 일만에 디스크를 꽉 채울만큼 생성됩니다. NTP는 수집하지 않지만, 대신 Conn 데이터가 너무 많아서 디스크 정리를 해야하는데 다른 데이터를 삭제할 수는 없으니 CONN 이벤트만 삭제할 필요가 있습니다.

말씀하신 대로면 "데이터베이스를 모두 삭제하는 경우"는 그냥 데이터베이스 디렉터리를 다 지우는 걸로 충분하지 않나요? #234 처럼 레코드를 하나하나 지울 필요가 없을 것 같은데요.

"특정 데이터베이스만 삭제하는 경우"가 특정 종류의 데이터가 너무 많아서 그런 거라면 각 데이터 종류별로 용량 상한 또는 저장 기한을 지정할 수 있게 해서, giganto가 주기적으로 오래된 것부터 지우도록 하는 것이 낫지 않을까요? 사용자가 지울 수 있게 하면 데이터를 읽어가는 hog, crusher, reconverge에서 볼 때 갑자기 데이터가 끊긴 셈이 되어서 분석 결과에 영향을 주게 되고, 오탐이 발생할 가능성이 커집니다.

Pending: 삭제 논의

말씀하신 대로면 "데이터베이스를 모두 삭제하는 경우"는 그냥 데이터베이스 디렉터리를 다 지우는 걸로 충분하지 않나요? #234 처럼 레코드를 하나하나 지울 필요가 없을 것 같은데요.

"특정 데이터베이스만 삭제하는 경우"가 특정 종류의 데이터가 너무 많아서 그런 거라면 각 데이터 종류별로 용량 상한 또는 저장 기한을 지정할 수 있게 해서, giganto가 주기적으로 오래된 것부터 지우도록 하는 것이 낫지 않을까요? 사용자가 지울 수 있게 하면 데이터를 읽어가는 hog, crusher, reconverge에서 볼 때 갑자기 데이터가 끊긴 셈이 되어서 분석 결과에 영향을 주게 되고, 오탐이 발생할 가능성이 커집니다.

많이 늦었지만 좀 더 논의가 필요한 부분이 있어서 덧붙입니다.
필요한 기능 목록:

• 데이터 일부(프로토콜 DB 단위) 삭제
• 전체 삭제(초기화)
• 데이터가 삭제되는 동안 그 데이터를 받아서 사용하던 프로세스들의 불일치 문제 해결

사내에서 테스트하는 경우 혹은 우리 엔지니어가 직접 관리하는 서버에 대해서는 Giganto를 멈추고, DB를 삭제하고, 다시 Giganto를 시작하는 순서로 DB 초기화가 가능합니다. 하지만 우리가 3rd party 제휴회사를 통해서 판매한 제품이나 엔진 혹은 플랫폼만 판매하는 경우는 UI를 통해서 간편하게 전체 DB 초기화 혹은 일부 프로토콜 DB 초기화 같은 작업을 지원할 필요가 있습니다.

프로세스들의 불일치 문제의 해결을 위해서는 REview에서 프로세스들 사이의 데이터 흐름이나 연결을 제어할 필요가 있습니다.
시스템 전체의 Shutdown을 시도한다면 가장 끝단의 클라이언트인 Piglet부터 시작해서 Crusher, Hog, REconverge를 먼저 Stop한 후 서버역할을 수행하는 Giganto, REview를 Stop하는 것처럼, 시스템 초기화 시나리오를 작성하고 REview에서 그 시나리오에 따라 제어하도록 하는게 좋을 것 같습니다.