Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
설치 환경에 따른 SysMaster DB 8.3의 배포 파일은 다음과 같이 구성된다.
Java TPM Agent의 배포 파일은 다음과 같이 구성된다.
sysmaster-db
sysmaster-db-{version}.tar
meta.conf
repo.conf
docker-compose.yml
podman-compose.yml
.env
sysmaster-db-patch-{version}.tar
patch
license
+-- oss_license
|-- font_licenses.md
|-- OSS_LICENSES.md
|-- THIRD-PARTY-NOTICES.txt
|-- (and other open-source license files)sysmaster-db-{version}.tar
kubernetes
+-- init
|-- 0.namespace.yaml
|-- configmap.yaml
|-- pvc.yaml
|-- service.yaml
+-- db
|-- metadb-deployment.yaml
|-- repodb-deployment.yaml
+-- kafka
|-- kafka.yaml
+-- sysmaster
|-- analyzer-deployment.yaml
|-- client-deployment.yaml
|-- collector-deployment.yaml
|-- sdm-deployment.yaml
|-- tibero-master-deployment.yaml
sysmaster-db-patch-{version}.tar
patch
license
+-- oss_license
|-- font_licenses.md
|-- OSS_LICENSES.md
|-- THIRD-PARTY-NOTICES.txt
|-- (and other open-source license files)jdk8
+-- aix7
|-- ibm-semeru-open-jdk_ppc64_aix_8u382b05_openj9-0.40.0.tar
+-- centos7
|-- OpenJDK8U-jdk_x64_linux_8u342b07.tar.gz
lib
+-- aix7
|-- libJNITpmStat.so
+-- centos7
|-- libJNITpmStat.so
application.yml
set.sh
tpmagent.jar
tpmctl.sh
tryrun.shSysMaster DB 8.3를 설치하기 전 준비 과정을 다음과 같은 단계로 설명한다.
- 설치하기 전에 확인해야 할 시스템의 요구 사항에 대해서 설명한다.
- SysMaster DB 8.3를 설치하기 전에 필요한 환경 구성에 대해서 설명한다.
- 설치를 위한 배포 파일들의 구성 요소에 대해서 설명한다.
사용하고자 하는 엔진에 따라 도커 혹은 파드맨을 설치한다.
Docker 엔진을 사용할 경우
Docker-compose, Kubernetes 를 통해 SysMaster DB를 구동할 수 있다.
RHEL의 Podman 엔진을 사용할 경우
Podman-compose 환경을 통해 SysMaster DB를 구동할 수 있다.
아래의 주소에서 도커 엔진 설치 방법 문서를 확인한 후 운영체제에 맞는 도커 엔진을 설치한다.
설치 환경의 인터넷 연결 여부에 따른 설치 방법은 다음과 같다.
인터넷 연결이 가능한 경우
"Install using the repository" 과정에 따라 설치한다.
이때 별도의 버전을 명시하지 않고 가장 최신 버전을 설치할 것을 권장한다.
인터넷 연결이 불가능한 경우
이때 도커 엔진 설치 과정에서 최종적으로 설치되어야 하는 패키지는 docker-ce, docker-ce-cli, containerd.io, docker-compose-plugin이다.
docker version 명령을 사용하여 정상적으로 도커/ 파드맨이 설치되었는지 확인한다.
아래의 주소에서 설치 방법을 확인한 후 설치한다.
파드맨 엔진 설치 과정에서 최종적으로 설치되어야 하는 패키지는 podman, Slirp4netns, podman-plugins이다.
podman version 명령을 사용하여 정상적으로 도커/ 파드맨이 설치되었는지 확인한다.
'Docker-compose', 'Kubernetes', 'Podman-compose' 중에서 하나만 선택하여 설치한다.
Docker 설치 시 docker-compose-plugin 패키지가 함께 설치된다. Docker가 정상적으로 설치되었을 경우 docker-compose 환경을 위한 별도의 추가 설치 과정은 필요 없다.
docker compose version 명령을 사용해 정상적으로 docker compose가 설치되었는지 확인한다.
Podman-compose
"Install from a package" 과정에 따라 패키지 별 설치 파일을 별도로 배포해 설치한다.
이때 각 패키지 별로 가장 최신 버전을 설치할 것을 권장한다.
다음은 Centos 7, x86-64 기준의 설치 파일 경로 예시이다.
https://download.docker.com/linux/centos/7/x86_64/stable/Packages/
Podman-compose 는 podman 을 docker-compose 처럼 사용할 수 있게 해주는 툴이다.
Python 기반으로 만들어져 있어 pip를 사용해서 설치한다
sudo pip3 install podman-compose
정상적으로 podman-compose가 설치되었는지 확인한다.
podman-compose version
Kubernetes
아래의 주소에서 Kubernetes 설치 방법을 확인한 후 운영체제에 맞는 Kubernetes를 설치한다.
https://kubernetes.io/ko/docs/setup/production-environment/tools/
추가적으로 아래의 주소에서 Kubectl 설치 방법을 확인한 후 운영체제에 맞는 Kubectl을 설치한다.
https://kubernetes.io/ko/docs/tasks/tools/
관제 데이터베이스의 설정 방법 및 TPM Agent의 설치 방법을 다음과 같은 단계로 설명한다.
유저 / TIP 설정 - 관제 데이터베이스의 유저와 TIP 설정하는 방법을 설명한다.
TPM Agent 설치하기 - TPM Agent의 설치 방법을 설명한다.
SysMaster DB 8.3 설치 방법을 Docker-compose / Podman-compose 환경과 Kubernetes 환경으로 나누어 설명한다. 이때 각 환경에서 다음과 같은 단계로 설명한다.
설치 및 파라미터 설정 - SysMaster DB 8.3 의 설치 및 파라미터 설정방법에 대해서 설명한다.
기동 / 로그 확인 / 종료 / 초기화- 기동, 로그 확인, 종료, 초기화 방법에 대해서 설명한다.
마지막으로 외부 접속 허용 포트에서는 SysMaster DB 8.3에서 사용하는 포트들에 대해서 설명한다.
SysMaster DB 에서 관제 데이터베이스 등록 시 유저 정보를 입력하게 된다. 기존에 생성된 유저를 사용할 수 있고, 새로운 유저를 생성해 사용할 수도 있다. 이때 유저에게 필요한 권한은 CONNECT, ALTER SYSTEM, SELECT_CATALOG_ROLE이다. 유저 생성 및 권한 부여는 SYS 계정에서 아래 DDL 및 DCL 문을 사용한다.
추가로 TPR Report, ASH Report 기능을 사용하려면 아래 DCL 문을 사용하여 관련 권한을 부여해야 한다.
TPM Agent에서 Tibero로부터 정보를 수집하기 위해서는 libtpmstat 라이브러리가 필요하다. 관제 데이터베이스에 279651 패치가 적용되어 libtpmstat 라이브러리가 있는 경우에는 Tibero 환경 변수 설정 과정을 통해 해당 라이브러리를 사용할 수 있다.
만약 관제 데이터베이스에 libtpmstat 라이브러리가 없는 경우에는 해당 데이터베이스에 맞는 라이브러리를 추가로 배포해야 한다. 이때 배포된 libtpmstat.so 파일을 TPM Agent 디렉터리로 이동시킨 후 TPM Agent 라이브러리 경로 설정을 통해 해당 라이브러리를 사용할 수 있다.
SysMaster DB 8에서 사용하는 포트 중 외부 접속을 허용해야 하는 포트들은 다음과 같다.
SysMaster DB 서버에서 허용해야 하는 포트 목록
80
SysMaster DB UI 접속을 위해 브라우저를 실행하는 사용자 PC
COLLECTOR_PORT
TPM Agent가 SysMaster DB 로 수집 정보를 보내기 위해 연결하는 포트
8292
관제 데이터베이스 서버
REPODB_PORT
REPODB에 접속하기 위한 포트 (사용자가 REPODB를 직접 조회하기 위한 용도로 SysMaster DB 동작과는 무관)
15432
REPODB에 접속할 사용자 PC
METADB_PORT
METADB에 접속하기 위한 포트 (사용자가 METADB를 직접 조회하기 위한 용도로 SysMaster DB 동작과는 무관)
25432
METADB에 접속할 사용자 PC
관제 데이터베이스 서버에서 허용해야 하는 포트 목록
티베로 리스너 포트
SysMaster DB 서버에서 관제 데이터베이스에 연결하는 포트
8629
SysMaster DB 서버
CLIENT_PORT
브라우저에서 SysMaster DB UI에 접속하기 위한 포트
CREATE USER [username] IDENTIFIED BY [password];
GRANT CONNECT, ALTER SYSTEM, SELECT_CATALOG_ROLE TO [username];GRANT EXECUTE ON SYS.DBMS_TPR TO [username];
GRANT EXECUTE ON UTL_TPR TO [username];웹 브라우저
Chrome (최신 버전 사용 권장)
281081
V$TEMPSEG_USAGE 뷰의 SESSION_NUMBER 컬럼 값 표기 잘못되는 문제 개선
[참고] 해당 패치가 없는 경우 [Realtime] > [Usage Monitoring] > [Temp Usage], [Analysis] > [Usage Analysis] > [Temp Usage] 메뉴에 부정확한 정보가 표출될 수 있다.
304981b
SQL Trace 정보 수집 시 machine, OS user 추가 수집
[참고] 해당 패치가 없는 경우 SQL Trace 정보에서 OS User 와 Machine 정보가 부정확하게 표출될 수 있다. 279651f 패치 선적용이 필요하며, 279651e 패치 이하 패치와는 호환되지 않는다.
307175a
SQL Trace 정보 수집 시, 이미 닫힌 세션의 경우 수집되지 않는 문제 수정
[참고] 해당 패치가 없는 경우 세션이 자주 열리고 닫히는 환경의 경우에는 SQL Trace 정보를 상당히 누락하여 수집하게 된다.
328607b
Wait count, wait time 정보 수집 시, wait event 의 wait count, time 보정 문제 수정 [참고] 해당 패치가 없는 경우 wait time과 wait count의 값이 부정확하게 표출될 수 있다.
304770a
TSC 모니터링 전용 패치 [참고] 해당 패치가 없는 경우 아래 정보들이 V$DATABASE 뷰에 없어 primary와 standby가 구분되지 않는 등 TSC 모니터링 관련 정보들이 부정확하게 보여진다.
338513a
실제 TPR 연동에 필요한 패치로, 서버 패치 없이 패키지 생성 스크립트만 실행하면 된다.
338594a
TPR 연동 중 TPR 리포트 파일이 티베로 서버에 생성되는데, 이를 삭제해주는 티베로 패키지의 버그를수정한 패치이다.
[참고] 해당 패치 없어도 TPR 연동 기능은 동작하지만 리포트 파일이 서버에 쌓여서 주기적으로 삭제가 필요하다.
리포트 파일 수동으로 삭제 방법 : 주기적으로 다음과 같이 .tpr 로 시작하는 리포트 파일 삭제.
rm -f .tpr*
149894l
해당 패치가 없는 티베로 6에서 지원하지 않는 쿼리를 TPR 스냅샷 조회시 사용하고 있어 해당 패치가 없으면 해당 패치가 없는 티베로 6에서는 조회가 되지 않는다.
250728f
Standby에서 V$INSTANCE 뷰를 조회할 수 있도록 해주는 패치. 해당 패치가 없으면 해당 인스턴스가 클러스터링이 되지 않는다.
339899a
DB 비정상 종료 상태 판단 로직 개선
[참고] 해당 패치가 없는 경우 kill -9 등 외부 요인으로 DB가 비정상 종료되었을 때, TPM Agent에서 DB 종료 여부가 정확히 판단되지 않을 수 있다.
Rocky Linux release 8 ~ 9 (64-bit)
Windows:
Windows 10 (64-bit)
Windows Server 2022 (64-bit)
아래(Docker 및 Podman) 지원 플랫폼 및 소프트웨어 요구 사항 설치를 지원하는 운영체제면 기동 가능
v28 이상
Docker-compose
v2.40.2 이상
Podman
v4.4.1 이상, Linux Kernel 4.18을 사용하는 Linux Red Hat Enterprise Linux 8 이상부터 지원.
Podman-compose
v1.0.6 이상
Kubernetes
v1.17 이상
관제 데이터베이스
Tibero 6 FixSet06 이상 Tibero 7
[참고] SysMasterDB의 Tibero 관제 연동은 Tibero 버전명뿐 아니라 서버 바이너리의 빌드 형상과 연동 라이브러리 간 호환성을 기준으로 한다. 동일한 Tibero 버전이라도 빌드 시점 및 적용 패치 내역에 따라 연동 라이브러리와 호환되지 않을 수 있다. 특히 2022년 이전 빌드 바이너리는 정상 관제를 보장하지 않으며, 기본 지원 대상에서 제외된다.
관제 데이터베이스 운영 체제
Linux:
CentOS 7 (64-bit)
Red Hat Enterprise Linux 7 ~ 10 (64-bit)
Oracle Linux 8 ~ 10 (64-bit)
Rocky Linux 8 ~ 10 (64-bit)
ProLinux 7.5 (64-bit)
AIX 7.2 (64-bit)
[참고]
C++11 지원 컴파일러
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44) 이상
GLIBCXX_3.4.19 이상
CPU
8 Core
RAM
32 GB
저장 공간
240373
Program 이 PE_SLAVE 인 Session 에서 OS User 와 Machine 정보 누락 개선
[참고] 해당 패치가 없다면 Program 이 PE_SLAVE 인 Session 에서 OS User 와 Machine 정보가 누락된다.
276404
티베로의 global view 조회 시 수행되는 내부 쿼리에 대해 수행 시마다 physical plan을 새로 생성하는 문제 개선
[참고] SysMaster DB 8에서는 Lock 정보 수집을 위해 global view를 매초 조회한다. 해당 패치가 없는 경우 매초 특정 SQL에 대해 physical plan을 생성하여 [Analysis] > [Plan Analysis] 등에서 해당 SQL에 대해 조회 시 응답 없음 현상이 발생할 수 있다.
279651f
주의
Docker Compose 2.40.2 버전 미만인 경우 Docker Compose에서 원격 OCI Compose 아티팩트 설정 값 검증 미흡으로 발생하는 경로 탐색 취약점이 있다. 따라서 2.40.2 버전 이상으로 업데이트를 권고한다.
30 GB 이상 (수집 정보의 보관 주기(RETENTION_DAY)에 따라 일 당 50 GB 추가 필요)
libtpmstat 라이브러리 생성
[참고] 해당 패치가 없는 경우 libtpmstat 라이브러리를 TPM Agent 설치 시 함께 배포해야 한다. TPM Agent 8.1.3 이상은 하위 버전 패치인 279651e 이하 패치와 호환이 되지 않기에, 279651f 이상 패치가 필요하다. Tibero에 적용된 279651 패치 버전과 상관 없이, TPM Agent 빌드 시 사용한 279651 패치 버전과 라이브러리의 279651 패치 버전이 맞아야 한다.
Docker-compose 및 Podman-compose 환경에서 SysMaster DB 8.3를 기동, 로그 확인, 종료, 초기화하는 방법이다.
export SYSMASTERDB_HOME={SysMasterDB_Home_Path}{SysMasterDB_Home_Path}
docker-compose.yml 파일이 위치한 디렉터리 경로
export PATH=$PATH:$SYSMASTERDB_HOME지정된 경로 하위에 발급받은 라이선스 파일을 배치한다. 라이선스 파일명과 경로는 아래와 같으며, 변경 불가능하다.
라이선스 파일명
sysmaster-db-license.xml
라이선스 경로
$SYSMASTERDB_HOME/license
$SYSMASTERDB_HOME 경로 하위에 license 디렉토리가 존재하지 않는 경우, 해당 디렉토리를 직접 생성해준 후 라이선스 파일(sysmaster-db-license.xml)을 넣어주면 된다.
부팅이 완료된 이후에 로그인과 프로그램 사용이 가능하다. 부팅 완료는 SDM 로그에서 아래와 같은 로그를 통해 확인할 수 있다.
.env 파일의 로그 관련 파라미터 설정을 통해 로그가 저장될 경로를 지정할 수 있다. default 로그 경로는 ./logs이므로 docker-compose.yml 파일이 있는 디렉터리에 logs 폴더가 자동으로 생성되며, 여기서 로그 파일을 확인할 수 있다.
SysMaster DB 8.3 기동을 위한 환경 변수 및 PATH가 설정된 상태에서 아래의 명령을 수행하면 모든 서비스가 제거되고, SysMaster DB 8.3가 종료된다. 이때 SysMaster DB 8.3를 종료해도 METADB_PATH와 REPODB_PATH에 생성된 파일은 유지되므로, SysMaster DB 8.3를 다시 기동하면 종료 전과 동일하게 사용할 수 있다.
METADB_PATH와 REPODB_PATH 디렉터리를 삭제한 후 SysMaster DB 8를 다시 기동하면 최초 설치 상태와 동일하게 동작한다. 단, 이전에 저장한 데이터는 사용할 수 없다.
Kubernetes 환경에서 SysMaster DB 를 기동 / 로그 확인/ 종료 / 초기화하는 방법이다.
설치 파일이 위치한 디렉터리에서 아래와 같은 순서로 명령을 수행하여 쿠버네티스 오브젝트를 생성한다.
kubectl apply -f kubernetes/initkubectl apply -f kubernetes/db다음 단계로 진행하기 전 RepoDB, MetaDB가 정상적으로 부팅 완료되어야 한다. 이는 다음과 같은 로그를 통해 확인 가능하다.
먼저 각각 해당 pod의 터미널 출력 로그에서 아래와 같은 메세지가 출력되는 것을 확인한다.
[ENTRYPOINT LOG]: INFO: Attempting to start PostgreSQL server...다음으로 각 데이터베이스의 로그파일에 아래와 같은 메세지가 출력되는 것을 확인한다.
LOG: database system is ready to accept connections이때 각 데이터베이스의 로그 파일 확인 방법은 "2. 로그 확인"을 참고한다.
kubectl apply -f kubernetes/kafkakubectl apply -f kubernetes/sysmastersysmasterdb8-sdm-container가 생성되면, 해당 컨테이너 내 sysmaster/license 경로 하위에 발급받은 라이선스 파일을 배치한다. 라이선스 파일명은sysmaster-db-license.xml 이며, 변경 불가능하다.
부팅이 완료된 이후에 로그인과 프로그램 사용이 가능하다. 부팅 완료는 SDM 로그에서 아래와 같은 로그를 통해 확인할 수 있다.
기본적으로 각 모듈들의 pod 내 컨테이너에 접속하여 해당 모듈의 log 파일을 볼 수 있다. SysMaster DB 모듈들은 동일하게 각 컨테이너 내 아래 경로에 로그가 적재된다.
추가로, 사용자의 편의를 위하여 로그 확인 전용 컨테이너를 생성하여 활용할 수 있다.
배포 파일 구성에 포함된 client-deployment.yaml 파일에 정의된 sysmasterdb8-client-pod 내에, 로그 확인 전용 컨테이너인 sysmasterdb8-log-container가 정의되어 있다. 사용자는 해당 컨테이너 내 로그 디렉터리 경로(/sysmaster/logs)를 통해 모든 SysMaster DB 모듈의 로그를 확인할 수 있다.
설치 파일이 위치한 디렉터리에서 아래와 같은 순서로 명령을 수행하면 SysMaster DB 가 종료된다. 이때 SysMaster DB 를 종료해도 Repository DB와 Meta DB의 데이터 파일은 유지되므로, SysMaster DB 를 다시 기동하면 이전에 저장한 데이터를 사용할 수 있다.
아래의 명령을 수행하면 모든 데이터가 삭제되고, 최초 설치 상태와 동일하게 동작한다. 단, 이전에 저장한 데이터는 사용할 수 없다.
GLIBC_2.17 이상
sysmaster-db uppodman compose -f podman-compose.yml up -dStarted SdmApplication in ... seconds (JVM running for ...)sysmaster-db downStarted SdmApplication in ... seconds (JVM running for ...)/sysmaster/logskubectl delete -f kubernetes/sysmasterkubectl delete -f kubernetes/kafkakubectl delete -f kubernetes/dbkubectl delete -f kubernetes/init1) OPEN_MODE에 value 추가
- READ ONLY WITH APPLY
2) PROTECTION_MODE
: Protection mode currently in effect for the database
- UNPROTECTED
- PROTECTION
- AVAILABILITY
- PERFORMANCE
3) DATABASE_ROLE
: Current role of the database
- PRIMARY
- PHYSICAL STANDBY
- LOGICAL STANDBY (TODO)
- SNAPSHOT STANDBY
- CASCADING STANDBY
4) STANDBY_BECAME_PRIMARY_TSN
: TSN at which the physical standby database became primary
5) STANDBY_BECAME_PRIMARY_DATE
: Time at which the physical standby database became primaryapplication.yml 파일 설정 완료 후 아래와 같은 순서로 TPM Agent를 환경을 설정한다.
ulimit -c unlimited. set.shset.sh 스크립트 내용
if [ -n "$JAVA_HOME" ] && [ -x "$JAVA_HOME/bin/java" ]; then
TARGET="$JAVA_HOME/bin/tpmagent"
# 하드링크 시도, 실패하면 복사
if ln -f "$JAVA_HOME/bin/java" "$TARGET" 2>/dev/null; then
echo "Hardlink created: $TARGET"
elif cp -p "$JAVA_HOME/bin/java" "$TARGET"; then
echo "Copied binary to: $TARGET"
else
echo "WARNING: Failed to create $TARGET"
echo " This may be a permission issue. Please check write access to $JAVA_HOME/bin."
echo " You can start TPM Agent, but in 'top'/'topas', process name will appear as java."
fi
# 실행 가능 확인
if [ -x "$TARGET" ]; then
echo "Installed $TARGET"
fi
else
echo "ERROR: JAVA_HOME not set or java not found in \$JAVA_HOME/bin"
fi
# 사용자 환경변수 설정
export TPMAGENT_HOME={TPM_Agent_Home_Path}
export PATH=$TPMAGENT_HOME:$PATH
export LD_LIBRARY_PATH=$TPMAGENT_HOME:$LD_LIBRARY_PATH
# 기존 실행 중이던 Agent가 있다면, 종료 후 실행
export BOOT_WITH_AUTO_DOWN_CLEAN=true
export ENABLE_DEBUG=false
export ENABLE_GC_LOG=false
# Agent 의 java heap 메모리 설정. 2000 session 기준 1000m. 이후 1000 session 마다 200m 추가 권장
export JAVA_MIN_HEAP_SIZE=1000m
export JAVA_MAX_HEAP_SIZE=1000m{TPM_Agent_Home_Path}
"java_tpmagent_dist_{version}.tar.gz" 압축 파일 해제 디렉터리 경로
export TB_HOME={Monitoring_DB_Path}
export TB_SID={Monitoring_DB_SID}
export LD_LIBRARY_PATH=$TB_HOME/lib:$TB_HOME/client/lib
export PATH=$PATH:$TB_HOME/bin:$TB_HOME/client/bintpmctl.sh 명령어는 아래와 같으며, help로 터미널에서 사용법 확인이 가능하다.
Java TPM Agent에서 libtpmstat.so를 사용하기 위하여 필요한 라이브러리이다.
Tibero Down 이후 바로 Tibero Boot를 위해서 TPM Agent Down이 필요하다. TPM Agent가 참조하고 있는 Tibero Shared Memory를 해제해야 하기 때문이다.
{Monitoring_DB_Path}
관제 데이터베이스의 경로를 입력
{Monitoring_DB_SID}
관제 데이터베이스의 SID를 입력
./tpmctl.sh [-p port] up
TPM Agent 실행, -p 옵션을 통하여 jvm 디버그 포트들을 지정할 수 있다. 기본적으로 사용 가능한 포트를 찾으나, 해당 환경에서 사용 가능한 포트를 찾지 못하여 프로세스 실행이 되지 않는다면 해당 옵션을 사용하여 수동으로 포트를 지정할 수 있다.
./tpmctl.sh down
TPM Agent 종료
./tpmctl.sh help
주의
Tibero 버전명 또는 코어셋명만으로 연동 라이브러리의 호환 여부를 판단할 수 없다. 연동 라이브러리(libtpmstat.so)는 Tibero 서버와 공유 메모리 구조체가 일치해야 정상 동작하므로, 동일한 Tibero 버전이라도 빌드 시점, 직반 패치 내역, 컴파일 옵션 등에 따라 호환되지 않을 수 있다. 따라서 과거 빌드 바이너리 또는 별도 패치가 적용된 바이너리를 사용하는 경우, 관제 연동 전 동일한 Tibero 형상 기준으로 라이브러리를 빌드하고 호환 여부를 확인해야 한다.
libJNITpmStat.so 파일이 사용하는 libtpmstat.so 라이브러리 버전이 현재 Tibero 바이너리 버전과 맞지 않다면, 기존 TPM Agent 와 동일하게 SIGSEGV 문제 등 오류가 발생하여 프로세스가 실행되지 않는다. 각 JVM 벤더별로 생성되는 오류 관련 파일 종류는 다르나 core, jitdump, javacore 등의 파일 들이 생성될 수 있으므로 해당 파일 생성시 libtpmstat.so 라이브러리 버전을 확인해야한다.
주의
TPM Agent가 참조하고 있는 Tibero Shared Memory를 해제하기 위해서는 Tibero Down을 감지해야 하는데 감지 주기는 매 수집 주기와 동일하다. 따라서 사용자의 수집 주기 설정이 길게 되어있거나 TPM Agent 자체가 느려지는 경우 등 Tibero Down 감지 자체가 늦어질 경우 Tibero Down을 하고 다시 Tibero Boot가 가능한 시점이 지연되게 된다. 이와 같이 Tibero Down 감지가 늦어져 Tibero Boot 가능 시점이 지연되는 것을 방지하기 위해서는 TPM Agent Down을 진행하고 Tibero Boot를 하면 된다.
TPM Agent 도움말 출력
./tpmctl.sh version
TPM Agent 버전 출력
./tpmctl.sh libversion
TPM Agent 이 사용하는 TPM Stat 라이브러리 빌드 패치 목록과 Tibero의 패치 목록 출력
TPM Agent를 설치하는 과정은 다음과 같다. 단, 반드시 관제 데이터베이스를 설치한 계정과 동일한 OS 계정으로 진행해야 한다.
관제 데이터베이스가 위치한 서버에 "tpmagent_dist_{version}.tar.gz" 압축 파일을 배포한 후 압축을 해제한다.
tar -zxvf java_tpmagent_dist_{version}.tar.gz"java_tpmagent_dist_{version}.tar.gz" 압축 파일을 해제한 디렉터리에 application.yml 파일을 아래와 같이 작성하여 설정을 적용한다. yml 문법에 맞게 각 파라미터들의 값을 조정하여 설정한다.
agent-config:
id: "AAA1"
ip: "192.1.3.225"
port: 8292
freq: 1000
charset: "utf-8"
cpu-mem-proc-freq: 5000
disk-freq: 5000
sessioninfo-freq: 5000
dbsysinfo-freq: 5000
sqltrace-freq: 5000
sqltrace-queue-size: 10
sqltrace-elapsed-time-threshold: 100
sqltrace-monitoring-freq: 10
sqltrace-monitoring-thread-per-session-count: 500
log:
level: INFO
rotate-time-interval: 24
rotate-file-size: 50MB
max-log-file-number: 7
path: logs/해당 과정에서 설정하는 파라미터에 대한 설명은 다음과 같다.
Tibero에서 지원하는 문자 집합은 다음과 같다.
ASCII
EUC-KR
MSWIN949
UTF-8
"java_tpmagent_dist_{version}.tar.gz" 압축 파일을 해제한 디렉터리에 set.sh 파일에 적용시킬 환경 변수들이 있으며, 아래와 같이 작성하여 설정을 적용한다.
해당 과정에서 설정하는 환경변수에 대한 설명은 다음과 같다.
O
agent-config
freq
수집 주기 (단위: msec).
[참고] 설정하지 않으면 1000ms로 설정되므로 1초 주기로 수집.
X
agent-config
charset
관제 DB의 문자 집합 (NLS_CHARACTERSET 파라미터로 확인).
[참고] 설정하지 않으면 utf-8 로 설정
X
agent-config
cpu-mem-proc-freq
CPU, 메모리, 프로세스 목록 정보를 가져오는 주기(단위: ms) [참고] 설정하지 않으면 "freq" 값으로 설정됨
X
agent-config
disk-freq
디스크 정보를 가져오는 주기 (단위: ms)
[참고] 설정하지 않으면 "freq × 60" 값으로 설정되며, 설정하면 설정한 주기로 수집을 진행
X
agent-config
session-freq
세션 정보를 가져오는 주기 (단위: ms)
[참고] 설정하지 않으면 "freq" 값으로 설정됨
X
agent-config
dbsysinfo-freq
관제 DB의 시스템 지표 정보를 가져오는 주기 (단위: ms)
[참고] 설정하지 않으면 "freq" 값으로 설정됨
X
agent-config
sqltrace-freq
SQL Trace 정보를 가져오는 주기 (단위: ms)
[참고] 설정하지 않으면 "freq" 값으로 설정됨
X
agent-config
sqltrace-queue-size
메모리에 SQL Trace를 수집하기 전에 저장하는 개수. sqltrace-freq마다 해당 queue에서 수집된 SQL Trace를 모아서 수집한다. (1 ~ 2^32-1 사이의 정수). [참고] 설정하지 않으면 10으로 설정
X
agent-config
sqltrace-elapsed-time-threshold
SQL 실행 정보 생성 기준 실행 시간 임계치(단위: ms)(예: 100msec 이상 수행된 SQL에 대해서만실행 정보 생성) [참고] 설정하지 않으면 100으로 설정
X
agent-config
sqltrace-monitoring-freq
SQL Trace를 모니터링하는 스레드의 세션 목록 조회 주기(단위: ms) [참고] 설정하지 않으면 10으로 설정
X
agent-config
sqltrace-monitoring-thread-per-session-count
SQL Trace를 모니터링하는 스레드가 담당하는 세션의 개수 [참고] 설정하지 않으면 500으로 설정
X
log
level
로그 레벨로
FATAL
ERROR
WARN
INFO
X
log
rotate-time-interval
로그 파일이 아카이빙되는 주기 (단위: h)
적재 중인 로그 파일을 주기마다 아카이빙하고 새로운 로그 파일에 적재
[참고] 설정하지 않으면 24로 설정되므로 하루 주기로 로그 파일 아카이빙
X
log
rotate-file-size
로그 파일이 아카이빙되는 파일 사이즈 (단위: MB)
적재 중인 로그 파일이 해당 파일 사이즈에 도달하면 적재 중인 로그 파일을 아카이빙하고 새로운 로그 파일에 적재
[참고] 설정하지 않으면 50으로 설정되므로 적재 중인 로그 파일이 50MB에 도달하면 로그 파일 아카이빙
X
log
max-log-file-number
아카이빙되는 파일 최대 개수 (단위: 개수)
아카이빙한 파일 개수가 최대에 도달하면 가장 오래 된 로그 파일부터 삭제
[참고] 설정하지 않으면 7로 설정되므로 최대 로그 파일 개수는 7개
X
log
path
로그 파일 생성 디렉터리
[참고] 설정하지 않으면 tpmagent.jar 경로에 logs/ 로 경로 설정
X
SHIFT-JIS
JA16SJIS
JA16SJISTILDE
JA16EUC
JA16EUCTILDE
VN8VN3
GBK
WE8MSWIN1252
ZHT16HKSCS
CL8MSWIN1251
WE8ISO8859P1
EE8ISO8859P2
WE8ISO8859P9
WE8ISO8859P15
CL8KOI8R
CL8ISO8859P5
CP866
TH8TISASCII
EL8MSWIN1253
EL8ISO8859P7
AR8MSWIN1256
AR8ISO8859P6
SJISTILDE
ZHT16BIG5
ZHT16MSWIN950
GB18030
IW8ISO8859P8
EUC-TW
ENABLE_GC_LOG
TPM Agent 실행시 jvm gc log를 파일로 생성할 것인가에 대한 환경 변수, default는 false
X
JAVA_MIN_HEAP_SIZE
TPM Agent 실행시 시작 heap 크기 설정에 대한 환경 변수, default는 각 jvm 구현체마다 다르며 보통 현재 머신 메모리의 1/64 이다.
X
JAVA_MAX_HEAP_SIZE
TPM Agent 실행시 최대 heap 크기 설정에 대한 환경 변수, default는 각 jvm 구현체마다 다르며 보통 현재 머신 메모리의 1/4 이다.
X
agent-config
id
인스턴스 ID
[참고] 웹 UI에서 관제 데이터베이스 인스턴스 등록 시 입력한 INSTANCE ID 값과 동일해야 함. 잘못 입력시 잘못된 Tibero 설치 머신 현황과 세션 목록, 그리고 TSC 네트워크 구성을 모니터링하게 되므로 주의 요망.
O
agent-config
ip
SysMaster DB 서버에 접속할 수 있는 IP 주소
O
agent-config
port
export BOOT_WITH_AUTO_DOWN_CLEAN=true
export ENABLE_DEBUG=false
export ENABLE_GC_LOG=false
export JAVA_MIN_HEAP_SIZE=1000m
export JAVA_MAX_HEAP_SIZE=1000mBOOT_WITH_AUTO_DOWN_CLEAN
TPM Agent 실행시 기존에 실행중인 process가 있으면 해당 프로세스 종료 후 실행할 것인가에 대한 환경 변수, default는 true
X
ENABLE_DEBUG
TPM Agent 실행시 debug port를 열 것인 지에 대한 환경 변수, default는 false
TPM Agent가 SysMaster DB 서버의 COLLECTOR_PORT로 연결하기 위한 포트 번호
X
DEBUG
TRACE
[참고]설정하지 않으면 INFO 로 설정됨.
DEBUG 이상 설정을 할 경우 로그양이 많아져 TPM Agent 에 설정한 주기 안에 수집을 하지 못하여 데이터 누락이 발생할 수 있음. 그로 인하여 실시간 데이터 모니터링 중 데이터가 조회되지 않는 현상이 있을 수 있음. 따라서 운영 환경에서는 해당 설정을 하지 않는 것을 권고하며, 이슈 분석을 위해서만 해당 로그 레벨을 설정.
Kubernetes 환경에서 SysMaster DB를 설치하는 과정이다.
설치 파일이 준비된 디렉터리에서 아래의 명령을 수행하여 도커 이미지를 로드한다.
docker load -i sysmaster-db-{version}.tar
이때 로드된 도커 이미지 목록은 다음과 같다.
sysmaster-db-client:{version}
sysmaster-db-sdm:{version}
sysmaster-db-tibero-master:{version}
sysmaster-db-collector:{version}
sysmaster-db-analyzer:{version}
sysmaster-db-tiberoopensql-postgres:{version}
sysmaster-db-schema-registry:{version}
sysmaster-db-kafka-loggable:{version}
sysmaster-db-zookeeper-loggable:{version}
sysmaster-db-alpine-linux:{version}
로드한 도커 이미지들을 해당 환경에서 사용 중인 이미지 리포지터리로 푸시한다.
설치 디렉터리에서 kubernetes 디렉터리 안의 yaml 파일들을 통해서 8개의 디플로이먼트들에 대해 정의한다. 각 디플로이먼트에 대한 설명은 다음과 같다.
설치 디렉터리에서 kubernetes/init/configmap.yaml 파일을 열어 SysMaster DB의 설치에 필요한 계정 정보 및 보관 주기 관련 파라미터 값을 설정한다.
해당 과정에서 설정하는 파라미터에 대한 설명은 다음과 같다.
설치 디렉터리에서 kubernetes/init/service.yaml 파일을 열어 SysMaster DB의 설치에 필요한 포트 관련 파라미터 값을 설정한다. 해당 과정에서 설정하는 파라미터에 대한 설명은 다음과 같다.
설치 디렉터리에서 kubernetes/init/configmap.yaml 파일을 통해 Meta DB 및 Repository DB 파라미터 값을 확인할 수 있다. 다음은 Meta DB에 대한 파라미터 설정 예시이다.
해당 conf 파일은 기본적으로 제공되는 설정값을 사용하되, 다음에서 설명하는 파라미터는 필요 시 구동 환경에 맞게 사용자가 직접 설정해준다.
collector
관제 데이터베이스로부터 데이터를 수집하는 서버
analyzer
수집한 정보를 가공해 분석 및 저장하는 서버
metadb
UI 관련 설정 정보를 저장하는 DB 서버
repodb
관제 데이터베이스 수집 데이터를 저장하는 DB 서버
kafka
Kafka 클러스터(ZooKeeper, Broker, Schema Registry 포함)
admin
METADB_USER
Meta DB의 슈퍼 사용자 이름
sysmaster
METADB_PASSWORD
Meta DB의 슈퍼 사용자 암호
sysmaster
REPODB_USER
Repository DB의 슈퍼 사용자 이름
sysmaster
REPODB_PASSWORD
Repository DB의 슈퍼 사용자 암호
sysmaster
RETENTION_DAY
수집 정보의 보관 주기
7
LOG_RETENTION_DAY
로그 파일 보관 주기
1
LOG_FILE_SIZE
로그 파일 하나의 최대 크기
100MB
LOG_TOTAL_SIZE
모듈 별 최대 로그 저장 용량
1000MB
LOG_LEVEL
모듈 별 최대 로그 레벨
info
CONTAINER_LOG_PATH
컨테이너 내부 로그 경로 설정
/sysmaster/logs
KAFKA_MESSAGE_MAX_BYTES
카프카 메시지 사이즈 설정, 1MB ~ 2GB 범위로 설정 가능
20971520 Byte
TIME_ZONE
SysMaster DB 서버 Time-Zone 설정
Asia/Seoul
SQL_FLUSH_THRESHOLD
SQL 관련 하나의 메시지가 담을 수 있는 정보 개수 제한. SQL Plan의 경우 해당 값의 10배로 제한한다.
관제 DB 당 100개
SQL_RS_FETCH_SIZE
한 번에 관제 DB 로부터 조회하는 SQL 관련 정보 row 개수
관제 DB 당 1000개
SKIP_DB_USER_COUNT_MIGRATION_PATCH
(기설치 환경 패치 시,) 기수집 데이터 기반 Repository DB의 DB_USER_COUNT 테이블 데이터 생성 패치 생략 여부. 필요 시 아래 [참고 1]을 확인하고 설정.
true (주석 처리를 통한 미적용)
SKIP_DAILY_SEGMENT_MIGRATION_PATCH
(기설치 환경 패치 시,) 기수집 데이터 기반 Repository DB의 DAILY_SEGMENT 테이블 데이터 생성 패치 생략 여부. 필요 시 아래 [참고 1]을 확인하고 설정.
true (주석 처리를 통한 미적용)
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH
(기설치 환경 패치 시,) v8.3.0 신규 스키마 적용 테이블 대상 v8.2.1 이하 기수집 데이터 마이그레이션 생략 여부. 필요 시 아래 [참고 2]를 확인하고 설정.
true (주석 처리를 통한 미적용)
RETENTION_DAY_FOR_V8_2_1_TO_V8_3_0_MIGRATION_PATCH
(기설치 환경 패치 시,) v8.3.0에서 신규 스키마가 적용된 테이블에 대한 v8.2.1 이하 기수집 데이터 중 마이그레이션 대상 데이터 범위(일 단위 기간). 필요 시 아래 [참고 2]를 확인하고 설정.
7 (주석 처리를 통한 미적용)
SDM_HEAP_SIZE_MAX
SDM의 최대 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/4 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
SDM_HEAP_SIZE_MIN
SDM의 최소 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/64 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
ANALYZER_HEAP_SIZE_MAX
Analyzer의 최대 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/4 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
ANALYZER_HEAP_SIZE_MIN
Analyzer의 최소 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/64 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
COLLECTOR_HEAP_SIZE_MAX
Collector의 최대 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/4 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
COLLECTOR_HEAP_SIZE_MIN
Collector의 최소 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/64 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
TBM_HEAP_SIZE_MAX
TBM의 최대 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/4 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
TBM_HEAP_SIZE_MIN
TBM의 최소 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/64 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
PERFORMANCE_LOGGING
성능 관련 로그 작성 여부 [참고] 추가적인 CPU, Disk를 사용하는 것이기 때문에 Y로 설정 시 성능 저하가 발생할 수 있음.
N
LIMIT_SQL_HASH_COUNT
중복 수집 방지를 위해 메모리에 저장하는 SQL plan hash value + cost 조합의 최대 개수이며, 동시에 SQL text hash value 최대 개수
100만개
[참고] 총 약 300MB 메모리를 차지한다.
METADB_PORT
Meta DB의 접속 포트 번호
[수정 위치] metadata.name=metadb, name="metadb-port"인 ports의 nodePort 수정
25432
REPODB_PORT
Repository DB의 접속 포트 번호
[수정 위치] metadata.name=repodb, name="repodb-port"인 ports의 nodePort 수정
15432
client
사용자가 브라우저를 통해 접속하게 될 웹 서버
sdm
수집 정보를 조회하고 클라이언트와 통신하는 API 서버
tibero-master
apiVersion: v1
kind: ConfigMap
metadata:
name: config-sysmaster
namespace: sysmasterdb
data:
RETENTION_DAY: "7"
METADB_USER: sysmaster
METADB_PASSWORD: sysmaster
REPODB_USER: sysmaster
REPODB_PASSWORD: sysmaster
ADMIN_USERNAME: admin
ADMIN_PASSWORD: admin
LOG_RETENTION_DAY: "1"
LOG_FILE_SIZE: "100MB"
LOG_TOTAL_SIZE: "1000MB"
LOG_LEVEL: "info"
CONTAINER_LOG_PATH: "/sysmaster/logs"
KAFKA_MESSAGE_MAX_BYTES: "20971520"
TIME_ZONE: Asia/Seoul
SQL_FLUSH_THRESHOLD: 100
SQL_RS_FETCH_SIZE: 1000
# SKIP_DB_USER_COUNT_MIGRATION_PATCH: true
# SKIP_DAILY_SEGMENT_MIGRATION_PATCH: true
# SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH=true
# RETENTION_DAY_FOR_V8_2_1_TO_V8_3_0_MIGRATION_PATCH=7
SDM_HEAP_SIZE_MAX: ""
SDM_HEAP_SIZE_MIN: ""
ANALYZER_HEAP_SIZE_MAX: ""
ANALYZER_HEAP_SIZE_MIN: ""
COLLECTOR_HEAP_SIZE_MAX: ""
COLLECTOR_HEAP_SIZE_MIN: ""
TBM_HEAP_SIZE_MAX: ""
TBM_HEAP_SIZE_MIN: ""
PERFORMANCE_LOGGING: ""
LIMIT_SQL_HASH_COUNT: ""ADMIN_USERNAME
Admin 계정의 사용자 이름
admin
ADMIN_PASSWORD
CLIENT_PORT
UI 접속 URL의 포트 번호
[수정 위치] metadata.name=client, name="client-port"인 ports의 nodePort 수정
80
COLLECTOR_PORT
수집 모듈(TPM Agent)이 접속할 포트 번호
[수정 위치] metadata.name=collector, name="collector-port"인 ports의 nodePort 수정
[참고] 관제 DB에서 접속할 수 있도록 SysMaster 서버에서 열려 있어야 함.
apiVersion: v1
kind: ConfigMap
metadata:
name: sysmasterdb8-metadb-configmap
namespace: sysmasterdb
data:
meta.conf: |
pg_superuser: "postgres"
pg_superuser_password: "postgres"
pg_data: "/pgdata"
pg_log: "/sysmaster/logs"
pg_users:
- name: "sysmaster"
pass: "sysmaster"
role_attr_flags: LOGIN
pg_databases:
- name: metadb
owner: sysmaster
pg_max_connections: 20
pg_postgres_conf_params:
- name: "log_filename"
value: "metadb-%H%M.log"
- name: "log_timezone"
value: "Asia/Seoul"
- name: "log_min_messages"
value: "INFO"
- name: "log_rotation_age"
value: "60"
- name: "log_rotation_size"
value: "100MB"
- name: "log_truncate_on_rotation"
value: "on"pg_max_connections
Meta DB(또는 Repository DB)의 최대 커넥션 수
log_timezone
Meta DB(또는 Repository DB)의 로그 시간 Time-Zone
관제 데이터베이스에 대한 상태 확인과 Admin 기능을 수행하는 서버
Admin 계정의 암호
8292
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH 파라미터를 true로 설정(주석 제거)한 경우, 본 파라미터 설정은 무시됨.
Docker-compose 및 Podman-compose 환경에서 SysMaster DB 8.3를 설치하는 과정이다.
설치 파일이 준비된 디렉터리에서 아래의 명령을 수행하여 Docker / Podman 이미지를 로드한다.
Docker:
docker load -i sysmaster-db-{version}.tarPodman:
podman load -i sysmaster-db-{version}.tar이때 로드된 컨테이너 이미지 목록은 다음과 같다.
sysmaster-db-client:{version}
sysmaster-db-sdm:{version}
sysmaster-db-tibero-master:{version}
sysmaster-db-collector:{version}
sysmaster-db-analyzer:{version}
sysmaster-db-tiberoopensql-postgres:{version}
sysmaster-db-schema-registry:{version}
sysmaster-db-kafka-loggable:{version}
sysmaster-db-zookeeper-loggable:{version}
설치 디렉터리에서 docker-compose.yml 파일을 열어 Docker-compose / Podman-compose 환경에 생성하는 10개의 서비스들에 대해 정의한다. 각 서비스에 대한 설명은 다음과 같다.
설치 디렉터리에서 .env 파일을 열어 SysMaster DB 8.3의 설치에 필요한 파라미터 값을 설정한다.
이때 각 파라미터들은 개행으로 구분하며, 파라미터 이름과 값 사이에는 공백 없이 등호를 하나 입력한다.
해당 과정에서 설정하는 파라미터에 대한 설명은 다음과 같다.
Rootless podman 환경에서는 NGINX_RESOLVER 패러미터 설정이 별도로 필요하다. 이는 시스마스터 기동 후 개별 컨테이너가 재기동 되는 상황에서의 재연결을 위해 필요하며 sysmaster 네트워크의 gateway ip 주소를 사용한다. 해당 값은 환경 / podman 기동마다 달라질 수 있다.
아래 예시에서 NGINX_RESOLVER=10.89.0.1로 설정 후 시스마스터를 부팅하는 과정을 보여준다.
Podman bridge 네트워크 환경에서 SysmasterDB 컨테이너가 동일 호스트에 설치된 관제 DB에 호스트 IP(예: 192.168.141.12) 로 접속을 시도할 경우, 컨테이너 → 호스트 방향의 Hairpin NAT(DNAT loopback) 가 기본적으로 보장되지 않아 Connection Refused가 발생할 수 있다.
이는 동일 서버 내 구성이라도 컨테이너와 호스트가 서로 다른 네트워크 네임스페이스에 존재하기 때문에 발생하는 Podman bridge 구조적 제약이다.
예시로, 컨테이너에 접속하여 telnet 192.168.141.12 40010을 수행하면 Connection refused로 실패하고, Host Gateway 경로 적용 후 telnet host.docker.internal 40010은 정상 접속되는 것으로 확인할 수 있다.
해결을 위해 podman-compose.yml에 Host Gateway 매핑을 추가하고, 관제 DB 접속 주소를 호스트 IP → host.docker.internal 로 변경한다.
아래 예시처럼 서비스에 extra_hosts를 추가한다.
그리고 아래처럼 관제 DB IP를 host.docker.internal 로 설정하면 동일 호스트에 설치된 관제 DB를 등록 할 수 있다.
설치 디렉터리에서 meta.conf, repo.conf 파일을 통해 Meta DB 및 Repository DB 파라미터 값을 확인할 수 있다. 해당 conf 파일은 기본적으로 제공되는 설정값을 사용하되, 다음에서 설명하는 파라미터는 필요 시 구동 환경에 맞게 사용자가 직접 설정해준다.
collector
관제 데이터베이스로부터 데이터를 수집하는 서버
analyzer
수집한 정보를 가공해 분석 및 저장하는 서버
metadb
UI 관련 설정 정보를 저장하는 DB 서버
repodb
관제 데이터베이스 수집 데이터를 저장하는 DB 서버
zookeeper
Kafka Broker 서버의 상태 관리
broker
Kafka Broker 서버
schema-registry
Kafka 메시지 프로토콜 관리
Admin 계정의 사용자 이름
admin
ADMIN_PASSWORD
Admin 계정의 암호
admin
COLLECTOR_PORT
수집 모듈(TPM Agent)이 접속할 포트 번호
[참고] 관제 DB에서 접속할 수 있도록 SysMaster 서버에서 열려 있어야 함
8292
METADB_PORT
Meta DB의 접속 포트 번호
25432
METADB_USER
Meta DB의 슈퍼 사용자 이름
sysmaster
METADB_PASSWORD
Meta DB의 슈퍼 사용자 암호
sysmaster
METADB_PATH
Meta DB의 데이터 파일 경로
./meta
METADB_CONF_PATH
Meta DB의 설정 파일 경로
./meta.conf
REPODB_PORT
Repository DB의 접속 포트 번호
15432
REPODB_USER
Repository DB의 슈퍼 사용자 이름
sysmaster
REPODB_PASSWORD
Repository DB의 슈퍼 사용자 암호
sysmaster
REPODB_PATH
Repository DB의 데이터 파일 경로
./repo
REPODB_CONF_PATH
Repository DB의 설정 파일 경로
./repo.conf
RETENTION_DAY
수집 정보의 보관 주기
7
LOG_PATH
로그 생성 위치
./logs
LOG_RETENTION_DAY
로그 파일 보관 주기
1
LOG_FILE_SIZE
로그 파일 하나의 최대 크기
100MB
LOG_TOTAL_SIZE
모듈 별 최대 로그 저장 용량
1000MB
LOG_LEVEL
모듈 별 로그 레벨
info
CONTAINER_LOG_PATH
컨테이너 내부 로그 경로 설정
/sysmaster/logs
KAFKA_MESSAGE_MAX_BYTES
카프카 메시지 사이즈 설정, 1MB ~ 2GB 범위로 설정 가능
20971520 Byte
TIME_ZONE
SysMaster DB 서버 Time-Zone 설정
Asia/Seoul
SQL_FLUSH_THRESHOLD
SQL 관련 하나의 메시지가 담을 수 있는 정보 개수 제한. SQL Plan의 경우 해당 값의 10배로 제한한다.
관제 DB 당 100개
SQL_RS_FETCH_SIZE
한 번에 관제 DB 로부터 조회하는 SQL 관련 정보 row 개수
관제 DB 당 1000개
SKIP_DB_USER_COUNT_MIGRATION_PATCH
(기설치 환경 패치 시,) 기수집 데이터 기반 Repository DB의 DB_USER_COUNT 테이블 데이터 생성 패치 생략 여부. 필요 시 아래 [참고 1]을 확인하고 설정.
true (주석 처리를 통한 미적용)
SKIP_DAILY_SEGMENT_MIGRATION_PATCH
(기설치 환경 패치 시,) 기수집 데이터 기반 Repository DB의 DAILY_SEGMENT 테이블 데이터 생성 패치 생략 여부. 필요 시 아래 [참고 1]을 확인하고 설정.
true (주석 처리를 통한 미적용)
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH
(기설치 환경 패치 시,) v8.3.0 신규 스키마 적용 테이블 대상 v8.2.1 이하 기수집 데이터 마이그레이션 생략 여부. 필요 시 아래 [참고 2]를 확인하고 설정.
true (주석 처리를 통한 미적용)
RETENTION_DAY_FOR_V8_2_1_TO_V8_3_0_MIGRATION_PATCH
(기설치 환경 패치 시,) v8.3.0에서 신규 스키마가 적용된 테이블에 대한 v8.2.1 이하 기수집 데이터 중 마이그레이션 대상 데이터 범위(일 단위 기간). 필요 시 아래 [참고 2]를 확인하고 설정.
7 (주석 처리를 통한 미적용)
SDM_HEAP_SIZE_MAX
SDM의 최대 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/4 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
SDM_HEAP_SIZE_MIN
SDM의 최소 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/64 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
ANALYZER_HEAP_SIZE_MAX
Analyzer의 최대 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/4 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
ANALYZER_HEAP_SIZE_MIN
Analyzer의 최소 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/64 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
COLLECTOR_HEAP_SIZE_MAX
Collector의 최대 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/4 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
COLLECTOR_HEAP_SIZE_MIN
Collector의 최소 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/64 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
TBM_HEAP_SIZE_MAX
TBM의 최대 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/4 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
TBM_HEAP_SIZE_MIN
TBM의 최소 힙 크기
현재 컨테이너 전체 메모리(free 명령어의 total mem 참고)의 1/64 이다.
[참고] 현재 docker 기본 이미지는 openjdk:17-alpine 이다.
PERFORMANCE_LOGGING
성능 관련 로그 작성 여부 [참고] 추가적인 CPU, Disk를 사용하는 것이기 때문에 Y로 설정 시 성능 저하가 발생할 수 있음.
N
LIMIT_SQL_HASH_COUNT
중복 수집 방지를 위해 메모리에 저장하는 SQL plan hash value + cost 조합의 최대 개수이며, 동시에 SQL text hash value 최대 개수
100만개 [참고] 총 약 <등록된 인스턴스 개수> * 300MB 메모리를 차지한다.
NGINX_RESOLVER
Podman 환경 전용 설정 NGINX에서 DNS 이름을 해석하기 위해, Sysmaster 내부 DNS 네트워크의 게이트웨이 주소를 지정. 이설정은 Podman 환경에서만 필요하며, Docker 환경 등 다른 런타임에서는 별도의 설정이 요구되지 않습니다.
podman network inspect script_sysmaster 로 확인 가능.
log_timezone
Meta DB(또는 Repository DB)의 로그 시간 Time-Zone
client
사용자가 브라우저를 통해 접속하게 될 웹 서버
sdm
수집 정보를 조회하고 클라이언트와 통신하는 API 서버
tibero-master
CLIENT_PORT=80
ADMIN_USERNAME=admin
ADMIN_PASSWORD=admin
COLLECTOR_PORT=8292
METADB_PORT=25432
METADB_USER=sysmaster
METADB_PASSWORD=sysmaster
METADB_PATH=./meta
METADB_CONF_PATH=./meta.conf
REPODB_PORT=15432
REPODB_USER=sysmaster
REPODB_PASSWORD=sysmaster
REPODB_PATH=./repo
REPODB_CONF_PATH=./repo.conf
RETENTION_DAY=7
LOG_PATH=./logs
LOG_RETENTION_DAY=1
LOG_FILE_SIZE=100MB
LOG_TOTAL_SIZE=1000MB
LOG_LEVEL=info
CONTAINER_LOG_PATH=/sysmaster/logs
KAFKA_MESSAGE_MAX_BYTES=20971520
TIME_ZONE=Asia/Seoul
SQL_FLUSH_THRESHOLD=100
SQL_RS_FETCH_SIZE=1000
# SKIP_DB_USER_COUNT_MIGRATION_PATCH=true
# SKIP_DAILY_SEGMENT_MIGRATION_PATCH=true
# SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH=true
# RETENTION_DAY_FOR_V8_2_1_TO_V8_3_0_MIGRATION_PATCH=7
SDM_HEAP_SIZE_MAX=
SDM_HEAP_SIZE_MIN=
ANALYZER_HEAP_SIZE_MAX=
ANALYZER_HEAP_SIZE_MIN=
COLLECTOR_HEAP_SIZE_MAX=
COLLECTOR_HEAP_SIZE_MIN=
TBM_HEAP_SIZE_MAX=
TBM_HEAP_SIZE_MIN=
PERFORMANCE_LOGGING=
LIMIT_SQL_HASH_COUNT=
# NGINX_RESOLVER=127.0.0.11 CLIENT_PORT
UI 접속 URL의 포트 번호
80
[tibero@smdb-podman ~]$ podman compose up --no-start
[tibero@smdb-podman ~]$ podman network inspect script_sysmaster
[
{
"name": "script_sysmaster",
"id": "e014d8811e9b51f417d578358ab41e2624a465d9026c7916f9ba7e4ce382f699",
"driver": "bridge",
"network_interface": "cni-podman1",
"created": "2025-08-04T22:55:11.345378476-04:00",
"subnets": [
{
"subnet": "10.89.0.0/24",
"gateway": "10.89.0.1" /// -> 이 주소를 사용.
}
],
"ipv6_enabled": false,
"internal": false,
"dns_enabled": true,
"labels": {
"com.docker.compose.project": "script",
"io.podman.compose.project": "script"
},
"ipam_options": {
"driver": "host-local"
}
}
]
/// .env 파일에 패러미터 설정하기
[tibero@smdb-podman ~]$ podman compose up -dtibero-master:
image: sysmaster-db-tibero-master:8.3.4
container_name: tibero-master
hostname: tibero-master
environment:
<<: *common-env
# (기타 환경변수 생략)
networks:
sysmaster:
aliases:
- tibero-master
restart: on-failure
# 이 부분 추가
extra_hosts:
- "host.docker.internal:host-gateway"pg_max_connections
Meta DB(또는 Repository DB)의 최대 커넥션 수
pg_owner_id
해당 DB 데이터 디렉토리 접근 권한 설정을 위한 Host OS의 사용자 ID(uid). 호스트 머신의 특정 유저에서 컨테이너 DB 디렉토리로 직접 접근하고 싶을 경우 해당 유저의 사용자 ID로 설정한다.
pg_group_id
관제 데이터베이스에 대한 상태 확인과 Admin 기능을 수행하는 서버
ADMIN_USERNAME
해당 DB 데이터 디렉토리 접근 권한 설정을 위한 Host OS의 사용자 그룹 ID(gid). 호스트 머신의 특정 유저에서 컨테이너 DB 디렉토리로 직접 접근하고 싶을 경우 해당 유저의 그룹 ID로 설정한다.
SKIP_V8_2_1_TO_V8_3_0_MIGRATION_PATCH 파라미터를 true로 설정(주석 제거)한 경우, 본 파라미터 설정은 무시됨.