4.5. 메시지 지속성 구성
기본적으로 AMQ Broker는 메시지 데이터를 유지(즉, 저장)하지 않습니다. AMQ Broker에는 메시지 데이터를 유지하기 위한 두 가지 옵션이 있습니다.
- 저널에 메시지 저장. 지속성을 활성화하는 경우 메시지를 유지하는 기본 방법입니다. 저널 기반 지속성은 파일 시스템의 저널에 메시지를 쓰는 고성능 옵션입니다.
- 데이터베이스에 메시지 저장. 이 옵션은 JDBC(Java Database Connectivity) 연결을 사용하여 선택한 데이터베이스에 메시지를 저장합니다.
AMQ Broker에서 지원하는 데이터베이스 및 네트워크 파일 시스템에 대한 최신 정보는 Red Hat 고객 포털에서 Red Hat AMQ 7 지원 구성 을 참조하십시오.
4.5.1. 저널 기반 지속성 구성 링크 복사링크가 클립보드에 복사되었습니다!
지속성을 활성화하면 기본적으로 저널 파일에 메시지가 유지됩니다.
프로세스
-
브로커 배포에 대한
ActiveMQArtemisCR(사용자 정의 리소스)을 편집합니다. persistenceEnabled특성을true로 설정합니다. 예를 들면 다음과 같습니다.spec: ... deploymentPlan: persistenceEnabled: true ...spec: ... deploymentPlan: persistenceEnabled: true ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - CR을 저장합니다.
4.5.2. 데이터베이스 지속성 구성 링크 복사링크가 클립보드에 복사되었습니다!
JDBC(Java Database Connectivity) 연결을 사용하여 데이터베이스에서 메시지를 유지하도록 AMQ Broker를 구성할 수 있습니다.
데이터베이스에서 메시지 데이터를 저장하면 브로커는 JDBC(Java Database Connectivity) 연결을 사용하여 메시지 및 바인딩 데이터를 데이터베이스 테이블에 저장합니다. 테이블의 데이터는 AMQ Broker 저널 인코딩을 사용하여 인코딩됩니다. 지원되는 데이터베이스에 대한 자세한 내용은 Red Hat Customer Portal의 Red Hat AMQ 7 지원 구성 을 참조하십시오.
관리자는 조직의 광범위한 IT 인프라의 요구 사항에 따라 메시지 데이터를 데이터베이스에 저장하도록 선택할 수 있습니다. 그러나 데이터베이스를 사용하면 메시징 시스템의 성능에 부정적인 영향을 미칠 수 있습니다. 특히 JDBC를 통해 데이터베이스 테이블에 메시징 데이터를 작성하면 브로커에 상당한 성능 오버헤드가 발생합니다.
사전 요구 사항
- AMQ Broker와 함께 사용할 전용 데이터베이스입니다.
- 필요한 JDBC 드라이버 JAR 파일은 런타임 시 브로커에서 사용할 수 있습니다. 런타임 시 브로커에서 JAR 파일을 사용할 수 있도록 하는 방법에 대한 자세한 내용은 4.4절. “타사 JAR 파일 추가” 을 참조하십시오.
-
배포에는 단일 브로커 인스턴스가 있습니다. 배포에 단일 브로커 인스턴스가 있는지 확인하려면
deployment.size속성이ActiveMQArtemisCR(사용자 정의 리소스)에 없는지 확인합니다. CR에서deployment.size속성이 생략되면 단일 브로커 인스턴스가 배포됩니다.
프로세스
-
브로커 배포에 대한
ActiveMQArtemisCR(사용자 정의 리소스)을 편집합니다. brokerProperties속성을 사용하여 JDBC 데이터베이스 지속성을 활성화합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - storeConfiguration
-
JDBC 데이터베이스에 메시지를 유지하려면
DATABASE값을 지정합니다. - storeConfiguration.jdbcDriverClassName
JDBC 데이터베이스 드라이버의 정규화된 클래스 이름입니다. 예를 들면
org.postgresql.Driver입니다.지원되는 데이터베이스에 대한 자세한 내용은 Red Hat Customer Portal의 Red Hat AMQ 7 지원 구성 을 참조하십시오.
- storeConfiguration.jdbcConnectionUrl
데이터베이스 이름 및 모든 구성 매개변수를 포함하여 데이터베이스 서버의 전체 JDBC 연결 URL입니다. 예를 들면 다음과 같습니다.
JDBC:postgresql://postgresql-service.default.svc.cluster.local:5432/postgres?user=postgres&password=postgres이 예에서 데이터베이스 이름은
postgres입니다.- HAPolicyConfiguration
-
SHARED_STORE_PRI Cryostat로 설정하여 브로커가 JDBC 리스 잠금을 사용하여 데이터베이스 테이블을 여러 브로커의 동시 액세스로부터 보호합니다. 두 번째 브로커 인스턴스가 의도치 않게 배포되는 경우 리스 잠금을 통해 두 번째 브로커가 데이터베이스에 기록되지 않습니다.
(선택 사항) 필요한 경우 다음 속성의 기본값을 변경합니다.
- storeConfiguration.jdbcNetworkTimeout
- JDBC 네트워크 연결 제한 시간(밀리초)입니다. 기본값은 20000밀리초입니다.
- storeConfiguration.jdbcLockRenewPeriod
-
현재 JDBC 잠금에 대한 갱신 기간의 길이(밀리초)입니다. 이 시간이 지나면 브로커는 잠금을 갱신할 수 있습니다.
storeConfiguration.jdbcLockExpiration값보다 여러 번 작은 값을 설정하여 브로커에게 리스를 연장할 수 있는 충분한 시간을 제공하고 브로커에게 연결 문제 발생 시 잠금을 갱신할 수 있는 시간을 제공합니다. 기본값은 2000밀리초입니다. - storeConfiguration.jdbcLockExpiration
-
storeConfiguration.jdbcLockRenewPeriod의 값이 경과한 경우에도 현재 JDBC 잠금이 보유(즉, 획득 또는 갱신됨)로 간주되는 시간(밀리초)입니다. 브로커는storeConfiguration.jdbcLockRenewPeriod의 값에 따라 소유한 잠금을 주기적으로 갱신하려고 합니다. 예를 들어 연결 문제로 인해 브로커가 잠금을 갱신하지 못하면 브로커는 잠금을 성공적으로 획득하거나 갱신한 후storeConfiguration.jdbcLockExpiration의 값이 전달될 때까지 잠금을 갱신하려고 합니다. 위에서 설명한 갱신 동작의 예외는 다른 브로커가 잠금을 취득하는 경우입니다. 이는 DBMS(데이터베이스 관리 시스템)와 브로커 간에 시간 불일치가 있거나 가비지 수집에 대한 일시 중지가 긴 경우 발생할 수 있습니다. 이 경우 원래 잠금을 보유한 브로커는 잠금을 손실하고 갱신하려고 시도하지 않습니다. 만료 후 현재 소유하고 있는 브로커에 의해 JDBC 잠금이 갱신되지 않은 경우 다른 브로커는 JDBC 잠금을 설정할 수 있습니다. 기본값은 20000밀리초입니다. - storeConfiguration.jdbcJournalSyncPeriod
- 브로커 저널이 JDBC와 동기화되는 기간(밀리초)입니다. 기본값은 5밀리초입니다.
- storeConfiguration.jdbcMaxPageSizeBytes
- AMQ Broker가 JDBC 데이터베이스에 메시지를 저장할 때 각 페이지 파일의 최대 크기(바이트)입니다. 기본값은 102400이며, 이는 100KB입니다. 지정한 값은 "K" "MB" 및 "GB"와 같은 바이트 표기법도 지원합니다.
- CR을 저장합니다.