Amazon RDS for MySQL 또는 MariaDB 인스턴스가 ‘스토리지 가득 참’ 상태로 표시되는 이유는 무엇입니까?

7분 분량
0

Amazon Relational Database Service(RDS) for MySQL 또는 MariaDB 인스턴스가 ‘스토리지 가득 참’ 상태로 표시됩니다. 이러한 현상이 발생하는 이유는 무엇입니까? 그리고 DB 인스턴스에서 스토리지를 사용 중인 항목을 보려면 어떻게 해야 합니까?

간략한 설명

스토리지 가득 참 문제를 해결하려면 먼저, DB 인스턴스에서 사용된 총 공간을 분석해야 합니다. DB 인스턴스의 공간은 다음과 같은 용도로 사용됩니다.

  • 사용자가 생성한 데이터베이스
  • 임시 테이블
  • 이진 로그 또는 MySQL 대기 인스턴스 릴레이 로그(읽기 전용 복제본을 사용하는 경우)
  • InnoDB 테이블스페이스
  • 일반 로그, 느린 쿼리 로그 및 오류 로그

스토리지 공간을 사용하는 항목을 식별한 후에 스토리지 공간을 회수할 수 있습니다. 그런 다음, FreeStorageSpace 지표를 모니터링하여 공간이 다시 부족하지 않도록 방지할 수 있습니다.

참고: 사용 가능한 스토리지가 갑자기 감소하는 경우 SHOW FULL PROCESSLIST 명령을 실행하여 DB 인스턴스 수준에서 진행 중인 쿼리를 확인합니다. SHOW FULL PROCESSLIST 명령은 모든 활성 연결 및 각 연결에 의해 실행되는 쿼리에 관한 정보를 제공합니다. 오랫동안 활성 상태였던 트랜잭션을 검토하려면 INFORMATION_SCHEMA.INNODB_TRX 또는 SHOW ENGINE INNODB STATUS 명령을 실행한 다음, 출력을 검토합니다.

해결 방법

DB 인스턴스(사용자가 생성한 데이터베이스)에서 사용된 총 공간 분석

각 사용자가 생성한 데이터베이스의 크기를 찾으려면 다음 쿼리를 실행합니다.

mysql> SELECT table_schema, ROUND(SUM(data_length+index_length)/1024/1024/1024,2) "size in GB" FROM information_schema.tables GROUP BY 1 ORDER BY 2 DESC;

DB 인스턴스의 특정 데이터베이스에 대한 각 테이블의 크기를 확인하려면 다음 쿼리를 실행합니다.

mysql> SELECT table_schema "DB Name", table_name,(data_length + index_length)/1024/1024/1024 AS "TableSizeinGB" from information_schema.tables where table_schema='database_name';

MySQL 버전 5.7 이상 또는 MySQL 8.0 이상에서 더 정확한 테이블 크기를 얻으려면 다음 쿼리를 사용하십시오.
참고: information_schema.files 쿼리는 MariaDB 엔진에는 적용할 수 없습니다.

mysql> SELECT file_name, ROUND(SUM(total_extents * extent_size)/1024/1024/1024,2) AS "TableSizeinGB" from information_schema.files where file_name like '%/database_name/%';

데이터베이스 수준 및 테이블 수준에서 전체 스토리지 세부 정보와 조각화된 대략적인 공간을 구하려면 다음 쿼리를 실행합니다.
참고: 이 쿼리는 공유 테이블스페이스에 있는 테이블에는 적용할 수 없습니다.

mysql> SELECT table_schema AS "DB_NAME", SUM(size) "DB_SIZE", SUM(fragmented_space) APPROXIMATED_FRAGMENTED_SPACE_GB FROM (SELECT table_schema, table_name, ROUND((data_length+index_length+data_free)/1024/1024/1024,2) AS size, ROUND((data_length - (AVG_ROW_LENGTH*TABLE_ROWS))/1024/1024/1024,2)
    AS fragmented_space FROM information_schema.tables WHERE table_type='BASE TABLE' AND table_schema NOT IN ('performance_schema', 'mysql', 'information_schema') ) AS TEMP GROUP BY DB_NAME ORDER BY APPROXIMATED_FRAGMENTED_SPACE_GB DESC;

mysql> SELECT table_schema DB_NAME, table_name TABLE_NAME, ROUND((data_length+index_length+data_free)/1024/1024/1024,2) SIZE_GB, ROUND((data_length - (AVG_ROW_LENGTH*TABLE_ROWS))/1024/1024/1024,2) APPROXIMATED_FRAGMENTED_SPACE_GB from information_schema.tables
    WHERE table_type='BASE TABLE' AND table_schema NOT IN ('performance_schema', 'mysql', 'information_schema') ORDER BY APPROXIMATED_FRAGMENTED_SPACE_GB DESC;

이 두 쿼리에서 얻은 데이터베이스 크기를 기록하고 Amazon RDS의 Amazon CloudWatch 지표와 비교합니다. 그러면 데이터 사용으로 인해 스토리지 가득 참 문제가 발생했는지 여부를 확인할 수 있습니다.

임시 테이블

InnoDB 사용자 생성 임시 테이블 및 온디스크 내부 임시 테이블은 ibtmp1이라는 임시 테이블스페이스 파일에 생성됩니다. 때로 임시 테이블스페이스 파일이 MySQL 데이터 디렉터리의 ibtmp2로 확장될 수도 있습니다.

팁: 임시 테이블(ibtmp1)이 과도한 스토리지를 사용하는 경우 DB 인스턴스를 재부팅하여 공간을 해제합니다.

온라인 DDL 작업은 다음에 대해 임시 로그 파일을 사용합니다.

  • 동시 DML 기록
  • 인덱스 생성 시 임시 정렬 파일 생성
  • 테이블 재구축 시 임시 중간 테이블 파일 생성(임시 테이블이 스토리지를 차지할 수 있도록)

참고: InnoDB 테이블스페이스의 파일 크기는 MySQL 버전 5.7 이상 또는 MySQL 8.0 이상을 사용해서만 쿼리할 수 있습니다.

InnoDB 임시 테이블스페이스를 찾으려면 다음 쿼리를 실행합니다.

mysql> SELECT file_name, tablespace_name, table_name, engine, index_length, total_extents, extent_size from information_schema.files WHERE file_name LIKE '%ibtmp%';

전역 임시 테이블스페이스 데이터 파일이 차지하는 디스크 공간을 회수하려면 MySQL 서버를 다시 시작하거나 DB 인스턴스를 재부팅합니다. 자세한 내용은 MySQL 웹 사이트의 임시 테이블스페이스를 참조하세요.

InnoDB 테이블스페이스

때로 MySQL은 쿼리가 개입 중이기 때문에 제거할 수 없는 내부 임시 테이블을 생성합니다. 이러한 임시 테이블은 information_schema 내부의 "tables"라는 이름의 테이블에 포함되지 않습니다. 자세한 내용은 MySQL 웹 사이트에서 MySQL의 내부 임시 테이블 사용을 참조하세요.

이러한 내부 임시 테이블을 찾으려면 다음 쿼리를 실행합니다.

mysql> SELECT * FROM information_schema.innodb_sys_tables WHERE name LIKE '%#%';

InnoDB 시스템 테이블스페이스InnoDB 데이터 사전을 위한 스토리지 영역입니다. 데이터 사전과 함께 이중 쓰기 버퍼, 변경 버퍼 및 실행 취소 로그도 InnoDB 시스템 테이블스페이스에 있습니다. 또한 테이블이 시스템 테이블스페이스(테이블당 파일 또는 일반 테이블스페이스 대신)에서 생성되는 경우 테이블스페이스에 인덱스 및 테이블 데이터가 포함될 수 있습니다.

InnoDB 시스템 테이블스페이스를 찾으려면 다음 쿼리를 실행합니다.

mysql> SELECT file_name, tablespace_name, table_name, engine, index_length, total_extents, extent_size from information_schema.files WHERE file_name LIKE '%ibdata%';

참고: 이 쿼리는 MySQL 버전 5.7 이상 또는 MySQL 8.0 이상에서 실행됩니다.

시스템 테이블스페이스의 크기를 늘린 후에는 줄일 수 없습니다. 그러나 모든 InnoDB 테이블을 덤프하고 테이블을 새 MySQL DB 인스턴스로 가져올 수 있습니다. 대규모 시스템 테이블스페이스를 방지하려면 테이블당 파일 테이블스페이스 사용을 고려하세요. 자세한 내용은 MySQL 웹 사이트에서 테이블당 파일 테이블스페이스를 참조하세요.

Innodb_file_per_table을 사용하도록 설정하면 각 테이블은 자체 테이블스페이스 파일에 데이터 및 인덱스를 저장합니다. 해당 테이블에서 OPTIMIZE TABLE을 실행하여 (데이터베이스 및 테이블의 조각화에서) 공간을 회수할 수 있습니다. OPTIMIZE TABLE 명령은 테이블의 빈 복사본을 새로 만듭니다. 그런 다음, 이전 테이블의 데이터를 행별로 새 테이블에 복사합니다. 이 프로세스 중에 새 .ibd 테이블스페이스가 생성되고 공간이 회수됩니다. 이 프로세스에 대한 자세한 내용은 MySQL 웹 사이트에서 OPTIMIZE TABLE 문을 참조하십시오.

중요: OPTIMIZE TABLE 명령은 COPY 알고리즘을 사용하여 원본 테이블과 같은 크기의 임시 테이블을 생성합니다. 이 명령을 실행하기 전에 사용 가능한 디스크 공간이 충분히 있는지 확인합니다.

테이블을 최적화하려면 다음 명령 구문을 실행합니다.

mysql> OPTIMIZE TABLE <tablename>;

또는 다음 명령을 실행하여 테이블을 재구축할 수 있습니다.

mysql> ALTER TABLE <table_name> ENGINE=INNODB;

이진 로그

Amazon RDS 인스턴스에서 자동 백업을 활성화하도록 설정하면 이진 로그도 DB 인스턴스에서 자동으로 활성화하도록 설정됩니다. 이러한 이진 로그는 디스크에 저장되고 스토리지 공간을 사용하지만 모든 이진 로그 보존 구성에서 제거됩니다. 인스턴스의 기본 binlog 보존 값도 "Null"로 설정됩니다. 즉, 파일이 즉시 제거됩니다.

스토리지 공간 부족 문제를 방지하려면 Amazon RDS for MySQL에서 적절한 이진 로그 보존 기간을 설정하세요. 다음과 같이 mysql.rds_show_configuration 명령 구문을 사용하여 이진 로그가 보존되는 시간을 검토할 수 있습니다.

CALL mysql.rds_show_configuration;

또한 이 값을 줄여 더 짧은 기간 동안 로그를 보존함으로써 로그가 사용하는 공간의 양을 줄일 수 있습니다. NULL 값은 로그가 최대한 빨리 제거됨을 의미합니다. 활성 인스턴스에 대한 대기 인스턴스가 있다면 대기 인스턴스에서 ReplicaLag 지표를 모니터링합니다. ReplicaLag 지표는 활성 인스턴스 또는 대기 인스턴스의 릴레이 로그에서 이진 로그를 처리하는 동안 발생하는 지연을 나타냅니다.

활성 인스턴스에 대한 대기 인스턴스가 있다면 대기 인스턴스에서 ReplicaLag 지표를 모니터링합니다. ReplicaLag 지표는 활성 인스턴스 및 대기 인스턴스의 릴레이 로그에서 이진 로그 제거 중 지연을 나타냅니다. 제거 또는 복제 문제가 있다면 이러한 이진 로그가 시간이 지남에 따라 누적되어 추가 디스크 공간을 소비할 수 있습니다. 인스턴스의 이진 로그 수와 파일 크기를 확인하려면 SHOW BINARY LOGS 명령을 사용합니다. 자세한 내용은 MySQL 웹 사이트에서 SHOW BINARY LOGS 문을 참조하세요.

DB 인스턴스가 복제 대기 인스턴스 역할을 한다면 다음 명령을 사용하여 릴레이 로그의 크기(Relay_Log_Space) 값을 확인합니다.

SHOW SLAVE STATUS\G

MySQL 로그(일반 로그, 느린 쿼리 로그 및 오류 로그)

Amazon RDS for MySQL은 데이터베이스를 모니터링하는 데 사용할 수 있는 로그(예: 일반 로그, 느린 쿼리 로그, 오류 로그)를 제공합니다. 오류 로그는 기본값으로 활성화됩니다. 그러나 일반 로그 및 느린 쿼리 로그는 RDS 인스턴스의 사용자 지정 파라미터 그룹을 사용하여 활성화하도록 설정할 수 있습니다. 느린 쿼리 로그 및 일반 로그를 활성화하도록 설정하면 이러한 로그는 MySQL 데이터베이스 내의 slow_loggeneral_log 테이블에 자동으로 저장됩니다. 느린 쿼리, 일반 로그("FILE" 유형) 및 오류 로그의 크기를 확인하려면 데이터베이스 로그 파일을 보고 나열하면 됩니다.

느린 쿼리 로그 및 일반 로그 테이블이 과도하게 스토리지를 사용하고 있다면 수동으로 로그 테이블을 교체하여 테이블 기반 MySQL 로그를 관리합니다. 오래된 데이터를 완전히 제거하고 디스크 공간을 회수하려면 다음 명령을 두 번 연속으로 호출합니다.

mysql> CALL mysql.rds_rotate_slow_log;
mysql> CALL mysql.rds_rotate_general_log;

참고: 테이블은 로그의 정확한 파일 크기를 제공하지 않습니다. slow_loggeneral_log에 대한 log_output 값이 "Table"이 아니라 "File"이 되도록 파라미터를 수정합니다.

또한 Amazon CloudWatch를 사용하여 Amazon RDS DB 인스턴스를 모니터링하는 것도 모범 사례입니다. FreeStorageSpace 지표에 대한 CloudWatch 경보를 설정하여 스토리지 공간이 특정 임계값 아래로 떨어질 때마다 알림을 받을 수 있습니다. 마지막으로 CloudWatch 경보를 설정하여 FreeStorageSpace 지표를 모니터링하여 DB 인스턴스의 여유 공간이 부족할 때마다 알림을 받도록 합니다. 자세한 내용은, Amazon RDS의 여유 스토리지 공간을 모니터링하고, 스토리지가 가득 차는 문제를 방지하기 위해 CloudWatch 경고를 생성하려면 어떻게 해야 하나요?를 참조하세요.

또한 Amazon RDS 스토리지 자동 크기 조정 기능을 사용하여 용량을 자동으로 관리할 수도 있습니다. 스토리지 자동 크기 조정을 사용하면 데이터베이스 스토리지를 수동으로 확장할 필요가 없습니다. Amazon RDS 스토리지 자동 크기 조정에 대한 자세한 내용은 Amazon RDS DB 인스턴스 스토리지 작업을 참조하세요.


관련 정보

예상보다 많은 스토리지를 사용하는 Amazon RDS for MySQL DB 인스턴스 문제를 해결하려면 어떻게 해야 합니까?