로깅 유형

IBM® MQ 에는 큐 관리자 활동의 레코드를 유지보수하는 두 가지 방법 (순환 로깅 및 선형 로깅) 이 있습니다. 세 번째 유형의 로깅인 복제 로깅은 고유 HA 구성에 의해 사용됩니다.

순환 로깅

재시작 복구만 필요한 경우 로그를 사용하여 시스템이 중지될 때 진행 중이었던 트랜잭션을 롤백하는 순환 로깅을 사용하십시오.

순환 로깅은 모든 재시작 데이터를 로그 파일의 링에 보관합니다. 로깅은 링에서 첫 번째 파일을 채운 후 다음 단계로 이동하며 모든 파일이 가득 찰 때까지 계속됩니다. 그런 다음 링에서 첫 번째 파일로 돌아와서 다시 시작합니다. 이 순환은 제품을 사용 중인 한 계속되며 로그 파일 부족이 발생하지 않는 장점이 있습니다.

IBM MQ 는 큐 관리자 데이터 복구를 위해 더 이상 필요하지 않을 때까지 데이터를 유실하지 않고 큐 관리자를 재시작하는 데 필요한 로그 항목을 보존합니다. 재사용을 위해 로그 파일을 릴리스하는 메커니즘은 완전한 복구를 보장하기 위한 체크포인트 사용에 설명되어 있습니다.

선형 로깅

재시작 복구 및 매체 복구를 둘 다 원하는 경우 선형 로깅을 사용하십시오(로그의 컨텐츠를 재실행하여 손실되거나 손상된 데이터를 다시 작성). 선형 로깅에서는 일련의 연속 로그 파일에 로그 데이터를 보관합니다.

선택적으로 로그 파일에 대해 다음을 수행할 수 있습니다.
  • 재사용(재시작 복구 또는 매체 복원을 위해 더 이상 필요하지 않은 경우에만)
  • 장기 저장 및 분석을 위해 수동으로 아카이브
매체 이미지의 빈도는 선형 로그 파일을 재사용할 수 있는 시기를 판별하므로 선형 로그 파일에 사용 가능해야 하는 디스크 공간의 크기를 결정하는 데 있어 중요한 요인입니다.

시간 또는 로그 사용량을 기반으로 자동으로 주기적 매체 이미지를 기록하도록 큐 관리자를 구성하거나 수동으로 매체 이미지를 스케줄할 수 있습니다.

구현할 정책 및 디스크 공간 사용량에 대한 의미는 관리자가 결정합니다. 재시작 복구에 필요한 로그 파일은 항상 사용 가능해야 하지만 매체 복원을 위해서만 필요한 로그 파일은 장기 스토리지(예: 테이프)에 아카이브할 수 있습니다.

관리자가 자동 로그 관리 및 자동 매체 이미지를 사용으로 설정하면 선형 로깅은 매우 큰 순환 로그의 경우와 비슷한 방식으로 작동하지만 매체 복원에 의해 사용으로 설정된 매체 장애에 대한 중복성이 개선됩니다.

migmqlog 명령을 사용하여 큐 관리자의 기존 로그 유형을 선형에서 순환으로 또는 순환에서 선형으로 변경할 수 있습니다.

[IBM Cloud Pak for Integration]

복제 로깅

복제 로깅을 사용하여 고유 HA 구성을 구성할 수 있습니다. 고유 HA 그룹을 작성하는 경우 사용자는 서로 다른 노드에서 세 개의 큐 관리자를 작성합니다. 사용자는 각각의 큐 관리자에 대해 고유 인스턴스 이름으로 복제의 로깅 유형을 함께 지정합니다. 고유 HA 구성은 두 개의 복제본 인스턴스에 대한 활성 인스턴스 복제 로그 데이터를 보유함으로써 고가용성 솔루션을 제공합니다. 활성 인스턴스가 실패하면, 복제 인스턴스 중 하나가 활성 역할을 대신합니다. 로그 복제는 만약 있다고 해도 데이터 손실이 거의 없음을 보장합니다. 자세한 내용은 네이티브 HA를 참조하세요. 복제된 로그는 자동 로그 관리 및 자동 매체 이미지가 사용 가능한 선형 로그와 동일합니다.

[UNIX, Linux, Windows, IBM i]

활성이 아닌 선형 로드 익스텐트

아카이브를 포함하여 자동 로그 관리를 사용하는 경우 로거는 활성 상태가 아닌 선형 로그 익스텐트를 추적합니다.
주의: 아카이브 없이 자동 로그 관리를 사용하는 경우 백업 큐 관리자의 사용은 이 프로세스에 대해 지원되지 않습니다.

[AIX, Linux, Windows]복구를 위해 로그 익스텐트가 더 이상 필요하지 않을 때 필요한 경우 해당 로그 익스텐트가 아카이브되면 로거는 편리한 지점에서 해당 로그 익스텐트를 삭제하거나 재사용합니다.

재사용된 로그 익스텐트는 로그 순서에서 다음 로그 익스텐트로 이름이 바뀝니다. 작성되거나 삭제되거나 재사용된 익스텐트 수를 표시하는 AMQ7490 메시지가 주기적으로 기록됩니다.

로거는 재사용할 준비가 된 상태를 유지할 익스텐트 수와 해당 익스텐트를 삭제할 시기를 선택합니다.

활성 로그

선형 및 순환 로깅 모두에서 활성으로 불리는 파일이 여러 개 있습니다. 순환 로깅인지 아니면 선형 로깅인지에 관계없이 활성 로그는 재시작 복구에서 참조하는 로그 공간의 최대 크기입니다.

활성 로그 파일의 수는 일반적으로 구성 파일에 정의된 1차 로그 파일의 수보다 적습니다. (숫자 정의에 대한 자세한 내용은 로그 크기 계산하기를 참조하세요.)

활성 로그 공간에는 매체 복원을 위해 필요한 공간이 포함되지 않으며 선형 로깅에 사용되는 로그 파일 수는 메시지 플로우 및 매체 이미지 빈도에 따라 매우 많을 수 있습니다.

비활성 로그

로그 파일이 재시작 복구를 위해 더 이상 필요하지 않으면 해당 로그 파일은 inactive 상태가 됩니다. 재시작 복구 또는 매체 복원을 위해 필요하지 않은 로그 파일은 불필요한 로그 파일로 간주할 수 있습니다.

자동 로그 관리를 사용하는 경우 큐 관리자는 이 불필요한 로그 파일의 처리를 제어합니다. 수동 로그 관리를 선택한 경우 불필요한 로그 파일이 더 이상 조작과 관련이 없을 때 불필요한 로그 파일을 관리(예: 삭제 및 아카이브)하는 것은 관리자가 담당하게 됩니다.

로그 파일 처리에 대한 자세한 내용은 로그 관리하기를 참조하세요.

보조 로그 파일

선형 로깅에 대해 보조 로그 파일이 정의되더라도 이러한 파일은 정상 조작에서는 사용되지 않습니다. 재시작을 위해 계속해서 필요할 수 있으므로 파일을 활성 풀로부터 비울 수 없는 상황이 발생하면(아마도 장기 트랜잭션으로 인해) 보조 파일이 형식화되고 활성 로그 파일 풀에 추가됩니다.

사용 가능한 보조 파일 수를 다 사용한 경우 로그 활동이 필요한 가장 마지막 조작에 대한 요청이 거부되고 MQRC_RESOURCE_PROBLEM 리턴 코드가 애플리케이션에 리턴되며 장기 실행 트랜잭션은 모두 비동기 롤백을 위해 고려됩니다.

주의: 모든 유형의 로깅은 하드웨어 장애가 없다고 가정하고 예기치 않은 전원 손실에 대처할 수 있습니다.