Amazon RDS for MySQL DB 인스턴스가 예상보다 많은 스토리지를 사용하는 이유는 무엇인가요?

4분 분량

Amazon Relational Database Service (RDS) for MySQL DB 인스턴스가 예상보다 많은 공간을 사용하고 있습니다. 왜 이런 현상이 발생하며, 디스크 스토리지를 최적화하려면 어떻게 해야 합니까?

해결 방법

FreeStorageSpace Amazon CloudWatch 지표를 사용하여 RDS DB 인스턴스의 가용 스토리지 공간을 모니터링할 수 있습니다. 하지만 FreeStorageSpace는 DB 인스턴스가 스토리지를 어떻게 소비하는지 설명하지 않습니다.

다음 전략을 사용하여 스토리지 공간을 확보합니다.

OPTIMIZE TABLE 실행

테이블은 실제로 사용되지 않는 일부 공간을 소비하지만 Amazon RDS는 어쨌든 해당 공간을 테이블에 할당합니다. innodb_file_per_table이 켜져 있는 경우(기본적으로 켜져 있음) OPTIMIZE TABLE을 사용하여 해당 공간을 확보할 수 있습니다. OPTIMIZE TABLE은 InnoDB, MyISAM 및 ARCHIVE 테이블에 사용할 수 있습니다. Amazon RDS는 OPTIMIZE TABLE 명령을 수락하지만 실제로는 ALTER TABLE...FORCE 명령을 대신 실행합니다. 이 경우 다음과 유사한 경고 메시지가 표시됩니다. "Table does not support optimize, doing recreate + analyze instead.(테이블이 최적화를 지원하지 않습니다. 대신 테이블을 다시 생성하고 분석하십시오.)" 자세한 내용은 MySQL 설명서에서 OPTIMIZE TABLE을 참조하세요.

조각화를 확인하려면 다음과 같은 쿼리를 실행합니다.

SELECT
 table_name,
 data_length,
 max_data_length,
 index_length,
 data_free
FROM
 information_schema.tables 
WHERE table_schema='schema_name'
;

data_free 열에는 사실상 사용 중이 아닌 테이블에 할당된 여유 공간의 양이 강조 표시됩니다. OPTIMIZE TABLE을 사용하면 이 공간을 확보할 수 있을 것입니다. Amazon RDS 기본 innodb_file_per_table 구성 설정에 따라 별도의 테이블스페이스에 테이블이 생성되는 경우 OPTIMIZE TABLE이 작동합니다. 자세한 내용은 MySQL 설명서에서 File-Per-Table Tablespaces를 참조하세요.

애플리케이션 테이블 스토리지 감소

DB 인스턴스에서 애플리케이션 테이블이 사용하는 스토리지 크기를 확인하려면 다음과 같은 쿼리를 실행합니다.

SELECT 
 table_schema,
 SUM(data_length + index_length + data_free)/1024/1024 AS total_mb,
 SUM(data_length)/1024/1024 AS data_mb,
 SUM(index_length)/1024/1024 AS index_mb,
 SUM(data_free)/1024/1024 AS free_mb,
 COUNT(*) AS tables,
 CURDATE() AS today 
FROM 
 information_schema.tables
 GROUP BY table_schema
 ORDER BY 2 DESC
;

DB 인스턴스에 가장 큰 애플리케이션 테이블을 찾으려면 다음과 같은 쿼리를 실행합니다.

SELECT 
 table_schema,
 table_name,
 (data_length + index_length + data_free)/1024/1024 AS total_mb,
 (data_length)/1024/1024 AS data_mb,
 (index_length)/1024/1024 AS index_mb,
 (data_free)/1024/1024 AS free_mb,
 CURDATE() AS today
FROM 
 information_schema.tables
 ORDER BY 3 DESC
;

참고: 데이터베이스에 768바이트 이상의 가변 길이 열이 있는 테이블이 들어 있는 경우, 개별 데이터베이스 및 테이블에서 사용한 총 스토리지를 계산할 수 없습니다. 예를 들어 여기에는 BLOB, TEXT, VARCHAR 또는 VARBINARY가 포함됩니다.

이진 로그 스토리지 감소

읽기 전용 복제본을 추가하면 소스 인스턴스의 이진 로그가 스토리지를 추가로 사용하게 됩니다. 소스 인스턴스의 이진 로그가 스토리지를 얼마나 많이 사용 중인지 알아보려면 BinLogDiskUsage CloudWatch 지표를 확인하세요. 분량이 대폭 증가하는 것은 하나 이상의 읽기 전용 복제본이 동기화되지 않았음을 의미할 수 있습니다.

일반 로그 및 느린 쿼리 로그의 스토리지 감소 또는 비활성화

일반 로그 및 느린 쿼리 로그 파라미터를 끄면 인스턴스가 이러한 로그를 저장하기 시작합니다. 또한 이러한 로그의 백업도 저장합니다. 이 파일을 교체하고 디스크 사용량을 통제하는 방법은 mysql.rds_rotate_general_log 및 mysql.rds_rotate_slow_log를 참조하세요.

참고: 문제 해결에 자주 사용하지 않는 일반 쿼리 로그 및 느린 쿼리 로그를 끄세요.

InnoDB 시스템 테이블스페이스 크기 관리 또는 감소

시스템 테이블스페이스에는 InnoDB 데이터 사전과 실행 취소 공간이 들어 있으며, 10MB부터 시작됩니다. 장기 실행 트랜잭션의 경우 사용 가능한 스토리지를 더 많이 소비할 수도 있지만, 이 파일은 공간이 할당된 뒤로 항상 최소한 이 크기를 유지합니다.

기본적으로 Amazon RDS는 innodb_file_per_table을 1로 설정합니다. 즉, 각 테이블스페이스의 데이터가 자체 .ibd 파일에 저장됩니다. 관련 테이블에 재사용할 수 있다고 표시된 공간을 복구하려면 OPTIMIZE TABLE을 사용하여 테이블당 테이블스페이스 파일의 크기를 조정하거나 테이블을 하나 삭제합니다.

innodb_file_per_table이 0으로 설정된 경우, 모든 테이블은 시스템 테이블스페이스에도 할당됩니다. 테이블 또는 인덱스를 삭제하거나 시스템 테이블스페이스에 할당된 테이블에서 데이터를 삭제하거나 자르면 이전에 사용하던 해당 공간이 재사용 가능한 것으로 표시됩니다. 그러나 innodb_file_per_table은 파일 시스템의 공간을 확보하지는 않습니다.

현재 위치에서 시스템 테이블스페이스를 축소할 수 없으므로 현재 데이터베이스의 데이터를 내보냅니다. 그런 다음 데이터를 새 인스턴스로 가져옵니다. 가동 중단 시간을 줄이려면 새 MySQL 인스턴스를 소스 Amazon RDS 인스턴스의 복제본으로 구성하세요. 복제본이 소스 Amazon RDS 인스턴스와 동기화되면 새 인스턴스로 전환하세요.

참고: 스냅샷에서 복원하거나 읽기 전용 복제본을 생성하는 것은 시스템 테이블스페이스에서 공간을 복구하는 데 도움이 되지 않습니다. 두 방법 모두 시스템 테이블스페이스가 들어 있는 소스 인스턴스 스토리지 볼륨의 스냅샷을 사용하기 때문입니다.