Amazon Aurora 클러스터에서“사용 된 볼륨 바이트”가 항상 증가하는 이유는 무엇입니까?


11

내가이 아마존 (AWS) 오로라 DB 클러스터, 모든 일을 그가 [Billed] Volume Bytes Used증가하고있다.

시간에 따른 사용 된 CloudWatch 지표

테이블을 사용하여 (클러스터의 모든 데이터베이스에서) 모든 테이블의 크기를 확인했습니다 INFORMATION_SCHEMA.TABLES.

SELECT ROUND(SUM(data_length)/1024/1024/1024) AS data_in_gb, ROUND(SUM(index_length)/1024/1024/1024) AS index_in_gb, ROUND(SUM(data_free)/1024/1024/1024) AS free_in_gb FROM INFORMATION_SCHEMA.TABLES;
+------------+-------------+------------+
| data_in_gb | index_in_gb | free_in_gb |
+------------+-------------+------------+
| 30         | 4           | 19         |
+------------+-------------+------------+

총 : 53GB

그렇다면이 시점에서 왜 거의 75GB가 청구됩니까?

일반 MySQL 서버의 ibdata 파일이 절대 축소되지 않는 것과 같은 방식으로 프로비저닝 된 공간을 확보 할 수 없다는 것을 알고 있습니다. 나는 괜찮습니다. 이것은 문서화되어 있으며 수용 가능합니다.

내 문제는 매일 청구되는 공간이 증가한다는 것입니다. 그리고 나는 75GB의 공간을 일시적으로 사용하지 않을 것이라고 확신합니다. 그런 식으로해야한다면 이해할 것입니다. 마치 테이블에서 행을 삭제하거나 테이블을 삭제하거나 데이터베이스를 삭제하여 사용 가능한 저장 공간이 재사용되지 않는 것처럼 보입니다.

AWS (프리미엄) 지원 팀에 여러 번 문의 한 적이 있는데 그 이유에 대한 설명을 얻을 수 없었습니다. 삭제 된 데이터가 여전히 롤백 세그먼트에 유지되지 않도록 ( 테이블 당) 많은 테이블에서
실행 하거나 InnoDB 기록 길이를 확인 하라는 제안을 받았습니다 ( MVCC ) 롤백 세그먼트가 비 었는지 확인하기 위해 인스턴스를 다시 시작하십시오. 그들 중 누구도 도움이되지 않았습니다.OPTIMIZE TABLEfree_spaceINFORMATION_SCHEMA.TABLES

답변:


19

여기에는 여러 가지가 있습니다 ...

  1. 각 테이블은 자체 테이블 스페이스에 저장됩니다.

    기본적으로 Aurora 클러스터 (이름 default.aurora5.6)에 대한 매개 변수 그룹은을 정의합니다 innodb_file_per_table = ON. 이는 각 테이블이 Aurora 스토리지 클러스터에서 별도의 파일에 저장됨을 의미합니다. 이 쿼리를 사용하여 각 테이블에 어떤 테이블 스페이스가 사용되는지 확인할 수 있습니다.

    SELECT name, space FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES;

    참고 : 나는 변화를 시도하지 않은 innodb_file_per_tableOFF. 아마도 도움이 될 것입니다 ..?

  2. 테이블 스페이스를 삭제하여 사용 가능한 스토리지 공간은 재사용되지 않습니다.

    AWS 프리미엄 지원 인용 :

    성능 및 내결함성을 높이기위한 Aurora 스토리지 엔진의 고유 한 설계로 인해 Aurora에는 표준 MySQL과 동일한 방식으로 테이블 당 파일 공간을 조각 모음하는 기능이 없습니다.

    불행히도 Aurora는 표준 MySQL과 마찬가지로 테이블 공간을 축소 할 수있는 방법이없고 VolumeBytesUsed에 포함되어 있기 때문에 조각난 공간이 모두 청구됩니다.
    Aurora가 표준 MySQL과 동일한 방식으로 삭제 된 테이블의 공간을 회수 할 수없는 이유는 테이블의 데이터가 단일 스토리지 볼륨으로 표준 MySQL 데이터베이스와 완전히 다른 방식으로 저장되기 때문입니다.

    Aurora에서 테이블 또는 행을 삭제하면이 복잡한 설계로 인해 Auroras 클러스터 볼륨에서 공간이 회수되지 않습니다.
    적은 양의 스토리지 공간을 회수 할 수 없기 때문에 Auroras 클러스터 스토리지 볼륨의 추가 성능 향상과 Aurora의 내결함성이 크게 향상됩니다.

    그러나 낭비 된 공간 중 일부를 재사용하는 모호한 방법이 있습니다 ...
    다시 한 번 AWS 프리미엄 지원을 인용하십시오.

    전체 데이터 세트가 특정 크기 (약 160GB)를 초과하면 재사용을 위해 160GB 블록으로 공간을 확보하기 시작할 수 있습니다. 예를 들어 Aurora 클러스터 볼륨에 400GB가 있고 160GB 이상의 테이블이있는 경우 Aurora 160GB의 데이터를 자동으로 재사용합니다. 그러나이 공간을 확보하는 데 시간이 오래 걸릴 수 있습니다.
    한 번에 많은 양의 데이터를 확보해야하는 이유는이 규모로는 사용할 수없는 표준 MySQL과 달리 엔터프라이즈 규모의 DB 엔진으로서 Auroras의 고유 한 설계 때문입니다.

  3. 최적화 테이블은 사악합니다!

    Aurora는 MySQL 5.6을 기반으로하기 때문에 OPTIMIZE TABLE로 매핑되어 ALTER TABLE ... FORCE인덱스 통계를 업데이트하고 클러스터형 인덱스에서 사용되지 않은 공간을 확보하기 위해 테이블을 재구성합니다. 효과적으로을 (를) innodb_file_per_table = ON실행하면 OPTIMIZE TABLE새 테이블 스페이스 파일이 생성되고 이전 테이블 스페이스 파일이 삭제됩니다. 테이블 스페이스 파일을 삭제해도 사용중인 스토리지가 비워지지 않으므로 OPTIMIZE TABLE항상 더 많은 스토리지가 프로비저닝됩니다. 아야!

    참조 : https://dev.mysql.com/doc/refman/5.6/en/optimize-table.html#optimize-table-innodb-details

  4. 임시 테이블 사용

    기본적으로 Aurora 인스턴스 (이름 default.aurora5.6)에 대한 파라미터 그룹은을 정의합니다 default_tmp_storage_engine = InnoDB. 즉, TEMPORARY테이블을 생성 할 때마다 모든 일반 테이블 과 함께 Aurora 스토리지 클러스터에 저장됩니다. 즉, 해당 테이블을 보유 할 새 공간이 프로비저닝되어 사용 된 총 VolumeBytes가 증가합니다.
    이에 대한 해결책은 충분히 간단 default_tmp_storage_engine합니다 MyISAM. 매개 변수 값을로 변경하십시오 . 이렇게하면 Aurora가 TEMPORARY인스턴스의 로컬 스토리지에 테이블 을 생성하게됩니다 .
    참고 : 인스턴스의 로컬 스토리지는 제한되어 있습니다. Free Local Storage인스턴스의 스토리지 용량을 확인하려면 CloudWatch 의 지표를 참조하십시오. 더 큰 (비용이 많이 드는) 인스턴스에는 더 많은 로컬 스토리지가 있습니다.

    참고 : 아직 없음; 현재 Amazon Aurora 설명서에는 이것을 언급하지 않았습니다. AWS 지원 팀에 문서를 업데이트하도록 요청했으며, 필요한 경우 답변을 업데이트하겠습니다.


1
이것은 훌륭한 답변이며, 요크 는 몇 가지 주요 경고 사항입니다. 다행 이네요.
ceejayoz

같게. 공간이 회수되지 않으면 MySQL에서보고 된 크기가 54GB 인 데이터베이스의 경우 DB 서버 한 대가 최대 300GB 인 것을 알 수 있습니다. 예 : 로그 테이블, 인덱스 테이블 등).
geerlingguy

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.