Aurora MySQL 데이터베이스의 테이블이 전체 스토리지의 약 80%(약 400GB)를 소비하고 있었습니다. 오래된 데이터를 CSV 파일로 보관할 수 있었기 때문에 오래된 기록을 삭제하고 저장공간을 확보하기로 했습니다.
처음에는 기록을 삭제하면 저장공간이 확보될 줄 알았는데, 생각보다 복잡하더군요. 그래서 나중에 참고할 수 있도록 자세한 단계를 문서화하고 있습니다.
다음 쿼리를 사용하여 각 .ibd 파일의 크기를 확인할 수 있습니다.
SELECT file_name, ROUND(SUM(total_extents * extent_size)/1024/1024/1024,2) AS "TableSizeinGB" FROM information_schema.files GROUP BY file_name ORDER BY total_extents DESC;
참조: MySQL 문서
AWS re:Post에서는 테이블 크기를 확인하기 위해 다음 쿼리를 권장했지만 대상 테이블에 대한 결과는 첫 번째 쿼리에 비해 약 150GB가 작아졌습니다.
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';
AWS Support에 문의했을 때 information_schema.tables가 종종 부정확한 통계 값만 제공한다는 사실을 확인했습니다. 정확한 데이터를 얻으려면 information_schema.files를 사용하는 것이 좋습니다.
테이블 크기(390GB) 관련 정보는 information_schema.tables에서 가져온 것으로 통계자료이므로 정확하지 않을 가능성이 높습니다. 앞으로는 테이블 크기 정보를 검색하기 위해 information_schema.files를 사용하는 것이 좋습니다.
참조: AWS re:Post
다음 쿼리는 전체 데이터베이스 사용량을 확인합니다. 또한 정확성을 위해 information_schema.files를 사용합니다.
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/%';
저장용량을 확보하는 단계는 다음과 같습니다.
단순히 기록을 삭제해도 저장 공간이 확보되지 않습니다. 공간을 해제하려면 OPTIMIZE TABLE을 실행해야 합니다.
추가로 OPTIMIZE TABLE(또는 ALTER TABLE ... FORCE) 작업 중에 임시 중간 테이블 파일이 생성됩니다. Aurora에서는 이러한 임시 파일이 로컬 스토리지에 저장됩니다. 로컬 스토리지의 양은 인스턴스 클래스에 따라 다릅니다. 제 경우에는 db.r6g.xlarge 인스턴스의 로컬 스토리지가 80GB밖에 되지 않아 삭제된 레코드의 크기에 비해 부족했습니다. 그래서 임시로 db.r6g.8xlarge(640GB)로 확장했습니다.
참고: 테이블 최적화
참고: Alter Table
참고: InnoDB 온라인 DDL 공간 요구 사항
참조: Aurora MySQL 임시 저장소
250GB 정도의 레코드를 삭제한 후 OPTIMIZE TABLE 실행에는 약 130분(약 2시간)이 소요되었습니다. OPTIMIZE TABLE은 테이블을 잠그기 때문에 가동 중지 시간을 예약하거나 사용량이 적은 시간에 이 작업을 수행해야 할 수도 있습니다. 참고로 모든 기록을 삭제하는데 총 15시간 정도 걸렸고, 며칠에 걸쳐서 정리했습니다.
위 내용은 불필요한 데이터를 삭제하여 Aurora MySQL 스토리지 최적화의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!