Amazon Aurora DSQL 사용에 대한 고려 사항

DROP TABLE 명령을 실행한 후 스토리지 제한 계산에 여유 스토리지가 반영되는 데 시간이 걸릴 수 있습니다. 추가 스토리지 용량이 필요한 경우 클러스터 할당량를 참조하여 할당량 업데이트를 요청합니다.

Aurora DSQL의 대형 테이블의 경우 시스템 카탈로그를 사용하여 COUNT(*) 작업 대신 테이블 행 수를 검색합니다. 자세한 내용은 Aurora DSQL에서 시스템 테이블 및 명령 사용을 참조하세요.

Aurora DSQL은 스키마 수준 권한 부여를 통해 권한을 관리합니다. 관리자 사용자는 CREATE SCHEMA를 사용하여 스키마를 만들고 GRANT USAGE ON SCHEMA를 사용하여 다른 역할에 대한 액세스 권한을 부여합니다. 관리자 사용자는 퍼블릭 스키마에서 객체를 관리하는 반면, 관리자가 아닌 사용자는 사용자가 만든 스키마에서 객체를 만듭니다. 관리자 역할은 다른 역할을 부여하여 사용자가 만든 객체에 대한 권한을 얻을 수 있습니다. 자세한 내용은 데이터베이스 역할이 데이터베이스에서 SQL을 사용하도록 권한 부여 섹션을 참조하세요.

드라이버가 PG_PREPARED_STATEMENTS를 직접적으로 호출하면 Aurora DSQL은 캐시된 준비된 문에 대한 클러스터 전체 보기를 제공합니다. 동일한 클러스터 및 IAM 역할에 대해 예상보다 연결당 더 많은 준비된 문이 표시될 수 있습니다. Aurora DSQL은 준비 중에 문 이름을 동적으로 관리합니다.

IPv4 전용 인스턴스에서 연결할 때 클라이언트가 IPv4 연결에 맞게 구성되어 있는지 확인합니다. 일부 PostgreSQL 클라이언트는 듀얼 스택 모드에서 IPv4 및 IPv6 연결을 모두 시도합니다. IPv4 연결에 스로틀링이 발생하는 경우 클라이언트는 IPv6를 시도하고 IPv4 전용 호스트에서 NetworkUnreachable 오류를 반환할 수 있습니다. IPv4를 명시적으로 사용하도록 클라이언트를 구성하여 이러한 동작을 방지합니다.

관리자 사용자가 새 스키마를 만들고 GRANT 및 REVOKE 변경 사항이 연결 수명(최대 1시간) 내에 기존 연결로 전파된 후 즉시 적용하려면 권한 변경 후 새 연결을 설정합니다.

드문 다중 리전 연결 클러스터 복구 시나리오에서는 자동 클러스터 복구 작업이 고가용성을 유지하지만 일시적인 동시성 제어 또는 연결 오류가 발생할 수 있습니다. 대부분의 경우 워크로드의 일부만 영향을 받습니다. 이러한 전송 오류가 표시되면 트랜잭션을 다시 시도하거나 클라이언트와 다시 연결합니다.

Datagrip과 같은 일부 SQL 클라이언트는 스키마 정보를 채우기 위해 광범위한 시스템 메타데이터를 요청합니다. Aurora DSQL은 SQL 쿼리 기능에 대한 핵심 메타데이터를 제공합니다. 이러한 클라이언트의 스키마 표시는 전체 기능 세트에 비해 제한된 정보를 표시할 수 있습니다.

쿼리가 새로 만들어진 스키마와 테이블을 인식하도록 하려면 데이터베이스 객체를 만들거나 삭제한 후 연결을 새로 고칩니다. 여기에는 스키마를 삭제한 후 또는 다른 연결에서 만들어진 객체를 쿼리할 때 Schema Already Exists 오류가 표시되는 시나리오가 포함됩니다. 연결 해제했다가 다시 연결하거나 SET search_path를 다시 실행하여 카탈로그 캐시를 새로 고칩니다.

복잡한 쿼리의 경우 EXPLAIN ANALYZE VERBOSE를 사용하여 지연 시간이 긴 작업을 식별하고 쿼리 계획을 최적화합니다. 인덱스를 커버하면 전체 테이블 스캔 대신 인덱스 전용 스캔을 활성화하여 DPU 비용을 크게 줄일 수 있습니다. 자세한 내용은 Aurora DSQL EXPLAIN 계획 작업 섹션을 참조하세요.

연결 제한은 클러스터 수준에서 관리됩니다. 할당량 업데이트를 요청하려면 클러스터 할당량 섹션을 참조하세요.