Admin

PostgreSQL을 위한 일반 DBA 작업

Qhtlr 2020. 9. 2. 08:47

PostgreSQL을 위한 일반 DBA 작업

이번 단원에서는 PostgreSQL 데이터베이스 엔진을 실행하는 DB 인스턴스의 몇 가지 공통 DBA 작업에 대한 Amazon RDS 구현에 대해 설명합니다. 관리형 서비스 환경을 제공하기 위해 Amazon RDS는 DB 인스턴스에 대해 shell 액세스를 제공하지 않으며, 고급 권한을 필요로 하는 특정 시스템 절차와 테이블에 대한 액세스를 제한합니다.

Amazon RDS의 PostgreSQL 로그 파일 작업 방법에 대한 자세한 내용은 PostgreSQL 데이터베이스 로그 파일 단원을 참조하십시오.

주제

역할 생성

DB 인스턴스를 생성할 때 마스터 사용자 시스템 계정은 rds_superuser 역할에 할당됩니다. rds_superuser 역할은 PostgreSQL 수퍼유저 역할(로컬 인스턴스에 사용자 정의로 명명된 postgres)과 마찬가지로 사전에 정의된 Amazon RDS 역할이지만 일부 제한 사항이 있습니다. PostgreSQL 수퍼유저 역할과 마찬가지로 rds_superuser 역할에는 DB 인스턴스에 대한 최대의 권한이 있습니다. 사용자에게 DB 인스턴스에 대한 최대의 액세스 권한이 필요하지 않다면 사용자에게 이 역할을 할당하면 안 됩니다.

rds_superuser 역할은 다음을 수행할 수 있습니다.

Amazon RDS와 함께 사용할 수 있는 확장 기능을 추가합니다. 자세한 내용은 지원되는 PostgreSQL 기능 및 PostgreSQL 문서를 참조하십시오.
테이블스페이스 생성 및 삭제를 포함한 테이블스페이스 관리. 자세한 내용은 PostgreSQL 문서에서 테이블스페이스 단원을 참조하십시오.
pg_stat_activity 명령을 사용하여 rds_superuser 역할이 할당되지 않은 모든 사용자를 보고, pg_terminate_backend 및 pg_cancel_backend 명령을 사용하여 연결 중단
rds_superuser 역할이 아닌 모든 역할에 대해 rds_replication 역할을 부여하고 취소합니다. 자세한 내용은 PostgreSQL 문서에서 GRANT 단원을 참조하십시오.

다음은 사용자를 생성한 후 사용자에게 rds_superuser 역할을 부여하는 방법을 나타낸 예제입니다. 여기서는 rds_superuser 같은 사용자 정의 역할을 부여해야 합니다.

create role testuser with password 'testuser' login; CREATE ROLE grant rds_superuser to testuser; GRANT ROLE

PostgreSQL 데이터베이스 액세스 관리

PostgreSQL용 Amazon RDS에서 어느 사용자가 어느 데이터베이스에 연결할 권한이 있는지 관리할 수 있습니다. 다른 PostgreSQL 환경에서 pg_hba.conf 파일을 수정하여 이러한 관리를 수행하는 경우도 있습니다. Amazon RDS에서 데이터베이스 권한을 대신 사용할 수 있습니다.

PostgreSQL의 새 데이터베이스는 항상 기본 권한 세트를 사용하여 생성됩니다. 기본 권한을 사용하면 PUBLIC(모든 사용자)이 데이터베이스에 연결하고 연결된 동안 임시 테이블을 생성할 수 있습니다.

Amazon RDS의 주어진 데이터베이스에 연결할 수 있는 사용자를 제어하려면 먼저 기본 PUBLIC 권한을 취소합니다. 그런 다음 권한을 다시 세부적으로 허용합니다. 다음 예제 코드에서는 작업 방법을 보여줍니다.

psql> revoke all on database <database-name> from public; psql> grant connect, temporary on database <database-name> to <user/role name>;

PostgreSQL 데이터베이스의 권한에 대한 자세한 내용은 PostgreSQL 설명서에서 GRANT 명령을 참조하십시오.

PostgreSQL 파라미터 작업

postgresql.conf 파일에서 로컬 PostgreSQL 인스턴스의 PostgreSQL 파라미터를 설정하면 DB 인스턴스의 DB 파라미터 그룹에 유지됩니다. 기본 파라미터 그룹을 사용해 DB 인스턴스를 생성하면 파라미터 설정은 default.postgres9.6이라는 이름의 파라미터 그룹에 저장됩니다.

DB 인스턴스를 생성하면 연동되어 있는 DB 파라미터 그룹의 파라미터가 로드됩니다. 여기서 파라미터 값을 변경할 수 있습니다. 또한 변경할 수 있는 보안 권한이 있는 경우에는 ALTER DATABASE, ALTER ROLE 및 SET 명령을 사용해서도 파라미터 값 변경이 가능합니다. 호스트에 대한 액세스 권한이 없기 때문에 명령줄 postgres 명령 또는 env PGOPTIONS 명령은 사용할 수 없습니다.

PostgreSQL 파라미터 설정은 경우에 따라 추적이 어렵기도 합니다. 다음은 현재 파라미터 설정과 기본 값을 표시하는 명령입니다.

select name, setting, boot_val, reset_val, unit from pg_settings order by name;

출력 값에 대한 자세한 설명은 PostgreSQL 문서의 pg_settings 항목을 참조하십시오.

max_connections 또는 shared_buffers의 메모리를 너무 크게 설정하면 PostgreSQL 인스턴스가 시작되지 않습니다. 익숙하지 않은 단위를 사용하는 파라미터도 있습니다. 예를 들어 shared_buffers는 서버에서 사용하는 8KB 공유 메모리 버퍼의 수치를 설정합니다.

다음은 인스턴스를 시작하려고 하지만 잘못된 파라미터 설정으로 인해 시작되지 않을 때 postgres.log 파일로 출력되는 오류입니다.

2013-09-18 21:13:15 UTC::@:[8097]:FATAL: could not map anonymous shared memory: Cannot allocate memory 2013-09-18 21:13:15 UTC::@:[8097]:HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space. To reduce the request size (currently 3514134274048 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

PostgreSQL 파라미터는 정적과 동적, 두 가지 유형이 있습니다. 정적 파라미터를 적용하려면 DB 인스턴스를 재부팅해야 합니다. 동적 파라미터는 바로 적용됩니다. 다음 표는 PostgreSQL DB 인스턴스에서 변경할 수 있는 파라미터와 각 파라미터 유형을 나타냅니다.

파라미터 이름적용 유형설명

application_name	동적	애플리케이션 이름이 통계 및 로그에 표시되도록 설정합니다.
array_nulls	동적	어레이의 NULL 요소 입력을 활성화합니다.
authentication_timeout	동적	클라이언트 인증 완료를 위한 최대 허용 시간을 설정합니다.
autovacuum	동적	autovacuum 서브프로세스를 시작합니다.
autovacuum_analyze_scale_factor	동적	분석 전 삽입, 업데이트 또는 삭제되는 튜플 수를 reltuples 분수 값으로 지정합니다.
autovacuum_analyze_threshold	동적	분석 전 삽입, 업데이트 또는 삭제되는 튜플의 최소 수를 지정합니다.
autovacuum_naptime	동적	autovacuum 실행 간 절전 시간을 지정합니다.
autovacuum_vacuum_cost_delay	동적	autovacuum에서 vacuum 코스트 지연 시간(밀리초)을 지정합니다.
autovacuum_vacuum_cost_limit	동적	autovacuum에서 지연 시간 이전에 이용 가능한 vacuum 코스트 값을 지정합니다.
autovacuum_vacuum_scale_factor	동적	vacuum 전 업데이트 또는 삭제되는 튜플 수를 reltuples 분수 값으로 지정합니다.
autovacuum_vacuum_threshold	동적	vacuum 전 업데이트 또는 삭제되는 튜플의 최소 수를 지정합니다.
backslash_quote	동적	문자열 리터럴에서 백슬래시(\)의 허용 여부를 설정합니다.
bgwriter_delay	동적	라운드 사이에 백그라운드 라이터의 절전 시간을 지정합니다.
bgwriter_lru_maxpages	동적	백그라운드 라이터가 라운드마다 LRU 페이지를 작성할 최대 수를 지정합니다.
bgwriter_lru_multiplier	동적	라운드마다 해제할 평균 버퍼 사용량의 배수를 지정합니다.
bytea_output	동적	바이트의 출력 형식을 설정합니다.
check_function_bodies	동적	CREATE FUNCTION 도중 함수 본문을 검사합니다.
checkpoint_completion_target	동적	체크포인트 도중 변경된 버퍼 플러시에 사용된 시간으로 체크포인트 간격의 분수 값입니다.
checkpoint_segments	동적	로그 세그먼트에서 자동 write-ahead log(WAL) 체크포인트의 최대 간격을 설정합니다.
checkpoint_timeout	동적	자동 WAL 체크포인트 사이의 최대 시간을 설정합니다.
checkpoint_warning	동적	체크포인트 세그먼트가 이 파라미터 값보다 더 빨리 채워지는 경우 경고를 활성화합니다.
client_encoding	동적	클라이언트 문자 세트 인코딩을 설정합니다.
client_min_messages	동적	클라이언트에게 보여지는 메시지 수준을 설정합니다.
commit_delay	동적	트랜잭션 커밋부터 디스크에 대한 WAL 플러시까지 지연 시간(밀리초)을 설정합니다.
commit_siblings	동적	commit_delay 실행 전에 동시에 열려 있는 트랜잭션 최소 개수를 설정합니다.
constraint_exclusion	동적	planner가 제약 조건을 사용하여 쿼리를 최적화하도록 활성화합니다.
cpu_index_tuple_cost	동적	인덱스 스캔 중 각 인덱스 항목을 처리하는 데 따른 planner의 예상 코스트를 설정합니다.
cpu_operator_cost	동적	각 연산자 또는 함수 호출을 처리하는 데 따른 planner의 예상 코스트를 설정합니다.
cpu_tuple_cost	동적	각 튜플(행)을 처리하는 데 따른 planner의 예상 코스트를 설정합니다.
cursor_tuple_fraction	동적	planner가 예상하는 검색할 커서 행의 분수 값을 설정합니다.
datestyle	동적	날짜와 시간 값에 대한 표시 형식을 설정합니다.
deadlock_timeout	동적	교착 상태 여부를 확인하기 이전 잠금 대기 시간을 설정합니다.
debug_pretty_print	동적	구문과 실행 계획 트리를 들여쓰기 하여 표시합니다.
debug_print_parse	동적	각 쿼리의 구문 분석 트리를 기록합니다.
debug_print_plan	동적	각 쿼리의 실행 계획을 기록합니다.
debug_print_rewritten	동적	각 쿼리에서 재작성된 구문 분석 트리를 기록합니다.
default_statistics_target	동적	기본 통계 대상을 설정합니다.
default_tablespace	동적	테이블과 인덱스를 생성할 기본 테이블스페이스를 설정합니다.
default_transaction_deferrable	동적	새로운 트랜잭션의 기본 deferrable 상태를 설정합니다.
default_transaction_isolation	동적	새로운 트랜잭션마다 트랜잭션 격리 수준을 설정합니다.
default_transaction_read_only	동적	새로운 트랜잭션의 기본 읽기 전용 상태를 설정합니다.
default_with_oids	동적	새로운 테이블을 생성할 때 OID가 기본적으로 포함됩니다.
effective_cache_size	동적	디스크 캐시 크기에 대한 planner의 가정을 설정합니다.
effective_io_concurrency	동적	디스크 하위 시스템에서 효율적으로 동시에 처리할 수 있는 요청 수를 지정합니다.
enable_bitmapscan	동적	planner가 비트맵 스캔 계획을 사용할 수 있도록 활성화합니다.
enable_hashagg	동적	planner가 해시된 집계 계획을 사용할 수 있도록 활성화합니다.
enable_hashjoin	동적	planner가 해시 조인 계획을 사용할 수 있도록 활성화합니다.
enable_indexscan	동적	planner가 인덱스 스캔 계획을 사용할 수 있도록 활성화합니다.
enable_material	동적	planner가 구체화를 사용할 수 있도록 활성화합니다.
enable_mergejoin	동적	planner가 병합 조인 계획을 사용할 수 있도록 활성화합니다.
enable_nestloop	동적	planner가 중첩 루프 조인 계획을 사용할 수 있도록 활성화합니다.
enable_seqscan	동적	planner가 순차적 스캔 계획을 사용할 수 있도록 활성화합니다.
enable_sort	동적	planner가 명시적 정렬 단계를 사용할 수 있도록 활성화합니다.
enable_tidscan	동적	planner가 TID 스캔 계획을 사용할 수 있도록 활성화합니다.
escape_string_warning	동적	일반 문자열 리터럴의 백슬래시(\) 이스케이프에 대해 경고합니다.
extra_float_digits	동적	부동 소수점으로 표시할 자릿수를 설정합니다.
from_collapse_limit	동적	서브 쿼리가 축소되지 않는 FROM 목록 크기를 설정합니다.
fsync	동적	업데이트를 디스크와 강제로 동기화합니다.
full_page_writes	동적	체크포인트 후 최초 변경 시 전체 페이지를 WAL에 기입합니다.
geqo	동적	유전적 쿼리 최적화를 활성화합니다.
geqo_effort	동적	GEQO: 다른 GEQO 파라미터의 기본값을 설정하는 데 사용됩니다.
geqo_generations	동적	GEQO: 알고리즘의 반복 횟수입니다.
geqo_pool_size	동적	GEQO: 모집단의 개체 수입니다.
geqo_seed	동적	GEQO: 무작위 경로 선택을 위한 시드(seed)를 지정합니다.
geqo_selection_bias	동적	GEQO: 모집단 내 선택적 압력을 지정합니다.
geqo_threshold	동적	GEQO가 사용되는 FROM 항목의 임계값을 설정합니다.
gin_fuzzy_search_limit	동적	정확한 GIN 기준 검색에 허용되는 최대 결과 수를 설정합니다.
hot_standby_feedback	동적	핫 스탠바이가 피드백 메시지를 기본 또는 업스트림 스탠바이로 전송하는지 여부를 결정합니다.
intervalstyle	동적	간격 값에 대한 표시 형식을 설정합니다.
join_collapse_limit	동적	JOIN 구문이 결합되지 않는 FROM 목록 크기를 설정합니다.
lc_messages	동적	메시지 표시 언어를 설정합니다.
lc_monetary	동적	통화 금액의 형식으로 사용할 로캘을 설정합니다.
lc_numeric	동적	숫자의 형식으로 사용할 로캘을 설정합니다.
lc_time	동적	날짜와 시간 값의 형식으로 사용할 로캘을 설정합니다.
log_autovacuum_min_duration	동적	autovacuum 작업이 기록되는 최소 실행 시간을 설정합니다.
log_checkpoints	동적	각 체크포인트를 기록합니다.
log_connections	동적	성공한 연결을 모두 기록합니다.
log_disconnections	동적	지속 시간을 포함해 세션 종료를 기록합니다.
log_duration	동적	완료된 개별 SQL 문의 지속 시간을 기록합니다.
log_error_verbosity	동적	기록된 메시지의 세부 사항을 설정합니다.
log_executor_stats	동적	실행기 성능 통계를 서버 로그에 기록합니다.
log_filename	동적	로그 파일의 이름 패턴을 설정합니다.
log_hostname	동적	연결 로그에 호스트 이름을 기록합니다.
log_lock_waits	동적	오랜 잠금 대기 시간을 기록합니다.
log_min_duration_statement	동적	문이 기록되는 최소 실행 시간을 설정합니다.
log_min_error_statement	동적	이 수준 이상으로 오류 원인이 되는 모든 문을 기록합니다.
log_min_messages	동적	기록되는 메시지 수준을 설정합니다.
log_parser_stats	동적	구문 분석기 성능 통계를 서버 로그에 기록합니다.
log_planner_stats	동적	planner 성능 통계를 서버 로그에 기록합니다.
log_rotation_age	동적	N분 후에 자동 로그 파일 로테이션이 일어납니다.
log_rotation_size	동적	N킬로바이트 후에 자동 로그 파일 로테이션이 일어납니다.
log_statement	동적	기록할 문 유형을 설정합니다.
log_statement_stats	동적	누적 성능 통계를 서버 로그에 기록합니다.
log_temp_files	동적	이 킬로바이트 수치보다 큰 임시 파일의 사용을 기록합니다.
maintenance_work_mem	동적	유지 관리 작업에 사용할 최대 메모리를 설정합니다.
max_stack_depth	동적	최대 스택 깊이(KB)를 설정합니다.
max_standby_archive_delay	동적	핫 스탠바이 서버가 아카이브 WAL 데이터를 처리할 때 쿼리 취소까지 걸리는 최대 지연 시간을 설정합니다.
max_standby_streaming_delay	동적	핫 스탠바이 서버가 스트리밍 WAL 데이터를 처리할 때 쿼리 취소까지 걸리는 최대 지연 시간을 설정합니다.
max_wal_size	정적	검사 점을 트리거하는 WAL 크기를 설정합니다. PostgreSQL 버전 9.6 이하의 경우 max_wal_size는 16MB 단위입니다. PostgreSQL 버전 10 이상의 경우 max_wal_size는 1MB 단위입니다.
min_wal_size	정적	WAL을 축소할 최소 크기를 설정합니다. PostgreSQL 버전 9.6 이하의 경우 min_wal_size는 16MB 단위입니다. PostgreSQL 버전 10 이상의 경우 min_wal_size는 1MB 단위입니다.
quote_all_identifiers	동적	SQL 조각 생성 시 모든 식별자에 인용 부호(")를 추가합니다.
random_page_cost	동적	비순차적으로 가져온 디스크 페이지에 대한 planner의 예상 코스트를 설정합니다.
rds.adaptive_autovacuum	동적	트랜잭션 ID 임계값이 초과될 때마다 autovacuum 파라미터를 자동으로 조정합니다.
rds.log_retention_period	동적	Amazon RDS가 N분보다 오래된 PostgreSQL 로그를 삭제하도록 로그 보존을 설정합니다.
rds.restrict_password_commands	정적	암호를 관리할 수 있는 사람을 rds_password 역할이 있는 사용자로 제한합니다. 암호 제한을 활성화하려면 이 파라미터를 1로 설정합니다. 기본값은 0입니다.
search_path	동적	스키마로 한정되지 않은 이름의 스키마 검색 순서를 설정합니다.
seq_page_cost	동적	순차적으로 가져온 디스크 페이지에 대한 planner의 예상 코스트를 설정합니다.
session_replication_role	동적	트리거 및 다시 쓰기 규칙에 대한 세션 동작을 설정합니다.
sql_inheritance	동적	다양한 명령에서 서브테이블이 기본적으로 상속됩니다.
ssl_renegotiation_limit	동적	암호화 키를 재협상하기 전에 전송 및 수신할 트래픽 양을 설정합니다.
standard_conforming_strings	동적	... 문자열에서 백슬래시가 리터럴로 처리됩니다.
statement_timeout	동적	모든 문에 허용되는 최대 지속 시간을 설정합니다.
synchronize_seqscans	동적	동기 방식의 순차적 스캔을 활성화합니다.
synchronous_commit	동적	현재 트랜잭션 동기화 수준을 설정합니다.
tcp_keepalives_count	동적	TCP keepalive의 최대 재전송 횟수를 지정합니다.
tcp_keepalives_idle	동적	TCP keepalive의 실행 주기를 지정합니다.
tcp_keepalives_interval	동적	TCP keepalive의 재전송 주기를 지정합니다.
temp_buffers	동적	각 세션에서 사용하는 임시 버퍼의 최대 수를 설정합니다.
temp_tablespaces	동적	임시 테이블 및 정렬 파일에 사용할 테이블스페이스를 설정합니다.
timezone	동적	타임스탬프를 표시 및 해석할 시간대를 설정합니다.
track_activities	동적	명령 실행에 대한 정보를 수집합니다.
track_counts	동적	데이터베이스 작업에 관한 통계를 수집합니다.
track_functions	동적	데이터베이스 작업에 관한 함수 수준 통계를 수집합니다.
track_io_timing	동적	데이터베이스 I/O 작업에 관한 시간 통계를 수집합니다.
transaction_deferrable	동적	잠재적 직렬화 오류 없이 실행될 때까지 직렬화가 가능한 읽기 전용 트랜잭션의 지연 여부를 결정합니다.
transaction_isolation	동적	현재 트랜잭션 격리 수준을 설정합니다.
transaction_read_only	동적	현재 트랜잭션의 읽기 전용 상태를 설정합니다.
transform_null_equals	동적	expr=NULL을 expr IS NULL로 처리합니다.
update_process_title	동적	프로세스 제목을 업데이트하여 활성 SQL 명령을 표시합니다.
vacuum_cost_delay	동적	vacuum 코스트 지연 시간(밀리초)을 지정합니다.
vacuum_cost_limit	동적	지연 시간 이전에 이용 가능한 vacuum 코스트 값을 지정합니다.
vacuum_cost_page_dirty	동적	vacuum으로 페이지 변경 시 부과되는 vacuum 코스트를 지정합니다.
vacuum_cost_page_hit	동적	버퍼 캐시에서 발견되는 페이지에 대한 vacuum 코스트를 지정합니다.
vacuum_cost_page_miss	동적	버퍼 캐시에서 발견되지 않는 페이지에 대한 vacuum 코스트를 지정합니다.
vacuum_defer_cleanup_age	동적	vacuum 및 hot cleanup을 연기해야 하는 트랜잭션 수를 지정합니다(있는 경우).
vacuum_freeze_min_age	동적	vacuum에서 테이블 행을 동결해야 하는 최소 기간을 지정합니다.
vacuum_freeze_table_age	동적	vacuum에서 전체 테이블을 스캔하여 튜플을 동결해야 하는 기간을 지정합니다.
wal_writer_delay	동적	WAL 플러시 사이에 WAL 작성기의 절전 시간을 지정합니다.
work_mem	동적	쿼리 작업 공간에 사용할 최대 메모리를 설정합니다.
xmlbinary	동적	XML에서 바이너리 값의 인코딩 방식을 설정합니다.
xmloption	동적	암시적 구문 분석 및 직렬화 작업에서 XML 데이터를 문서 또는 내용 조각으로 간주할지 여부를 설정합니다.
autovacuum_freeze_max_age	정적	트랜잭션 ID 랩어라운드를 방지하기 위한 테이블의 autovacuum 기간을 지정합니다.
autovacuum_max_workers	정적	autovacuum 작업자 프로세스를 동시에 실행할 수 있는 최대 수를 설정합니다.
max_connections	정적	동시에 접속할 수 있는 최대 수를 설정합니다.
max_files_per_process	정적	서버 프로세스마다 파일을 동시에 열 수 있는 최대 수를 설정합니다.
max_locks_per_transaction	정적	하나의 트랜잭션에서 사용할 수 있는 최대 잠금 횟수를 설정합니다.
max_pred_locks_per_transaction	정적	하나의 트랜잭션에서 사용할 수 있는 최대 술어(predicate) 잠금 횟수를 설정합니다.
max_prepared_transactions	정적	트랜잭션을 동시에 준비할 수 있는 최대 수를 설정합니다.
shared_buffers	정적	서버에서 사용할 공유 메모리 버퍼의 수를 설정합니다.
ssl	정적	SSL 연결을 활성화합니다.
temp_file_limit	정적	임시 파일이 증가할 수 있는 최대 크기(KB)를 설정합니다.
track_activity_query_size	정적	pg_stat_activity.current_query에 예약되는 크기(바이트)를 설정합니다.
wal_buffers	정적	WAL 기능을 위해 공유 메모리에서 사용할 디스크 페이지 버퍼 수를 설정합니다.

Amazon RDS는 모든 파라미터에서 기본 PostgreSQL 단위를 사용합니다. 다음 표는 PostgreSQL 기본 단위 및 각 파라미터에 대한 값을 나타냅니다.

파라미터 이름단위

effective_cache_size	8KB
segment_size	8KB
shared_buffers	8KB
temp_buffers	8KB
wal_buffers	8KB
wal_segment_size	8KB
log_rotation_size	KB
log_temp_files	KB
maintenance_work_mem	KB
max_stack_depth	KB
ssl_renegotiation_limit	KB
temp_file_limit	KB
work_mem	KB
log_rotation_age	minutes
autovacuum_vacuum_cost_delay	ms
bgwriter_delay	ms
deadlock_timeout	ms
lock_timeout	ms
log_autovacuum_min_duration	ms
log_min_duration_statement	ms
max_standby_archive_delay	ms
max_standby_streaming_delay	ms
statement_timeout	ms
vacuum_cost_delay	ms
wal_receiver_timeout	ms
wal_sender_timeout	ms
wal_writer_delay	ms
archive_timeout	s
authentication_timeout	s
autovacuum_naptime	s
checkpoint_timeout	s
checkpoint_warning	s
post_auth_delay	s
pre_auth_delay	s
tcp_keepalives_idle	s
tcp_keepalives_interval	s
wal_receiver_status_interval	s

Amazon RDS에서 PostgreSQL Autovacuum 사용

PostgreSQL 데이터베이스용 autovacuum 기능을 사용하여 PostgreSQL DB 인스턴스의 상태를 유지 관리하는 것이 좋습니다. Autovacuum은 VACUUM 및 ANALYZE 명령의 실행을 자동화합니다. Autovacuum은 삽입되고 업데이트되거나 삭제된 튜플 수가 많은 테이블이 있는지 확인합니다. 그런 다음 Autovacuum은 PostgreSQL 데이터베이스에서 폐기된 데이터 또는 튜플을 제거하여 스토리지를 회수합니다.

Autovacuum 은 모든 새로운 Amazon RDS PostgreSQL DB 인스턴스에 대해 기본적으로 활성화되며, 관련 Autovacuum 구성 파라미터는 적절히 기본적으로 설정됩니다. 기본값이 일반적으로 설정되어 있으므로 특정 워크로드에 맞게 파라미터를 조정하면 유용하게 사용할 수 있습니다. 다음 단원에는 필요한 autovacuum 조정을 수행하는 데 도움이 되는 정보가 나와 있습니다.

주제

Autovacuum에 메모리 할당

autovacuum 성능에 영향을 미치는 가장 중요한 파라미터 중 하나는 maintenance_work_mem 파라미터입니다. 이 파라미터는 autovacuum에서 데이터베이스 테이블을 스캔하고 vacuum되는 모든 행 ID를 보관하는 데 사용할 수 있는 메모리를 얼만큼 할당할지를 결정합니다. maintenance_work_mem 파라미터 값을 너무 낮게 설정하면 vacuum 프로세스가 테이블을 여러 번 스캔해야 작업이 완료될 수 있습니다. 이러한 다중 스캔은 성능에 부정적인 영향을 줄 수 있습니다.

maintenance_work_mem 파라미터 값을 결정하는 계산을 할 때 다음 두 가지 사항을 유의하십시오.

이 파라미터의 기본 단위는 킬로바이트(KB)입니다.
maintenance_work_mem 파라미터는 autovacuum_max_workers 파라미터와 함께 작동합니다. 작은 테이블이 많이 있는 경우에는 autovacuum_max_workers를 더 많이 할당하고 maintenance_work_mem을 더 적게 할당합니다. 큰 테이블이 많이 있는 경우(100GB 이상)에는 메모리를 더 많이 할당하고 작업자 프로세스를 더 적게 할당합니다. 가장 큰 테이블에서 성공적으로 작업을 수행하려면 충분한 메모리를 할당해 두어야 합니다. 각각의 autovacuum_max_workers는 할당된 메모리를 사용할 수 있습니다. 따라서 작업자 프로세스와 메모리를 합한 양이 할당하려는 전체 메모리 양과 같도록 해야 합니다.

일반적으로 큰 호스트의 경우 maintenance_work_mem 파라미터를 1~2기가바이트 사이(1,048,576 ~ 2,097,152KB) 값으로 설정합니다. 매우 큰 호스트의 경우 파라미터를 2~4기가바이트 사이(2,097,152 ~ 4,194,304KB) 값으로 설정합니다. 이 파라미터에 설정하는 값은 워크로드에 따라 달라져야 합니다. Amazon RDS는 이 파라미터의 기본값이 다음과 같이 계산된 킬로바이트 값이 되도록 업데이트했습니다.

GREATEST({DBInstanceClassMemory/63963136*1024},65536)를 선택하십시오.

트랜잭션 ID 랩어라운드의 가능성 감소

경우에 따라 Autovacuum과 관련된 파라미터 그룹 설정이 트랜잭션 ID 랩어라운드를 방지하기에 충분히 공격적이지 않을 수 있습니다. 이를 해결하기 위해 PostgreSQL용 Amazon RDS는 Autovacuum 파라미터 값을 자동으로 조정하는 메커니즘을 제공합니다. 적응형 autovacuum 파라미터 튜닝은 RDS for PostgreSQL의 기능입니다. TransactionID wraparound에 대한 자세한 설명은 PostgreSQL 설명서에 나와 있습니다.

동적 파라미터 rds.adaptive_autovacuum이 ON으로 설정된 RDS PostgreSQL 인스턴스의 경우 적응형 autovacuum 파라미터 튜닝이 기본적으로 활성화됩니다. 이 설정을 항상 활성화해 놓는 것이 좋습니다. 그러나 적응형 Autovacuum 파라미터 튜닝을 끄려면 rds.adaptive_autovacuum 파라미터를 0 또는 OFF로 설정합니다.

RDS가 autovacuum 파라미터를 조정하더라도 트랜잭션 ID 랩어라운드는 계속 가능합니다. 트랜잭션 ID 랩어라운드에 대한 Amazon CloudWatch 경보를 구현하는 것이 좋습니다. 자세한 내용은 Amazon RDS에서 블로그 게시물 PostgreSQL용 Amazon RDS의 트랜잭션 ID 랩어라운드용 조기 경고 시스템 구현을 참조하십시오.

적응형 Autovacuum 파라미터 튜닝을 활성화한 경우 RDS는 CloudWatch 지표 MaximumUsedTransactionIDs가 autovacuum_freeze_max_age 파라미터 값 또는 500,000,000 중 큰 값에 도달하면 Autovacuum 파라미터를 조정하기 시작합니다.

테이블이 계속 트랜잭션 ID 랩어라운드 방향으로 향하면 RDS는 Autovacuum의 파라미터를 계속 조정합니다. 이러한 각각의 조정은 랩어라운드를 피하기 위해 Autovacuum에 더 많은 리소스를 할애합니다. RDS는 다음 Autovacuum 관련 파라미터를 업데이트합니다.

RDS는 새 값이 Autovacuum을 보다 공격적으로 만드는 경우에만 이러한 파라미터를 수정합니다. 파라미터는 DB 인스턴스의 메모리에서 수정됩니다. 파라미터 그룹의 값은 변경되지 않습니다. 현재 인 메모리 설정을 보려면 PostgreSQL SHOW SQL 명령을 사용하십시오.

RDS가 이러한 Autovacuum 파라미터를 수정하면 RDS API를 통해 AWS Management 콘솔(https://console.aws.amazon.com/rds/)에서 볼 수 있는 영향 받은 DB 인스턴스에 대한 이벤트를 생성합니다. MaximumUsedTransactionIDs CloudWatch 지표가 임계값 미만의 값을 반환하면 RDS는 메모리의 Autovacuum 관련 파라미터를 파라미터 그룹에 지정된 값으로 다시 설정하고, 이 변경에 해당하는 다른 이벤트를 생성합니다.

데이터베이스의 테이블을 Vacuum해야 하는지 여부를 결정

다음 쿼리를 사용하여 데이터베이스의 vacuum되지 않은 트랜잭션 수를 표시할 수 있습니다. 데이터베이스 pg_database 행의 datfrozenxid 열은 해당 데이터베이스에 나타나는 정상 트랜잭션 ID의 하한값입니다. 이 열은 데이터베이스 내 테이블 단위 relfrozenxid 값 중 최소값입니다.

SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc limit 20;

예를 들어 앞의 쿼리를 실행하면 다음과 같은 결과가 나올 수 있습니다.

데이터베이스의 수명이 20억 트랜잭션 ID에 도달하면 트랜잭션 ID(XID) 랩어라운드가 발생하고 데이터베이스는 읽기 전용이 됩니다. 이 쿼리를 사용하면 지표를 생성하고 쿼리가 하루에 몇 번 실행되도록 할 수 있습니다. 기본적으로 autovacuum은 트랜잭션 수명을 200,000,000(autovacuum_freeze_max_age) 미만으로 유지하도록 설정됩니다.

샘플 모니터링 전략은 다음과 같습니다.

autovacuum_freeze_max_age 값을 2억 개 트랜잭션으로 설정하십시오.
테이블이 5억 개의 vacuum되지 않은 트랜잭션에 도달하면 낮은 심각도 경보가 트리거됩니다. 이 값은 타당한 값이지만 autovacuum이 계속 수행되고 있지 않음을 나타낼 수 있습니다.
테이블 수명이 10억이 되면 조치를 취해야 할 경보로 처리되어야 합니다. 성능상의 이유로 수명을 autovacuum_freeze_max_age에 더 가깝게 유지하려는 경우가 대부분입니다. 다음 권장 사항을 사용하여 조사하는 것이 좋습니다.
테이블이 15억 개의 vacuum되지 않은 트랜잭션에 도달하면 높은 심각도 경보가 트리거됩니다. 데이터베이스가 트랜잭션 ID를 사용하는 속도에 따라 이 경보는 시스템에서 autovacuum을 실행할 시간이 부족함을 나타낼 수 있습니다. 이 경우 즉시 이를 해결하는 것이 좋습니다.

테이블이 지속적으로 이 임계값을 위반하면 autovacuum 파라미터를 추가로 수정해야 합니다. 기본적으로 수동 VACUUM을 사용하면(비용에 따른 지연이 비활성화됨)은 기본 autovacuum을 사용할 때보다 더 적극적이지만 시스템 전체에 더 많이 침입할 수 있는 상태이기도 합니다.

다음과 같이 하는 것이 좋습니다.

모니터링 메커니즘을 숙지하고 활성화하여 가장 오래된 트랜잭션의 수명을 확인합니다.

트랜잭션 ID 랩어라운드에 대해 경고하는 프로세스 생성에 대한 자세한 내용은 AWS Database 블로그 게시물 PostgreSQL용 Amazon RDS의 트랜잭션 ID 랩어라운드용 조기 경고 시스템 구현을 참조하십시오.
더 많이 사용되는 테이블의 경우 autovacuum을 사용하는 것 이외에 유지 관리 기간 동안 수동 vacuum freeze를 정기적으로 수행합니다. 수동 vacuum freeze 수행에 대한 자세한 내용은 수동 vacuum freeze 수행 단원을 참조하십시오.

현재 Autovacuum을 수행할 수 있는 테이블 결정

vacuum을 수행해야 하는 테이블이 하나이거나 두 개인 경우가 많습니다. relfrozenxid 값이 autovacuum_freeze_max_age의 트랜잭션 수보다 큰 테이블은 항상 Autovacuum의 대상이 됩니다. 그렇지 않은 경우 VACUUM이 "vacuum 임계값"을 초과하여 튜플 수가 더 이상 사용되지 않는 경우 테이블이 vacuum됩니다.

autovacuum 임계값은 다음과 같이 정의되어 있습니다.

Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples

데이터베이스에 연결되어 있는 상태에서 다음 쿼리를 실행하여 autovacuum이 vacuum 가능한 대상으로 분류하는 테이블 목록을 확인합니다.

WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM pg_settings WHERE name = 'autovacuum_vacuum_threshold') , vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM pg_settings WHERE name = 'autovacuum_vacuum_scale_factor') , fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age') , sto AS (select opt_oid, split_part(setting, '=', 1) as param, split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt) SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation , pg_size_pretty(pg_table_size(c.oid)) as table_size , age(relfrozenxid) as xid_age , coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age , (coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) + coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples) as autovacuum_vacuum_tuples , n_dead_tup as dead_tuples FROM pg_class c join pg_namespace ns on ns.oid = c.relnamespace join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1) left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid WHERE c.relkind = 'r' and nspname <> 'pg_catalog' and ( age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float) or coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) + coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples <= n_dead_tup -- or 1 = 1 ) ORDER BY age(relfrozenxid) DESC LIMIT 50;

현재 Autovacuum이 실행 중인지 여부 및 실행 기간 확인

테이블을 수동으로 vacuum해야 하는 경우 autovacuum이 현재 실행 중인지 확인해야 합니다. 실행 중이면 더 효율적으로 실행되도록 파라미터를 수정하거나 VACUUM을 수동으로 실행할 수 있도록 autovacuum을 종료해야 합니다.

다음 쿼리를 사용하여 autovacuum이 실행 중인지 여부와 얼마 동안 실행되고 있는지, 다른 세션에 대해 대기하고 있는지 확인합니다.

Amazon RDS PostgreSQL 9.6+ 이상을 사용하면 다음 쿼리를 사용합니다.

SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY xact_start;

쿼리를 실행하면 다음과 유사한 출력이 표시됩니다.

9.6 미만의 Amazon RDS for PostgreSQL 버전을 사용하는 경우 다음 쿼리를 사용합니다.

SELECT datname, usename, pid, waiting, current_timestamp - xact_start AS xact_runtime, query FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY xact_start;

쿼리를 실행하면 다음과 유사한 출력이 표시됩니다.

몇 가지 문제로 인해 autovacuum 세션이 오래(며칠간) 실행될 수 있습니다. 이 문제는 대부분 maintenance_work_mem 파라미터 값이 테이블 크기 또는 업데이트 속도에 대해 너무 낮게 설정된 경우입니다.

다음 공식을 사용하여 maintenance_work_mem 파라미터 값을 설정하는 것이 좋습니다.

GREATEST({DBInstanceClassMemory/63963136*1024},65536)

짧은 기간 동안 실행되는 autovacuum 세션에서도 문제를 표시할 수 있습니다.

워크로드에 autovacuum_max_workers가 충분하지 않다고 표시될 수 있습니다. 이 경우 작업자 수를 명시해야 합니다.
인덱스 손상(autovacuum에 충돌이 발생하여 동일한 관계에서 다시 시작되지만 진행되지 않음)이 있다고 표시될 수 있습니다. 이 경우 수동 vacuum freeze verbose ___table___을 실행하여 정확한 원인을 확인합니다.

수동 vacuum freeze 수행

vacuum 프로세스가 실행되고 있는 테이블에서 수동 vacuum을 수행하려는 경우가 있습니다. 이 작업은 수명이 20억 개 트랜잭션에 도달하거나 모니터링 중인 임계값을 초과한 테이블을 파악해 둔 경우 유용합니다.

다음 단계는 지침이며 이 프로세스를 여러 가지로 변형할 수 있습니다. 예를 들어 테스트 중에 maintenance_work_mem 파라미터 값이 너무 작게 설정되었고 테이블에 작업을 즉시 수행해야 한다고 가정해보십시오. 그러나 지금은 인스턴스를 반송하고 싶지 않을 수도 있습니다. 이전 세션의 쿼리를 사용하여 어떤 테이블이 문제이고 오랜 기간 동안 실행 중인 autovacuum 세션이 있는지 확인합니다. maintenance_work_mem 파라미터 설정도 변경해야 하지만 즉시 조치를 취해 문제가 되는 테이블을 vacuum해야 하기도 합니다. 이 경우 어떤 작업을 수행해야 하는지가 다음 절차에 나와 있습니다.

vacuum freeze를 수동으로 수행하려면

vacuum할 테이블이 포함되어 있는 데이터베이스에 세션 두 개를 엽니다. 두 번째 세션의 경우 "screen"을 사용하거나 연결이 끊긴 경우 세션을 유지하는 다른 유틸리티를 사용합니다.
첫 번째 세션에서는 테이블에서 실행 중인 autovacuum 세션의 PID를 가져옵니다.

다음 쿼리를 실행하여 autovacuum 세션의 PID를 가져옵니다.

SELECT datname, usename, pid, current_timestamp - xact_start AS xact_runtime, query FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY xact_start;
세션 2에서 이 작업에 필요한 메모리 양을 계산합니다. 이 예제에서는 이 작업에 메모리를 최대 2GB까지 사용할 수 있는 것으로 보고 현재 세션의 maintenance_work_mem을 2GB로 설정합니다.

set maintenance_work_mem='2 GB'; SET
세션 2에서 테이블에 대한 vacuum freeze verbose 명령을 실행하십시오. 현재 PostgreSQL에서 이 작업에 대한 진행률 보고가 없음에도 작업을 확인할 수 있기 때문에 상세 정보 표시 설정이 유용하게 사용됩니다.

\timing on Timing is on. vacuum freeze verbose pgbench_branches;

INFO: vacuuming "public.pgbench_branches" INFO: index "pgbench_branches_pkey" now contains 50 row versions in 2 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: index "pgbench_branches_test_index" now contains 50 row versions in 2 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: "pgbench_branches": found 0 removable, 50 nonremovable row versions in 43 out of 43 pages DETAIL: 0 dead row versions cannot be removed yet. There were 9347 unused item pointers. 0 pages are entirely empty. CPU 0.00s/0.00u sec elapsed 0.00 sec. VACUUM Time: 2.765 ms
세션 1에서 autovacuum이 차단된 경우 pg_stat_activity에서 vacuum 세션에 대한 대기를 나타내는 "T"를 확인할 수 있습니다. 이 경우 다음과 같이 autovacuum 프로세스를 종료해야 합니다.

SELECT pg_terminate_backend('the_pid');
이때 세션이 시작됩니다. 이 테이블이 작업 목록에서 가장 상위에 있을 것이므로 autovacuum이 즉시 다시 시작된다는 점을 알아 두어야 합니다. 세션 2에서 vacuum freeze verbose 명령을 시작한 다음 세션 1에서 autovacuum 프로세스를 종료합니다.

Autovacuum이 실행 중인 경우 테이블 인덱스 다시 지정

인덱스가 손상되면 autovacuum은 계속해서 테이블을 처리하려 하고 실패합니다. 이 경우 수동 vacuum을 시도하면 다음과 비슷한 오류 메시지가 표시됩니다.

mydb=# vacuum freeze pgbench_branches; ERROR: index "pgbench_branches_test_index" contains unexpected zero page at block 30521 HINT: Please REINDEX it.

인덱스가 손상된 상태에서 테이블에 대해 autovacuum을 실행하려고 하면 이미 실행 중인 autovacuum 세션이 있음을 확인하게 됩니다. "REINDEX" 명령을 실행하면 테이블에 대한 단독 잠금을 해제합니다. 쓰기 작업과 해당 특정 인덱스를 사용하는 읽기 작업도 차단됩니다.

테이블에서 autovacuum을 실행할 때 테이블 인덱스를 다시 지정하려면

vacuum할 테이블이 포함되어 있는 데이터베이스에 세션 두 개를 엽니다. 두 번째 세션의 경우 "screen"을 사용하거나 연결이 끊긴 경우 세션을 유지하는 다른 유틸리티를 사용합니다.
첫 번째 세션에서는 테이블에서 실행 중인 autovacuum 세션의 PID를 가져옵니다.

다음 쿼리를 실행하여 autovacuum 세션의 PID를 가져옵니다.

SELECT datname, usename, pid, current_timestamp - xact_start AS xact_runtime, query FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY xact_start;
세션 2에서 reindex 명령을 실행합니다.

\timing on Timing is on. reindex index pgbench_branches_test_index; REINDEX Time: 9.966 ms
세션 1에서 autovacuum이 차단된 경우 pg_stat_activity에서 vacuum 세션에 대한 대기를 나타내는 "T"를 확인할 수 있습니다. 이 경우 autovacuum 프로세스를 종료해야 합니다.

select pg_terminate_backend('the_pid');
이때 세션이 시작됩니다. 이 테이블이 작업 목록에서 가장 상위에 있을 것이므로 autovacuum이 즉시 다시 시작된다는 점을 알아 두어야 합니다. 세션 2에서 명령을 시작한 다음 세션 1에서 autovacuum 프로세스를 종료합니다.

autovacuum에 영향을 주는 기타 파라미터

이 쿼리를 사용하면 autovacuum 및 해당 동작에 직접 영향을 주는 일부 파라미터 값이 표시됩니다. autovacuum 파라미터는 PostgreSQL 설명서에 자세히 설명되어 있습니다.

SELECT name, setting, unit, short_desc FROM pg_settings WHERE name IN ( 'autovacuum_max_workers', 'autovacuum_analyze_scale_factor', 'autovacuum_naptime', 'autovacuum_analyze_threshold', 'autovacuum_analyze_scale_factor', 'autovacuum_vacuum_threshold', 'autovacuum_vacuum_scale_factor', 'autovacuum_vacuum_threshold', 'autovacuum_vacuum_cost_delay', 'autovacuum_vacuum_cost_limit', 'vacuum_cost_limit', 'autovacuum_freeze_max_age', 'maintenance_work_mem', 'vacuum_freeze_min_age');

모두 autovacuum에 영향을 주지만 가장 중요한 사항 몇 가지는 다음과 같습니다.

테이블 수준 Autovacuum 파라미터 설정

Autovacuum이 관련된 스토리지 파라미터를 테이블 수준에서 설정할 수 있습니다. 이 방법은 전체 데이터베이스의 동작을 변경하는 방법보다 더 나을 수 있습니다. 큰 테이블에 적극적인 설정을 지정해야 하지만 autovacuum이 모든 테이블에서 이와 같은 방식으로 작동하지 않도록 하려는 경우가 있을 수 있습니다.

이 쿼리를 사용하면 현재 어떤 테이블에 테이블 수준 옵션을 사용 중인지가 표시됩니다.

SELECT relname, reloptions FROM pg_class WHERE reloptions IS NOT null;

이 쿼리가 유용한 경우는 테이블 하나가 나머지 테이블보다 훨씬 더 큰 경우입니다. 300GB 테이블 하나와 1GB 미만의 테이블 30개가 있다고 가정하십시오. 이 경우 더 큰 테이블에 특정 파라미터를 설정하여 전체 시스템의 동작이 변경되지 않도록 할 수 있습니다.

ALTER TABLE mytable set (autovacuum_vacuum_cost_delay=0);

이렇게 하면 시스템의 리소스를 더 많이 사용하는 대신 이 테이블의 비용에 따른 autovacuum 지연이 비활성화됩니다. 일반적으로 autovacuum은 autovacuum_cost_limit에 도달할 때마다 autovacuum_vacuum_cost_delay에서 일시 정지됩니다. 비용에 따른 vacuum 수행에 대한 자세한 내용은 PostgreSQL 설명서에서 확인할 수 있습니다.

Autovacuum 로깅

기본적으로 postgresql.log에는 autovacuum 프로세스에 대한 정보가 없습니다. rds.force_autovacuum_logging_level 파라미터를 설정하면 autovacuum 작업자 작업에서 생성된 PostgreSQL 오류 로그의 출력을 볼 수 있습니다. 허용되는 값은 disabled, debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, 및 panic입니다. 다른 허용 가능 값은 로그에 방대한 양의 정보를 추가할 수 있기 때문에 기본값은 disabled로 설정됩니다.

rds.force_autovacuum_logging_level 파라미터 값을 log로 설정하고 log_autovacuum_min_duration파라미터 값을 1,000 ~ 5000밀리초로 설정하는 것이 좋습니다. 이 값을 5,000으로 설정하면 Amazon RDS가 5초 이상 걸리는 모든 활동을 로그에 씁니다. 또한 애플리케이션 잠금으로 인해 Autovacuum이 의도적으로 표를 건너뛸 때 "vacuum skipped" 메시지가 표시됩니다. 문제를 해결 중이어서 더 많은 정보가 필요한 경우 debug1 또는 debug3과 같은 다른 로깅 레벨 값을 사용할 수 있습니다. 이 설정을 사용하면 오류 로그 파일에 매우 자세한 내용이 기록되므로 짧은 기간일 경우 이 디버그 파라미터를 사용합니다. 디버그 설정에 대한 자세한 내용은 PostgreSQL 설명서를 참조하십시오.

참고

PostgreSQL을 사용하면 rds_superuser 계정에서 pg_stat_activity의 autovacuum 세션을 볼 수 있습니다. 예: 명령의 실행을 차단하거나, 수동으로 실행한 vacuum 명령보다 느리게 실행되는 autovacuum 세션을 식별 및 종료 가능

PostgreSQL DB 인스턴스에 대한 감사 로깅

PostgreSQL DB 인스턴스에 발생하는 로그 활동을 설정하는 파라미터가 몇 가지 있습니다. 이러한 파라미터에는 다음이 포함됩니다.

log_statement 파라미터는 PostgreSQL 데이터베이스에서 사용자 활동 로그에 사용할 수 있습니다. 자세한 내용은 PostgreSQL 데이터베이스 로그 파일 단원을 참조하십시오.
rds.force_admin_logging_level 파라미터는 RDS 내부 사용자(rdsadmin)가 DB 인스턴스의 데이터베이스에서 수행한 작업을 기록하고 PostgreSQL 오류 로그에 출력을 씁니다. 허용되는 값은 disabled, debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal 및 panic입니다. 기본값은 disabled입니다.
rds.force_autovacuum_logging_level 파라미터는 DB 인스턴스의 모든 데이터베이스에서 autovacuum 작업자 작업을 기록하고 PostgreSQL 오류 로그에 출력을 씁니다. 허용되는 값은 disabled, debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal 및 panic입니다. 기본값은 disabled입니다. rds.force_autovacuum_logging_level에 대한 Amazon RDS 권장 설정은 LOG입니다. 1000 또는 5000에서 log_autovacuum_min_duration 값을 설정합니다. 이 값을 5000으로 설정하면 5초 이상 걸리는 작업을 로그에 쓰고 "vacuum skipped" 메시지를 표시합니다. 이 파라미터에 대한 자세한 내용은 PostgreSQL로 작업하기 위한 모범 사례 단원을 참조하십시오.

pgaudit 확장 작업

pgaudit 확장은 PostgreSQL 버전 9.6.3 이상 및 버전 9.5.7 버전 이상의 Amazon RDS에 대한 세부적인 세션 및 객체 감사 로깅을 제공합니다. 이 확장을 사용하여 세션 감사 또는 객체 감사를 활성화할 수 있습니다.

세션 감사를 사용하면 다양한 소스의 감사 이벤트를 기록할 수 있으며 사용 가능한 경우 정규화된 명령 텍스트를 포함할 수 있습니다. 예를 들어 세션 감사를 사용하여 pgaudit.log를 'READ'로 설정하면 데이터베이스에 연결된 모든 READ 문을 기록할 수 있습니다.

객체 감사를 사용하면 특정 명령을 사용하도록 감사 로깅을 구체화할 수 있습니다. 예를 들어 특정 테이블 수에서 READ 작업에 대한 로깅을 지정할 수 있습니다.

pgaudit 확장을 사용하여 객체 기반 로깅을 사용하려면

rds_pgaudit라는 특정 데이터베이스를 생성합니다. 다음 명령을 실행해 역할을 생성합니다.

CREATE ROLE rds_pgaudit; CREATE ROLE
DB 인스턴스와 연결되어 있는 파라미터 그룹을 수정하여 pgaudit를 포함하는 공유된 사전 로드를 사용하고 pgaudit.role을 설정합니다. pgaudit.role은 rds_pgaudit 역할로 설정해야 합니다.

다음 명령은 사용자 지정 파라미터 그룹을 수정합니다.

aws rds modify-db-parameter-group --db-parameter-group-name rds-parameter-group-96 --parameters "ParameterName=pgaudit.role,ParameterValue=rds_pgaudit,ApplyMethod=pending-reboot" --parameters "ParameterName=shared_preload_libraries,ParameterValue=pgaudit,ApplyMethod=pending-reboot" --region us-west-2
DB 인스턴스가 파라미터 그룹에 대한 변경 사항을 가져오도록 인스턴스를 재부팅합니다. 다음 명령은 DB 인스턴스를 재부팅합니다.

aws rds reboot-db-instance --db-instance-identifier rds-test-instance --region us-west-2
다음 명령을 실행하여 pgaudit가 초기화되었는지 확인합니다.

show shared_preload_libraries; shared_preload_libraries -------------------------- rdsutils,pgaudit (1 row)
다음 명령을 실행하여 pgaudit 확장을 생성합니다.

CREATE EXTENSION pgaudit; CREATE EXTENSION
다음 명령을 실행하여 pgaudit.role이 rds_pgaudit로 설정되었는지 확인합니다.

show pgaudit.role; pgaudit.role ------------------ rds_pgaudit

감사 로깅을 테스트하려면 감사하기로 선택한 여러 명령을 실행합니다. 예를 들어 다음과 같은 명령을 실행할 수 있습니다.

CREATE TABLE t1 (id int); CREATE TABLE GRANT SELECT ON t1 TO rds_pgaudit; GRANT select * from t1; id ---- (0 rows)

데이터베이스 로그에는 다음과 유사한 항목이 포함됩니다.

... 2017-06-12 19:09:49 UTC:…:rds_test@postgres:[11701]:LOG: AUDIT: OBJECT,1,1,READ,SELECT,TABLE,public.t1,select * from t1; ...

로그 확인에 대한 자세한 내용은 Amazon RDS 데이터베이스 로그 파일 단원을 참조하십시오.

pg_repack 확장 작업

pg_repack 확장을 사용하여 테이블과 인덱스에서 부풀림을 제거할 수 있습니다. 이 확장은 Amazon Amazon RDS의 PostgreSQL 버전 9.6.3 이상을 지원합니다. pg_repack 확장에 대한 자세한 내용은 GitHub 프로젝트 설명서를 참조하십시오.

pg_repack 확장을 사용하려면

다음 명령을 실행하여 PostgreSQL DB 인스턴스용 Amazon RDS에 pg_repack 확장을 설치합니다.

CREATE EXTENSION pg_repack;
pg_repack 클라이언트 유틸리티를 사용하여 데이터베이스에 연결합니다. rds_superuser 권한이 있는 데이터베이스 역할을 사용하여 데이터베이스에 연결합니다. 다음 연결 예제에서 rds_test 역할은 rds_superuser 권한을 가지며, 사용되는 데이터베이스 엔드포인트는 rds-test-instance.cw7jjfgdr4on8.us-west-2.rds.amazonaws.com입니다.

pg_repack -h rds-test-instance.cw7jjfgdr4on8.us-west-2.rds.amazonaws.com -U rds_test -k postgres
-k 옵션을 사용하여 연결합니다. -a 옵션은 지원되지 않습니다.
pg_repack 클라이언트의 응답은 다시 구성된 DB 인스턴스 상의 테이블에 대한 정보를 제공합니다.

INFO: repacking table "pgbench_tellers" INFO: repacking table "pgbench_accounts" INFO: repacking table "pgbench_branches"

PostGIS 작업

PostGIS는 공간 정보를 저장하고 관리하기 위해 PostgreSQL을 확장한 것입니다. PostGIS에 대해 잘 알지 못하는 경우 PostGIS Introduction에서 일반 개요를 볼 수 있습니다.

PostGIS 확장 모듈을 사용하려면 그 전에 몇 가지 설정을 수행해야 합니다. 해야 할 설정은 다음과 같습니다. 각 단계는 이번 단원에서 더욱 자세히 설명하겠습니다.

DB 인스턴스를 생성할 때 사용한 마스터 사용자 이름으로 DB 인스턴스에 연결합니다.
PostGIS 확장 모듈을 로드합니다.
확장 모듈의 소유권을 rds_superuser 역할로 이전합니다.
객체 소유권을 rds_superuser 역할로 이전합니다.
확장 모듈을 테스트합니다.

1단계: DB 인스턴스를 생성할 때 사용한 마스터 사용자 이름으로 DB 인스턴스에 연결합니다.

먼저 DB 인스턴스를 생성할 때 사용한 마스터 사용자 이름으로 DB 인스턴스에 연결합니다. 해당 이름은 rds_superuser 역할에 자동으로 할당됩니다. 나머지 단계를 수행하는 데 필요한 rds_superuser 역할이 필요합니다.

다음은 SELECT를 사용하여 현재 사용자를 표시한 예제입니다. 여기서 현재 사용자는 DB 인스턴스 생성 시 선택한 마스터 사용자 이름이어야 합니다.

select current_user; current_user ------------- myawsuser (1 row)

2단계: PostGIS 확장 모듈을 로드합니다.

CREATE EXTENSION 문을 사용하여 PostGIS 확장 모듈을 로드합니다. 반드시 확장 모듈을 로드해야 합니다. 그런 다음 \dn psql 명령을 사용하여 PostGIS 스키마의 소유자를 표시합니다.

create extension postgis; CREATE EXTENSION create extension fuzzystrmatch; CREATE EXTENSION create extension postgis_tiger_geocoder; CREATE EXTENSION create extension postgis_topology; CREATE EXTENSION \dn List of schemas Name | Owner --------------+----------- public | myawsuser tiger | rdsadmin tiger_data | rdsadmin topology | rdsadmin (4 rows)

3단계: 확장 모듈의 소유권을 rds_superuser 역할로 이전합니다.

ALTER SCHEMA 문을 사용하여 스키마 소유권을 rds_superuser 역할로 이전합니다.

alter schema tiger owner to rds_superuser; ALTER SCHEMA alter schema tiger_data owner to rds_superuser; ALTER SCHEMA alter schema topology owner to rds_superuser; ALTER SCHEMA \dn List of schemas Name | Owner --------------+--------------- public | myawsuser tiger | rds_superuser tiger_data | rds_superuser topology | rds_superuser (4 rows)

4단계: 객체 소유권을 rds_superuser 역할로 이전합니다.

다음 함수를 사용하여 PostGIS 객체 소유권을 rds_superuser 역할로 이전합니다. psql 프롬프트에서 다음 문을 실행하여 함수를 생성합니다.

CREATE FUNCTION exec(text) returns text language plpgsql volatile AS $f$ BEGIN EXECUTE $1; RETURN $1; END; $f$;

그런 다음 이 쿼리로 실행 함수를 실행하면 이 함수가 해당하는 문을 실행하여 권한을 변경합니다.

SELECT exec('ALTER TABLE ' || quote_ident(s.nspname) || '.' || quote_ident(s.relname) || ' OWNER TO rds_superuser;') FROM ( SELECT nspname, relname FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid) WHERE nspname in ('tiger','topology') AND relkind IN ('r','S','v') ORDER BY relkind = 'S') s;

5단계: 확장 모듈을 테스트합니다.

다음 명령을 사용하여 tiger를 검색 경로에 추가합니다.

SET search_path=public,tiger;

다음 SELECT 문을 사용하여 tiger 모듈을 테스트합니다.

select na.address, na.streetname, na.streettypeabbrev, na.zip from normalize_address('1 Devonshire Place, Boston, MA 02109') as na; address | streetname | streettypeabbrev | zip ---------+------------+------------------+------- 1 | Devonshire | Pl | 02109 (1 row)

다음 SELECT 문을 사용하여 topology 모듈을 테스트합니다.

select topology.createtopology('my_new_topo',26986,0.5); createtopology ---------------- 1 (1 row)

pgBadger를 사용한 PostgreSQL의 로그 분석

pgbadger 등의 로그 분석기를 사용하여 PostgreSQL 로그를 분석할 수 있습니다. pgbadger 문서에는 %l 패턴(세션/프로세스의 로그 라인)은 접두사에 포함되어야 한다고 나와 있습니다. 그러나 현재 rds log_line_prefix를 pgbadger에 파라미터로 사용하더라도 여전히 보고서를 생성해야 합니다.

예를 들어 다음 명령은 pgbadger를 사용하여 2014-02-04 일자의 Amazon RDS PostgreSQL 로그 파일을 정확한 형식으로 나타내고 있습니다.

./pgbadger -p '%t:%r:%u@%d:[%p]:' postgresql.log.2014-02-04-00

pg_config의 내용 보기

PostgreSQL 버전 9.6.1에서는 새로 보기 pg_config를 이용해 현재 설치된 PostgreSQL 버전의 컴파일 시간 구성 파라미터를 볼 수 있습니다. 다음 예제와 같이 pg_config 함수를 호출하여 볼 수 있습니다.

select * from pg_config(); name | setting -------------------+--------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------- BINDIR | /rdsdbbin/postgres-9.6.1.R1/bin DOCDIR | /rdsdbbin/postgres-9.6.1.R1/share/doc HTMLDIR | /rdsdbbin/postgres-9.6.1.R1/share/doc INCLUDEDIR | /rdsdbbin/postgres-9.6.1.R1/include PKGINCLUDEDIR | /rdsdbbin/postgres-9.6.1.R1/include INCLUDEDIR-SERVER | /rdsdbbin/postgres-9.6.1.R1/include/server LIBDIR | /rdsdbbin/postgres-9.6.1.R1/lib PKGLIBDIR | /rdsdbbin/postgres-9.6.1.R1/lib LOCALEDIR | /rdsdbbin/postgres-9.6.1.R1/share/locale MANDIR | /rdsdbbin/postgres-9.6.1.R1/share/man SHAREDIR | /rdsdbbin/postgres-9.6.1.R1/share SYSCONFDIR | /rdsdbbin/postgres-9.6.1.R1/etc PGXS | /rdsdbbin/postgres-9.6.1.R1/lib/pgxs/src/makefiles/pgxs.mk CONFIGURE | '--prefix=/rdsdbbin/postgres-9.6.1.R1' '--with-openssl' '--with-perl' '--with-tcl' '--with-ossp-uuid' '--with-libxml' '--with-libraries=/rdsdbbin /postgres-9.6.1.R1/lib' '--with-includes=/rdsdbbin/postgres-9.6.1.R1/include' '--enable-debug' CC | gcc CPPFLAGS | -D_GNU_SOURCE -I/usr/include/libxml2 -I/rdsdbbin/postgres-9.6.1.R1/include CFLAGS | -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict- aliasing -fwrapv -fexcess-precision=standard -g -O2 CFLAGS_SL | -fpic LDFLAGS | -L../../src/common -L/rdsdbbin/postgres-9.6.1.R1/lib -Wl,--as-needed -Wl, -rpath,'/rdsdbbin/postgres-9.6.1.R1/lib',--enable-new-dtags LDFLAGS_EX | LDFLAGS_SL | LIBS | -lpgcommon -lpgport -lxml2 -lssl -lcrypto -lz -lreadline -lrt -lcrypt -ldl -lm VERSION | PostgreSQL 9.6.1 (23 rows)

바로 보기에 액세스하려고 하면 요청이 실패합니다.

select * from pg_config; ERROR: permission denied for relation pg_config

orafce 확장 작업

orafce 확장은 상용 데이터베이스에서 흔히 사용되는 함수를 제공하며, 상용 데이터베이스를 PostgreSQL로 더 쉽게 포팅할 수 있게 합니다. Amazon RDS PostgreSQL 버전 9.6.6 이상에서 이 확장을 지원합니다. orafce에 대한 자세한 내용은 GitHub에서 orafce 프로젝트를 참조하십시오.

참고

PostgreSQL용 Amazon RDS는 orafce 확장의 일부분인 utl_file 패키지를 지원하지 않습니다. 이는 utl_file 스키마 함수가 기본 호스트에 대한 수퍼유저 권한을 필요로 하는 운영 체제 텍스트 파일의 읽기 및 쓰기 작업을 제공하기 때문입니다.

orafce 확장을 사용하려면

DB 인스턴스를 생성할 때 사용한 마스터 사용자 이름으로 DB 인스턴스에 연결합니다.

참고

동일한 인스턴스의 다른 데이터베이스에서 orafce를 활성화하려는 경우 연결을 시작한 후 /c dbname psql 명령을 사용하여 마스터 데이터베이스에서 변경하십시오.
CREATE EXTENSION 문을 사용하여 orafce 확장을 활성화합니다.

CREATE EXTENSION orafce;
ALTER SCHEMA 문을 사용하여 oracle 스키마 소유권을 rds_superuser 역할로 이전합니다.

ALTER SCHEMA oracle OWNER TO rds_superuser;
참고

oracle 스키마의 소유자 목록을 보려면 \dn psql 명령을 사용합니다.

postgres_fdw 확장으로 외부 데이터 액세스

postgres_fdw 확장으로 원격 데이터베이스에 있는 테이블의 데이터에 액세스할 수 있습니다. PostgreSQL DB 인스턴스에서 원격 연결을 설정하는 경우 읽기 전용 복제본에도 액세스할 수 있습니다.

postgres_fdw로 원격 데이터베이스 서버에 액세스하려면

postgres_fdw 확장을 설치합니다.

CREATE EXTENSION postgres_fdw;
CREATE SERVER로 외부 데이터 서버를 생성합니다.

CREATE SERVER foreign_server FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host 'xxx.xx.xxx.xx', port '5432', dbname 'foreign_db');
원격 서버에 사용할 역할 식별을 위하여 사용자 매핑을 생성합니다.

CREATE USER MAPPING FOR local_user SERVER foreign_server OPTIONS (user 'foreign_user', password 'password');
원격 서버에서 테이블을 매핑할 테이블을 생성합니다.

CREATE FOREIGN TABLE foreign_table ( id integer NOT NULL, data text) SERVER foreign_server OPTIONS (schema_name 'some_schema', table_name 'some_table');

아웃바운드 네트워크 액세스에 사용자 지정 DNS 서버 사용

PostgreSQL용 Amazon RDS는 DB 인스턴스에서 아웃바운드 네트워크 액세스를 지원하고, 고객이 소유한 사용자 지정 DNS 서버에서의 DNS(Domain Name Service) 확인을 허용합니다. 사용자 지정 DNS 서버를 통해 Amazon RDS DB 인스턴스에서 전체 주소 도메인 이름만을 확인할 수 있습니다.

주제

사용자 지정 DNS 확인 활성화

고객 VPC에서 DNS 확인을 활성화하려면 사용자 지정 DB 파라미터 그룹을 RDS PostgreSQL 인스턴스에 연결하고, rds.custom_dns_resolution 파라미터를 1로 설정하여 켜고, 변경 사항이 적용되도록 DB 인스턴스를 다시 시작합니다.

사용자 지정 DNS 확인 비활성화

고객 VPC에서 DNS 확인을 비활성화하려면 사용자 지정 DB 파라미터 그룹의 rds.custom_dns_resolution 파라미터를 0으로 설정하여 끄고 변경 사항이 적용되도록 DB 인스턴스를 다시 시작합니다.

사용자 지정 DNS 서버 설정

사용자 지정 DNS 이름 서버를 설정한 후 변경 사항이 DB 인스턴스에 전파되는 데 최대 30분이 걸립니다. 변경 사항이 DB 인스턴스에 전파된 후 DNS 조회를 필요로 하는 모든 아웃바운드 네트워크 트래픽은 포트 53을 통해 DNS 서버를 쿼리합니다.

참고

사용자 지정 DNS 서버를 설정하지 않고 rds.custom_dns_resolution이 1로 설정된 경우 Route 53 프라이빗 영역을 사용하여 호스트가 확인됩니다. 자세한 내용은 프라이빗 호스팅 영역 작업을 참조하십시오.

Amazon RDS PostgreSQL DB 인스턴스의 사용자 지정 DNS 서버를 설정하려면

VPC에 연결된 DHCP 옵션 세트에서 DNS 이름 서버의 IP 주소에 대해 domain-name-servers 옵션을 설정합니다. 자세한 내용은 DHCP 옵션 세트 단원을 참조하십시오.

참고

domain-name-servers 옵션은 최대 4개의 값을 받아들이지만 Amazon RDS DB 인스턴스는 첫 번째 값만을 사용합니다.
DNS 서버가 DNS 이름, Amazon EC2 프라이빗 DNS 이름, 고객별 DNS 이름을 비롯한 모든 조회 쿼리를 확인할 수 있는지 확인합니다. 아웃바운드 네트워크 트래픽에 DNS 서버가 처리할 수 없는 DNS 조회가 포함된 경우, DNS 서버에 적절한 업스트림 DNS 공급자가 구성되어 있어야 합니다.
512바이트 이하의 UDP(User Datagram Protocol) 응답을 생성하도록 DNS 서버를 구성하십시오.
1,024바이트 이하의 TCP(Transmission Control Protocol) 응답을 생성하도록 DNS 서버를 구성하십시오.
포트 53을 통한 Amazon RDS DB 인스턴스로부터의 인바운드 트래픽을 허용하도록 DNS 서버를 구성하십시오. DNS 서버가 Amazon VPC에 있는 경우, VPC에는 포트 53에서 UDP 및 TCP 트래픽을 허용하는 인바운드 규칙이 포함된 보안 그룹이 있어야 합니다. DNS 서버가 Amazon VPC에 없는 경우, 포트 53에서 UDP 및 TCP 트래픽을 허용하는 적절한 방화벽 화이트리스트가 있어야 합니다.

자세한 내용은 VPC의 보안 그룹 및 규칙 추가 및 제거 단원을 참조하십시오.
포트 53을 통한 아웃바운드 트래픽을 허용하도록 Amazon RDS DB 인스턴스의 VPC를 구성하십시오. VPC에는 포트 53에서 UDP 및 TCP 트래픽을 허용하는 아웃바운드 규칙이 포함된 보안 그룹이 있어야 합니다.

자세한 내용은 VPC의 보안 그룹 및 규칙 추가 및 제거 단원을 참조하십시오.
Amazon RDS DB 인스턴스와 DNS 서버 간 라우팅 경로가 DNS 트래픽을 허용하도록 올바로 구성되어야 합니다.

Amazon RDS DB 인스턴스와 DNS 서버가 같은 VPC에 있지 않은 경우, 그 사이에 피어링 연결을 구축해야 합니다. 자세한 내용은 VPC 피어링이란?을 참조하십시오.

암호 관리 제한

데이터베이스 사용자 암호를 관리할 수 있는 사람을 특정 역할로 제한할 수 있습니다. 이렇게 하면 클라이언트 측의 암호 관리를 더 잘 제어할 수 있습니다.

정적 파라미터 rds.restrict_password_commands로 제한된 암호 관리를 활성화하고 rds_password라는 역할을 사용합니다. rds.restrict_password_commands 파라미터를 1로 설정하면, rds_password 역할의 멤버인 사용자만 특정 SQL 명령을 실행할 수 있습니다. 제한된 SQL 명령은 데이터베이스 사용자 암호와 암호 만료 시간을 수정하는 명령입니다.

제한된 암호 관리를 사용하려면 DB 인스턴스가 PostgreSQL 10.6 이상용 Amazon RDS를 실행해야 합니다. rds.restrict_password_commands 파라미터는 정적이므로 이 파라미터를 변경하려면 데이터베이스를 다시 시작해야 합니다.

데이터베이스에 제한된 암호 관리가 활성화되어 있을 때 제한된 SQL 명령을 실행하려고 하면 ERROR: must be a member of rds_password to alter passwords 오류가 표시됩니다.

다음은 제한된 암호 관리가 활성화되어 있을 때 제한되는 몇 가지 SQL 명령 예입니다.

postgres=> CREATE ROLE myrole WITH PASSWORD 'mypassword'; postgres=> CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2020-01-01'; postgres=> ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2020-01-01'; postgres=> ALTER ROLE myrole WITH PASSWORD 'mypassword'; postgres=> ALTER ROLE myrole VALID UNTIL '2020-01-01'; postgres=> ALTER ROLE myrole RENAME TO myrole2;

RENAME TO가 포함된 일부 ALTER ROLE 명령도 제한될 수 있습니다. 이러한 명령이 제한될 수 있는 이유는 MD5 암호가 있는 PostgreSQL 역할 이름을 바꾸면 암호가 지워지기 때문입니다.

rds_superuser 역할에는 기본적으로 rds_password 역할의 멤버십이 있으므로 변경할 수 없습니다. GRANT SQL 명령을 사용하여 다른 역할에 rds_password 역할의 멤버십을 제공할 수 있습니다. 암호 관리에만 사용하는 몇 가지 역할에만 rds_password 멤버십을 제공하는 것이 좋습니다. 이러한 역할에는 다른 역할을 수정할 CREATEROLE 속성이 필요합니다.

만료 및 클라이언트 측에 필요한 복잡성 등의 암호 요구 사항을 확인해야 합니다. 자체 클라이언트 측 유틸리티를 사용하여 암호 관련 변경을 제한하는 것이 좋습니다. 이 유틸리티에는 rds_password의 멤버이며 CREATEROLE 역할 속성이 있는 역할이 있어야 합니다.

출처 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html

현재글PostgreSQL을 위한 일반 DBA 작업

오라클, EXP, 스마트폰, export, JPPD, 11i, oracle, 파티션 테이블, 포스트그레스큐엘, 10g, oracle 9i, RMAN, Oracle 10g, 스마트미러링, DBlink, dg4odbc, 이기종DB, EBS 11i, 팝업노트, PostgreSQL,

Today :
Yesterday :

orcl